Models Help Predict Enterprise Architecture

Because enterprise architecture needs to be able to design changes before they are actually put into place during the build, test, and deploy stages of a project, it is a prime candidate for predictive modeling. Not surprisingly, then, each of the activities of BTM makes good use of this trait by utilizing business, process, and technology models as important tools for developing enterprise architecture. Together, these three types of models make up a complete enterprise model, which mimics the behavior of end-to-end enterprise architecture.

Like other models in general, enterprise models are composed of four primary building blocks: elements (things), attributes (descriptions of things), relationships (links to other things in the model), and cross-links (links to other things in separate models). Elements within the model can be organized (into parent-child hierarchies, for example), tied together to imply causal relationships, and cross-linked with external elements from other models in order to create concrete connections. This final point is an extremely important one for the purposes of BTM. Any technique that promises to close disconnects between business, process, and technology must clearly rely upon a mechanism to enforce alignment. By cross-linking individual elements in discrete models together, BTM accomplishes this feat, and ensures that the ripple effects of any specific decision are anticipated throughout each modeling environment.

Consider an example: An IT analyst creates an element in a technology model that represents a new software package he or she is installing. Beneath this package, the analyst creates child elements that describe the functional requirements for the package. Each of these functional requirements is then linked back to the individual processes in the process model that it supports. If a change needs to be made to the package down the road, whoever is considering the modifications can trace links back to the processes that would be impacted, and anticipate the full ramifications of the decision before making the final call.

This ability to change models and to dynamically view ripple effects both within an individual model and between multiple business, process, and technology models is the primary reason why conventional drawings aren't sufficient for designing enterprise architecture. In order to simulate the full impact of any individual decision, the design needs to respond dynamically when models are modified. If designing enterprise architecture was an afterthought to IT projects, static drawings would be fine. But because enterprise architecture needs to be developed during the design stage, only predictive models ”business, process, and technology models ”can get the job done.

The process of designing enterprise architecture and carrying out the activities of BTM begins when the project team identifies an as-is current enterprise model (which includes business, process, and technology) that describes the end-to-end architecture as it exists today. Then, the team leverages the capabilities of predictive modeling to develop multiple to-be enterprise scenario models (also called patterns), each of which previews potential changes to the architecture. By comparing the current enterprise model and the enterprise scenario models, team members can discover practical opportunities for IT to benefit the company, and ultimately use impact analysis to make better decisions about which opportunities to pursue . Once these opportunities have been identified, the final enterprise scenario model becomes the basis for an IT project that implements these changes. After the IT project has been rolled out, the final enterprise scenario model is folded into the current enterprise model to make sure that the changes become part of a new, updated enterprise model (see Fig. 4.4).

Figure 4.4. During the activities of BTM, companies perform impact analysis to evaluate multiple scenarios and select the appropriate option for implementation

Notice that before you can follow this sequence of events, you first need to have an accurate, current enterprise model. There are two ways to go about developing this model. The first is to charter a team headed by senior executives to review the current enterprise model (or create it from scratch if necessary) after regular, but reasonably long intervals (one to three years is typical). These reviews should be timed to coincide with reviews of corporate strategy, so that changes in strategy ripple down immediately into the model. The second method for developing the current enterprise model is by accumulation. As projects finish, final scenario models are folded into the updated enterprise model, or become the updated enterprise model altogether if one doesn't yet exist. Over time, and as projects touch upon different areas of the business, the effect will be to flesh out a complete current enterprise model piece by piece.

One final note about the current enterprise model is that it provides a powerful vehicle for capturing and enforcing enterprise standards. Since each enterprise scenario model is patterned after the current enterprise model, design standards such as standard process flows, approved application packages, and technical standards are automatically passed along to each enterprise scenario model, and in turn to the implementation projects that make them a reality. This helps enterprise architects to maintain tactical control over how projects are implemented, a subject that Ch. 8 discusses in more detail.