BEAM (Business EA Modeling) by The Ken Orr Institute

Enterprise Architecture Vol. 8, No. 3

Business Enterprise Architecture Modeling by Ken Orr, Senior Consultant, Cutter Consortium; in collaboration with Bill Roth and Ben Nelson In most large organizations, how quickly the organization can respond to critical market changes is directly related to how well it manages its business-IT assets and infrastructure. The need for reduced cycle time has spurred a growing interest and investment in enterprise architecture. In recent years, a number of breakthroughs have occurred in enterprise architecture that help organizations better manage their business-IT assets; Business Enterprise Architecture Modeling is a new framework that incorporates these breakthroughs.

Cutter Business Technology Council Rob Austin

Tom DeMarco

Christine Davis

Access to the

Experts

Lynne Ellyn

Jim Highsmith

Tim Lister

Ken Orr

Lou Mazzucchelli

Ed Yourdon

About Cutter Consortium Cutter Consortium is a truly unique IT advisory firm, comprising a group of more than 100 internationally recognized experts who have come together to offer content, consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, groundbreaking work in organizations worldwide, helping companies deal with issues in the core areas of software development and agile project management, enterprise architecture, business technology trends and strategies, enterprise risk management, metrics, and sourcing. Cutter offers a different value proposition than other IT research firms: We give you Access to the Experts. You get practitioners’ points of view, derived from hands-on experience with the same critical issues you are facing, not the perspective of a desk-bound analyst who can only make predictions and observations on what’s happening in the marketplace. With Cutter Consortium, you get the best practices and lessons learned from the world’s leading experts; experts who are implementing these techniques at companies like yours right now. Cutter’s clients are able to tap into its expertise in a variety of formats including content via online advisory services and journals, mentoring, workshops, training, and consulting. And by customizing our information products and training/ consulting services, you get the solutions you need, while staying within your budget. Cutter Consortium’s philosophy is that there is no single right solution for all enterprises, or all departments within one enterprise, or even all projects within a department. Cutter believes that the complexity of the business-technology issues confronting corporations today demands multiple detailed perspectives from which a company can view its opportunities and risks in order to make the right strategic and tactical decisions. The simplistic pronouncements other analyst firms make do not take into account the unique situation of each organization. This is another reason to present the several sides to each issue: to enable clients to determine the course of action that best fits their unique situation. For more information, contact Cutter Consortium at +1 781 648 8700 or sales@cutter.com.

Business Enterprise Architecture Modeling

ENTERPRISE ARCHITECTURE ADVISORY SERVICE Executive Report, Vol. 8, No. 3

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.

â&#x20AC;&#x201D; 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 â&#x20AC;&#x153;The whole is greater than the sum of its parts.â&#x20AC;?

Enterprise architecture, as its name implies, is all about highlevel 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.

2 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.1 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 1There are an increasing number of EA frame-

works being promoted and deployed around the world. Many of these have decades of R&D behind them, as does BEAM. The three approaches described here are the ones that have become increasingly popular in North America, and we believe in northern Europe as well, but this does not mean that we have a full understanding of what all these approaches recommend or what their strengths and weaknesses are.

ENTERPRISE ARCHITECTURE ADVISORY SERVICE 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 longterm 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

The Enterprise Architecture Advisory Service Executive Report is published by Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA. Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America, +1 800 888 1816; E-mail: service@cutter.com; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: kletourneau@cutter.com. Production Editor: Linda M. Dias, E-mail: ldias@cutter.com. ISSN: 1530-3462. ©2005 by Cutter Consortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law. Reprints make an excellent training tool. For information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail service@cutter.com.

VOL. 8, NO. 3

www.cutter.com

EXECUTIVE REPORT 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.

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

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.

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:

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

An extension to the classic Zachman Framework

A basic Enterprise Systems Feedback Model (ESFM) A new way of considering business-technology alignment and innovation

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

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

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.

decisions back to critical business decisions.

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

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

Enterprise/Agency

Sources (Business Partners)

Market (Customer/Client) products/ services

resources

product usage

product feedback customer (usage) feedback

Figure 1 — The Enterprise Systems Feedback Model.2

Business Planning

Impact

Organize

Business Operations

Technology Planning

Opportunity

Align Technology Operations

Figure 2 — Benson and Parker’s square wheel [1]. 2There are hundreds of examples of systems models in literature, but this model is adapted

directly from Improving Performance [11].

VOL. 8, NO. 3

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

www.cutter.com

EXECUTIVE REPORT 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 ©2005 CUTTER CONSORTIUM

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 SarbanesOxley 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 VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

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:

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.

Urban planning skills Transportation planning skills Building inspection skills County agent skills

VOL. 8, NO. 3

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

www.cutter.com

EXECUTIVE REPORT 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â&#x20AC;&#x2122;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

ÂŠ2005 CUTTER CONSORTIUM

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.

VOL. 8, NO. 3

8 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 VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE 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 19403 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 3On 7 November 1940, the Tacoma Narrows

Bridge, a suspension bridge, collapsed due to wind-induced vibrations. Situated on the Tacoma Narrows in Puget Sound, near the city of Tacoma, Washington, USA, the bridge had been open to traffic for only four months.

www.cutter.com

EXECUTIVE REPORT 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 architecture4 For small organizations, a highlevel 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. In each of the following sections, the same general framework shown in Figure 3 is used to drive the activity. 4The first four architectures here represent a

classic way of looking at enterprise architecture. Recently, we have been working to bring yet another development/integration/ maintenance/migration architecture into the picture as well.

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

Strategic Strategic Intentions Intentions Business Architecture

Business u B iness Co ntext Context Business Value

Business Process Data Architecture Application Architecture Technology Architecture

Figure 3 — The BEAM approach.

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

VOL. 8, NO. 3

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

www.cutter.com

EXECUTIVE REPORT job request proposal Customer

order complaints

Sales

delivery date invoice customer shipment

estimate

Estimating

job spec

vendor shipment

Receiving

P.O.

receipt notice

P.O. forecast Production Scheduling

product prices Purchasing

order production schedule inventory status

production report

Vendor

purchase request Inventory Control

vendor payment

inventory status

production schedule Production

time cards time cards

payroll checks

Payroll

material costs

Employee

payroll j/e production report

cust inv j/e

Billing

G/L System

cust payment j/e

A/P

P.O. vendor invoice

purchasing j/e credits customer payment

invoice A/R and Sales Accounting

Cost Accounting

material j/e

G/L report Management P/L

management reports

Figure 4 — A business context diagram.

process should add value to the preceding steps.

HR Management R&D

Service

Outbound Logistics Marketing and Sales

Procurement Operations

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

Supporting Activities

Inbound Logistics

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

Firm Infrastructure

Primary Activities

Figure 5 — Michael Porter’s business value diagram [10].

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

VOL. 8, NO. 3

12 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. VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE 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 Council5 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. The business value map is a map of the entire IT landscape for the 5The Supply-Chain Council is an organization

made up of supply chain managers from some of the world’s largest enterprises.

www.cutter.com

EXECUTIVE REPORT 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.”)

Administrative Management IT Management HR Management Financial Management Supporting (Financial, HR, IT) Assets Program/Project/Contract Management Preconstruction

Construction

Maintenance

Business Processes

An organization is only as effective as its processes.

Real-Time Operations

Planning

Local Support (Public, Transit, Aviation, Other)

— Improving Performance [11, p. 45]

Research and Laboratories

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

Safety Transportation Infrastructure Assets Figure 6 — A business value map for a transportation organization.

USING BUSINESS VALUE MAPS Like any good map, a business value map provides an overall way of looking at the territory — in this case, the whole enterprise. What makes this map useful is that it continuously ties enterprise architecture components (applications, data classes, etc.) to the business itself. These maps have no technological bias, and they allow people unfamiliar with the enterprise to have a quick look at what it does and what it produces. In practice, we usually place an organization’s business value map as the first or second thing in our enterprise business documentation. The business value map fits neatly within our Enterprise Systems Feedback Model (ESFM) as well. Recently, we have begun to reinterpret business value and systems feedback diagrams in light of the Federal Enterprise Architecture (FEA) initiative. In FEA, a series of reference models are used, including: Performance Reference Model (PRM) Business Reference Model (BRM) Service Component Reference Model (SRM) Data Reference Model (DRM) Technical Reference Model (TRM)

From a business architecture standpoint, PRM and BRM are by far the most important. Using the ESFM and the business value map, we have been able to link the ESFM and FEA frameworks directly (see Figure A). (Sidebar continues on next page.)

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

USING BUSINESS VALUE MAPS (continued) This is quite useful for those in the government sphere using the FEA framework. As you can see in Figure A, BRM is broken down into the following four major areas that have been developed to categorize the various business processes that go on within the public government sector: 1. Services for citizens 2. Mode of delivery 3. Support structure for delivery of services 4. Management of government resources

Based on the underlying business value concepts of primary activities and supporting activities, it was a straightforward exercise to identify “services for citizens” and “mode of delivery” as primary activities, and “support delivery of services” and “management of government resources” as support activities. This in turn allows us to provide an even stronger linkage between the BEAM and the FEA frameworks. By bringing the BEAM and FEA PRM/BRM frameworks together, it has been possible to go even further and to map the major components within FEA’s BRM into the appropriate spots. There is a strong need to move BRM from a taxonomy to a set of solution templates.

Law Enforcement

Financial Assistance

Services of Citizens (Primary Activities)

Judicial Legal

Credit and Insurance

Corrections

Controls and Oversight

Environmental

Direct Service to Citizen

Natural Resources

Risk t Management

Health

Knowledge Creation and Delivery

Community and Social Services

Planning and Resource

Education

Public Goods Creation and Delivery

Workforce Support

Revenue Collection

Economic

Resources

Regulatory Compliance

Infrastructure

Regulatory Development

Financial Assets/Supply Chain

Public Affairs

Management of Government Resources (Support Activities)

Federal Pass thru-

Budget

Federal Regulatory and Compliance Reporting

HR Management

Legislative Relations

IT Management

General Government

Administrative Management

Support Structure Suppor Su por t st ructure for Delivery Deliv Delivery yofofServices Services (Delivery ofofServices — Supporting Activities) (Delivery –Supporting Ac tivities) Support Structure for Delivery of Services (Delivery Services —Supporting Activities)

iC tiz ens Citizens

Services Ser ices

End End Results Re s lts

Mode of Delivery (Delivery of Services — Primary Activities)

Inputs

Ou tcomes Outcomes

Outputs

BRM

PRM

Figure A — Integrating BRM components into the business value map.

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

VOL. 8, NO. 3

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

www.cutter.com

EXECUTIVE REPORT

Customer

shipment invoice Order Entry Order Entry

preapproved? Yes

Accept Goods

preapproved credit

Credit Manager

entered order

Check Credit

approved order

Sales Manager Allocate

shipping notice

Shop Ship Goods

billing notice

Accounting

payment

Bill Customer

Accept Payment

Customer Service

Product Management

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

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. 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 swimlane 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 (Text continues on page 18.)

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

ENTERPRISE DATA ARCHITECTURE MODELS AND BUSINESS SEMANTICS For some time, we have been basing our systems development on a set of basic business semantic categories that come out of our business context and business process modeling. The primary categories are actors/roles, messages, objects/subjects, and events. Armed with an understanding of these categories, a skilled modeler can in fact read the various data characteristics directly from a context diagram. To make this clearer, in Figure A we have taken a business context diagram and made the actors gray, the messages black lines, and the objects/subjects black. We have found that, for the most part, these same semantics carry over into our enterprise data models. Figure B, for example, shows an entity-relationship diagram for the same business domain. One thing that has gone somewhat unnoticed and unremarked is that enterprise modeling and application modeling are not the same thing. Most of the tools that we have for enterprise modeling were adapted from application modeling, but the size and scope of enterprise modeling require diagramming techniques and tools that are more flexible, capable of much more sophisticated leveling, and able to show time-related change. Suppliers

Customers

Business Domain

values to other counties

Other Counties

values from other counties

boundary information

Division of Property Valuation

state abstract 2

tax entity budget

Taxing Entities

distributed funds

state abstract 1

tax valuations by tax entity initial state assessed values

mill levy real estate value

Deed transfer request

Title/Mortgage Company

real estate tax unit

County Clerk Deed transfer approval

Owner/Taxpayer

tax notice

Treasurer fees

certified values

tax warrent

owner info

tax appeal decision

tax unit info

Approved deed transfer

building permit

plat proposal

approved plat proposal

tax bill changes

tax appeal

lien

plat changes

notice of assessed value (NOAV)

deed or changes

Planning and Development

permits

permit application

Public Works permit inspection

Developer

deed or changes

Lienholders

sales questionnaire (aka Cert of Value)

Appraiser

Competitors

Division of Motor Vehicles (DMV)

Personal Property

Real Estate Parcel

inspection checklist

Figure A â&#x20AC;&#x201D; Enterprise business context diagram with semantic categories highlighted. (Sidebar continues on next page.)

VOL. 8, NO. 3

www.cutter.com

EXECUTIVE REPORT

ENTERPRISE DATA ARCHITECTURE MODELS AND BUSINESS SEMANTICS (continued) Our feeling is that, over time, enterprise architecture will evolve new classes of diagramming and documenting techniques that are more appropriate for architectural work. Historically, all of the diagramming techniques in common use across IT, such as classic business modeling techniques (context, workflow, ERD, and data structure models), as well as OO techniques, such as UML versions 1.0 and 2.0, were adapted from systems and programming uses. For the most part, BEAM uses modified classic business modeling diagrams because they have proved better suited to communicating directly with business management and users, whereas many UML techniques seem aimed at communicating with technical people, particularly developers. But even the best classic business modeling techniques still leave a great deal to be desired with respect to enterprise modeling. Our expectation is that over the next decade, there will be enormous developments in this area as enterprise architects and EA tool vendors work to model the entire enterprise.

Address

contains

refers to may have

has

maintains submit

State Assessment

Certified Value

used to set calc from

is submitted by

Mill Levy

calc from used to set

Tax Entity Budget

NOAV

specific to

used to set receive

is established by

sent

Appeal resolves

has resolution

Mortgage Company

used to calc

submitted by

has loaned

has loan from

Special Assessments

establishes calc from

submits

calc from calc from based on

Tax Bill

Tax Year

may trigger

has sent to

makes

refers to

receives

triggered by triggered by

may trigger may be triggered by

Tax Payment receives from

may be triggered by

Tax Notice

Tax Warrent

Tax Sale

may trigger may be triggered by

goe

mad

relates to

used in

may trigger

Tax Appeal Decision

has

Tax Payer/ Owner

Property Intere st

associated with

is defined by

Assessed Value

is assigned

receive

has

defines

owns owned by

may be part of relates to

defines ownership

has

refers to identified by

Deed

Party Responsible for Tax Payments

Taxing Entity

is contained in

Parcel may have

associated with

refers to

Parcel History

has refers to

is referenced by

refers to

is a

County

contains

may have

Improvement

is contained in

refers to

Tax Payer History

Note

may trigger

Tax Collection

made up of goes into

goes into

is made up of

Tax Distribution

distributed to

Figure B â&#x20AC;&#x201D; Enterprise data architecture (entity-relationship) model with semantic categories highlighted.

ÂŠ2005 CUTTER CONSORTIUM

VOL. 8, NO. 3

18 (Text continued from page 15.)

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 VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE 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]

Data6 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 6Throughout this section, we use “data” to

include all the sorts of information, content, and multimedia that are stored in a modern organization.

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

www.cutter.com

EXECUTIVE REPORT 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]

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

“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

Foreign ISs

End Users

System Interfaces

User Interfaces

Application Modules

Database Services

Databases

Figure 8 — Brodie and Stonebraker’s decomposable applications [2].

VOL. 8, NO. 3

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]

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,

www.cutter.com

EXECUTIVE REPORT 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

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

think further into the future. Figure 9 shows such a chart containing both technology (data warehousing, wireless, telematics, etc.) and demographic (aging workforce) 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.

incoming issues 5-10

3-5

outgoing issues 0-3

0-3 0-3

3-5

5-10

Data Warehousing Warehousing Wareho sing Data

GIS/GPS GIS/GPS

Wireless

Server xx Server

Workflow Workflow Mainframe Mainframe DocManagement Mgmt Document

Telematics Telematics

Aging Retirement aging Workforce workforce retire nt

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

VOL. 8, NO. 3

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

www.cutter.com

EXECUTIVE REPORT 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.

Elimination of redundancies

Cycle Time Reduction

Cycle time reduction

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.

Increased Focus on Business Strategies/Needs

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.

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 ©2005 CUTTER CONSORTIUM

Improved reuse of existing IT assets Leveraging technology through new business initiatives

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.

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 offthe-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 VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

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.

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

Leveraging Technology Through New Business Initiatives

Allowing easier access to management information

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.

VOL. 8, NO. 3

Providing a central repository of integrated management information Providing baseline business-IT documentation

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 www.cutter.com

EXECUTIVE REPORT 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 LongRange 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 needs to be planned. The evolution has come about as those “doing EA” have come to recognize that they are fundamentally in the same business as those engineers and professionals charged with planning electrical, telephone, and transportation networks. In each of these cases, because planning affects so many interconnected components, it

VOL. 8, NO. 3

26 must be done carefully with considerable attention to flawless execution. Enterprise architecture makes this process easier. A Better Portfolio of Projects

Projects are the way things get done in IT. The quality of strategic IT planning is reflected in the quality of projects proposed for management approval and in the care that goes into the selection of the projects that are ultimately approved. The better the information that business and IT management has with respect to the important projects underway, the better the resulting decisions will be. Because enterprise architecture provides a continuous view of the existing and planned IT environment, everyone (users, user management, top management, IT management, and IT developers) has a better understanding of how things fit together. Enterprise architecture enhances the portfolio management process by providing a broader vision of business-IT alignment and a focus on a longer time frame, which are both particularly significant. In this way, enterprise architecture lowers the business-IT risk and cost; by focusing on developing incremental plans, EA also provides users with value faster. Increased Leveraging of the Business-IT Infrastructure

One of enterprise architecture’s fundamental goals is to reduce VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE the overall cost of IT by better leveraging the business-IT infrastructure (i.e., the whole set of business, data, application, and technology assets). This means looking at each business-IT initiative and asking, how can we use what we or someone else has already done? Many critical applications for large organizations were not available 20 or 30 years ago. Today, however, most critical application areas have either commercial or inhouse solutions that can be adapted to do what is required at a much lower cost than by starting from scratch. By modeling the EA process after best-practice methods such as FEA, SCOR, and others, it is possible to provide value at a much faster pace. Improved IT Project Management

IT projects are notoriously difficult to manage, especially very large projects (VLPs). Replacing very large legacy applications and bringing in new technologies are particularly difficult. Enterprise architecture provides a great deal of useful information that makes it much easier for organizations to attack the troublesome projects. As many as 60% of VLPs are never completed. VLPs are the Bermuda Triangle of IT management. For this reason, most IT managers will go to almost any length to avoid engaging in such projects. One of the goals of enterprise architecture is to break VLPs into small, doable projects, which can be executed in a short

(three-to-six-month) period and are far less risky than a three-tosix-year project. EA accomplishes this by providing the information to do the following: Get the project off to a faster start Break the VLP into a set of smaller projects Employ a mechanism for integration and change control of the small projects Plan legacy renovation/ replacement projects Plan IT technology initiative projects Get the Project Off to a Faster Start

Most VLPs have a long startup cycle because of the amount of information that needs to be collected, organized, and digested. EA helps this process by providing a single source to key business-IT information for specific business areas. Moreover, this information has been collected using uniform standards and integrated. As a result, project teams don’t need to spend as much time getting their feet on the ground. Break the VLP into a Set of Smaller Projects

IT executives have known for decades that small projects are much less expensive and much less risky than VLPs. But managing a whole set of incremental projects has been difficult — as hard www.cutter.com

EXECUTIVE REPORT to carry off as managing one big project. There are numerous reasons for this, one of which is a lack of mechanisms for breaking big projects into smaller ones. And even if you have broken down a VLP into several architected smaller projects, coordinating and keeping control of the changes in these pieces becomes exceedingly difficult. Employ a Mechanism for Integration and Change Control

A historic problem in breaking VLPs into a set of cumulative incremental projects has been integration and change control. In most cases, not enough effort was expended in the architecture of the individual incremental projects to ensure they would fit together when completed. Enterprise architecture addresses this problem by providing a mechanism for doing this architectural work on VLPs. Change control is the second critical aspect of breaking large highrisk projects into a set of much smaller incremental projects. Even if there is a serious, consistent architecture developed before incremental projects are launched, as projects progress, there are always significant changes that need to be made in terms of the interfaces between the incremental pieces. A role of enterprise architecture is to manage those changes and make sure that major changes in the implementation are not approved

ÂŠ2005 CUTTER CONSORTIUM

without a complete understanding of what this means in terms of long-term costs, benefits, and risks. Plan Legacy Renovation/ Replacement Projects

The most expensive element in many IT organizations is maintaining and upgrading major legacy systems. Historically, this represents 50%-60% of most software development budgets. Most of that maintenance, however, is allocated to changes in business rules, new outputs, and certain interfaces with other systems. However, there is a strong reluctance to invest in major changes to legacy systems on a regular basis. Enterprise architecture treats all legacy systems (especially major ones) as IT assets that must be regularly updated. This means that going forward, plans must be in place for keeping all systems up to current standards. Ultimately, as an increasing number of major parts (business areas) of the enterprise are automated and integrated with other parts, the constant renewal/ replacement of legacy systems will need to be considered. This process is ongoing and will become more critical every year. The network of IT applications makes it possible for organizations to be more efficient and to get by with fewer people. But there is no free lunch; the core application systems have to be constantly

redefined and repaired. This requires a new level of planning. Enterprise architecture helps business-IT management look at the entire systems environment and spot areas that have to be upgraded before they become points of failure. Plan IT Technology Initiative Projects

Finally, enterprise architecture also provides a framework for addressing IT technology initiative projects, which are intended to test out projects for emerging technologies or major new uses of existing technologies. Because of its focus on the careful implementation of new technologies, enterprise architecture provides a framework for identifying important new technologies and setting up low-cost, small-scale implementations. This enhances the organizationâ&#x20AC;&#x2122;s ability to pilot new technologies and to develop basic skills for larger projects using the same technologies. Increased Focus on IT Asset Management

Over the years, most large organizations have invested hundreds of millions of dollars in their IT assets. Many of these organizations are now recognizing that in the case of the enterpriseâ&#x20AC;&#x2122;s IT assets, the whole is considerably greater than the sum of its parts. Today, organizations operate faster with far fewer people than they did just a few years ago, not just because of one or two so-called

VOL. 8, NO. 3

ENTERPRISE ARCHITECTURE ADVISORY SERVICE

killer apps but rather as a result of streamlining entire business processes and integrating whole sets of systems end to end.

interesting to consider what we could be doing today if we were able to truly leverage technology to the max.

Enterprise architecture is moving to make this process more explicit. EA allows business-IT management to see how the entire business-IT network of applications and data fits together and to make sure that future projects extend and enhance the existing investment. This change in orientation is shown in the increased management of all the IT assets over an extended period. These assets include:

Historically, our organizations have put our IT infrastructure and environment together a little at a time over a period of decades, not unlike the way countries built their high-speed auto routes. Then, all of a sudden, we discovered that everybody, or nearly everybody, in the organization that had an office had a computer and that those computers were hooked to networks that were hooked to everyone else’s computers. We found that our people were using computers more and more, not just for the applications that supported their business functions but for everything they did — letters, spreadsheets, memos, presentations, collaboration — everything!

Data assets Application assets Core applications Purchased applications Technology assets Anticipating the future Constant scanning of businesstechnology changes Forecasting effect of new technologies on strategic IT plan Forecasting effect of new business changes on strategic IT plan CONCLUSION IT has reached a new stage. If the whole is greater than the sum of its parts, and if it is possible to rethink the way organizations everywhere do business, then it is

VOL. 8, NO. 3

This new era of the “digital enterprise” that runs on its IT infrastructure brings new responsibilities for IT asset management. Today, our IT systems are so important that if they are down even for a short time, everybody in the organization notices. We’ve reached a stage like that of other utility functions: people are only aware of IT when something fails. This means that those involved in IT asset management have to plan, design, and architect everything to new standards of performance, security, and reliability.

BEAM is the result of solving dozens, maybe hundreds, of practical problems over many years. It has proven useful and teachable, which are good signs. Enterprise architecture is no longer of interest only to researchers and academics. Big, complex systems are common, as are big failures. Organizations have to be better prepared to deal with all the elements of enterprise architecture, especially the business and data architectures. Our organizations are moving faster, and they need systems that are more flexible and more directly related to the business environment — that is what enterprise architecture is all about. REFERENCES 1. Benson, Robert J., and Marilyn M. Parker, with H.E. Trainor. Information Economics: Linking Business Performance to Information Technology. Prentice Hall, 1988. 2. Brodie, Michael L., and Michael Stonebraker. Migrating Legacy Systems. Morgan Kaufmann Publishers, 1995. 3. Davis, Steven P. “The Walt Disney Company Enterprise Architecture Overview.” Presented at Enterprise Architecture Summit 2004, Rancho Mirage, California, USA, June 2004. 4. “Enterprise Data Flow Architecture.” The Ken Orr Institute, 1988.

www.cutter.com

EXECUTIVE REPORT 5. Helland, Pat. “Metropolis: The Evolution of the IT Shop into the World of Services.” Presented at Enterprise Architecture Summit 2004, Rancho Mirage, California, USA, June 2004. 6. Orr, Ken. “Extending Zachman: Enterprise Architecture and Strategic IT Planning.” Cutter Consortium Business-IT Strategies Advisory Service Executive Report, Vol. 7, No. 4, April 2004. 7. Orr, Ken. “Pushing the Envelope: Managing Very Large Projects.” Cutter Consortium Agile Software Development and Project Management Advisory Service Executive Report, Vol. 5, No. 7, July 2004. 8. Orr, Ken. “The Three Faces of Enterprise Architecture.” Cutter Consortium Enterprise Architecture Advisory Service Executive Report, Vol. 7, No. 1, January 2004. 9. Orr, Ken, and Andy Maher. “The Digital Age: Managing Digital Assets.” Cutter Consortium Business Intelligence Advisory Service Executive Report, Vol. 4, No. 11, November 2004.

10. Porter, Michael. Competitive Strategy: Techniques for Analyzing Industries and Competitors. Free Press, 1980. 11. Rummler, Geary A., and Alan P. Brache. Improving Performance: How to Manage the White Space in the Organization Chart. 2nd edition. Jossey-Bass,1995. ABOUT THE AUTHORS Ken Orr is a Fellow of the Cutter Business Technology Council and a Senior Consultant with Cutter Consortium’s Agile Software Development and Project Management, Business Intelligence, Business-IT Strategies, and Enterprise Architecture Practices. He is also a regular speaker at Cutter Summits and symposia. Mr. Orr is founder and Chief Researcher for The Ken Orr Institute, a business-technology research organization. Previously, he was an Affiliate Professor and Director of the Center for the Innovative Application of Technology with the School of Technology and Information Management at Washington University. He is an internationally recognized expert on technology transfer, software engineering, information

architecture, and data warehousing. Mr. Orr has more than 30 years’ experience in analysis, design, project management, technology planning, and management consulting. He is the author of Structured Systems Development, Structured Requirements Definition, and The One Minute Methodology. He can be reached korr@cutter.com. Bill Roth is the Chief Enterprise Architecture for the Kansas Department of Transportation (KDOT) and Chief IT Architect for the state of Kansas. Mr. Roth has been involved for more than 20 years in developing and managing major application systems and has been involved directly in EA at KDOT since its inception. Ben Nelson is the CIO for the Kansas Department of Transportation. He has held this position for the past 18 years. Prior to that, Mr. Nelson held a series of positions in the US Navy. Mr. Nelson is also Cochairman of the Computer and Information Technology Committee of the Transportation Research Board and is involved in a wide variety of IT and transportation management activities.

VOL. 8, NO. 3

About the Practice

Enterprise Architecture Practice Today the demands on corporate IT have never been greater. Cutting costs and accelerating time to market for individual line-of-business projects are still priorities, but even that’s not nearly enough anymore. Companies are now looking for strategies to better leverage their entire IT infrastructure. They want IT to deliver sophisticated enterprise applications that can provide value across many lines of business and provide marked differentiation from their competitors. The Enterprise Architecture Practice provides the information, analysis, and strategic advice to help organizations commit to and develop an overarching plan that ensures their whole system fits together and performs seamlessly. The subscription-based services within this practice — Enterprise Architecture Advisory Service and Web Services Strategies journal — offer continuous research into the latest developments in this area, including Web services, enterprise application integration, XML, security, emerging and established methodologies, Model Driven Architecture, how to build an enterprise architecture, plus unbiased reports on the vendors and products in this market. Consulting and training offerings, which are customized, can range from mapping an infrastructure architecture to transitioning to a distributed computing environment. Products and Services Available from the Enterprise Architecture Practice

• • • • • •

The Enterprise Architecture Advisory Service Web Services Strategies Consulting Inhouse Workshops Mentoring Research Reports

Other Cutter Consortium Practices

Cutter Consortium aligns its products and services into the nine practice areas below. Each of these practices includes a subscription-based periodical service, plus consulting and training services.

• • • • • • • • •

Agile Software Development and Project Management Business Intelligence Business-IT Strategies Business Technology Trends and Impacts Enterprise Architecture IT Management Measurement and Benchmarking Strategies Enterprise Risk Management and Governance Sourcing and Vendor Relationships

Senior Consultant Team Our team of internationally recognized specialists offers expertise in security issues, e-business implementation, XML, e-business methodologies, agents, Web services, J2EE, .NET, high-level architecture and systems integration planning, managing distributed systems, performing architecture assessments, providing mentoring and training, overseeing or executing pilot projects, and more. The team includes:

• • • • • • • • • • • • • • • • • • • • • • • •

Scott W. Ambler Douglas Barry Don Estes Michael Guttman Paul Harmon Ian S. Hayes Tushar Hazra Peter Herzum J. Bradford Kain Bartosz Kiepuszewski André LeClerc Arun Majumdar Jason Matthews Tom Marzolf Terry Merriman James Odell Ken Orr Wojciech Ozimek Michael Rosen Rob Shelton Oliver Sims Borys Stokalski William Ulrich Tom Welsh