BUSINESS ENTERPRISE ARCHITECTURE MODELING

by Ken Orr, Senior Consultant, Cutter Consortium; in collaboration with Bill Roth and Ben Nelson

We have to be very careful about making even small changes in IT today because they can impact the entire organization.

-- Transportation Division Director

All of a sudden, enterprise architecture (EA) is a very hot activity. Most large enterprises today have some sort of EA program, and billions of dollars are being spent around the globe on enterprise architectures in order to help organizations manage their vast IT expenditures and exposures in a more rational fashion. An interesting question is, why now? Why is it that enterprise architecture is suddenly so hot? Why are enterprise architects in such demand?

We think the primary reason enterprise architecture has become so interesting is that, at some point during the past few years, IT made a quantum leap into a new domain, a domain in which IT assets are increasingly important to the overall success (or failure) of large enterprises. Suddenly, people in large organizations around the world are discovering just how dependent they are on IT systems and IT infrastructure as well as how interdependent all the various pieces of IT are with one another and with users inside and outside the organization. Most importantly, people are seeing that IT enables new things to be done, things that were not possible before. Once again, we see the truth behind the old saw "The whole is greater than the sum of its parts."

Enterprise architecture, as its name implies, is all about high-level thinking and high-level design. IT and communications have become so complex and so interrelated in large organizations, and enterprise data has become so fundamental, that it is no longer possible to design, build, and install major systems in isolation. Someone has to be thinking about the big picture, about how all the pieces fit together, because the big picture has become such a significant issue.

This Executive Report discusses a new way of looking at enterprise architecture that encompasses both advanced and traditional design concepts. The EA framework that we propose here is called BEAM, short for Business Enterprise Architecture Modeling. While this approach builds on many of the historical enterprise architecture frameworks, it is in many ways a different approach, a much more business- and data/information-driven strategy.

THE THREE FACES OF ENTERPRISE ARCHITECTURE

Because of its newness in the marketplace, there is confusion surrounding what enterprise architecture is exactly and its value to business and IT management. A recent Cutter Consortium Executive Report [8] laid out the major strategies for enterprise architecture that are popular in North America. ¹ Those three approaches are:

1. Technology-driven enterprise architecture

2. Business (process)-driven enterprise architecture

3. Federal Enterprise Architecture (FEA)

Since that report was published, a great deal of practical work has been done to bring these three different approaches into better alignment. While these three approaches still represent three different views of what enterprise architecture is about, there is greater consensus today about how they complement each other. The Cutter report made a strong case for business-driven enterprise architecture as the key to the long-term success of EA programs regardless of whether the enterprise is public or private. In the time since the report was published, the enterprise architecture discipline has moved to reinforce this conviction.

Enterprise architecture is now at a period of consolidation and reassessment. More and more organizations are extracting value from their EA programs at a variety of levels. These organizations are increasingly aware of how critical enterprise architecture is to their enterprises over both the short and long term. And there is also a whole new set of organizations that are just adopting enterprise architecture and trying to put it into practice. Both of these classes of users need guidance. Those just getting started need advice on where to begin, what kinds of skills they need, what steps they should take, and so on. Those well underway need guidance on how to extend the impact and value of their EA program. This report is intended to address both of these audiences.

BEAM -- AN EXTENDED EA FRAMEWORK

In a world of acronyms, adding yet another is not likely to be greeted with universal applause; however, acronyms do seem to help people remember and differentiate between different approaches. We chose BEAM as an acronym because it captures the business-process orientation that largely drives our strategy and because "physical beams" are structural members of buildings and houses, so BEAM makes sense in an architectural setting as well.

As with any good framework, creating BEAM involved tying together a number of different ideas: mental models, process models, diagramming approaches, and organizational strategies. Also, like any good methodology, much of BEAM is simply applied common sense. We do not apologize for that fact. Indeed, we have all been involved in business, systems, and technology for quite a long time and, as a result, have found things that work well in doing systems planning, requirements, and high-level design, and we have discovered that these things also seem to work well in doing EA.

But BEAM is no panacea; rather, it is a practical approach to doing something very important. At base, enterprise architecture is about getting people -- all sorts of people -- within the organization to think in both broader and longer terms about IT, IT infrastructures, and the core data and systems that IT supports. During the past 30 or 40 years, computers and communications have played a major part in restructuring most, if not all, major organizations around the world. Today, organizations are now significantly different in the ways they operate and are managed -- much different than they were just a decade or two ago. Information no longer just circulates within organizations, it literally beams across the organization at light speed.

But while computers and communication have revolutionized the way organizations operate, the systems, connections, and hardware involved in this amazing transformation are largely invisible to most who use it and even more invisible to those who make the key decisions about how many resources should go into IT and for what projects.

With the coming wave of ever more powerful wireless devices, the underlying IT infrastructure will be even harder to visualize. But IT, particularly as it relates to an enterprise's computer and communications infrastructure and to its core (mission-critical) applications, can hinder as well as facilitate management strategies and plans. Poor IT strategies can create arthritic organizations just as it can create agile ones.

In the same sense that modern cities and nations depend upon their fundamental infrastructure investments in utilities, transportation, communications, and so on, so too do large enterprises depend upon their IT infrastructure investments. As a result, savvy management increasingly realizes that it will have to invest both wisely and well if it is going to be competitive in the 21st century. Enterprise architecture, then, is a tool for leveraging technology to make things happen faster and at less cost.

THE ELEMENTS OF BEAM

Like any good approach to solving large problems, BEAM involves several interrelated components. The most important of these components, discussed in detail in this section, are:

• A basic Enterprise Systems Feedback Model (ESFM)
  
  
• A new way of considering business-technology alignment and innovation
  
  
• An extension to the classic Zachman Framework
  
  
• Treating the role of enterprise architect as a "committee of skills"
  
  

The Enterprise Systems Feedback Model

There are literally hundreds of ways of thinking about enterprises. The one underlying BEAM is the Enterprise Systems Feedback Model, which is derived from cybernetics (systems thinking). The idea is that an enterprise can be thought of as a component in a larger environment; what the enterprise does is convert resources from sources into products and services for some given market or set of customers. Figure 1 shows these components connected in such a feedback structure.

Figure 1 -- The Enterprise Systems Feedback Model. 2

In this model, the enterprise is represented as a black box that takes in "resources" and produces "products" or "services." These products or services, in turn, are used by customers or clients to "do something" (that something we refer to as "product usage"). As a result of producing these products and services, there is also "product feedback," which deals with how well the product meets its internal requirements, and "customer (or usage) feedback," which deals with how well the product meets the customer's expectations. If we were to apply this model to the auto business, for example, product feedback could be thought of as the "Six Sigma" (quality) part of the model, and the customer (usage) feedback might be referred to as the "J.D. Power's" (customer relationship) part of the model.

ESFM brings two important ideas to the study of enterprise architecture: (1) all enterprises are in business to "make something" or "provide some service," and (2) they survive by adding value.

One of the great things about the ESFM is that it works both in the public and the private sector. Later, when we discuss the US government FEA model, we will be able to show the necessary correspondences between the ESFM and FEA models without any difficulty.

While the ESFM may seem too simple for those who think of the organization as a complex thing, it is useful for getting people to think of their organization as a system component itself. In a systems feedback sense, IT is all about systems and infrastructure. If one cannot understand how those systems and infrastructure relate to the business goals and objectives, it is exceedingly difficult to tie IT decisions back to critical business decisions.

Benson and Parker's Square Wheel: Business and Technology Alignment and Innovation

A second conceptual model that is extremely important to BEAM is Bob Benson and Marilyn Parker's "square wheel" model [1]. Figure 2 shows this model, with the left side of the diagram representing the business domain, and the right side representing the technological or technology domain. In the business domain, there are two components: business planning and business operations. Similarly in the technology domain, there are also two components: technology planning and technology operations. The square wheel gets its name from the sequence of linkages between these various components.

Figure 2 -- Benson and Parker's square wheel [1].

Between business planning and business operations, there is the "organize" function. Between business operations and technology operations there is an "align" function. Between technology operations and technology planning, there is the "opportunity" function. And, finally, between technology planning and business planning, there is the "impact" (innovation) function.

For the most part, technology management experts have focused almost exclusively on the organizing and aligning functions to bring business and IT closer together. They tended to leave out the link between technology operations and technology planning. It might have made sense 20 or 30 years ago to have most of IT's focus be on aligning technology with the business as it existed, but today, technology is changing the way business is done everywhere. Key initiatives, even entire business marketplaces, have been created in the past 10 or 15 years that leverage new technologies to deliver goods and services in previously unthinkable ways.

Benson and Parker have provided us, then, with an important new way of thinking about management communication. One of the most difficult problems confronting business and IT managers today is communication. Historically, in most organizations, top IT management has not always been part of the highest-level business decision making. Benson and Parker's square wheel shows just how important including IT management is and will be in making decisions about the enterprise's IT assets -- what systems to attack, what technologies to invest in, and so on.

Increasingly, organizations rely on their IT infrastructure and systems to produce value. In order to be competitive, public and private organizations will have to become much more agile. They will need to continuously improve their business processes, find the right data to solve management problems, and connect the right people both inside and outside their organizations via real-time collaboration. And organizations will have to be increasingly "transparent." Their systems will have to be documented and auditable. New requirements like those imposed by the US Sarbanes-Oxley Act focus increased scrutiny on the role that IT systems play in today's management of large organizations.

Extending Zachman's Framework

A previous Cutter Executive Report [6] discussed the need to extend the Zachman Framework using urban/transportation planning rather than building architecture as the basic model for enterprise architecture. This extension has proved extremely useful, both in doing enterprise architecture and in explaining it to business and IT management.

Recently, a number of other influential organizations have begun to speak in similar terms. For example, Microsoft now refers to what it calls its "Metropolis" metaphor [5]. This model reflects a new thinking on the part of high-level enterprise architecture developers and consultants. Similarly, Disney has begun to speak of the "building code metaphor" in which it refers to "master plans" and "building codes" as the key elements [3].

We feel the urban/transportation planner is a more realistic analogy than a classic building architect. Urban planners are interested not just in individual buildings (systems) but in the entire region (enterprise). Urban planners develop long-range documents that promote the well-being and happiness of all the residents (users). To do this, they create land-use plans, negotiate with developers, and help set building codes (architectural standards) -- building architects do none of these activities. In this regard, urban planners do a great many things for cities and counties that enterprise architects must do for the enterprises and divisions if they are to be successful.

Transportation planners are involved in planning the most important infrastructure in any city or region -- the highway/public transportation infrastructure that moves the region's goods, services, and people. That physical infrastructure is both very expensive and very difficult to put in place. Moreover, highways and light rail are extremely hard to modify once they are constructed. So transportation planners must be exceedingly careful and detailed in their planning. Transportation planners routinely look 20 or 30 years into the future when thinking about major arterial roads, intersections, and projects; likewise, enterprise infrastructure planners are going to have to plan further and further ahead. If enterprise architecture is to become a mature discipline, it will have to model itself after other mature disciplines like urban and transportation planning. In developing the BEAM framework, we have worked hard to create a framework that makes sense and that parallels similar disciplines.

The BEAM Enterprise Architect: A "Committee of Skills"

Architect (Gk. arkhitekton "head builder," from arkhi- "head" + tekton "builder, carpenter.")

-- Oxford Dictionary of English Etymology (Oxford University Press, 1966)

Increasingly, our work brings us into contact with a wide variety of EA organizations -- each different but with a similar set of problems and constraints. One issue that continues to concern EA managers is determining the kind of personalities, skills, and training that are needed to do enterprise architecture work.

In putting together the BEAM framework, we have come up with some clear ideas about roles and skills that are needed in an EA group. What we have found, for example, is that the "complete enterprise architect" doesn't exist. Rather, we concluded that there is a "committee of skills" that a rounded enterprise architecture team should contain. These skills include:

• Urban planning skills
  
  
• Transportation planning skills
  
  
• Building inspection skills
  
  
• County agent skills
  
  
• Building architect skills
  
  
• Librarian skills
  
  

The remainder of this section examines each of these skill sets as they apply to BEAM.

Urban Planning Skills

The first set in the committee of skills is urban planning. Urban planners work in an environment in which they must try to reach a consensus among several competing parties. Urban planning involves working with developers, elected officials, and community representatives to further the entire community. As it turns out, this is much the same job that enterprise architects face every day in the business-IT workplace.

Urban planning skills involve planning, research, negotiation, and, most importantly, communication. Planners must be technical enough to understand the dynamics of urban growth and decay and sensitive enough to get warring parties to sit down and negotiate workable, economically viable solutions. Enterprise architects must be able to get user management, IT management, and vendors to reach solutions that work in both the short and long term.

Transportation Planning Skills

In real urban or regional environments, the highway engineers are often responsible for the most profound changes. In the US, the period from the mid-1950s to the 1980s, for example, was dominated first by the development of the interstate road system and then by the "ring roads" that increasingly encircled major cities. These changes brought about profound revolutions in our cities and suburbs. Interstate roads funneled people further and further away from inner cities; and ring roads, in an attempt to allow interstate traffic to bypass the central cities, made high-speed, light-rail public transportation almost impossible, furthering the deterioration of the central core.

So transportation planners have an enormous burden; they have to be able to decide today where people and businesses will be located decades from now. To do this, they look at all the possible information: economic data, demographic information, as well as changes in technology and lifestyle.

In enterprise architecture, enterprise infrastructure architects take on the same role as the transportation planners. They must look at what IT infrastructure exists today; try to imagine how and where people will be operating in the future; and then come up with approaches that best provide a communication and computer infrastructure that is both reliable and secure. To do this job well, enterprise infrastructure architects must be good at detailed planning, but they must also be highly skilled at research, forecasting, and, again, communication.

Building Inspection Skills

In the world of urban planning/zoning/building codes, it is the building inspector who takes on the role of enforcer. The building inspector is responsible for reviewing plans, checking blueprints, and periodically visiting building sites to see that the plans and all the requisite building codes are followed.

In enterprise architecture, the enterprise project architects and enterprise project architecture review teams play the role of building inspector. In most mature EA organizations, this process is one of the key ways in which enterprise architecture directly affects the long-term success of an enterprise's IT management. Since enterprise architecture is seen in many organizations as a technology-control function, this is not that surprising. In the better EA groups, this inspection process is pushed further and further down in the organization, so that the people who understand the local environment are also the ones charged with ensuring that individual projects meet enterprise standards.

One of the material differences between enterprise project architects and building inspectors in the real world is that building inspectors operate in an environment that has much more specific industry support. Because urban planning and building code inspection have been around for decades, the rules and procedures are well worked out. In addition, building codes are normally a reflection of industry standards, and, therefore, there are industry training classes available to help practitioners. For example, if you want to be a licensed electrician or a licensed plumber, you must attend specific classes and perform specific tasks to get your license. Moreover, before you can be licensed, you must have served as an apprentice for a period of time. With all of these standards in place, the building inspection department does not have to assume responsibility for training practitioners; it only has to monitor their work.

The enterprise architecture situation is quite different. EA standards and regulations are still evolving at a rapid rate, and, because there are few people in the organization that understand those standards and regulations, training, counseling, and mentoring are especially important issues. And while there is a certain amount of knowledge transfer that takes place as a result of project-review sessions, in the long haul, enterprise architecture will fail to take hold in most organizations unless significant up-front training is provided.

County Agent Skills

Between the end of the US Civil War and the beginning of World War I, agriculture in the US changed dramatically. Before the Civil War, American agriculture was basically on par with the rest of the world. However, by the beginning of World War I, American agriculture was clearly ahead of everyone else. Students of knowledge management credit this amazing leap forward to two major innovative programs: (1) the land-grant and (2) the county extension service/county agent.

As the name implies, land-grant colleges and universities came into existence through an act of the US Congress, which allowed states to sell large blocks of publicly owned land and earmark the monies obtained from these sales for funding colleges and universities devoted to research and teaching in the practical arts, especially agriculture and engineering. Some of the greatest universities in the country were created as land-grant schools (e.g., Ohio State University, Texas A&M, and Kansas State University). These schools conducted research in agriculture, pioneering such breakthroughs as hybrid seeds, new animal breeding techniques, and new pest control strategies. This led to huge amounts of information to help farmers and ranchers produce more at less cost.

But the research produced by land-grant colleges did not automatically change farming in the US. At the time, many farmers were illiterate, and even if they had been of the mindset to try new things, few were aware of the availability of new research information. This is where the county extension service and the county agent came into play.

The county extension service was created by the US Department of Agriculture to provide technical support for farmers and ranchers. In turn, the county extension service created the position of county agent, whose job was to review the research coming out of the land-grant colleges, internalize that information, and then take it out and demonstrate it to the farmers and ranchers. This proved to be amazingly successful. Most farmers and ranchers of that time were very practical people (as they are now), with little time to spare. County agents brought the information to them and showed them how to use whatever it was that the latest research recommended.

Today, county agents would be classified as mentors or field consultants. Their job in enterprise architecture is to take plans, standards, and rules to the individual developers and users and to explain and demonstrate them. In general, this means communicating the following: (1) the standards and rules; (2) the reasons for those standards; and (3) how to use those standards and rules. Like farmers and ranchers, developers are also practical people with little time to spare. Hands-on training helps people understand how to leverage enterprise architecture ideas, and mentoring links that information to real-world circumstances.

Over the past few years, we have been promoting the "enterprise architect as county agent." This idea has met with nearly unanimous interest and support. More and more organizations are coming to understand that for enterprise architecture to take root in an organization, there needs to be more than just EA project review and audit sessions. People need to know why and how these standards came into being and how to use them in the most efficient and practical ways.

Building Architect Skills

In BEAM's committee of enterprise architecture skills, the skills of a true building architect are still necessary. In the real world of large-scale construction, building architects are responsible for working with owners/developers, coming up with detailed plans, and then staying with the project throughout the construction, being responsible for quality and change control. This is a role for which there is a direct correlation in enterprise architecture, especially on large projects.

In a recent Cutter Executive Report [7], I described several issues that play a part in the failure of very large projects. I discussed the essential role a real, competent project architect plays, or should play, on these projects. I argued that, in the real world, building architects do the design and then stay with their projects over the entire length of a given construction cycle. Here we recommend that enterprise project architects do the same -- that they be responsible for detail requirements and design and then be charged with quality control and change control of those designs.

Throughout history, building codes and design standards have almost always been the result of disasters. One only has to think of the famous 1906 San Francisco earthquake and fire or the Tacoma Narrows Bridge disaster in 1940 ³ to see the point. Indeed, in one issue of the Society of Mechanical Engineers publication, there was a discussion of the organization's history, and it turned out that the organization came into being as a direct result of boilers blowing up and trestles falling down during the latter part of the 19th century. As a result of these disasters, engineering societies were formed, and politicians set up rules that included professional testing and licensing. Something similar will eventually happen with software, but until that occurs, the closest thing we have is training and certification.

Librarian Skills

The final set of skills that we recommend as being important for a serious EA group is that of a classic librarian. People who study library science learn a number of important things: how to analyze information, how to classify that information, and how to help people retrieve information from a large organized store.

In this world of information overload, being able to analyze, index, and retrieve huge amounts of information is increasingly important. For more than a decade, IT professionals have pursued the idea of reuse, but reuse has proved largely elusive. Part of the reason is that while the exact component that we might need in a given circumstance already exists, finding it can be a major undertaking; if people think that finding something will take too long, they are more likely to build their own.

Currently, enterprise architecture breaks down into business, data/information, application, and technology domains. Each of these domains requires skills for which librarians are trained. Over the next few years, we expect to see increased demand for these skills in enterprise architecture groups.

The Committee of Skills in Operation

In operation, our committee of skills may take several different forms. In a large organization, each skill set may end up being a separate section of an overall EA group. In this kind of environment, people tend to specialize by their specific roles. In turn, people with unique skills get classified into specific jobs.

In small organizations, individuals often wear more than one hat. For instance, an enterprise architect in a small group may have to play the role of urban planner one day and building inspector the next. Or he or she may have to be infrastructure planner one day and county agent the next. In small organizations, circumstances define what has to be done, so flexibility is a must.

Enterprise architecture is such a new field that it will be some time before we have enough experience to know exactly what the roles and responsibilities will look like. Until that time, the committee of skills is a good way to think about how we staff and manage enterprise architecture.

THE BEAM PROCESS

BEAM is a systematic approach for developing enterprise architecture for any size organization. It involves the following five major phases:

1. Strategic intentions

2. Business architecture

3. Data/information/content architecture

4. Application architecture

5. Technology architecture ⁴

For small organizations, a high-level version is usually sufficient to give them enough information to do their IT planning and management. For large organizations, BEAM has two major phases: a high-level version followed by a number of lower-level architectures for each major part (business area) of the business.

This may appear somewhat confusing at first. What we do is use the process in Figure 3 first to do a high-level "enterprise" version of our enterprise architecture (only about 10 to 15 diagrams) and then, depending on the organization, develop lower-lever versions by "business area." In practice, these business-area EAs typically evolve out of day-long joint application development (JAD) sessions with 15 to 25 users. At the end of this second cycle with the business areas, we have found it necessary to go back and rework the enterprise-level version as well.

Figure 3 -- The BEAM approach.

In each of the following sections, the same general framework shown in Figure 3 is used to drive the activity.

Strategic Intentions

The first step of BEAM, gathering strategic intentions, involves understanding the general direction of the enterprise as seen by top management, taking into account external forces. In an ideal world, enterprise architecture operates with a full-blown, three-to-five-year enterprise strategic plan. In those organizations where such a plan does not exist or where such plans cannot be divulged, IT planners must derive what they see as the organization's strategic intentions from their perception of top management's direction over time, including such items as budgets and changes in organizational structure as well as any explicit initiatives.

Over the long haul, it is possible to come up with a reasonable set of strategic intentions by looking at other similar-sized organizations in similar industries. Strategic intentions are normally updated as a result of interviews with top executives and facilitated sessions with executive committees.

Business Architecture

The next major step in BEAM involves developing the business architecture. Of the four major enterprise architecture components, the business architecture is by all measures the most critical, since it ties the basic and advanced business functions to the other pieces of the enterprise architecture. Within BEAM, business architecture is made up of three subareas:

1. Business context

2. Business value maps

3. Business processes

Business Context

A key subprocess within the business architecture step is the creation of one or more context diagrams such as the one shown in Figure 4. These diagrams show the major organizational units, business partners, and systems connected by arrows that represent the messages (transactions, documents). These diagrams provide a quick, easily understandable map of the primary interactions between parts of the organization and its business partners. The development of a good business context diagram provides a consistent framework for thinking about an organization's inputs, outputs, and outcomes.

View Figure 4 »

Figure 4 -- A business context diagram.

In practice, more than one working context diagram is often produced. And although it often takes more than one session to produce an enterprise context diagram all participants can agree upon, the effort helps to create a shared understanding of the flow of information within the enterprise. One of the most significant benefits of the context-diagramming process is that it allows everyone involved to express their knowledge and to reach a common understanding of how the pieces of the organization communicate with one another and with outside entities. Business context diagrams also provide a starting point for the business value maps and business process diagrams.

Business Value Maps

A process can be seen as a "value chain." By its contribution to the creation or delivery of a product or service, each step in a process should add value to the preceding steps.

-- Geary A. Rummler and Alan P. Brache,Improving Performance [11, p. 45]

The business value map can be traced back to the work of Michael Porter of the Harvard Business School. In 1980, Porter published the first of a set of diagrams that he called business value diagrams (see Figure 5) [10]. The most important feature of the diagrams was the idea that all enterprises have (1) a set of primary activities that are the fundamental value-adding processes by which enterprises produce their sets of products and/or services and (2) a set of supporting activities that provide resources and management for the primary activities (e.g., finance, HR, procurement, budgeting, IT management).

Figure 5 -- Michael Porter's business value diagram [10].

What is most important to get right in developing a business value map is the set and sequence of the primary activities. In Figure 5, the primary activities are taken from what Porter considers the basic sequence within a manufacturing organization: inbound logistics, operations, outbound logistics, marketing and sales, and, finally, service. Porter's insight in thinking of organizations as input/output processes allowed many organizations, for the first time, to look at their operations from the very highest level and to see not only their organizations' internal functions flow, but also how their organizations fit into an even larger business context -- a supply chain.

This simple but elegant way of representing complex businesses touched off a flurry of business reengineering processes in the 1980s and 1990s. With the advent of the Internet, it also provided an intellectual and engineering basis for developing e-business and e-government applications on the Web.

Over the years, it has become increasingly clear that what Porter actually described was only one of a number of "canonical business processes" -- value chains that are shared by organizations in the same business or business area. For example, a canonical business process (primary activities) for a highway construction organization might be as follows: planning --> design --> construction --> operations/maintenance.

We consider such a process canonical because a value map like this is common in many areas of large-scale construction (e.g., buildings, airports, terminals) as well as for highways. Since such process models are so common in the way architects and engineers think about the overall execution of their projects, it is not at all surprising to find that many construction organizations are organizationally structured into separate planning, design, construction, operations, and maintenance divisions.

The canonical construction model can be further extended to deal with utilities whose job it is to build (construct) and operate networks. In such models, the planning, design, and construction can be thought of as the "build-out of the network," and the "operations" can be considered (1) the part that deals with connecting the customer to the network and (2) customer service that provides the service and then bills and collects for that service.

All large organizations develop some sort of fundamental canonical business process based on the natural "break points" in their business activities. This allows the organization to subdivide the work naturally so that, for example, the planning, design, and construction units can work independently of one another with well-defined interfaces.

Porter's business value chains have simply rediscovered an underlying truth within businesses of all kinds. Earlier, Henry Ford took this idea of work sequencing and created the assembly line, which was simply a different way of executing business processes so that individual, specialized groups could work on what they were good at while the assembly line moved the work from organization (workstation) to organization.

Recently, the success of organizations like the Supply-Chain Council ⁵ with its SCOR model has reinforced the idea of canonical business processes. SCOR, which stands for Supply-Chain Operations Reference-model, has five major processes: planning, sourcing, making, delivering, and returning. Using just these processes, SCOR has been able to fashion an entire framework for analyzing, measuring, and improving a large organization's supply chain management.

Business value maps are exceedingly important as a guide for understanding an organization's business framework. Figure 6, for example, shows the business value map for a transportation agency. The items in gray refer to the primary activities, while those in black refer to the supporting activities.

Figure 6 -- A business value map for a transportation organization.

The business value map is a map of the entire IT landscape for the enterprise. It has proven especially useful in distinguishing between primary business activities and sporting ones. One of the uses we've made of the business value map is adding overlays to show the major applications or the major data classes for the enterprise. (See sidebar "Using Business Value Maps.")

Business Processes

An organization is only as effective as its processes.

-- Improving Performance [11, p. 45]

Business processes are the heart of large organizations. Business processes are the way things get done. There's a push today for organizations to formalize and rethink major business processes. One of the ways that enterprise architecture can have the biggest immediate impact is by focusing more attention on the business architecture, which starts with business processes.

As you probably noticed, much of the discussion in the section on business value maps centered on business processes -- canonical business processes. This section is more about modeling detailed business processes. What we are going to do here is talk about something called "swimlane diagrams," a form of documenting business processes first publicized by Rummler and Brache [11]. Figure 7 shows a swimlane diagram of a straightforward sales order fulfillment process.

View Figure 7 »

Figure 7 -- Swimlane diagram of a sales order fulfillment process.

These swimlane diagrams capture several essential business process components: roles, activities, decisions, and workflow. In a sense, these business process diagrams are simply augmented flowcharts -- exactly like those flowcharts used in programming but with a few additions. These additions, it turns out, are extremely important. Within business process modeling, it is extremely important to identify who does the work and when. That is where the concept of "role" comes into play.

Roles represent the key logical actors in a business process. As in the case of context diagrams, roles can be individuals, while organizations are systems. What is most important about a business process diagram is that the general activities and the value chain are captured.

All large organizations, and many small and medium-sized ones, have considerable business process documentation that has accumulated over the years. Procedures, regulations, and work rules exist everywhere. Unfortunately, in most organizations there is no common form of business process documentation. Some business process documentation exists in the form of traditional flowcharts, some exists in the form of structured text, and some exists in the form of decision tables.

While there are obviously a number of ways that organizations have documented business processes in the past, we suggest that organizations consider using swim.lane diagrams as their standard approach. This diagramming form has become something of a standard in the business-process world, and there are many tools that support developing and maintaining them. We have also found that using swimlane diagrams helps people think more creatively about how work gets done in their organizations.

In context diagrams, the actors are normally the ones that users come up with in our dialogue. For example, when developing context diagrams, most participants in BEAM sessions usually refer to the organizational units or the job positions that they are most familiar with, so that is what we use on the initial context diagrams. But by the time we get to creating swimlane diagrams, we frequently segue from the actors that users know to roles that more correctly capture the functional representation that is taking place. Oftentimes, we will find the same role being performed by two different actors in a business scenario. In a large organization, for example, a role often will be significant enough that a full-time position will be associated with it; whereas in a small organization, the same position (e.g., Accounting Clerk III) may handle three or four different roles.

In business-process analysis, there are typically several different kinds of business process models: "as is" models, which describe, as closely as possible, how the business operates today; and "to be" models, which describe alternative approaches.

As a result of our work in enterprise architecture during the past few years, we've come to believe that a major role of an enterprise architecture group is to encourage the creation of business process models for all portions of the enterprise. In addition, it is important to create an enterprise architecture repository that serves as a library for future business process analysis, since every time a large organization starts a new initiative, each new team invariably goes back and studies what the organization currently does. Documenting these processes takes a great deal of time and creates a body of knowledge that is extremely useful but is often thrown away after the project is completed. This is a waste of valuable time, money, and, most importantly, knowledge. Due to the aging workforce, a large percentage of current employees will be retiring within a short time period; having a central repository of understandable, up-to-date business process documentation is an enormous business asset.

Data/Information Architecture

The fundamental value of a legacy IS (system) is buried in its data, not in its functions or code.

-- Michael Brodie and Michael Stonebraker, Migrating Legacy Systems [2, p. 89]

Data ⁶ is the crown jewel of our IT assets. Our organization's data is also the most stable infrastructure. While hardware and programs change, data tends to persist. In many cases, our data structures still look much the same as they did 10 or 20 years ago. This is especially true in stable organizations that sell the same product year after year or do the same function/job year after year. Even after we convert one system to another, if the function remains the same, much of the data is carried over from one system to the next.

Data is also the most flexible component of our enterprise architecture. Starting in the 1960s, developers became aware that the same data was being used in multiple applications. Order entry, shipping, and billing systems all relied on the same customer and product data. This recognition led to the first database management systems (DBMSs). If organizations could reduce the data redundancy, then many systems problems could be eliminated and new applications could be built more rapidly.

DBMSs have been one of the great success stories of IT. They allow programmers to focus on programming and to leave the physical storage, indexing, and retrieval of information to the database management software. But even as powerful and successful as DBMSs have been, different systems in different organizations, even those that use the same fundamental data, have had a tendency to drift apart. Moreover, certain systems focused on different data, which meant that integration of data across the enterprise was at best a difficult undertaking.

Looking back, it is clear now that data warehousing was one of the first true "enterprise architectural solutions." Data warehousing was an enterprise solution because its function was to bring together data from disparate data sources across the enterprise to produce a unique enterprise view of information that was unavailable at any other level [4].

Data warehousing also made it possible to create integrated sets of data from a variety of data sources without disturbing the sources themselves. The data warehousing infrastructure was a template that could be used in a number of different situations. Today, data warehousing and data mart environments are utilized in tens of thousands of business intelligence applications across all business markets.

Over the past 10 or 15 years, the amount of different types of information that needs to be managed has grown significantly. Instead of just managing the "structured data" in their mainline applications, IT organizations everywhere are involved in managing COTS data, data warehouses, GIS data, CADD drawings, documents/images, photographs, e-mail, attachments, Web content, and multimedia.

Just as we learned how to integrate structured data from different sources during the late 1980s and early 1990s to create data warehouses, new classes of applications are being built today that integrate data of different types. Two major classes of these applications stand out: Web-based portals and GIS applications. Organizations are now beginning to think of the total set of information on computers as an enterprise asset that can be integrated in ways that not only change the way people work but also, in many cases, create a whole new class of product [9]. So instead of just focusing on data management, people are starting to build views of data/information/content architectures.

However, the data/information/content we see internally is but a small piece of the information that people are utilizing to do their work today. With search engines like Google and Yahoo, managers and workers in organizations everywhere have access to literally billions of data sources. Indeed, the next generation of Web applications and Web services seems to depend heavily on new and more powerful search capabilities and semantics to help them locate what they need.

Finally, data architecture plays a large role in fashioning the next generation of service-oriented architecture (SOA) applications. In this new environment, presentation, business logic, and data exist in different layers. Over the next few years, we predict an increasing emphasis on simplifying and rationalizing corporate data into a smaller number of "systems of record" that become the corporate repositories for key data assets. We will discuss this idea further in the next section on application architecture.

Application Architecture

During the past decade, application architecture has probably been the most discussed of all the four major architectures. This has been in part because of the interest in three-tier applications, Web services, and SOAs. But, like most things, application architecture is far bigger than any current technology strategy, even one as promising as SOA. Indeed, there is no end to technology architectures. Already, as SOA implementations are becoming more common, people are beginning to talk about grid architectures.

While it's true that application architecture is bigger than any one of these individual architectural styles, a great deal can be learned from our recent experiences with, in this case, three-tier architectures. Perhaps the best book on application architecture is Brodie and Stonebraker's Migrating Legacy Systems [2]. In this book, the authors address what we believe to be the most important problem in application architecture -- maintaining and migrating large systems over long periods of time. This is perhaps not so surprising, given that Brodie has spent the better part of his career working in an industry that prides itself on seamless upgrading of one of the world's most complex networks -- the telephone network.

The following quotes from Brodie and Stonebraker about legacy systems are particularly relevant:

• "A legacy information system is any information system that significantly resists modification and evolution." [2, p. 3]
  
  
• "Your legacy systems keep your business from staying on top." [2, p. 3]
  
  
• "Legacy systems maintenance monopolizes your time and money." [2, p. 4]
  
  

The reason these ideas are so important for application architecture in the 21st century is that legacy systems represent such a huge portion of an organization's IT assets as well as its investments. Therefore, the long-term goal of a well-formed application architecture is not just to use the latest architectural ideas on our new systems but, over the long run, to bring the key or core systems of an organization under a common and maintainable structure (i.e., to have a "migration strategy" for every mission-critical IT application). In the end, architectural investments are about the big things, and, as far as application architecture is concerned, the biggest things are the major systems. From our standpoint, anything that runs is legacy.

Much of what Brodie and Stonebraker lay down as their fundamental concepts mirror what others have been suggesting for some time in terms of dividing applications into three layers: the presentation layer, the business rule layer, and the data layer.

Brodie and Stonebraker's interfaces, applications, and database services (see Figure 8) described in the following quote correspond directly to the three-tier presentation, business rule, and data layers:

The best architecture for migration purposes is a decomposable structure, in which the interfaces, applications, and database services can be considered as the state components with well-defined interfaces. [2, p. 15]

Figure 8 -- Brodie and Stonebraker's decomposable applications [2].

Brodie and Stonebraker found that legacy systems fall into the following three categories:

1. Decomposable -- those that come apart at the presentation/interface, business rule/application, and data layers.

2. Semi-decomposable -- those where only the presentation/interface layer is truly separable. In practice, this means that the application and database layers are tightly coupled.

3. Non-decomposable -- those in which none of the major components can be cleanly decoupled from one another.

Of these three types of legacy systems, the decomposable ones are the easiest to migrate (replatform). We don't really recommend migrating legacy systems to anyone who's charged with thinking about application architecture for the future. Too often, in an attempt to solve a major problem, people become enamored of a new style of development that will suddenly free them from having to worry about long-term maintenance and long-term evolution of their applications. Reading Brodie and Stonebraker's book will provide you with a great deal of insight into how your organization ought to be thinking about building truly decomposable applications.

In the development of large-scale applications, critical design decisions involve interfaces. We feel that good systems have a common anatomy (i.e., they come apart at the same places). If our organizations are going to take advantage of new technologies, they need to pay attention to this anatomy, they need to have their best people working on modular design, and they need to enforce that modularity through their architecture standards and review.

SOA is a good thing. It attempts to build systems out of cleanly defined modules with cleanly defined interfaces. But it is not magic. SOA only works when people pay attention not only to the rules but also to the reasons for their existence. Like a good database design, good application design follows patterns, and those patterns are ultimately a reflection of the business that is being automated.

Technology Architecture

On one hand, technology architecture is the most complicated of all the architectures; on the other hand, it is the simplest. It is complicated because there are so many products -- both hardware and software -- that can go into a given application. It is vastly simplified because in a given environment, the choices are always limited. There are no perfect technologies, and there are no technologies that are done evolving.

Large organizations seek safety in a variety of strategies: market leaders, industry standards, and organizational strategies. All of these are subject to change. It would be wonderful if, somehow, it were possible to "futureproof" our technology decisions -- to make decisions now that would be good for all time -- but that never happens. For instance, market leaders change over time. Some of them fail to keep up with technology; some of them fail to keep up with business trends. No one prevails forever.

Industry standards reflect a desire of businesses and their vendors to lay out the basic interfaces between products in ways that will minimize obsolescence. Unfortunately, industry standards often lag technology and in many cases reflect either unrealized wishes or a means of protecting existing product investments into the future.

Organizational strategies change as market leaders and industry standards change. They also change as market conditions in their business arena shift. The technology architectures that make the most sense then are those that reflect the system's anatomy (introduced in the previous section). During the past 20 years, IT has moved from mainframes to client-server to the Internet/three-tier applications. Companies such as Google are pioneering a whole new range of technology based on massively parallel grid computing. In addition, IT is about to undergo a massive sea change based on converting an increasing number of applications to wireless devices and wireless networks.

Good technology architecture should closely reflect the business, data, and application architectures that have already been discussed. In the real world, technology architectures should also reflect the migration of technologies. Since no technology lasts forever, enterprise architects must plan for the day that various technologies disappear.

Technology architecture requires planning. Unless IT management takes an active role in deciding which technologies to invest in and which to eliminate, the result will be chaos. Technologies tend to accumulate. Even if there's only one application in an entire IT organization that uses some 30-year-old technology, if it is a mission-critical application, it will not go into retirement easily.

BEAM has several techniques for managing technology change along with business change, including "weather radar charts." Real weather radars in the US Midwest show that new things (fronts, storms, etc.) generally come in from the West and leave toward the East. One day when we were trying to get people to think about long-term technology planning, we came up with the idea of a weather radar chart that extended out in time as opposed to space. What would happen if we laid out our technology plans over multiple years (0-10) for new things, as well as for retiring things? This would help people to think further into the future. Figure 9 shows such a chart containing both technology (data warehousing, wireless, telematics, etc.) and demographic (aging workforce) issues.

Figure 9 -- A weather radar chart with both technology and demographic issues.

While these charts are fairly simple, they are effective in helping people think about the future. In most organizations, three years is a long way out, but in IT, three years comes before you know it. We consider these charts early-warning devices that help people think out loud about things that they would rather, for one reason or another, ignore.

Equally important are the things that we are trying to make go away. We have found in organization after organization that technologies pile up, like stuff in your garage or attic. Unless someone consciously starts thinking about how to get rid of them, technologies, like rarely used applications, stick around.

ENTERPRISE ARCHITECTURE VALUE CATEGORIES

Enterprise architecture is new, and some people question the value of anything new. Common questions include: Why do we need to do this now; after all, we've been getting along fine without it all these years, haven't we? Why are we spending so much time thinking about the future; why don't we just do what everybody else is doing? These are questions that need to be answered, so we thought it would be useful to address the values associated with enterprise architecture.

Since enterprise architecture touches nearly every part of the organization and every kind of technology, the possible value categories are broad. However, enterprise architecture is especially important for a number of major value categories, including:

• Business-IT alignment
  
  
• Support for business initiatives
  
  
• Strategic IT planning
  
  
• IT project management
  
  
• IT asset management
  
  

This section discusses each of these categories in detail.

Improved Business-IT Alignment

The overriding goal of IT is to support business uses and users. Historically, IT applications focused on supporting individual business areas. Over time, these individual, localized systems have been interfaced with dozens (sometimes hundreds) of other systems. This has made systems more powerful and allowed organizations to combine information from multiple operations. As the telecommunications infrastructure has evolved, the number of people using computers routinely has dramatically increased. In the future, with the introduction of wireless connections, nearly everyone within an organization will be connected to these systems. While this constantly enhances an organization's efficiency and effectiveness, it makes the job of business-IT alignment increasingly complex. Enterprise architecture makes the alignment of business and IT easier by providing both business and IT planners with a "base map" of how the current business-IT infrastructure fits together, as well as the impact of one system on another.

One thing is clear: IT plays a key role within the organization. A few decades ago, computers were employed in only a few highly specialized areas. Today, IT systems play a critical role in almost all aspects of the organization's operations. In many respects, IT planning contains many of the issues that are encountered in planning the highway infrastructure. Like highways, IT networks require considerable advanced planning, even with the most advanced IT development resources. And, like highways, all the pieces are interconnected and need to be reviewed and replaced on an ongoing basis.

By collecting and maintaining the underlying data relating to business processes, data needs, application programs, and technologies, enterprise architecture provides a baseline of information that can speed the development of new systems to support new business functions and at the same time make it easier for systems to support revised/modified business functions. The immediate advantages of this include the following:

• Increased focus on business strategies/needs
  
  
• Elimination of redundancies
  
  
• Cycle time reduction
  
  
• Improved reuse of existing IT assets
  
  
• Leveraging technology through new business initiatives
  
  

Increased Focus on Business Strategies/Needs

One of the issues expressed in a number of interviews and meetings with top managers is the difficulty of getting management strategies translated into information systems support. Enterprise architecture makes this much easier by providing a standardized picture of what processes, data, systems, and technology are involved in supporting the current business operations so that planners can lay out the differences between the future (to be) and the current (as is) environment.

Elimination of Redundancies

Within any large organization, there is a certain amount of redundancy. Over time, this redundancy can become a large factor. Enterprise architecture allows planners to view just how many times the same data is stored throughout all the systems within the organization. It also allows planners to see how many times the same business rules are coded in all of the thousands of programs the organization supports.

Cycle Time Reduction

Organizations are under pressure to work smarter and faster. This is especially true today when there are fewer resources in terms of dollars and people and as the benefit-cost ratio of technology continues to increase at an accelerated rate. Enterprise architecture provides a framework in which whole business processes can be reviewed and redesigned. Within the organization today, workflow management has already cut the time for specific business processes from as much as 30 days to less than three. Combining electronic forms/data with workflow management technology allows information to flow across organizations and across the world at electronic speeds. Things don't get lost, and advanced workflow technologies, for example, support much more agile organizations.

Improved Reuse of Existing IT Assets

Another major advantage of enterprise architecture is the ability to focus on the reuse of a wide variety of components, from individual computer procedures to the installation of complete off-the-shelf suites of applications for well-defined business processes. Because enterprise architecture looks across the entire organization, it becomes clear just how much reuse is possible.

Data is perhaps the place where the reuse of IT assets plays the biggest part. Keeping track of all the projects, documents, and activities within a large organization is an extremely complex process. Enterprise architecture makes it possible for IT planners to know exactly where critical data on projects or contracts exists and where possible inconsistencies may arise.

Leveraging Technology Through New Business Initiatives

Every day, new technologies make new business usages possible. While no organization is equipped to take advantage of all the technologies that exist, organizations that capitalize on the right technologies can reduce costs and increase productivity significantly. In some cases, this represents state-of-the-art technologies; it may also represent finding new ways to exploit well-known technologies.

Improved Support for Business Initiatives

One of the hardest things for business or government executives to do is to put new business initiatives into practice. Every new management or administration tries to communicate its basic priorities and often has trouble putting those priorities into practice. Because enterprise architecture focuses on tying the business strategies to the business systems and technologies, those charged with implementing new business initiatives can get a quick start.

A well-organized enterprise architecture environment should contain several key information resources critical to business initiatives, including:

• Providing a central repository of integrated management information
  
  
• Providing baseline business-IT documentation
  
  
• Allowing easier access to management information
  
  
• Providing easier user training/reference
  
  

Providing a Central Repository

The average large enterprise will normally maintain hundreds of documents across the organization that detail the organization's strategies, goals, objectives, and procedures. Historically, this documentation exists in the form of independent documents made up of text, organizational structures, and tables. While enormous effort is normally expended in creating, updating, and disseminating these various organizational strategies, they are often not communicated to the people who need to know about them.

EA tools make it possible to document goals, objectives, roles, responsibilities, and measures in a way that allows them to be tied back to the various applications, views, and reports that need to reflect them. Equally important, the enterprise architecture provides a place where fundamental business processes and business rules are documented and constantly updated as changes are made to them and to the systems that are supposed to execute them.

Providing Baseline Business-IT Documentation

Whenever a new management project begins, there is a need to capture the set of information (the baseline) about the organizational units involved. A serious enterprise architecture keeps this information for the entire organization and can save a considerable amount of time. Additionally, because the enterprise architecture is an ongoing activity, most of this information is up to the minute.

Allowing Easier Access to Management Information

Managers at all levels struggle with finding and structuring management information about a whole range of topics. Because enterprise architecture contains a directory of all the data for the enterprise, it can be a resource in a wide variety of situations. Over the past 15 or 20 years, data warehousing has emerged across the world in response to the need not only to access individual sets of data in specific applications but also to combine information from different parts of the organization in ways that allow managers to see the organization as a whole. Many people see data warehousing as one of the first enterprise architecture applications of any magnitude.

Enterprise data architecture is a major component of the enterprise architecture. Enterprise data architecture involves building enterprise data models and understanding the data not just in specific applications but in all the applications that span the organization. The enterprise data architecture is one of the most valuable components of the enterprise architecture.

Providing Easier User Training/Reference

Over the next decade, an increasing number of key management and professional employees will be retiring as the baby boomers come of age. Over a relatively short period, organizations around the world will have to transfer the knowledge from one generation to the next. In an increasing number of companies, the enterprise architecture is becoming the central repository for business and technology detailing how the enterprise operates. Nothing will replace face-to-face contact for transferring knowledge, but having a central repository can be a great aid.

Improved Strategic IT Planning

Perhaps the most important, and earliest, place where enterprise architecture provides significant value is in the area of strategic IT planning. By and large, IT organizations provide five basic services to their customers: (1) telecommunications infrastructure, (2) data, (3) applications, (4) support, and (5) expertise. Each of these areas requires an understanding of the ways that these functions relate to business goals and strategies. Over time, the existing IT asset network of business processes, data, applications, and technologies must be documented, updated, and ultimately replaced. At the same time, new business needs and technologies must be brought into this same IT asset network while other elements are being retired.

For decades, areas like the transportation network have used maps, engineering drawings, and videos to aid in the process of deciding which projects to do and in which sequence to do them. Until the advent of enterprise architecture, however, IT has not had a similar set of high-level maps, drawings, pictures, or videos of the IT landscape. So one of the most important initial values of an enterprise architecture has been to provide IT and business planners with a better set of maps and schematics of the business-IT landscape.

With this improved set of pictures, business and IT planners have a better framework in which to lay out their plans. Equally important, they can look across the organization and further into the future when considering business strategies. Enterprise architecture provides:

• An improved framework for long-range business-technology planning
  
  
• A better portfolio of projects
  
  
• Increased leveraging of the business-IT infrastructure
  
  

An Improved Framework for Long-Range Business-Technology Planning

Planning any complex area is a significant challenge, but it is made even more difficult in IT because of the extremely rapid rate at which new technologies are brought onstream and made obsolete. Because IT is so central to the operation of the modern real-time organization and to the time it takes to develop and install quality systems, strategic IT planning is a particularly challenging activity.

Enterprise architecture makes this process significantly easier by providing maps of how the various components (business processes, data, applications, and technologies) fit together. In addition, the latest forms of enterprise architecture have evolved new ways of talking about the long term in which IT n