InformationWeek

Technology How-To: Plan Your Enterprise Architecture

Thinking about where your organization wants to be is the first step in making sure it gets there

By Paul T. Cottey and Richard A. Chang
Issue date: June 24, 1996

Many businesses are working harder just to maintain their current market positions. The reason may be ineffective information technology resulting from mergers, acquisitions, or individual development efforts. Instead of helping a company succeed in a competitive marketplace, an enterprise's information technology may be w orking against its business goals. With appropriate technology planning at an enterprise level, a business can more effectively use its IT assets--people, skills, information, technology, applications, etc.--for business gain. Enterprise architecture planning comes into play before technology solutions are implemented. It determines where an organization is and where it would like to be, then gives the business a roadmap to get there. It ensures that an enterprise's technology investments are aligned with its strategy--and the processes and organizational structures needed to realize that strategy. This planning process, therefore, requires a synthesis and alignment of the technologies deployed in an enterprise, the people who make up the enterprise, their processes, and business strategies.

Enterprise architecture planning aligns IT visions with those of the enterprise and puts current and planned initiatives into a larger context. The goal is to make appropriate decisions on deploying IT resources and map out a program for enterprise change.

Planning an enterprise architecture lets you address current and planned initiatives as a portfolio of assets rather than as individual items. In the same way that you manage a stock portfolio for certain attributes--total investment, level of risk, etc.--you can manage IT as a portfolio to the defined goals of the business. By treating IT assets as a coordinated whole, the overall investment, level of risk, and flexibility to change can be managed and made to work for the good of the enterprise.

Enterprise architecture planning differs from traditional systems planning in scope and purpose. Many companies develop systems to meet the specific business needs in one area. Unfortunately, this creates a legacy of systems that do not interoperate. These "silos," or vertical solutions, and their associated architectures often duplicate efforts, deploying the same functionality and information differently.

Also, since enterprise architecture planning attempts to t ie the IT strategy tightly to business objectives, it avoids a common situation in traditional systems planning where each application must justify each part of its infrastructure--people and skills, new or modified processes, and technology.

Where You Are Now
To develop an enterprise architecture plan, start by assessing the relative health of your current business systems as objectively as possible. You can determine each application's relative health by weighing functional and technical criteria, and by applying subjective measures such as talking with the users and maintainers of the systems.

Functional health includes how well the application does what it needs to do, how well it measures whether a system delivers current and future functionality, how easy it is to learn, and how responsive it is to changes in the business environment.

Technical health is how well the application takes advantage of available technologies. The age of a system is often used to gauge this health, but there's more to it. Other influences include the programming language used (C, Cobol, or Assembler), current and future support for the platform from the vendor, required maintenance effort, and support for dates in years after 2000 in data structures.

Two Matrices
The end result of enterprise architecture planning is an assessment of this relative health of business systems versus their impact on the business, and an assessment of this impact versus the relative effort to address required changes.

This assessment is represented in the two matrices shown on p. 80. The "business impact" label on these matrices refers to the relative impact a group of applications has on the business' imperatives. Thus, in the first matrix, although asset management applications may be important to an enterprise that provides financial services to its customers, the ability to get a customer's current balance from the financial systems applications has a relatively larger impact on the direction in which th e business is heading.

Further, the second matrix suggests that to address the unhealthy state of financials, the company needs to deploy a common chart of accounts, a financial data warehouse, and a financials package. Also, it would take less effort from a people/organization, process change, and technology perspective to implement a common chart of accounts than to build or install a financial system.

"Quick" initiatives in the lower-left quadrant--such as E-mail in the example shown--require less effort to address, but have commensurately lower impact on the business. Projects that fall into the lower-right quadrant are relatively difficult to address and provide lower business impact. These initiatives may be maintained or played down over time.

Principles Of Planning
The diagram on p. 82, although fairly simple, provides the highest-level view of planning an enterprise architecture:

The "current state of business" refers to the current state of the enterprise, inclu ding how technologies are used, where they are deployed, how the enterprise is organized from IT and business perspectives, the health and capabilities of the current solutions, etc.
The "current initiatives" are ongoing or planned IT initiatives, including current design and development efforts, joint ventures, and strategic plans.
The "current future state" is where the enterprise will end up if the current plan or method of doing things continues unaltered.
The "desired future state" is where the enterprise would end up if its vision were completely implemented.
The "vision gap" is the difference between where the enterprise is headed and where it would like to be.
The "necessary initiatives" are the efforts required to move an enterprise toward its vision. They are the basis for a "transition plan" to change the enterprise's direction toward its desired future.

This framework is iterative because the desired future state is a moving target. Business st rategies or the business environment may change and cause the desired future state to change with them. By taking a view that enterprise architecture planning influences the desired future state, the iterations are refinements to an overall strategy. Coordination between the development of architecture releases and the evolution of the enterprise transition plan includes adding initiatives and refocusing or halting current initiatives. It also ensures that consistent views of the business are delivered together. To be effective, this framework must deliver business value quickly, add incremental value through each iteration, and be used and accepted by the enterprise's business leaders.

But if each release moves the enterprise toward its vision, why do we never reach the vision? Each release builds a base for the next release and provides incremental value, but each release should impart change that's significant enough to cause the enterprise to reevaluate subsequent releases. Thus, if a release were ext remely successful, the timing of other releases may be moved up, or other changes may be desirable. For example, when first-quarter sales results show tremendous gains in territories using applications, plans to roll out notebook computers and applications to a sales force over the next year may be moved up to the next few months.

What follows is a discussion of the key elements of the chart on p. 82:

Current State Of Business
The first step in determining an enterprise architecture plan has more to do with business than technology. This step develops a business blueprint to gain a thorough, explainable, high-level view of key business processes--those in place as well as those needed to realize the business' vision--the information that supports them, and their key characteristics.

A deep analysis of the whole enterprise requires too much time and effort--and would be ineffective. Staying at a high level, focusing on architecturally significant items, and consolidating similar busines s processes keeps the task manageable. The resulting business blueprint is a cornerstone to a plan that can deliver value in a timely manner.

Besides being a concise, compelling statement of where you are and where you want to go, the business blueprint also includes the business imperatives--the factors critical to the success of the enterprise--that guide the enterprise architecture planning. One imperative might be, "We will maintain our share of current markets and open new ones."

You must establish a clear vision before enterprise architecture planning can proceed. There are many ways to determine this vision, from executive fiat to long-running strategy planning sessions. No one way is best.

This business blueprint is key to determining an asset's business impact so that you can correctly place it on the Y axis of the matrices shown on p. 80. Creating a business blueprint in a reasonable amount of time requires a small, dedicated team that possesses both business and techno-logy skills. This team must also have authority to make key decisions.

Once you understand the current business environment, then attempt to better understand the current application and technology environment.

The blueprint assesses the enterprise environment and addresses questions such as: How successful is the busi- ness? How well is IT contributing to the business' success? How well is IT managed? What are the guiding technology principles? What are the current IT expenditures and initiatives?

For example, are individual groups buying PCs every month in groups of 10 when you could get volume discounts by pooling those orders? Does the enterprise have five different initiatives, each claiming to set the strategic direction for Internet computing?

To develop answers, you need to compare the current state of all IT assets with the business imperatives. For example, if the business imperative is eliminating internal barriers to cooperation, but constraints in your current systems prevent having information wh en
and where you need it for your customers, you should identify that deficiency in this baseline assessment.

The baseline provides the X axis of the business impact/health matrix on p. 80. It determines which assets meet the current and future business and technology requirements, and which need attention to continue being viable.

The tie between the business vision and the technology guiding principles is a tight one. To support the technology principle of giving sales representatives access to information in the field, the business people must be convinced that giving notebooks to sales people is valuable.

Current Future State
Having developed a thorough understanding of the enterprise's current environment, next determine where the enterprise would end up if you made no changes to current initiatives. Then compare that result with where the enterprise wants to end up. Is there a gap?

Desired State

To give form to the vision of the enterprise's future as arti culated in the business blueprint,
develop application and infrastructure blueprints that define the desired future state of the enterprise. An application blueprint maps the business impact/health matrix to the business impact/effort matrix. It defines what needs to be done to the high-priority items--those appearing in the top-left quadrant of the business impact/health matrix--to move them to a healthier state, and, therefore, to deliver on the business vision.

The application blueprint defines the business, application, and information needed to implement the business vision articulated in the business blueprint. Like the business blueprint, an application blueprint should be defined at a level that can be easily understood by your business leaders.

User requirements are expressed through "use cases" and the service characteristics expected for the application blueprint to be useful. A portion of a use case for a customer service representative might say, "The representative's telephone rings, and prior to answering, the touchscreen shows the customer's name, address, payment method, and account balance, and whether the customer typically takes advantage of special this-day-only offers. If the answer to the last item is affirmative, the representative recommends any special unadvertised offers and punches in the order."

The use case, which shows how IT could be applied to make an asset healthier, leads to the development of a high-level information and application distribution approach, as well as the identification of delivery vehicles.

A delivery vehicle is a collection of technology components--including hardware, software, standards, and processes--that provides the foundation for delivering business systems. The key distinction between an enterprise delivery vehicle and typical technical architecture is that delivery vehicles encompass the needs of multiple applications, including applications that have not yet been built.

As a vision of the application of technology across the en terprise, the application blueprint is linked closely to the infrastructure blueprint, which describes the technology needed to support the application vision.

The infrastructure blueprint, therefore, provides the vision of the technology environment. It defines the functionality of the technology environment, determines how technology will be physically implemented, and determines the components of the technology infrastructure. These components often are viewed as part of their delivery vehicles because it is easier to understand how software distribution and an object request broker, for example, fit within a transaction processing delivery vehicle than it is to understand why they are needed in the abstract.

The infrastructure blueprint incorporates the guiding technology principles, which help the organization choose among multiple technology options. These principles provide the starting point for IT strategies, priorities, and initiatives within the enterprise, and may include the enterprise's statement of direction on buying versus building systems or on the preferred languages and environments.

When you are in uncharted waters, you need to have the proper authority in order to bring about change.

Vision Gap
The difference between where the enterprise is going (current future state) and where the enterprise would like to be (desired future state) is the vision gap. This gap may have developed from a new understanding of business needs or some combination of events, but it is no less real whatever the cause. If the vision gap is not closed, it will lead to missed opportunities, frustrated users, wasted resources, and dissatisfaction with IT.

Transition Plan
The transition plan works to close the vision gap. To construct a transition plan, develop a prioritized list of initiatives to undertake--as articulated or envisioned in the application and infrastructure blueprints--and note the dependencies among them. The transition plan is essentially a result of the busi ness impact/effort matrix; that is, what needs to be done and what effort is required to do it. Effort includes everything from actual cost and time to how much change the organization must endure.

The transition plan defines the enterprise's architecture at each release, and defines what will be produced at each release, which make up the enterprise's project definitions and its business cases. Each release moves the enterprise toward its vision.

To complete the transition plan, you need to complete the X axis of the business impact/effort matrix. This information describes the difficulty in delivering a new or modified solution and its associated architecture. By reviewing and understanding the initiatives plotted on the matrix, you can seek opportunities for quick wins and long-term, strategic wins.

The sum of these initiatives forms the enterprise's technology and application release strategy and focuses its efforts on the most critical tasks.

To succeed, enterprise architecture planning m ust look for quick wins to prove its value. Because planning seems like more work than just building, these quick wins reassure the business people that it is worth the extra effort.

Fortunately, architecture planning is an iterative process. We say "fortunately," because the iterations allow you to find the quick wins through a first pass. Then, once others in the organization are convinced of the value of planning, subsequent iterations can drill out additional detail or cross into additional areas.

Paul T. Cottey is a senior manager, and Richard A. Chang is an associate partner at Andersen Consulting in Northbrook, Ill., where they direct the firm's worldwide enterprise architecture practice.

Comments on this story?

http://www.informationweek.com