What is a Technology Model?

Since modeling is an inherently technical exercise, it's anything but surprising that IT in has become fertile ground for a variety of models. Two of the most popular are object models (which help to develop new software applications) and data models (which describe how data is distributed, communicated, and translated between applications and systems). Although these two types of models (and still others such as network diagrams) can be useful and certainly have an important role to play in the IT department, it's important to recognize that they're not necessarily the best fit for technology automation. This is because many of the important design characteristics that have a profound effect upon whether business and technology are aligned happen at a higher level than that addressed by object and data models. For example, object modeling becomes useful only after a project team has determined what type of software to build, a decision which itself has a profound impact upon alignment and must be dealt with during BTM. Before drilling down to make the detailed decisions that are typical of object and data modeling, IT project teams need a mechanism to address the overall technology environment, make general decisions about the applications and systems that will help meet the project's goals, and get buy-in from their business audience. This device, called the technology model, is the cornerstone of technology automation.

In general, technology models contain two layers :

- The Applications Layer includes the business software that directly supports certain processes. Some examples of applications from this layer include customer relationship management, enterprise resource planning, business intelligence, and supply chain management.

- The Systems Layer includes the underlying technology that is necessary to implement and support the business software in the applications layer. The systems layer can include servers (e.g., application server, web server, integration server, etc.), software (e.g., browsers, middleware), data (e.g., databases, data warehouses), and networks.

The Applications Layer

The first of these layers, the applications layer, focuses on aspects of the technology architecture that provide direct support for business processes from process automation. The key cross-link between processes and applications is provided by requirements, which can be traced either back to individual activities in the process model or forward to the specific applications in the technology model that support this activity. The act of generating these requirements is shared between process optimization and technology automation, since the process involves give-and-take between each activity. Each application in this layer should also include some crucial attributes that describe it including standards it adheres to, possible vendors , and whether the application exists today or is proposed for the future.

In general, the applications layer serves three important purposes. The first is to help flesh out application functionality, or how requirements are supported by the components that make up each of the applications. One of the major challenges of linking processes to technology is that the two rarely match up one-to-one: a discrete business process may touch multiple applications and vice versa. For example, an insurance agent may directly or indirectly interface with distinct financial, document management, and customer support applications all during the course of processing a claim ”which is considered a single, discrete process. This mismatch makes it difficult for line-of-business employees , who tend to view their function in terms of the business processes for which they are responsible, to communicate effectively with IT specialists and developers, whose world view is framed by the distinct applications that they develop and deploy. This disconnect is magnified by today's technology environment, which (because it emphasizes object orientation and distributed computing over monolithic, process-based systems) separates user experience from the application functionality that is split between multiple building blocks of code. Going forward, analysts and researchers predict that Web services (where enterprise applications are broken down into discrete chunks of code that communicate over the Internet using open standards) will become the dominant paradigm for enterprise computing, a development that is sure to exacerbate this challenge even further, and make the cross-links between processes and application functionality, such as those illustrated in Fig. 7.1, even more critical.

Figure 7.1. Example requirements for the sourcing component of a procurement application in the applications layer

In fact, this trend towards application distribution provides a good segue into the second purpose of the applications layer, which is to help integrate the various systems that make up many technology architectures. Although detailed, nuts-and-bolts integration (such as the data-mapping and translation features provided by EAI software) is too detailed for technology automation, the application layer should provide a mechanism for visualizing where to share information at an application level, and for making sure that new applications are interoperable with existing platforms (see Fig. 7.2). This is especially true during gap analysis, where the project team works to design new applications that need to share crucial data with legacy systems.

Figure 7.2. An example view of application integration between internal platforms and an external business partner

Another time when application integration is crucial is when companies need to share information with customers, suppliers, and other entities outside of the enterprise. One of the great promises of the Internet revolution was to make it easier for business partners to electronically share information. But to actually accomplish this, partners need to visualize the information that should flow across company boundaries, and how it integrates with the applications on the other side of the gap. (An example of this inter-enterprise integration is when a sourcing application dispatches a purchase order to a supplier's order-processing platform.)

The final purpose of the applications layer is to visualize application flow, or how the applications will behave from the perspective of the end-user. Oftentimes, graphical user interface (GUI) mockups can be important tools here, because they allow users to walk through a simulation of applications, and suggest improvements and changes as they go. In fact, the application flow is most valuable for this very reason: It helps non-technical business representatives (whether they are executives responsible for giving the project a green light or end-users of the platform) visualize how the applications will work before they are irrevocably put into place (see Fig. 7.3).

Figure 7.3. An example application flow illustrates a basic GUI mockup for a buyer logging into a procurement application

The Systems Layer

The technology model also includes a systems layer that captures the underlying hardware, software, data, and networks that are necessary for implementing and integrating the applications described in the applications layer. For reinforcement's sake, remember that an application refers to business software such as CRM or ERP that directly supports business processes. A system ”even though it may only be software ” differs because it supports an application or another system. Some common examples of systems include middleware, hardware, networks, and data sources; some common attributes in the systems layer describe things like technology standards, configurations, and restrictions.

Within the systems layer, elements can be ordered according to either logical or physical views. The logical view (of which Fig. 7.4 is an example) partitions the systems into tiers according to the general function that they provide. While BTM doesn't prescribe any definitive set, system tiers generally include things like a presentation tier (e.g., Web browsers, PDA's, and dedicated devices through which end-users interface with applications), an integration tier (e.g., middleware, messaging, and enterprise application integration servers that help exchange information between disparate applications), a data tier (e.g., databases, data warehouses, and legacy data), and so on.

Figure 7.4. An example logical view of the systems layer that includes five tiers, including a presentation tier with a browser and PDA

The physical view, on the other hand, illustrates how systems are physically distributed between machines that are connected to networks, similar to a network topology (see Fig. 7.5). This perspective is valuable for IT developers, network engineers , and support personnel, who oftentimes are challenged to maintain and upgrade physical systems while making sure that any changes they make don't have unforeseen consequences elsewhere in the technology architecture.