Automating Technology in BTM

So far, this chapter has concentrated on what a technology model is and what types of information are generally captured in one. But to really paint a complete picture of how technology automation helps to align business and technology, this chapter also needs to explain how companies go about automating technology during the activities of BTM.

Technology automation follows the same general pattern as the other activities of BTM: The team starts out by examining the current technology model, which is an as-is snapshot of the applications and systems that exist today. Then they generate technology scenario models that correspond to each of the process scenario models inherited from process optimization. Next, they perform a gap analysis between the current model and each scenario to determine the new applications and systems that are required to pursue each. This analysis results in a final scenario model, which becomes the basis for the full implementation project, and eventually gets rolled into a new, updated technology model.

Within this general framework, however, there are four key tasks that the team responsible for technology automation needs to focus upon: Develop requirements that link processes to applications, design systems to the specifications required by each application, develop technology standards and reuse applications and systems, and select vendors and packages.

Develop Requirements That Link Processes to Applications

Since each of the technology scenario models needs to align with at least one of the process scenario models developed during process optimization, it makes sense that the first major task in technology automation is to develop requirements that cross-link individual applications to processes. This general charge is a specific manifestation of requirements management, a larger process that also encompasses change management, prioritization, and other aspects of development that come into play during both the design and implementation stages of the project.

The cornerstone for alignment between process and technology is the assumption that every application can be traced back to the processes it supports. In some cases, such as an online sales platform that supports the sales process or a call center application that supports customer service requests , this is self-evident. But even applications that don't obviously support individual processes follow this paradigm. For example, it may not be clear at first glance how the information encapsulated in a business intelligence (BI) application ”which slices and dices vast quantities of information to identify trends within the business ”is a natural fit to automate a process. However, if we consider that decisions are key components of process models, and that BI can be crucial for making informed decisions, we can still create direct cross links between business applications and particular elements in the process model that they support. In other words, even when applications don't "automate" per se, they can still be associated with requirements and in turn , processes, to maintain alignment.

Design Systems to The Specifications Required by Each Application

The second key task that happens during technology automation is the design of supporting systems for each application. Generally speaking, the connection between applications and systems is supplied by specifications, which represent the specific technology conditions that need to be in place in order for the application to run. These specifications, which are often captured as attributes within the model, can take many forms, depending on the specific needs of each application. For example, one enterprise application may require a database that complies with the Java Database Connectivity (JDBC) standard, while another may need a database package from Vendor Bravo, while still another may require a proprietary database that, in turn, requires a particular hardware or software platform on which to run.

At first glance, the specifications that link applications and systems look a lot like the requirements that play a similar role for processes and applications. There is a major distinction, however, that comes from the fact that specifications account for purely technical considerations, while requirements, by virtue of their connection to processes, are more oriented towards business. In addition, specifications differ from requirements in that they can connect applications to systems and also systems to systems. For example, a CRM package that shows up in the applications layer may require a Structured Query Language (SQL) database (a system), which may in turn require a particular operating environment or hardware configuration (also a system).

Develop Technology Standards and Reuse Applications and Systems

Established technology standards commonly show up as specifications that cross-link applications and systems. This points to another of the major tasks that makes up technology automation: Developing technology standards and reusing applications and systems wherever possible. This, of course, is closely related to the general principle of reusing knowledge and assets that Ch. 3 discusses. It makes sense to mention standards and reuse explicitly during this discussion of technology automation, since this is the activity of BTM in which this task plays the most prominent role.

Most IT professionals are familiar with common technology standards such as Extensible Markup Language (XML), Business Process Modeling Language (BPML), or Open Database Connectivity (ODBC). While these are powerful tools for achieving reuse, formal standards such as these aren't the only way that companies can achieve reuse during technology automation. In addition, technology professionals can capture almost any design decision in the form of a standard such as component libraries; packages; technologies for networking and data; and even logical rules and conditions which developers are required to follow. The logical extension of this capability is the establishment of virtual platforms ”complete standard operating environments for which the company's applications can be written. Ever since the beginning of the struggle between centralized and decentralized IT functions, companies have been challenged to set technology standards and to make sure that dispersed teams adhere to them. By giving centralized enterprise architects a mechanism to capture their standard virtual platforms and disseminate them as templates for far-flung projects, technology automation helps to mediate the struggle between standardization and specialization that tears many IT departments apart.

Standards and Sourcing

"At GE, we have a strong sourcing function that we try to get involved very early, and there are incentives for doing so because they're very good at what they do and they can get incredible leverage with vendors. Traditionally, there's been a tension between technology and sourcing where technology guys want to buy X and the sourcing guys want to buy Y. But we just don't seem to have a lot of those problems because we've streamlined the sourcing process with a couple types of technology standards.

On the one hand, there are some non-negotiable things that we all need to adhere to, and violating them is tantamount eventually to resignation . These are very serious and they're communicated quite well. Typically, they have to do with security or certain core infrastructure functions that are necessary for interaction with systems across the business unit. I'm not going to replace the mail system that I operate with a different mail system, for example, because the Chairman will eventually send email to everybody in the firm and it won't go through and then I'll be in deep trouble. These are kind of easy.

Then there are standards that we say are 'highly recommended', and they're justified either because we have favorable pricing or we have a lot of intellectual assets to go along with that vendor. These standards are wired into sourcing, so when I show up and say I want some random server to run this application, sourcing's initial response may be 'we get this great deal with another vendor because we've standardized on them'. In this case, it's to my advantage to take advantage of the standards. They'll be cheaper in the long run for me because I'll either have more intellectual property at my disposal or more support at a corporate level than I would have if I chose another solution.

So the sourcing and enabling functions that have a vested interest in controlling cost are wired into the decisions for technology standards. You cannot buy a Macintosh; you can buy a Dell and you can have the Dell as long as it's this model loaded with this software and that's what you're going to get. And that's a sourcing and financial decision, not a religious technology decision."

” Chris Perretta, CIO, GE Capital, Card Services

Select Vendors and Packages

The final task that IT project teams have to tackle during technology automation is the selection of off-the-shelf vendor/package solutions when they elect to buy rather than build application and system functionality. (In fact, the build, buy, or outsource decision itself is a crucial part of technology automation.) BTM doesn't advocate any method for selecting appropriate vendors. Instead, it provides key insights for performing impact analysis to determine the right vendor fit. Since it is rare for even leading vendors to meet every requirement for a project out of the box, the challenge while selecting vendors is fundamentally one of making smart trade-offs between competing priorities, both positive and negative. So, for example, one package may support an inventory management process that is similar to what the project team defined during process optimization, but would require the team to purchase a new application server. Another package might not match the inventory management process all that well, but wouldn't require any new technology purchases to integrate with the existing technology architecture.

Since selecting the best match for vendor/package solutions can mean the difference between on-time , on-budget completion of a project and unmitigated disaster, making smart trade-offs during vendor selection should clearly be a top priority. BTM, by virtue of its interconnected approach to business, process, and technology design helps to promote smart, holistic decision-making about vendors, so that the team responsible for selecting vendors/packages can visualize the end-to-end ramifications of choosing each solution. This is, of course, a specific manifestation of impact analysis, which is described in conjunction with predictive modeling in Ch. 3.