Creating an Enterprise Architecture

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.

The Myth of an Enterprise-Wide, Project-Deep Architecture

It is not reasonable to expect to put in one massive, collective effort to produce an enterprise architecture that:

  • Specifies all levels of detail, from business processes through technology selections and application functionality.
  • Covers all individual projects (project-deep).
  • Spans the entire enterprise (enterprise-wide).

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.

Milestone-Driven Process

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.

click to view at full size

Figure 1.3 Stages of enterprise architecture adoption

Getting from Current State to Future State

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).

click to view at full size

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.

Value of an Iterative Enterprise Architecture

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:

  • Elimination of unnecessary requirements from the plan Because business units and individual project teams know that there will be subsequent releases, they do not feel compelled to "throw in everything but the kitchen sink" into the first version. Each version can remain tightly focused on key issues while rapidly delivering value to the organization.
  • Ability to respond to feedback on each release Requirements and priorities for the "complete" architecture often change once a working version of the architecture is in place and some of the infrastructure and business application development issues are solved.
  • Discovery of answers Many organizations abhor uncertainty so intensely that they attempt to magically convert ignorance to knowledge by stating something as fact, when in reality it is unknown. This self-deception can lead to poor decisions. It can be avoided by using versioned releases and by operating under the principle of "Get it out there; get it validated; don't make it up."

Value of a Dynamic Process

An enterprise architecture is never static. It is an organic system in which each element has the following life cycle:

  • Creation (some functionality, low stability).
  • Development (growing quickly, not fully realized).
  • Maturity (running smoothly, stable).
  • Decline (struggling to maintain pace).
  • Death (retirement, disposition).

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:

  • Understanding which elements of the enterprise architecture must be changed.
  • Recognizing where those elements are located in the architecture life cycle.

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.

Philosophy of Versioned Releases

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:

  • Smaller is better than larger.
  • Understood is better than unknown.
  • Progress is better than promises.

Reactive and Proactive Flows

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:

  • Define business processes.
  • Identify applications and information.
  • Implement technology.

click to view at full size

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:

  • Analyze technology.
  • Identify applications and information.
  • Define business processes.

click to view at full size

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.

Maintaining Focus

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.

Enterprise Architecture and Individual Projects

The enterprise architecture, as illustrated in Figure 1.7, coordinates every project the organization undertakes. The enterprise architecture defines opportunities and constraints that:

  • Achieve consistency.
  • Leverage resources.
  • Align infrastructure and application systems with business goals across the enterprise.

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.

click to view at full size

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:

  • Proposed applications are aligned with broader business objectives.
  • The targeted technology is among those supported.
  • Applications can be operated efficiently after a technology is deployed.

The enterprise architecture establishes the business and technological domains within which individual projects should be designed and deployed.

Planning While Building and Building While Planning

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.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182 © 2008-2017.
If you may any questions please contact us: