Business Enterprise Architecture Modeling

Business EnterpriseArchitecture Modelingby 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.

Enterprise Architecture

Vol. 8, No. 3

http://www.cutter.com

About Cutter ConsortiumCutter Consortium is a truly unique IT advisory firm, comprising a group of morethan 100 internationally recognized experts who have come together to offercontent, consulting, and training to our clients. These experts are committed todelivering top-level, critical, and objective advice. They have done, and are doing,groundbreaking work in organizations worldwide, helping companies deal withissues in the core areas of software development and agile project management,enterprise architecture, business technology trends and strategies, enterprise riskmanagement, metrics, and sourcing.

Cutter offers a different value proposition than other IT research firms: We give youAccess to the Experts. You get practitioners’ points of view, derived from hands-onexperience 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’shappening in the marketplace. With Cutter Consortium, you get the best practicesand lessons learned from the world’s leading experts; experts who are implementingthese techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats includingcontent 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 allenterprises, or all departments within one enterprise, or even all projects within adepartment. Cutter believes that the complexity of the business-technology issuesconfronting corporations today demands multiple detailed perspectives from which acompany can view its opportunities and risks in order to make the right strategic andtactical decisions. The simplistic pronouncements other analyst firms make do nottake into account the unique situation of each organization. This is another reason topresent the several sides to each issue: to enable clients to determine the course ofaction that best fits their unique situation.

For more information, contact Cutter Consortium at +1 781 648 8700 [email protected].

Cutter Business Technology Council

Access to the

Experts

Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Lou Mazzucchelli Ed YourdonRob Austin



mailto:[email protected]

We have to be very carefulabout making even smallchanges in IT today becausethey can impact the entireorganization.

— TransportationDivision Director

All of a sudden, enterprise archi-tecture (EA) is a very hot activity.Most large enterprises today havesome sort of EA program, and bil-lions of dollars are being spentaround the globe on enterprisearchitectures in order to helporganizations manage their vastIT expenditures and exposures ina more rational fashion. An inter-esting question is, why now? Whyis it that enterprise architecture issuddenly so hot? Why are enter-prise architects in such demand?

We think the primary reasonenterprise architecture hasbecome so interesting is that, atsome point during the past fewyears, IT made a quantum leapinto a new domain, a domain inwhich IT assets are increasinglyimportant to the overall success(or failure) of large enterprises.Suddenly, people in large organi-zations around the world are dis-covering just how dependent theyare on IT systems and IT infra-structure as well as how inter-dependent all the various piecesof IT are with one another andwith users inside and outside theorganization. Most importantly,people are seeing that IT enablesnew things to be done, things thatwere not possible before. Onceagain, we see the truth behindthe old saw “The whole is greaterthan the sum of its parts.”

Enterprise architecture, as itsname implies, is all about high-level thinking and high-leveldesign. IT and communicationshave become so complex and sointerrelated in large organizations,and enterprise data has becomeso fundamental, that it is nolonger possible to design, build,and install major systems in isola-tion. Someone has to be thinkingabout the big picture, about howall the pieces fit together, becausethe big picture has become sucha significant issue.

This Executive Report discusses anew way of looking at enterprisearchitecture that encompassesboth advanced and traditionaldesign concepts. The EA frame-work that we propose here iscalled BEAM, short for BusinessEnterprise Architecture Modeling.

Business Enterprise Architecture ModelingENTERPRISE ARCHITECTUREADVISORY SERVICEExecutive Report, Vol. 8, No. 3

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


While this approach builds onmany of the historical enterprisearchitecture frameworks, it is inmany ways a different approach,a much more business- anddata/information-driven strategy.

THE THREE FACES OFENTERPRISE ARCHITECTURE

Because of its newness in themarketplace, there is confusionsurrounding what enterprisearchitecture is exactly and itsvalue to business and IT manage-ment. A recent Cutter ConsortiumExecutive Report [8] laid out themajor strategies for enterprisearchitecture that are popular inNorth America.1 Those threeapproaches are:

1. Technology-driven enterprisearchitecture

2. Business (process)-drivenenterprise architecture

3. Federal Enterprise Architecture(FEA)

Since that report was published,a great deal of practical work has

been done to bring these threedifferent approaches into betteralignment. While these threeapproaches still represent threedifferent views of what enterprisearchitecture is about, there isgreater consensus today abouthow they complement each other.The Cutter report made a strongcase for business-driven enterprisearchitecture as the key to the long-term success of EA programsregardless of whether the enter-prise is public or private. In thetime since the report was pub-lished, the enterprise architecturediscipline has moved to reinforcethis conviction.

Enterprise architecture is now at a period of consolidation andreassessment. More and moreorganizations are extracting valuefrom their EA programs at a vari-ety of levels. These organizationsare increasingly aware of how crit-ical enterprise architecture is totheir enterprises over both theshort and long term. And there isalso a whole new set of organiza-tions that are just adopting enter-prise architecture and trying toput it into practice. Both of theseclasses of users need guidance.Those just getting started needadvice on where to begin, whatkinds of skills they need, whatsteps they should take, and so on.Those well underway need guid-ance on how to extend the impact

and value of their EA program.This report is intended to addressboth of these audiences.

BEAM — AN EXTENDEDEA FRAMEWORK

In a world of acronyms, addingyet another is not likely to begreeted with universal applause;however, acronyms do seemto help people remember anddifferentiate between differentapproaches. We chose BEAM asan acronym because it capturesthe business-process orientationthat largely drives our strategy andbecause “physical beams” arestructural members of buildingsand houses, so BEAM makessense in an architectural settingas well.

As with any good framework,creating BEAM involved tyingtogether a number of differentideas: mental models, proc-ess models, diagrammingapproaches, and organizationalstrategies. Also, like any goodmethodology, much of BEAM issimply applied common sense.We do not apologize for that fact.Indeed, we have all been involvedin business, systems, and technol-ogy for quite a long time and, asa result, have found things thatwork well in doing systems plan-ning, requirements, and high-leveldesign, and we have discovered

VOL. 8, NO. 3 www.cutter.com

22 ENTERPRISE ARCHITECTURE ADVISORY SERVICE

The Enterprise Architecture Advisory Service Executive Report is published by Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA02474-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: [email protected]; Web site: www.cutter.com. Group Publisher: Kara Letourneau, E-mail: [email protected]. Production Editor:Linda M. Dias, E-mail: [email protected]. 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/orback issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail [email protected].

1There are an increasing number of EA frame-works being promoted and deployed aroundthe world. Many of these have decades ofR&D behind them, as does BEAM. The threeapproaches described here are the ones thathave become increasingly popular in NorthAmerica, and we believe in northern Europeas well, but this does not mean that wehave a full understanding of what all theseapproaches recommend or what theirstrengths and weaknesses are.





that these things also seem towork well in doing EA.

But BEAM is no panacea; rather,it is a practical approach to doingsomething very important. Atbase, enterprise architecture isabout getting people — all sortsof people — within the organiza-tion to think in both broader andlonger terms about IT, IT infra-structures, and the core data andsystems that IT supports. Duringthe past 30 or 40 years, computersand communications have playeda major part in restructuring most,if not all, major organizationsaround the world. Today, organiza-tions are now significantly differ-ent in the ways they operate andare managed — much differentthan they were just a decade ortwo ago. Information no longerjust circulates within organiza-tions, it literally beams acrossthe organization at light speed.

But while computers and com-munication have revolutionizedthe way organizations operate, thesystems, connections, and hard-ware involved in this amazingtransformation are largely invisibleto most who use it and even moreinvisible to those who make thekey decisions about how manyresources should go into IT andfor what projects.

With the coming wave of evermore powerful wireless devices,the underlying IT infrastructurewill be even harder to visualize.But IT, particularly as it relatesto an enterprise’s computer and

communications infrastructureand to its core (mission-critical)applications, can hinder as well asfacilitate management strategiesand plans. Poor IT strategies cancreate arthritic organizations justas it can create agile ones.

In the same sense that moderncities and nations depend upontheir fundamental infrastructureinvestments in utilities, transpor-tation, communications, and soon, so too do large enterprisesdepend upon their IT infrastruc-ture investments. As a result,savvy management increasinglyrealizes that it will have to investboth wisely and well if it is goingto be competitive in the 21st cen-tury. Enterprise architecture, then,is a tool for leveraging technologyto make things happen faster andat less cost.

THE ELEMENTS OF BEAM

Like any good approach to solvinglarge problems, BEAM involvesseveral interrelated components.The most important of these com-ponents, discussed in detail in thissection, are:

A basic Enterprise SystemsFeedback Model (ESFM)

A new way of consideringbusiness-technology alignmentand innovation

An extension to the classicZachman Framework

Treating the role of enterprisearchitect as a “committeeof skills”

The Enterprise SystemsFeedback Model

There are literally hundreds ofways of thinking about enter-prises. The one underlying BEAMis the Enterprise Systems Feed-back Model, which is derivedfrom cybernetics (systems think-ing). The idea is that an enterprisecan be thought of as a componentin a larger environment; whatthe enterprise does is convertresources from sources intoproducts and services for somegiven market or set of customers.Figure 1 shows these componentsconnected in such a feedbackstructure.

In this model, the enterprise isrepresented as a black box thattakes in “resources” and produces“products” or “services.” Theseproducts or services, in turn, areused by customers or clients to“do something” (that somethingwe refer to as “product usage”).As a result of producing theseproducts and services, there isalso “product feedback,” whichdeals with how well the productmeets its internal requirements,and “customer (or usage) feed-back,” which deals with how wellthe product meets the customer’sexpectations. If we were to applythis model to the auto business,for example, product feedbackcould be thought of as the “SixSigma” (quality) part of themodel, and the customer (usage)feedback might be referred toas the “J.D. Power’s” (customerrelationship) part of the model.

©2005 CUTTER CONSORTIUM VOL. 8, NO. 3

EXECUTIVE REPORT 33

ESFM brings two important ideasto the study of enterprise archi-tecture: (1) all enterprises are inbusiness to “make something” or“provide some service,” and (2)they survive by adding value.

One of the great things aboutthe ESFM is that it works both inthe public and the private sector.Later, when we discuss the USgovernment FEA model, we willbe able to show the necessarycorrespondences between the

ESFM and FEA models withoutany difficulty.

While the ESFM may seem toosimple for those who think of theorganization as a complex thing, itis useful for getting people to thinkof their organization as a systemcomponent itself. In a systemsfeedback sense, IT is all aboutsystems and infrastructure. If onecannot understand how those sys-tems and infrastructure relate tothe business goals and objectives,it is exceedingly difficult to tie IT

decisions back to critical businessdecisions.

Benson and Parker’s SquareWheel: Business and TechnologyAlignment and Innovation

A second conceptual model thatis extremely important to BEAM isBob Benson and Marilyn Parker’s“square wheel” model [1]. Figure2 shows this model, with the leftside of the diagram representingthe business domain, and the rightside representing the technologi-cal or technology domain. In thebusiness domain, there are twocomponents: business planningand business operations. Similarlyin the technology domain, thereare also two components: tech-nology planning and technologyoperations. The square wheel getsits name from the sequence oflinkages between these variouscomponents.

Between business planning andbusiness operations, there is the“organize” function. Betweenbusiness operations and technol-ogy operations there is an “align”function. Between technologyoperations and technology plan-ning, there is the “opportunity”function. And, finally, betweentechnology planning and businessplanning, there is the “impact”(innovation) function.

For the most part, technologymanagement experts havefocused almost exclusively onthe organizing and aligning func-tions to bring business and ITcloser together. They tended to



Business

Planning

Technology

Planning

Technology

Operations

Business

Operations

Impact

Align

Organize Opportunity

Figure 2 — Benson and Parker’s square wheel [1].

Sources

(Business Partners)

Enterprise/AgencyMarket

(Customer/Client)

resourcesproducts/

services

product

usage

product feedback

customer (usage) feedback

Figure 1 — The Enterprise Systems Feedback Model.2

2There are hundreds of examples of systems models in literature, but this model is adapteddirectly from Improving Performance [11].



EXECUTIVE REPORT 55

leave out the link between tech-nology operations and technologyplanning. It might have madesense 20 or 30 years ago to havemost of IT’s focus be on aligningtechnology with the business as itexisted, but today, technology ischanging the way business isdone everywhere. Key initiatives,even entire business market-places, have been created in thepast 10 or 15 years that leveragenew technologies to delivergoods and services in previouslyunthinkable ways.

Benson and Parker have providedus, then, with an important newway of thinking about manage-ment communication. One ofthe most difficult problems con-fronting business and IT managerstoday is communication. Histor-ically, in most organizations, top ITmanagement has not always beenpart of the highest-level businessdecision making. Benson andParker’s square wheel shows justhow important including IT man-agement is and will be in makingdecisions about the enterprise’s ITassets — what systems to attack,what technologies to invest in,and so on.

Increasingly, organizations relyon their IT infrastructure andsystems to produce value. In orderto be competitive, public and pri-vate organizations will have tobecome much more agile. Theywill need to continuously improvetheir business processes, find theright data to solve managementproblems, and connect the rightpeople both inside and outside

their organizations via real-timecollaboration. And organizationswill have to be increasingly “trans-parent.” Their systems will haveto be documented and auditable.New requirements like thoseimposed by the US Sarbanes-Oxley Act focus increased scrutinyon the role that IT systems playin today’s management of largeorganizations.

Extending Zachman’s Framework

A previous Cutter Executive Report[6] discussed the need to extendthe Zachman Framework usingurban/transportation planningrather than building architectureas the basic model for enterprisearchitecture. This extension hasproved extremely useful, both indoing enterprise architecture andin explaining it to business and ITmanagement.

Recently, a number of other influ-ential organizations have begun tospeak in similar terms. For exam-ple, Microsoft now refers to whatit calls its “Metropolis” metaphor[5]. This model reflects a newthinking on the part of high-levelenterprise architecture developersand consultants. Similarly, Disneyhas begun to speak of the “build-ing code metaphor” in which itrefers to “master plans” and“building codes” as the keyelements [3].

We feel the urban/transportationplanner is a more realistic analogythan a classic building architect.Urban planners are interestednot just in individual buildings

(systems) but in the entire region(enterprise). Urban plannersdevelop long-range documentsthat promote the well-being andhappiness of all the residents(users). To do this, they createland-use plans, negotiate withdevelopers, and help set buildingcodes (architectural standards) —building architects do none ofthese activities. In this regard,urban planners do a great manythings for cities and counties thatenterprise architects must do forthe enterprises and divisions ifthey are to be successful.

Transportation planners areinvolved in planning the mostimportant infrastructure in anycity or region — the highway/public transportation infrastruc-ture that moves the region’sgoods, services, and people.That physical infrastructure isboth very expensive and verydifficult to put in place. Moreover,highways and light rail areextremely hard to modify oncethey are constructed. So trans-portation planners must beexceedingly careful and detailedin their planning. Transportationplanners routinely look 20 or 30years into the future when think-ing about major arterial roads,intersections, and projects; like-wise, enterprise infrastructureplanners are going to have to planfurther and further ahead. If enter-prise architecture is to become amature discipline, it will have tomodel itself after other maturedisciplines like urban and trans-portation planning. In developing

the BEAM framework, we haveworked hard to create a frame-work that makes sense and thatparallels similar disciplines.

The BEAM Enterprise Architect:A “Committee of Skills”

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

— Oxford Dictionary ofEnglish Etymology (Oxford

University Press, 1966)

Increasingly, our work brings usinto contact with a wide variety ofEA organizations — each differentbut with a similar set of problemsand constraints. One issue thatcontinues to concern EA man-agers is determining the kind ofpersonalities, skills, and trainingthat are needed to do enterprisearchitecture work.

In putting together the BEAMframework, we have come upwith some clear ideas about rolesand skills that are needed in anEA group. What we have found,for example, is that the “completeenterprise architect” doesn’t exist.Rather, we concluded that thereis a “committee of skills” that arounded enterprise architectureteam should contain. Theseskills include:

Urban planning skills

Transportation planning skills

Building inspection skills

County agent skills

Building architect skills

Librarian skills

The remainder of this sectionexamines each of these skill setsas they apply to BEAM.

Urban Planning Skills

The first set in the committee ofskills is urban planning. Urbanplanners work in an environmentin which they must try to reach aconsensus among several com-peting parties. Urban planninginvolves working with developers,elected officials, and communityrepresentatives to further theentire community. As it turns out,this is much the same job thatenterprise architects face everyday in the business-IT workplace.

Urban planning skills involveplanning, research, negotiation,and, most importantly, communi-cation. Planners must be technicalenough to understand the dynam-ics of urban growth and decayand sensitive enough to get war-ring parties to sit down and nego-tiate workable, economicallyviable solutions. Enterprise archi-tects must be able to get usermanagement, IT management,and vendors to reach solutionsthat work in both the short andlong term.

Transportation Planning Skills

In real urban or regional environ-ments, the highway engineers areoften responsible for the mostprofound changes. In the US, the

period from the mid-1950s to the1980s, for example, was domi-nated first by the development ofthe interstate road system andthen by the “ring roads” thatincreasingly encircled majorcities. These changes broughtabout profound revolutions inour cities and suburbs. Interstateroads funneled people further andfurther away from inner cities; andring roads, in an attempt to allowinterstate traffic to bypass thecentral cities, made high-speed,light-rail public transportationalmost impossible, furthering thedeterioration of the central core.

So transportation planners havean enormous burden; they haveto be able to decide today wherepeople and businesses will belocated decades from now. To dothis, they look at all the possibleinformation: economic data,demographic information, as wellas changes in technology andlifestyle.

In enterprise architecture, enter-prise infrastructure architects takeon the same role as the trans-portation planners. They mustlook at what IT infrastructureexists today; try to imagine howand where people will be operat-ing in the future; and then comeup with approaches that bestprovide a communication andcomputer infrastructure that isboth reliable and secure. Todo this job well, enterprise infra-structure architects must be goodat detailed planning, but theymust also be highly skilled at





EXECUTIVE REPORT 77

research, forecasting, and, again,communication.

Building Inspection Skills

In the world of urban planning/zoning/building codes, it is thebuilding inspector who takeson the role of enforcer. The build-ing inspector is responsible forreviewing plans, checking blue-prints, and periodically visitingbuilding sites to see that the plansand all the requisite buildingcodes are followed.

In enterprise architecture, theenterprise project architects andenterprise project architecturereview teams play the role ofbuilding inspector. In most matureEA organizations, this process isone of the key ways in whichenterprise architecture directlyaffects the long-term success ofan enterprise’s IT management.Since enterprise architecture isseen in many organizations as atechnology-control function, this isnot that surprising. In the betterEA groups, this inspection proc-ess is pushed further and furtherdown in the organization, so thatthe people who understand thelocal environment are also theones charged with ensuring thatindividual projects meet enter-prise standards.

One of the material differencesbetween enterprise projectarchitects and building inspec-tors in the real world is thatbuilding inspectors operate in

an environment that has muchmore specific industry support.Because urban planning andbuilding code inspection havebeen around for decades, therules and procedures are wellworked out. In addition, buildingcodes are normally a reflection ofindustry standards, and, therefore,there are industry training classesavailable to help practitioners.For example, if you want to be alicensed electrician or a licensedplumber, you must attend specificclasses and perform specific tasksto get your license. Moreover,before you can be licensed, youmust have served as an appren-tice for a period of time. With allof these standards in place, thebuilding inspection departmentdoes not have to assume respon-sibility for training practitioners; itonly has to monitor their work.

The enterprise architecturesituation is quite different. EAstandards and regulations arestill evolving at a rapid rate, and,because there are few people inthe organization that understandthose standards and regulations,training, counseling, and men-toring are especially importantissues. And while there is a cer-tain amount of knowledge transferthat takes place as a result ofproject-review sessions, in thelong haul, enterprise architecturewill fail to take hold in mostorganizations unless significantup-front training is provided.

County Agent Skills

Between the end of the US CivilWar and the beginning of WorldWar I, agriculture in the USchanged dramatically. Before theCivil War, American agriculturewas basically on par with the restof the world. However, by thebeginning of World War I,American agriculture was clearlyahead of everyone else. Studentsof knowledge management creditthis amazing leap forward to twomajor innovative programs: (1)the land-grant and (2) the countyextension service/county agent.

As the name implies, land-grantcolleges and universities cameinto existence through an act ofthe US Congress, which allowedstates to sell large blocks of pub-licly owned land and earmark themonies obtained from these salesfor funding colleges and universi-ties devoted to research andteaching in the practical arts,especially agriculture and engi-neering. Some of the greatestuniversities in the country werecreated as land-grant schools(e.g., Ohio State University,Texas A&M, and Kansas StateUniversity). These schools con-ducted research in agriculture,pioneering such breakthroughs ashybrid seeds, new animal breed-ing techniques, and new pest con-trol strategies. This led to hugeamounts of information to helpfarmers and ranchers producemore at less cost.

But the research produced byland-grant colleges did not auto-matically change farming in theUS. At the time, many farmerswere illiterate, and even if theyhad been of the mindset to trynew things, few were awareof the availability of new researchinformation. This is where thecounty extension service and thecounty agent came into play.

The county extension service wascreated by the US Department ofAgriculture to provide technicalsupport for farmers and ranchers.In turn, the county extension ser-vice created the position of countyagent, whose job was to reviewthe research coming out of theland-grant colleges, internalizethat information, and then takeit out and demonstrate it to thefarmers and ranchers. This provedto be amazingly successful. Mostfarmers and ranchers of that timewere very practical people (asthey are now), with little time tospare. County agents brought theinformation to them and showedthem how to use whatever itwas that the latest researchrecommended.

Today, county agents would beclassified as mentors or field con-sultants. Their job in enterprisearchitecture is to take plans, stan-dards, and rules to the individualdevelopers and users and toexplain and demonstrate them.In general, this means communi-cating the following: (1) the stan-dards and rules; (2) the reasonsfor those standards; and (3) how

to use those standards and rules.Like farmers and ranchers, devel-opers are also practical peoplewith little time to spare. Hands-ontraining helps people understandhow to leverage enterprise archi-tecture ideas, and mentoring linksthat information to real-worldcircumstances.

Over the past few years, we havebeen promoting the “enterprisearchitect as county agent.” Thisidea has met with nearly unani-mous interest and support. Moreand more organizations are com-ing to understand that for enter-prise architecture to take root inan organization, there needs tobe more than just EA projectreview and audit sessions. Peopleneed to know why and how thesestandards came into being andhow to use them in the mostefficient and practical ways.

Building Architect Skills

In BEAM’s committee of enter-prise architecture skills, the skillsof a true building architect arestill necessary. In the real worldof large-scale construction, build-ing architects are responsible forworking with owners/developers,coming up with detailed plans,and then staying with the projectthroughout the construction, beingresponsible for quality and changecontrol. This is a role for whichthere is a direct correlation inenterprise architecture, especiallyon large projects.

In a recent Cutter ExecutiveReport [7], I described several

issues that play a part in thefailure of very large projects. I dis-cussed 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 designand then stay with their projectsover the entire length of a givenconstruction cycle. Here we rec-ommend that enterprise projectarchitects do the same — thatthey be responsible for detailrequirements and design and thenbe charged with quality controland change control of thosedesigns.

Throughout history, buildingcodes and design standards havealmost always been the result ofdisasters. One only has to thinkof the famous 1906 San Franciscoearthquake and fire or theTacoma Narrows Bridge disasterin 19403 to see the point. Indeed,in one issue of the Society ofMechanical Engineers publication,there was a discussion of theorganization’s history, and itturned out that the organizationcame into being as a direct resultof boilers blowing up and trestlesfalling down during the latter partof the 19th century. As a resultof these disasters, engineeringsocieties were formed, andpoliticians set up rules thatincluded professional testing andlicensing. Something similar will



3On 7 November 1940, the Tacoma NarrowsBridge, a suspension bridge, collapsed due to wind-induced vibrations. Situated on theTacoma Narrows in Puget Sound, near thecity of Tacoma, Washington, USA, the bridgehad been open to traffic for only four months.


eventually happen with software,but until that occurs, the closestthing we have is training andcertification.

Librarian Skills

The final set of skills that we rec-ommend as being important for aserious EA group is that of a clas-sic librarian. People who studylibrary science learn a number ofimportant things: how to analyzeinformation, how to classify thatinformation, and how to helppeople retrieve information froma large organized store.

In this world of informationoverload, being able to analyze,index, and retrieve huge amountsof information is increasinglyimportant. For more than adecade, IT professionals have pur-sued the idea of reuse, but reusehas proved largely elusive. Part ofthe reason is that while the exactcomponent that we might needin a given circumstance alreadyexists, finding it can be a majorundertaking; if people think thatfinding something will take toolong, they are more likely to buildtheir own.

Currently, enterprise architecturebreaks down into business, data/information, application, and tech-nology domains. Each of thesedomains requires skills for whichlibrarians are trained. Over thenext few years, we expect to seeincreased demand for these skillsin enterprise architecture groups.

The Committee of Skills in Operation

In operation, our committee ofskills may take several differentforms. In a large organization,each skill set may end up beinga separate section of an overall EAgroup. In this kind of environment,people tend to specialize by theirspecific roles. In turn, people withunique skills get classified intospecific jobs.

In small organizations, individualsoften wear more than one hat. Forinstance, an enterprise architect ina small group may have to playthe role of urban planner one dayand building inspector the next.Or he or she may have to be infra-structure planner one day andcounty agent the next. In smallorganizations, circumstancesdefine what has to be done, soflexibility is a must.

Enterprise architecture is such anew field that it will be some timebefore we have enough experi-ence to know exactly what theroles and responsibilities will looklike. Until that time, the commit-tee of skills is a good way to thinkabout how we staff and manageenterprise architecture.

THE BEAM PROCESS

BEAM is a systematic approachfor developing enterprise archi-tecture for any size organization.It involves the following fivemajor phases:

1. Strategic intentions

2. Business architecture

3. Data/information/contentarchitecture

4. Application architecture

5. Technology architecture4

For small organizations, a high-level version is usually sufficient togive them enough information todo their IT planning and manage-ment. For large organizations,BEAM has two major phases: ahigh-level version followed by anumber of lower-level architec-tures for each major part (busi-ness area) of the business.

This may appear somewhat con-fusing at first. What we do is usethe process in Figure 3 first to do ahigh-level “enterprise” version ofour enterprise architecture (onlyabout 10 to 15 diagrams) andthen, depending on the organiza-tion, develop lower-lever versionsby “business area.” In practice,these business-area EAs typicallyevolve out of day-long joint appli-cation development (JAD) ses-sions with 15 to 25 users. At theend of this second cycle with thebusiness areas, we have found itnecessary to go back and reworkthe enterprise-level versionas well.

In each of the following sections,the same general frameworkshown in Figure 3 is used todrive the activity.


EXECUTIVE REPORT 99

4The first four architectures here represent aclassic way of looking at enterprise architec-ture. Recently, we have been working to bring yet another development/integration/maintenance/migration architecture into thepicture as well.

Strategic Intentions

The first step of BEAM, gatheringstrategic intentions, involvesunderstanding the general direc-tion of the enterprise as seen bytop management, taking intoaccount external forces. In anideal world, enterprise architec-ture operates with a full-blown,three-to-five-year enterprise strate-gic plan. In those organizationswhere such a plan does not existor where such plans cannot bedivulged, IT planners must derivewhat they see as the organiza-tion’s strategic intentions fromtheir perception of top man-agement’s direction over time,including such items as budgetsand changes in organizationalstructure as well as any explicitinitiatives.

Over the long haul, it is possible tocome up with a reasonable set ofstrategic intentions by looking atother similar-sized organizationsin similar industries. Strategic

intentions are normally updatedas a result of interviews with topexecutives and facilitated sessionswith executive committees.

Business Architecture

The next major step in BEAMinvolves developing the businessarchitecture. Of the four majorenterprise architecture compo-nents, the business architectureis by all measures the most criti-cal, since it ties the basic andadvanced business functions tothe other pieces of the enterprisearchitecture. Within BEAM, busi-ness architecture is made up ofthree subareas:

1. Business context

2. Business value maps

3. Business processes

Business Context

A key subprocess within thebusiness architecture step is thecreation of one or more context

diagrams such as the one shownin Figure 4. These diagrams showthe major organizational units,business partners, and systemsconnected by arrows that repre-sent the messages (transactions,documents). These diagramsprovide a quick, easily under-standable map of the primaryinteractions between parts of theorganization and its business part-ners. The development of a goodbusiness context diagram pro-vides a consistent framework forthinking about an organization’sinputs, outputs, and outcomes.

In practice, more than one work-ing context diagram is often pro-duced. And although it often takesmore than one session to producean enterprise context diagram allparticipants can agree upon, theeffort helps to create a sharedunderstanding of the flow of infor-mation within the enterprise. Oneof the most significant benefits ofthe context-diagramming processis that it allows everyone involvedto express their knowledge and toreach a common understandingof how the pieces of the organi-zation communicate with oneanother and with outside entities.Business context diagrams alsoprovide a starting point for thebusiness value maps and businessprocess diagrams.

Business Value Maps

A process can be seen as a“value chain.” By its contri-bution to the creation ordelivery of a product orservice, each step in a



Strategic

Intentions

Bu iness

Context

Strategic

Intentions

Business

Context

Business

Value

Business

Process

Data

Architecture

Application

Architecture

Technology

Architecture

Business

Architecture

Figure 3 — The BEAM approach.


process should add valueto the preceding steps.

— Geary A. Rummler andAlan P. Brache, Improving

Performance [11, p. 45]

The business value map canbe traced back to the work ofMichael Porter of the HarvardBusiness School. In 1980, Porterpublished the first of a set ofdiagrams that he called businessvalue diagrams (see Figure 5)[10]. The most important featureof the diagrams was the idea thatall enterprises have (1) a set ofprimary activities that are thefundamental value-addingprocesses by which enterprisesproduce their sets of products

and/or services and (2) a set ofsupporting activities that provideresources and management

for the primary activities (e.g.,finance, HR, procurement,budgeting, IT management).


EXECUTIVE REPORT 1111

CustomerSales

Estimating

Production

SchedulingInventory

Control

Purchasing

Receiving

Vendor

Employee

G/L System

Management

P/L

A/P

PayrollProduction

Cost Accounting

Billing

A/R and Sales

Accounting

job request

proposal

ordercomplaints

delivery date

estimate

production report

production report

credits

customer payment

job spec

forecast

orderproduction schedule

inventory status

production schedule

time cards

material costs

invoice

cust payment j/eP.O.

vendor invoice

time cards

purchase request

receipt notice

vendor shipment

product prices

inventory status

P.O.

payroll checks

vendorpayment

payroll j/e

cust inv j/e

purchasing j/e

material j/e

G/L report

management reports

P.O

.

invo

ice

cust

om

er s

hip

men

t

Figure 4 — A business context diagram.

Inbound

Logis

tics

Op

era

tio

ns

Outb

ound

Logis

tics

Ma

rke

tin

g

an

d S

ale

s

Se

rvic

e

Firm Infrastructure

HR Management

R&D

Procurement

Supporting

Activities

Primary

Activities

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

What is most important to getright in developing a businessvalue map is the set andsequence of the primary activities.In Figure 5, the primary activitiesare taken from what Porter con-siders the basic sequence withina manufacturing organization:inbound logistics, operations, out-bound logistics, marketing andsales, and, finally, service. Porter’sinsight in thinking of organizationsas input/output processes allowedmany organizations, for the firsttime, to look at their operationsfrom the very highest level and tosee not only their organizations’internal functions flow, but alsohow their organizations fit into aneven larger business context — asupply chain.

This simple but elegant way ofrepresenting complex businessestouched off a flurry of businessreengineering processes in the1980s and 1990s. With the adventof the Internet, it also providedan intellectual and engineeringbasis for developing e-businessand e-government applicationson the Web.

Over the years, it has becomeincreasingly clear that what Porteractually described was only one ofa number of “canonical businessprocesses” — value chains thatare shared by organizations in thesame business or business area.For example, a canonical businessprocess (primary activities) for ahighway construction organizationmight be as follows: planning →design → construction → operations/maintenance.

We consider such a processcanonical because a value maplike this is common in many areasof large-scale construction (e.g.,buildings, airports, terminals) aswell as for highways. Since suchprocess models are so commonin the way architects and engi-neers think about the overall exe-cution of their projects, it is notat all surprising to find that manyconstruction organizations areorganizationally structured intoseparate planning, design, con-struction, operations, and mainte-nance divisions.

The canonical construction modelcan be further extended to dealwith utilities whose job it is tobuild (construct) and operate net-works. In such models, the plan-ning, design, and construction canbe thought of as the “build-out ofthe network,” and the “opera-tions” can be considered (1) thepart that deals with connectingthe customer to the network and(2) customer service that providesthe service and then bills andcollects for that service.

All large organizations developsome sort of fundamental canoni-cal business process based onthe natural “break points” in theirbusiness activities. This allows theorganization to subdivide the worknaturally so that, for example, theplanning, design, and constructionunits can work independently ofone another with well-definedinterfaces.

Porter’s business value chainshave simply rediscovered an

underlying truth within busi-nesses of all kinds. Earlier,Henry Ford took this idea ofwork sequencing and created theassembly line, which was simply adifferent way of executing busi-ness processes so that individual,specialized groups could work onwhat they were good at while theassembly line moved the workfrom organization (workstation)to organization.

Recently, the success of orga-nizations like the Supply-ChainCouncil5 with its SCOR model hasreinforced the idea of canonicalbusiness processes. SCOR,which stands for Supply-ChainOperations Reference-model, hasfive major processes: planning,sourcing, making, delivering,and returning. Using just theseprocesses, SCOR has been able tofashion an entire framework foranalyzing, measuring, and improv-ing a large organization’s supplychain management.

Business value maps are exceed-ingly important as a guide forunderstanding an organization’sbusiness framework. Figure 6, forexample, shows the businessvalue map for a transportationagency. The items in gray refer tothe primary activities, while thosein black refer to the supportingactivities.

The business value map is a mapof the entire IT landscape for the



5The Supply-Chain Council is an organizationmade up of supply chain managers fromsome of the world’s largest enterprises.


enterprise. It has proven espe-cially useful in distinguishingbetween primary business activi-ties and sporting ones. One of theuses we’ve made of the businessvalue map is adding overlays toshow the major applications orthe major data classes for theenterprise. (See sidebar “UsingBusiness Value Maps.”)

Business Processes

An organization is only aseffective as its processes.

— Improving Performance[11, p. 45]

Business processes are the heartof large organizations. Businessprocesses are the way things getdone. There’s a push today fororganizations to formalize and



Administrative Management

IT Management

Financial Management

Supporting (Financial, HR, IT) Assets

HR Management

Program/Project/Contract Management

Local Support (Public, Transit, Aviation, Other)

Research and Laboratories

Safety

Planning

Preconstruction Construction Maintenance Real-Time

Operations

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 enter-prise. 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 tohave 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 businessdocumentation. 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 EnterpriseArchitecture (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 businessvalue map, we have been able to link the ESFM and FEA frameworks directly (see Figure A).

(Sidebar continues on next page.)

rethink major business processes.One of the ways that enterprisearchitecture can have the biggestimmediate impact is by focusingmore attention on the business

architecture, which starts withbusiness processes.

As you probably noticed, much ofthe discussion in the section onbusiness value maps centered on

business processes — canonicalbusiness processes. This sectionis more about modeling detailedbusiness processes. What we aregoing to do here is talk aboutsomething called “swimlane



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 brokendown into the following four major areas that have been developed to categorize the various business processes that go onwithin 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 straightforwardexercise 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 linkagebetween 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 themajor components within FEA’s BRM into the appropriate spots. There is a strong need to move BRM from a taxonomy toa set of solution templates.

t

Suppor t st ructure for Delivery of Services

(Delivery of Services –Supporting Activities)

t t t

Suppor t st ructure for Delivery of Services


Outcomes

CitizensSer ices

End

Res lts

t

Su por t st ructure for Deliv y of Services


t t t

IT Management

Budget

Financial Assets/Supply Chain

Management of Government Resources (Support Activities)

Support Structure for Delivery of Services(Delivery of Services — Supporting Activities)

ServicesCitizens End

Results

Inputs Outputs Outcomes

PRMBRM

Fin

an

cia

l As

sis

tan

ce

Cre

dit a

nd

Ins

ura

nc

e

Dire

ct S

erv

ice

to C

itize

n

Kn

ow

led

ge

Cre

atio

n a

nd

De

live

ry

Pu

blic

Go

od

s C

rea

tion

an

d D

eliv

ery

Re

gu

lato

ry C

om

plia

nc

e

Fe

de

ral P

as

s th

ru-

Fe

de

ral R

eg

ula

tory

an

d C

om

plia

nc

eR

ep

ortin

gHR Management

Mode of Delivery(Delivery of Services —

Primary Activities)

Services of Citizens (Primary Activities)

Infrastructure

Economic

Workforce Support

Education

Community and Social Services

Health

Natural Resources

Environmental

Corrections

Judicial Legal

Law Enforcement

Administrative Management

Co

ntro

ls a

nd

Ov

ers

igh

t

Ris

kM

an

ag

em

en

t

Pla

nn

ing

an

d

Re

so

urc

e

Re

ve

nu

eC

olle

ctio

n

Re

gu

lato

ryD

ev

elo

pm

en

t

Pu

blic

Affa

irs

Le

gis

lativ

eR

ela

tion

s

Ge

ne

ral

Go

ve

rnm

en

t

Support Structure for Delivery of Services(Delivery Services —Supporting Activities)

Resources

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


diagrams,” a form of documentingbusiness processes first publicizedby Rummler and Brache [11].Figure 7 shows a swimlanediagram of a straightforward salesorder fulfillment process.

These swimlane diagrams captureseveral essential business processcomponents: roles, activities, deci-sions, and workflow. In a sense,these business process diagramsare simply augmented flowcharts— exactly like those flowchartsused in programming but with afew additions. These additions, itturns out, are extremely impor-tant. Within business processmodeling, it is extremely impor-tant to identify who does the workand when. That is where the con-cept of “role” comes into play.

Roles represent the key logicalactors in a business process. Asin the case of context diagrams,roles can be individuals, whileorganizations are systems. What

is most important about a busi-ness process diagram is that thegeneral activities and the valuechain are captured.

All large organizations, and manysmall and medium-sized ones,have considerable businessprocess documentation that hasaccumulated over the years.Procedures, regulations, andwork rules exist everywhere.Unfortunately, in most organiza-tions there is no common form ofbusiness process documentation.Some business process documen-tation exists in the form of tradi-tional flowcharts, some exists inthe form of structured text, andsome exists in the form of deci-sion tables.

While there are obviously a num-ber of ways that organizationshave documented businessprocesses in the past, wesuggest that organizations con-sider using swimlane diagrams

as their standard approach. Thisdiagramming form has becomesomething of a standard in thebusiness-process world, andthere are many tools that supportdeveloping and maintainingthem. We have also found thatusing swimlane diagrams helpspeople think more creativelyabout how work gets done in theirorganizations.

In context diagrams, the actorsare normally the ones that userscome up with in our dialogue. Forexample, when developing con-text diagrams, most participantsin BEAM sessions usually refer tothe organizational units or the jobpositions that they are most famil-iar with, so that is what we useon the initial context diagrams.But by the time we get to creatingswimlane diagrams, we frequentlysegue from the actors that usersknow to roles that more correctly



No

Customer

Order Entry

Credit Manager

Sales Manager

Shop

Accounting

Customer Service

Product Management

Order Entry

preapproved?

Yes

entered order approved orderCheck

Credit

Allocate

Ship Goods

Bill

Customer

Accept

Goods

Accept

Payment

preapproved credit

shipping notice

billingnotice

shipment

invoice

payment

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

(Text continues on page 18.)



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 outof 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 character-istics directly from a context diagram. To make this clearer, in Figure A we have taken a business context diagram and madethe 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 exam-ple, 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 notthe same thing. Most of the tools that we have for enterprise modeling were adapted from application modeling, but thesize and scope of enterprise modeling require diagramming techniques and tools that are more flexible, capable of muchmore sophisticated leveling, and able to show time-related change.

Suppliers Business Domain

values to other counties

values from other counties

state abstract 2

state abstract 1

initial state assessed values

Deed transfer request

Deed transfer approval

Approved deed transfer

boundary information

tax entity budget

tax valuations by tax entity

distributed funds

mill levy

real estate value

real estate tax unit

fees

tax bill changes

certified values

tax unit info

sales questionnaire (aka Cert of Value)

deed or changes

deed or changes

permits

tax appeal decision

tax appeal

notice of assessed value (NOAV)

permit application

Customers

tax notice

tax warrent

inspectionchecklist

plat changes

lien

pla

t p

rop

osa

l

ap

pro

ve

d p

lat

pro

po

sa

l

pla

t p

rop

osa

l

ow

ne

r in

fo

bu

ildin

g p

erm

it

perm

it inspection

de

ed

or

ch

an

ge

s

Other

Counties

Division of

Property

Valuation

Title/Mortgage

Company

Lienholders

Developer Public Works

Division of Motor

Vehicles (DMV)

Appraiser

Planning and

Development

Treasurer

Taxing Entities

County Clerk

Register of

Deeds

Owner/Taxpayer

Personal

Property

Real

Estate

Parcel

Competitors

Figure A — Enterprise business context diagram with semantic categories highlighted.

(Sidebar continues on next page.)




ENTERPRISE DATA ARCHITECTURE MODELS AND BUSINESS SEMANTICS (continued)

Our feeling is that, over time, enterprise architecture will evolve new classes of diagramming and documenting techniquesthat 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 tech-niques, such as UML versions 1.0 and 2.0, were adapted from systems and programming uses. For the most part, BEAMuses modified classic business modeling diagrams because they have proved better suited to communicating directly withbusiness 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 mod-eling. Our expectation is that over the next decade, there will be enormous developments in this area as enterprise archi-tects and EA tool vendors work to model the entire enterprise.

may be triggered by

Property

Interest

Tax PayerHistory

Party Responsiblefor Tax Payments

Tax Payer/Owner

MortgageCompany

Improvement

Address Note

Deed

County

Parcel

ParcelHistory

TaxingEntity

AssessedValue

MillLevyCertified

Value

StateAssessment

Tax EntityBudget

SpecialAssessments

NOAV

Appeal

Tax Bill

Tax AppealDecision

Tax Payment Tax Notice Tax Warrent Tax Sale

Tax Collection

TaxDistribution

refe

rs t

o

has

maintains

submit

receive

definesownership

sent

defines

refers to

refers to

is defined by

identified by

is referenced by

may have

owns

owned by

has lo

an

from

has lo

an

ed

receives

makes

sent to

receives from

su

bm

itted

by

ha

s

reso

lutio

n

res

olv

es

refe

rs to

refe

rs to re

fers

to

may

ha

ve

is containedin

contains

is a

has

refers to

is contained in

contains

is assigned

establishes

calc from

used to calc

contains

receive

submits

is submitted by

calc from

used to set

hasasso

cia

ted

with

used to set

calc from

used to set

asso

cia

ted

wit

h

has

Tax Year

sp

ecif

ic t

o

triggered by

used in

triggered by

relates to

used

to c

alc

calc from

calc from

based on

may trigger

may trigger

may trigger

may trigger

may trigger

may be triggered by

may be triggered by

made up of

goes into

distributed to

mad

go

e

has

go

es in

to

is m

ad

e u

p o

f

refe

rs t

o ma

y h

av

e

rela

tes to

may b

e p

art o

fh

as

is established by

Figure B — Enterprise data architecture (entity-relationship) model with semantic categories highlighted.

capture the functional represen-tation that is taking place. Often-times, we will find the same rolebeing performed by two differentactors in a business scenario. Ina large organization, for example,a role often will be significantenough that a full-time positionwill be associated with it; whereasin a small organization, the sameposition (e.g., Accounting ClerkIII) may handle three or fourdifferent roles.

In business-process analysis,there are typically several differentkinds of business process models:“as is” models, which describe, asclosely as possible, how the busi-ness operates today; and “to be”models, which describe alterna-tive approaches.

As a result of our work in enter-prise architecture during the pastfew years, we’ve come to believethat a major role of an enterprisearchitecture group is to encouragethe creation of business processmodels for all portions of theenterprise. In addition, it is impor-tant to create an enterprise archi-tecture repository that serves as alibrary for future business processanalysis, since every time a largeorganization starts a new initiative,each new team invariably goesback and studies what the organi-zation currently does. Document-ing these processes takes a greatdeal of time and creates a body ofknowledge that is extremely use-ful but is often thrown away afterthe project is completed. This is a

waste of valuable time, money,and, most importantly, knowl-edge. Due to the aging workforce,a large percentage of currentemployees will be retiring withina short time period; having acentral repository of understand-able, up-to-date business processdocumentation is an enormousbusiness asset.

Data/Information Architecture

The fundamental value of alegacy IS (system) is buriedin its data, not in its functionsor code.

— Michael Brodie andMichael Stonebraker,

Migrating Legacy Systems [2, p. 89]

Data6 is the crown jewel of our ITassets. Our organization’s data isalso the most stable infrastructure.While hardware and programschange, data tends to persist. Inmany cases, our data structuresstill look much the same as theydid 10 or 20 years ago. This isespecially true in stable organiza-tions that sell the same productyear after year or do the samefunction/job year after year. Evenafter we convert one system toanother, if the function remainsthe same, much of the data iscarried over from one system tothe next.

Data is also the most flexiblecomponent of our enterprise

architecture. Starting in the 1960s,developers became aware thatthe same data was being usedin multiple applications. Orderentry, shipping, and billing sys-tems all relied on the samecustomer and product data. Thisrecognition led to the first data-base management systems(DBMSs). If organizations couldreduce the data redundancy, thenmany systems problems could beeliminated and new applicationscould be built more rapidly.

DBMSs have been one of the greatsuccess stories of IT. They allowprogrammers to focus on pro-gramming and to leave the physi-cal storage, indexing, and retrievalof information to the databasemanagement software. But evenas powerful and successful asDBMSs have been, different sys-tems in different organizations,even those that use the samefundamental data, have had a ten-dency to drift apart. Moreover, cer-tain systems focused on differentdata, which meant that integrationof data across the enterprise wasat best a difficult undertaking.

Looking back, it is clear now thatdata warehousing was one of thefirst true “enterprise architecturalsolutions.” Data warehousing wasan enterprise solution becauseits function was to bring togetherdata from disparate data sourcesacross the enterprise to producea unique enterprise view ofinformation that was unavailableat any other level [4].



(Text continued from page 15.)

6Throughout this section, we use “data” toinclude all the sorts of information, content,and multimedia that are stored in a modernorganization.


Data warehousing also made itpossible to create integrated setsof data from a variety of datasources without disturbing thesources themselves. The datawarehousing infrastructure wasa template that could be used ina number of different situations.Today, data warehousing and datamart environments are utilized intens of thousands of businessintelligence applications acrossall business markets.

Over the past 10 or 15 years, theamount of different types of infor-mation that needs to be managedhas grown significantly. Insteadof just managing the “structureddata” in their mainline applica-tions, IT organizations everywhereare involved in managing COTSdata, data warehouses, GIS data,CADD drawings, documents/images, photographs, e-mail,attachments, Web content, andmultimedia.

Just as we learned how to inte-grate structured data from differentsources during the late 1980s andearly 1990s to create data ware-houses, new classes of applica-tions are being built today thatintegrate data of different types.Two major classes of theseapplications stand out: Web-basedportals and GIS applications.Organizations are now beginningto think of the total set of infor-mation on computers as anenterprise asset that can beintegrated in ways that not onlychange the way people work butalso, in many cases, create a

whole new class of product [9].So instead of just focusing ondata management, people arestarting to build views of data/information/content architectures.

However, the data/information/content we see internally is but asmall piece of the information thatpeople are utilizing to do theirwork today. With search engineslike Google and Yahoo, managersand workers in organizationseverywhere have access toliterally billions of data sources.Indeed, the next generation ofWeb applications and Web ser-vices seems to depend heavily onnew and more powerful searchcapabilities and semantics to helpthem locate what they need.

Finally, data architecture plays alarge role in fashioning the nextgeneration of service-orientedarchitecture (SOA) applications.In this new environment, presen-tation, business logic, and dataexist in different layers. Over thenext few years, we predict anincreasing emphasis on simplify-ing and rationalizing corporatedata into a smaller number of“systems of record” that becomethe corporate repositories for keydata assets. We will discuss thisidea further in the next section onapplication architecture.

Application Architecture

During the past decade, applica-tion architecture has probablybeen the most discussed of allthe four major architectures. Thishas been in part because of the

interest in three-tier applications,Web services, and SOAs. But, likemost things, application architec-ture is far bigger than any currenttechnology strategy, even oneas promising as SOA. Indeed,there is no end to technologyarchitectures. Already, as SOAimplementations are becomingmore common, people arebeginning to talk about gridarchitectures.

While it’s true that applicationarchitecture is bigger than anyone of these individual architec-tural styles, a great deal can belearned from our recent experi-ences with, in this case, three-tierarchitectures. Perhaps the bestbook on application architectureis Brodie and Stonebraker’sMigrating Legacy Systems [2]. Inthis book, the authors addresswhat we believe to be the mostimportant problem in applicationarchitecture — maintaining andmigrating large systems over longperiods of time. This is perhapsnot so surprising, given that Brodiehas spent the better part of hiscareer working in an industry thatprides itself on seamless upgrad-ing of one of the world’s mostcomplex networks — the tele-phone network.

The following quotes from Brodieand Stonebraker about legacy sys-tems are particularly relevant:

“A legacy information system isany information system that sig-nificantly resists modificationand evolution.” [2, p. 3]



“Your legacy systems keepyour business from stayingon top.” [2, p. 3]

“Legacy systems maintenancemonopolizes your time andmoney.” [2, p. 4]

The reason these ideas are soimportant for application archi-tecture in the 21st century is thatlegacy systems represent such ahuge portion of an organization’sIT assets as well as its invest-ments. Therefore, the long-termgoal of a well-formed applicationarchitecture is not just to use thelatest architectural ideas on ournew systems but, over the long

run, to bring the key or core sys-tems of an organization under acommon and maintainable struc-ture (i.e., to have a “migrationstrategy” for every mission-criticalIT application). In the end, archi-tectural investments are about thebig things, and, as far as applica-tion architecture is concerned,the biggest things are the majorsystems. From our standpoint,anything that runs is legacy.

Much of what Brodie andStonebraker lay down as theirfundamental concepts mirrorwhat others have been suggestingfor some time in terms of dividingapplications into three layers: thepresentation layer, the businessrule layer, and the data layer.

Brodie and Stonebraker’s inter-faces, applications, and databaseservices (see Figure 8) describedin the following quote corresponddirectly to the three-tier presenta-tion, business rule, and data layers:

The best architecture formigration purposes is adecomposable structure, inwhich the interfaces, appli-cations, and database ser-vices can be considered asthe state components withwell-defined interfaces. [2, p. 15]

Brodie and Stonebraker foundthat legacy systems fall into thefollowing three categories:

1. Decomposable — thosethat come apart at thepresentation/interface,

business rule/application,and data layers.

2. Semi-decomposable —those where only thepresentation/interface layeris truly separable. In practice,this means that the applicationand database layers are tightlycoupled.

3. Non-decomposable — thosein which none of the majorcomponents can be cleanlydecoupled from one another.

Of these three types of legacysystems, the decomposable onesare the easiest to migrate (replat-form). We don’t really recom-mend migrating legacy systems toanyone who’s charged with think-ing about application architecturefor the future. Too often, in anattempt to solve a major problem,people become enamored of anew style of development thatwill suddenly free them fromhaving to worry about long-termmaintenance and long-term evolu-tion of their applications. ReadingBrodie and Stonebraker’s bookwill provide you with a great dealof insight into how your organiza-tion ought to be thinking aboutbuilding truly decomposableapplications.

In the development of large-scaleapplications, critical design deci-sions involve interfaces. We feelthat good systems have a com-mon anatomy (i.e., they comeapart at the same places). If ourorganizations are going to takeadvantage of new technologies,



Foreign ISs End Users

System Interfaces User Interfaces

Application Modules

DatabaseServices

Databases

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


they need to pay attention to thisanatomy, they need to have theirbest people working on modulardesign, and they need to enforcethat modularity through theirarchitecture standards and review.

SOA is a good thing. It attemptsto build systems out of cleanlydefined modules with cleanlydefined interfaces. But it is notmagic. SOA only works when peo-ple pay attention not only to therules but also to the reasons fortheir existence. Like a good data-base design, good applicationdesign follows patterns, andthose patterns are ultimately areflection of the business that isbeing automated.

Technology Architecture

On one hand, technology architec-ture is the most complicated of allthe architectures; on the otherhand, it is the simplest. It is com-plicated because there are somany products — both hardwareand software — that can go into agiven application. It is vastly sim-plified because in a given environ-ment, the choices are alwayslimited. There are no perfect tech-nologies, and there are no tech-nologies that are done evolving.

Large organizations seek safetyin a variety of strategies: marketleaders, industry standards, andorganizational strategies. All ofthese are subject to change. Itwould be wonderful if, somehow,it were possible to “futureproof”our technology decisions — to

make decisions now that wouldbe good for all time — but thatnever happens. For instance,market leaders change over time.Some of them fail to keep up withtechnology; some of them fail tokeep up with business trends.No one prevails forever.

Industry standards reflect a desireof businesses and their vendorsto lay out the basic interfacesbetween products in ways thatwill minimize obsolescence.Unfortunately, industry standardsoften lag technology and in manycases reflect either unrealizedwishes or a means of protectingexisting product investments intothe future.

Organizational strategies changeas market leaders and industrystandards change. They alsochange as market conditions intheir business arena shift. Thetechnology architectures thatmake the most sense then arethose that reflect the system’sanatomy (introduced in the previ-ous section). During the past 20years, IT has moved from main-frames to client-server to theInternet/three-tier applications.Companies such as Googleare pioneering a whole new rangeof technology based on massivelyparallel grid computing. In addi-tion, IT is about to undergo amassive sea change based onconverting an increasing numberof applications to wireless devicesand wireless networks.

Good technology architectureshould closely reflect the busi-ness, data, and application archi-tectures that have already beendiscussed. In the real world, tech-nology architectures should alsoreflect the migration of technolo-gies. Since no technology lastsforever, enterprise architectsmust plan for the day that varioustechnologies disappear.

Technology architecture requiresplanning. Unless IT managementtakes an active role in decidingwhich technologies to invest inand which to eliminate, the resultwill be chaos. Technologies tendto accumulate. Even if there’sonly one application in an entireIT organization that uses some 30-year-old technology, if it is amission-critical application, it willnot go into retirement easily.

BEAM has several techniques formanaging technology changealong with business change,including “weather radar charts.”Real weather radars in the USMidwest show that new things(fronts, storms, etc.) generallycome in from the West and leavetoward the East. One day whenwe were trying to get people tothink about long-term technologyplanning, we came up with theidea of a weather radar chart thatextended out in time as opposedto space. What would happen ifwe laid out our technology plansover multiple years (0-10) fornew things, as well as for retiringthings? This would help people to



think further into the future. Figure9 shows such a chart containingboth technology (data warehous-ing, wireless, telematics, etc.) anddemographic (aging workforce)issues.

While these charts are fairly sim-ple, they are effective in helpingpeople think about the future. Inmost organizations, three yearsis a long way out, but in IT,three years comes before youknow it. We consider thesecharts early-warning devices thathelp people think out loud aboutthings that they would rather, forone reason or another, ignore.

Equally important are the thingsthat we are trying to make goaway. We have found in organiza-tion after organization that tech-nologies pile up, like stuff in your

garage or attic. Unless someoneconsciously starts thinking abouthow to get rid of them, technolo-gies, like rarely used applications,stick around.

ENTERPRISE ARCHITECTUREVALUE CATEGORIES

Enterprise architecture is new,and some people question thevalue of anything new. Commonquestions include: Why do weneed to do this now; after all,we’ve been getting along finewithout it all these years, haven’twe? Why are we spending somuch time thinking about thefuture; why don’t we just dowhat everybody else is doing?These are questions that need tobe answered, so we thought itwould be useful to address thevalues associated with enterprisearchitecture.

Since enterprise architecturetouches nearly every part of theorganization and every kind oftechnology, the possible valuecategories are broad. However,enterprise architecture is espe-cially important for a number ofmajor value categories, including:

Business-IT alignment

Support for business initiatives

Strategic IT planning

IT project management

IT asset management

This section discusses each ofthese categories in detail.

Improved Business-IT Alignment

The overriding goal of IT is tosupport business uses and users.Historically, IT applicationsfocused on supporting individualbusiness areas. Over time, theseindividual, localized systems havebeen interfaced with dozens(sometimes hundreds) of othersystems. This has made systemsmore powerful and allowed orga-nizations to combine informationfrom multiple operations. As thetelecommunications infrastructurehas evolved, the number of peo-ple using computers routinelyhas dramatically increased. Inthe future, with the introductionof wireless connections, nearlyeveryone within an organiza-tion will be connected to thesesystems. While this constantlyenhances an organization’s effi-ciency and effectiveness, it makesthe job of business-IT alignment



0-3

Telematics

GIS/GPSGIS/GPS

Data Warehousing

Workflow

Doc Mgmt

Mainframe

x Server

aging workforce retire nt

0-3

Telematics

GIS/GPSGIS/GPS

Data Warehousing

Workflow

Doc Mgmt

Mainframe

x Server

GIS/GPSGIS/GPSGIS/GPS

Data Wareho sing

Workflow

Doc Mgmt

Mainframe

x Server

incoming issues outgoing issues

Data Warehousing

GIS/GPS

Wireless

Workflow

Document Management

Telematics

x Server

Mainframe

Aging Workforce Retirement

5-10 3-5 0-3 5-103-50-3

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


increasingly complex. Enterprisearchitecture makes the alignmentof business and IT easier by pro-viding both business and IT plan-ners with a “base map” of howthe current business-IT infrastruc-ture fits together, as well as theimpact of one system on another.

One thing is clear: IT plays a keyrole within the organization. A fewdecades ago, computers wereemployed in only a few highlyspecialized areas. Today, IT sys-tems play a critical role in almostall aspects of the organization’soperations. In many respects, ITplanning contains many of theissues that are encountered inplanning the highway infrastruc-ture. Like highways, IT networksrequire considerable advancedplanning, even with the mostadvanced IT developmentresources. And, like highways,all the pieces are interconnectedand need to be reviewed andreplaced on an ongoing basis.

By collecting and maintainingthe underlying data relating tobusiness processes, data needs,application programs, and tech-nologies, enterprise architectureprovides a baseline of informationthat can speed the developmentof new systems to support newbusiness functions and at thesame time make it easier for sys-tems to support revised/modifiedbusiness functions. The immedi-ate advantages of this includethe following:

Increased focus on businessstrategies/needs

Elimination of redundancies

Cycle time reduction

Improved reuse of existingIT assets

Leveraging technology throughnew business initiatives

Increased Focus on BusinessStrategies/Needs

One of the issues expressed in anumber of interviews and meet-ings with top managers is thedifficulty of getting managementstrategies translated into informa-tion systems support. Enterprisearchitecture makes this mucheasier by providing a standardizedpicture of what processes, data,systems, and technology areinvolved in supporting the cur-rent business operations sothat planners can lay out thedifferences between the future(to be) and the current (as is)environment.

Elimination of Redundancies

Within any large organization,there is a certain amount ofredundancy. Over time, thisredundancy can become a largefactor. Enterprise architectureallows planners to view just howmany times the same data isstored throughout all the systemswithin the organization. It alsoallows planners to see how manytimes the same business rulesare coded in all of the thousandsof programs the organizationsupports.

Cycle Time Reduction

Organizations are under pressureto work smarter and faster. Thisis especially true today whenthere are fewer resources interms of dollars and people andas the benefit-cost ratio of tech-nology continues to increase atan accelerated rate. Enterprisearchitecture provides a frameworkin which whole business proc-esses can be reviewed andredesigned. Within the organiza-tion today, workflow managementhas already cut the time for spe-cific business processes from asmuch as 30 days to less thanthree. Combining electronicforms/data with workflow man-agement technology allowsinformation to flow across organi-zations and across the world atelectronic speeds. Things don’tget lost, and advanced work-flow technologies, for example,support much more agileorganizations.

Improved Reuse of Existing IT Assets

Another major advantage ofenterprise architecture is the abil-ity to focus on the reuse of a widevariety of components, from indi-vidual computer procedures tothe installation of complete off-the-shelf suites of applications forwell-defined business processes.Because enterprise architecturelooks across the entire organiza-tion, it becomes clear just howmuch reuse is possible.

Data is perhaps the place wherethe reuse of IT assets plays the



biggest part. Keeping track of allthe projects, documents, andactivities within a large organiza-tion is an extremely complexprocess. Enterprise architecturemakes it possible for IT plannersto know exactly where criticaldata on projects or contractsexists and where possibleinconsistencies may arise.

Leveraging Technology ThroughNew Business Initiatives

Every day, new technologiesmake new business usages pos-sible. While no organization isequipped to take advantage of allthe technologies that exist, organi-zations that capitalize on the righttechnologies can reduce costsand increase productivity signifi-cantly. In some cases, this repre-sents state-of-the-art technologies;it may also represent findingnew ways to exploit well-knowntechnologies.

Improved Support forBusiness Initiatives

One of the hardest things forbusiness or government execu-tives to do is to put new businessinitiatives into practice. Every newmanagement or administrationtries to communicate its basicpriorities and often has troubleputting those priorities into prac-tice. Because enterprise architec-ture focuses on tying the businessstrategies to the business systemsand technologies, those chargedwith implementing new businessinitiatives can get a quick start.

A well-organized enterprisearchitecture environment shouldcontain several key informationresources critical to businessinitiatives, including:

Providing a central repository of integrated managementinformation

Providing baseline business-ITdocumentation

Allowing easier access tomanagement information

Providing easier usertraining/reference

Providing a Central Repository

The average large enterprise willnormally maintain hundreds ofdocuments across the organiza-tion that detail the organization’sstrategies, goals, objectives, andprocedures. Historically, this docu-mentation exists in the form ofindependent documents made upof text, organizational structures,and tables. While enormous effortis normally expended in creating,updating, and disseminating thesevarious organizational strategies,they are often not communicatedto the people who need to knowabout them.

EA tools make it possible todocument goals, objectives,roles, responsibilities, and meas-ures in a way that allows them tobe tied back to the various appli-cations, views, and reports thatneed to reflect them. Equallyimportant, the enterprise archi-tecture provides a place where

fundamental business processesand business rules are docu-mented and constantly updatedas changes are made to them andto the systems that are supposedto execute them.

Providing Baseline Business-ITDocumentation

Whenever a new managementproject begins, there is a need tocapture the set of information (thebaseline) about the organizationalunits involved. A serious enter-prise architecture keeps this infor-mation for the entire organizationand can save a considerableamount of time. Additionally,because the enterprise architec-ture is an ongoing activity, mostof this information is up to theminute.

Allowing Easier Access toManagement Information

Managers at all levels strugglewith finding and structuring man-agement information about awhole range of topics. Becauseenterprise architecture containsa directory of all the data for theenterprise, it can be a resource ina wide variety of situations. Overthe past 15 or 20 years, data ware-housing has emerged across theworld in response to the need notonly to access individual sets ofdata in specific applications butalso to combine information fromdifferent parts of the organizationin ways that allow managers tosee the organization as a whole.Many people see data warehous-ing as one of the first enterprise




architecture applications of anymagnitude.

Enterprise data architecture is amajor component of the enter-prise architecture. Enterprisedata architecture involves build-ing enterprise data models andunderstanding the data not just inspecific applications but in all theapplications that span the organi-zation. The enterprise data archi-tecture is one of the most valuablecomponents of the enterprisearchitecture.

Providing Easier UserTraining/Reference

Over the next decade, an increas-ing number of key managementand professional employees willbe retiring as the baby boomerscome of age. Over a relativelyshort period, organizations aroundthe world will have to transfer theknowledge from one generationto the next. In an increasing num-ber of companies, the enterprisearchitecture is becoming the cen-tral repository for business andtechnology detailing how theenterprise operates. Nothing willreplace face-to-face contact fortransferring knowledge, but hav-ing a central repository can be agreat aid.

Improved Strategic IT Planning

Perhaps the most important, andearliest, place where enterprisearchitecture provides significantvalue is in the area of strategic ITplanning. By and large, IT organi-zations provide five basic services

to their customers: (1) telecom-munications infrastructure, (2)data, (3) applications, (4) support,and (5) expertise. Each of theseareas requires an understandingof the ways that these functionsrelate to business goals andstrategies. Over time, the existingIT asset network of businessprocesses, data, applications,and technologies must be docu-mented, updated, and ultimatelyreplaced. At the same time, newbusiness needs and technologiesmust be brought into this same ITasset network while other ele-ments are being retired.

For decades, areas like the trans-portation network have usedmaps, engineering drawings, andvideos to aid in the process ofdeciding which projects to do andin which sequence to do them.Until the advent of enterprisearchitecture, however, IT has nothad a similar set of high-levelmaps, drawings, pictures, orvideos of the IT landscape. Soone of the most important initialvalues of an enterprise architec-ture has been to provide IT andbusiness planners with a betterset of maps and schematics of thebusiness-IT landscape.

With this improved set of pictures,business and IT planners havea better framework in which tolay out their plans. Equally impor-tant, they can look across theorganization and further into thefuture when considering businessstrategies. Enterprise architectureprovides:

An improved framework forlong-range business-technologyplanning

A better portfolio of projects

Increased leveraging of thebusiness-IT infrastructure

An Improved Framework for Long-Range Business-Technology Planning

Planning any complex area is asignificant challenge, but it ismade even more difficult in ITbecause of the extremely rapidrate at which new technologiesare brought onstream and madeobsolete. Because IT is so centralto the operation of the modernreal-time organization and to thetime it takes to develop and installquality systems, strategic IT plan-ning is a particularly challengingactivity.

Enterprise architecture makes thisprocess significantly easier by pro-viding maps of how the variouscomponents (business processes,data, applications, and technolo-gies) fit together. In addition, thelatest forms of enterprise architec-ture have evolved new ways oftalking about the long term inwhich IT needs to be planned.The evolution has come aboutas those “doing EA” have cometo recognize that they are funda-mentally in the same business asthose engineers and professionalscharged with planning electrical,telephone, and transportationnetworks. In each of these cases,because planning affects so manyinterconnected components, it



must be done carefully with con-siderable attention to flawlessexecution. Enterprise architecturemakes this process easier.

A Better Portfolio of Projects

Projects are the way thingsget done in IT. The quality ofstrategic IT planning is reflectedin the quality of projects proposedfor management approval and inthe care that goes into the selec-tion of the projects that are ulti-mately approved. The better theinformation that business and ITmanagement has with respect tothe important projects underway,the better the resulting decisionswill be.

Because enterprise architectureprovides a continuous view of theexisting and planned IT environ-ment, everyone (users, user man-agement, top management, ITmanagement, and IT developers)has a better understanding ofhow things fit together. Enterprisearchitecture enhances the port-folio management process byproviding a broader vision of busi-ness-IT alignment and a focus ona longer time frame, which areboth particularly significant. In thisway, enterprise architecture low-ers the business-IT risk and cost;by focusing on developing incre-mental plans, EA also providesusers with value faster.

Increased Leveraging of the Business-IT Infrastructure

One of enterprise architecture’sfundamental goals is to reduce

the overall cost of IT by betterleveraging the business-IT infra-structure (i.e., the whole set ofbusiness, data, application, andtechnology assets). This meanslooking at each business-IT initia-tive and asking, how can we usewhat we or someone else hasalready done? Many critical appli-cations for large organizationswere not available 20 or 30 yearsago. Today, however, most criticalapplication areas have eithercommercial or inhouse solutionsthat can be adapted to do whatis required at a much lower costthan by starting from scratch. Bymodeling the EA process afterbest-practice methods such asFEA, SCOR, and others, it is pos-sible to provide value at a muchfaster pace.

Improved IT Project Management

IT projects are notoriously difficultto manage, especially very largeprojects (VLPs). Replacing verylarge legacy applications andbringing in new technologies areparticularly difficult. Enterprisearchitecture provides a great dealof useful information that makes itmuch easier for organizations toattack the troublesome projects.

As many as 60% of VLPs are nevercompleted. VLPs are the BermudaTriangle of IT management. Forthis reason, most IT managerswill go to almost any length toavoid engaging in such projects.One of the goals of enterprisearchitecture is to break VLPsinto small, doable projects,which can be executed in a short

(three-to-six-month) period andare far less risky than a three-to-six-year project.

EA accomplishes this by provid-ing the information to do thefollowing:

Get the project off to afaster start

Break the VLP into a set ofsmaller projects

Employ a mechanism for inte-gration and change control ofthe small projects

Plan legacy renovation/replacement projects

Plan IT technology initiativeprojects

Get the Project Off to a Faster Start

Most VLPs have a long startupcycle because of the amount ofinformation that needs to be col-lected, organized, and digested.EA helps this process by providinga single source to key business-ITinformation for specific businessareas. Moreover, this informationhas been collected using uniformstandards and integrated. As aresult, project teams don’t need tospend as much time getting theirfeet on the ground.

Break the VLP into a Set of Smaller Projects

IT executives have known fordecades that small projects aremuch less expensive and muchless risky than VLPs. But managinga whole set of incremental proj-ects has been difficult — as hard




to carry off as managing one bigproject. There are numerous rea-sons for this, one of which is alack of mechanisms for breakingbig projects into smaller ones. Andeven if you have broken downa VLP into several architectedsmaller projects, coordinating andkeeping control of the changes inthese pieces becomes exceed-ingly difficult.

Employ a Mechanism for Integrationand Change Control

A historic problem in breakingVLPs into a set of cumulativeincremental projects has beenintegration and change control.In most cases, not enough effortwas expended in the architectureof the individual incrementalprojects to ensure they wouldfit together when completed.Enterprise architecture addressesthis problem by providing a mech-anism for doing this architecturalwork on VLPs.

Change control is the second criti-cal aspect of breaking large high-risk projects into a set of muchsmaller incremental projects.Even if there is a serious, con-sistent architecture developedbefore incremental projects arelaunched, as projects progress,there are always significantchanges that need to be made interms of the interfaces betweenthe incremental pieces. A role ofenterprise architecture is to man-age those changes and make surethat major changes in the imple-mentation are not approved

without a complete understand-ing of what this means in termsof long-term costs, benefits, andrisks.

Plan Legacy Renovation/Replacement Projects

The most expensive element inmany IT organizations is maintain-ing and upgrading major legacysystems. Historically, this repre-sents 50%-60% of most softwaredevelopment budgets. Most of thatmaintenance, however, is allo-cated to changes in businessrules, new outputs, and certaininterfaces with other systems.However, there is a strong reluc-tance to invest in major changesto legacy systems on a regularbasis. Enterprise architecturetreats all legacy systems (espe-cially major ones) as IT assets thatmust be regularly updated. Thismeans that going forward, plansmust be in place for keeping allsystems up to current standards.

Ultimately, as an increasingnumber of major parts (businessareas) of the enterprise are auto-mated and integrated with otherparts, the constant renewal/replacement of legacy systemswill need to be considered.This process is ongoing and willbecome more critical every year.The network of IT applicationsmakes it possible for organizationsto be more efficient and to get bywith fewer people. But there is nofree lunch; the core applicationsystems have to be constantly

redefined and repaired. Thisrequires a new level of planning.

Enterprise architecture helpsbusiness-IT management look atthe entire systems environmentand spot areas that have to beupgraded before they becomepoints of failure.

Plan IT Technology Initiative Projects

Finally, enterprise architecturealso provides a framework foraddressing IT technology initiativeprojects, which are intended totest out projects for emergingtechnologies or major new usesof existing technologies. Becauseof its focus on the careful imple-mentation of new technologies,enterprise architecture providesa framework for identifyingimportant new technologies andsetting up low-cost, small-scaleimplementations. This enhancesthe organization’s ability to pilotnew technologies and to developbasic skills for larger projectsusing the same technologies.

Increased Focus on IT Asset Management

Over the years, most large organi-zations have invested hundredsof millions of dollars in their ITassets. Many of these organiza-tions are now recognizing that inthe case of the enterprise’s ITassets, the whole is considerablygreater than the sum of its parts.Today, organizations operate fasterwith far fewer people than theydid just a few years ago, not justbecause of one or two so-called



killer apps but rather as a resultof streamlining entire businessprocesses and integrating wholesets of systems end to end.

Enterprise architecture is movingto make this process moreexplicit. EA allows business-ITmanagement to see how theentire business-IT network ofapplications and data fits togetherand to make sure that future proj-ects extend and enhance theexisting investment. This changein orientation is shown in theincreased management of all theIT assets over an extended period.These assets include:

Data assets

Application assets

Core applications

Purchased applications

Technology assets

Anticipating the future

Constant scanning of business-technology changes

Forecasting effect of newtechnologies on strategicIT plan

Forecasting effect of newbusiness changes on strategicIT plan

CONCLUSION

IT has reached a new stage. If thewhole is greater than the sum ofits parts, and if it is possible torethink the way organizationseverywhere do business, then it is

interesting to consider what wecould be doing today if we wereable to truly leverage technologyto the max.

Historically, our organizationshave put our IT infrastructure andenvironment together a little at atime over a period of decades,not unlike the way countries builttheir high-speed auto routes.Then, all of a sudden, we discov-ered that everybody, or nearlyeverybody, in the organization thathad an office had a computerand that those computers werehooked to networks that werehooked to everyone else’s com-puters. We found that our peoplewere using computers more andmore, not just for the applicationsthat supported their businessfunctions but for everything theydid — letters, spreadsheets,memos, presentations, collab-oration — everything!

This new era of the “digital enter-prise” that runs on its IT infrastruc-ture brings new responsibilities forIT asset management. Today, ourIT systems are so important thatif they are down even for a shorttime, everybody in the organiza-tion notices. We’ve reached astage like that of other utility func-tions: people are only aware of ITwhen something fails. This meansthat those involved in IT assetmanagement have to plan, design,and architect everything to newstandards of performance, secu-rity, and reliability.

BEAM is the result of solvingdozens, maybe hundreds, of prac-tical problems over many years. Ithas proven useful and teachable,which are good signs. Enterprisearchitecture is no longer of inter-est only to researchers and acade-mics. Big, complex systems arecommon, as are big failures.Organizations have to be betterprepared to deal with all the ele-ments of enterprise architecture,especially the business and dataarchitectures. Our organizationsare moving faster, and they needsystems that are more flexible andmore directly related to the busi-ness environment — that is whatenterprise architecture is allabout.

REFERENCES

1. Benson, Robert J., and MarilynM. Parker, with H.E. Trainor.Information Economics: LinkingBusiness Performance toInformation Technology.Prentice Hall, 1988.

2. Brodie, Michael L., and MichaelStonebraker. Migrating LegacySystems. Morgan KaufmannPublishers, 1995.

3. Davis, Steven P. “The WaltDisney Company EnterpriseArchitecture Overview.” Presentedat Enterprise Architecture Summit2004, Rancho Mirage, California,USA, June 2004.

4. “Enterprise Data FlowArchitecture.” The Ken OrrInstitute, 1988.




5. Helland, Pat. “Metropolis: TheEvolution of the IT Shop into theWorld of Services.” Presented atEnterprise Architecture Summit2004, Rancho Mirage, California,USA, June 2004.

6. Orr, Ken. “Extending Zachman:Enterprise Architecture andStrategic IT Planning.” CutterConsortium Business-IT StrategiesAdvisory Service Executive Report,Vol. 7, No. 4, April 2004.

7. Orr, Ken. “Pushing theEnvelope: Managing VeryLarge Projects.” CutterConsortium Agile SoftwareDevelopment and ProjectManagement Advisory ServiceExecutive Report, Vol. 5, No. 7,July 2004.

8. Orr, Ken. “The Three Facesof Enterprise Architecture.”Cutter Consortium EnterpriseArchitecture Advisory ServiceExecutive Report, Vol. 7, No. 1,January 2004.

9. Orr, Ken, and Andy Maher.“The Digital Age: Managing DigitalAssets.” Cutter ConsortiumBusiness Intelligence AdvisoryService Executive Report, Vol. 4,No. 11, November 2004.

10. Porter, Michael. CompetitiveStrategy: Techniques for AnalyzingIndustries and Competitors. FreePress, 1980.

11. Rummler, Geary A., and AlanP. Brache. Improving Performance:How to Manage the White Spacein the Organization Chart. 2ndedition. Jossey-Bass,1995.

ABOUT THE AUTHORS

Ken Orr is a Fellow of theCutter Business TechnologyCouncil and a Senior Consultantwith Cutter Consortium’s AgileSoftware Development andProject Management, BusinessIntelligence, Business-ITStrategies, and EnterpriseArchitecture Practices. He isalso a regular speaker at CutterSummits and symposia. Mr. Orris founder and Chief Researcherfor The Ken Orr Institute, abusiness-technology researchorganization. Previously, he wasan Affiliate Professor and Directorof the Center for the InnovativeApplication of Technology withthe School of Technology andInformation Management atWashington University. He isan internationally recognizedexpert on technology transfer,software engineering, information

architecture, and data warehous-ing. Mr. Orr has more than 30years’ experience in analysis,design, project management,technology planning, and manage-ment consulting. He is the authorof Structured SystemsDevelopment, StructuredRequirements Definition, and TheOne Minute Methodology. He canbe reached [email protected].

Bill Roth is the Chief EnterpriseArchitecture for the KansasDepartment of Transportation(KDOT) and Chief IT Architect forthe state of Kansas. Mr. Roth hasbeen involved for more than 20years in developing and managingmajor application systems and hasbeen involved directly in EA atKDOT since its inception.

Ben Nelson is the CIO forthe Kansas Department ofTransportation. He has held thisposition for the past 18 years.Prior to that, Mr. Nelson held aseries of positions in the US Navy.Mr. Nelson is also Cochairman ofthe Computer and InformationTechnology Committee of theTransportation Research Boardand is involved in a wide varietyof IT and transportation manage-ment activities.



Abou

t the

Pra

ctice Enterprise Architecture

PracticeToday the demands on corporate IT have never been greater. Cutting costs andaccelerating time to market for individual line-of-business projects are still priorities,but even that’s not nearly enough anymore. Companies are now looking forstrategies to better leverage their entire IT infrastructure. They want IT to deliversophisticated enterprise applications that can provide value across many lines ofbusiness and provide marked differentiation from their competitors. The EnterpriseArchitecture Practice provides the information, analysis, and strategic advice to helporganizations commit to and develop an overarching plan that ensures their wholesystem fits together and performs seamlessly.

The subscription-based services within this practice — Enterprise ArchitectureAdvisory Service and Web Services Strategies journal — offer continuous researchinto the latest developments in this area, including Web services, enterpriseapplication integration, XML, security, emerging and established methodologies,Model Driven Architecture, how to build an enterprise architecture, plus unbiasedreports on the vendors and products in this market. Consulting and trainingofferings, which are customized, can range from mapping an infrastructurearchitecture 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 PracticesCutter Consortium aligns its products and services into the nine practice areasbelow. 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 ConsultantTeamOur team of internationally recognizedspecialists offers expertise in security issues,e-business implementation, XML, e-businessmethodologies, agents, Web services, J2EE,.NET, high-level architecture and systemsintegration planning, managing distributedsystems, performing architecture assessments,providing mentoring and training, overseeingor executing pilot projects, and more. Theteam 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
