We have examined the four perspectives of the MSF Enterprise Architecture Model (Business, Application, Information, and Technology), and we have looked at some of the difficulties organizations encounter when using an enterprise architecture process. We have looked at the four enterprise architecture objectives (to be integrated, iterative, actionable, and prioritized), and we have pointed out the artificial walls that business and IT people often construct around themselves. At this point, these questions often arise: "How do we accomplish these goals? What steps do we need to take, and in what order?" As one exasperated IT manager exclaimed, "Just tell me where to download the Project file and Excel templates so I can get started!"
Unfortunately, it's not that simple. The enterprise architecture process is more than just a list of steps for achieving a goal. Rather, enterprise architecture is built on certain key principles that allow organizations to tailor the architecture to their unique business needs. Keeping the following principles in mind ensures that an enterprise architecture design will be both valued and valuable.
It is not reasonable to expect to put in one massive, collective effort to produce an enterprise architecture that:
Despite how unreasonable these expectations are, many approaches to enterprise architecture attempt the impossible. They use a horde of architects and consultants who closet themselves away for years at a time and then deliver "the answer." The problem with this approach is that by the time the answer is delivered, it is out of date. In attempting to define all things for all people, this approach severely compromises the value of any decisions.
We recommend recognizing these limitations when going into the process and taking appropriate measures to build the enterprise architecture in successive iterations. This approach allows the architecture to provide business value quickly, allows the gathering of feedback from actual use, and allows adjustments to be made through subsequent iterations.
The MSF Enterprise Architecture Model promotes an iterative, milestone-driven process based upon a series of versioned releases to advance the organization to the desired future state. As shown in Figure 1.3, the organization can pass through different stages, which we will discuss in more detail later, as it adopts an enterprise architecture for development projects.
Figure 1.3 Stages of enterprise architecture adoption
Organizations are constantly forced to re-create their business processes and rewrite their business rules. Business application systems must be equally adaptable and responsive to these changes. Successful architectural teams must move beyond the "big bang" approach to enterprise architecture. We have found that teams employing an ongoing, iterative approach—implicitly assuming that the architecture is never finished but remains a work-in-progress—have greater long-term success.
The enterprise architecture is established by framing the definition of an organization's current state (as-is) and where it wants to be in the future (to-be). Teams establish priorities and then undertake individual projects in order to incrementally move toward that future state. As they deliver systems and services, they constantly update the enterprise architecture plan based on feedback and an ongoing assessment of business and technology changes (see Figure 1.4).
Figure 1.4 Evolution through multiple versions
Stating that the enterprise architecture is never finished can kill both the hope of ever reaching implementation and the satisfaction of reaching a milestone. Applying the concept of versioned releases prevents this from happening. Each release is a part of, or a continual improvement in, the overall capabilities of the organization, and each release is a logically coherent and achievable milestone.
The concept of versioned releases recognizes that most enterprise architectures are too big to effectively produce at one time. It is better to prioritize the implementation of successive product versions based on business needs and then deliver completely working subsets of the envisioned future state in rapid succession.
The versioned release approach has several advantages:
An enterprise architecture is never static. It is an organic system in which each element has the following life cycle:
To make appropriate changes to an enterprise architecture, constant attention must be paid to changes in the business and technology environment so that teams can respond accordingly by:
Versioned releases allow adjustment over time, responding in a controlled manner to changes in the environment. Implementing small elements of the overall architecture in successive releases allows for better management and budgeting, while still providing something useful at each release.
For versioned releases to work, the team must produce a first release of the architecture and then frequently produce subsequent releases that are directly responsive to the changing needs of the organization.
We can summarize the approach of versioned releases as follows:
One of the most significant problems that IT may encounter in developing an enterprise architecture is that all of the fundamental business processes have been defined and established by the time IT becomes involved. As a result, the business may miss significant opportunities to use existing technology more effectively or in new ways.
Developing an enterprise architecture is not just a reactive activity. A reactive flow is a one-way flow of decisions and input that determines how technology will be implemented in the organization. As shown in Figure 1.5, a reactive flow includes the following steps:
Figure 1.5 A reactive flow of decisions and input
Reactive flow is important, but it should be coupled with a proactive flow of input from the technology side to the definition of business processes. As shown in Figure 1.6, a proactive flow includes the following steps:
Figure 1.6 A proactive flow of decisions and input
Technology by itself doesn't provide value, but applying technology in innovative ways to business opportunities can provide important value. Deciding where and how to apply technology is another area where business and IT cooperation is essential. Electronic commerce is a good example of a proactive flow beginning with the Technology Perspective.
The MSF Enterprise Architecture Model focuses IT efforts on defining and prioritizing core processes that drive the business and that are therefore critical to the organization. Support for these processes should form the foundation of the enterprise architecture. Many architectures existing today have grown without proper focus. The result is an increase in activities that are more supportive of peripheral and administrative processes than of the core processes that truly drive the business. Core processes are left languishing and are often never adequately addressed.
By focusing first on the core processes of critical areas, the MSF Enterprise Architecture Model maintains the proper perspective as the architecture is first established and then begins to evolve. Each versioned release is driven by the need to be implementable. This requirement reduces the time spent on "ivory tower" dreaming, and recognizes the need to look to the future and plan accordingly.
The enterprise architecture, as illustrated in Figure 1.7, coordinates every project the organization undertakes. The enterprise architecture defines opportunities and constraints that:
The enterprise architecture should therefore be the basis for IT strategic planning. It helps define the domain of application systems and infrastructure development by addressing core business processes and the technologies available to automate them. This big-picture view is especially critical when applications will run concurrently or share resources.
Figure 1.7 Coordination of individual projects by the enterprise architecture
The enterprise architecture is more than a planning tool. It also defines the development and operation of applications and the deployment of infrastructure. This can greatly benefit the organization by assuring that:
The enterprise architecture establishes the business and technological domains within which individual projects should be designed and deployed.
Organizations by their very nature often dictate top-down decision-making, especially where it relates to establishing business policy or strategic planning. When developing an enterprise architecture, the organization can impose standards from above, but as shown in Figure 1.8, the architecture should also be refined and expanded from below, using input from specific individual projects.
Figure 1.8 The enterprise architecture planning structure
It was once conventional wisdom to construct a model of the entire enterprise before proceeding with individual IT projects. To assure consistency of data definitions, interfaces, and business processes across the enterprise, each project would be neatly carved out of the enterprise model. However, this approach to architecture planning often broke down because it assumed that all the details were attainable and known at the start of the planning process. We now know from experience that this assumption is false. The enterprise architecture should not be defined in a vacuum, but should reflect information discovered by actually building solutions. Using versioned releases that incorporate feedback from teams and users must result in progressive refinement of the architecture. Otherwise, a rapidly changing business environment could quickly overtake an organization's ability to both complete models at the enterprise level and deploy projects before business changes make the models invalid.