the hitchhiker's guide to enterprise architecture roadmapping

The Hitchhiker’s Guide toEnterprise ArchitectureRoadmapping

by Sebastian Konkol; with contributions fromWojciech Ozimek, Bartosz Kiepuszewski, and Borys Stokalski, Senior Consultants, Cutter Consortium

This Executive Report presents a technique that supports the

development of the enterprise architecture roadmap. Our goal was

to design an agile approach that can be seen as a core process for

enterprise architecture management that can be used as is or

modified as needed. The report concludes with a review of case

studies in which the principles of enterprise architecture roadmapping

(EARM) have been successfully adopted.

Enterprise Architecture

Vol. 8, No. 9

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]


At a recent IT conference, one ofthe speakers — an experiencedindustry analyst — defined theterm “enterprise architecture” asa concept, which makes businessdecision makers immediately loseinterest in further conversationswith CIOs. This remark is a goodillustration of the communicationsdeficiencies that are plaguing theterritory of business-IT alignment.It is as if technology managementis protected by some kind ofDouglas Adams–type SEP field, aprotective shield that can cover a“bizarre and unbelievable sceneso that the unconscious minds of

the observers instantly abdicateresponsibility for its existence.”1

Similarly, the growing tendency tooutsource any activities related toinformation technology indicatesthat decision makers are morecomfortable managing businessrelationships with an outsourcerthan managing technology as abusiness asset. However, this factseems to be a paradox: withdecades of exponential growth ofIT capabilities still ahead, the ideaof turning technology investmentsinto Somebody Else’s Problem is

not a viable proposition, as thefollowing three reasons explain:

1. The development of technology(materials, processors, net-works, power cells, wirelessdevices, etc.) systematicallydelivers disruptive businesscapabilities and creates newmarket niches. We cannotforesee exactly what businesschanges will be triggered bytechnology advances, butsome will.

2. The technology lifecycle is to alarge extent independent fromthe evolution of markets that

The Hitchhiker’s Guide to EnterpriseArchitecture RoadmappingENTERPRISE ARCHITECTUREADVISORY SERVICEExecutive Report, Vol. 8, No. 9

by Sebastian Konkol; with contributions from Wojciech Ozimek, Bartosz Kiepuszewski, andBorys Stokalski, Senior Consultants, Cutter Consortium

1A definition of the Somebody Else’s Problem (SEP) field, from The Hitchhiker’s Guide to the Galaxy by Douglas Adams, can be found on Wikipedia(http://en.wikipedia.org/wiki/Somebody_Else%27s_Problem_Field): “An SEP field can be erected on, or projected around a bizarre and unbelievablescene so that the unconscious minds of the observers instantly abdicate responsibility for its existence, assert that it’s ‘somebody else’s problem,’and therefore don’t perceive it at all. The primary example of this was given in the third book Life, the Universe and Everything, when a UFO …landed in the middle of a cricket ground during a match, and the assembled crowd failed to notice it. Another prime example is when [a] ship’sfield is extended so that the characters fail to notice the fact that they cannot breathe or the fact that the asteroid that they are standing on doesnot have enough gravitational force to hold them down. The SEP field requires much less energy than a normal invisibility field (a single flashlightbattery can run it for over a hundred years) due to the natural propensity of humans to see things as Somebody Else’s Problem.”


implement solutions basedon technology and exploittechnology advancements(such as modern financialservices and telecommunica-tions). Therefore, any strategylinking markets with technol-ogy has to analyze and exploitthe relationships betweenwhat is feasible and what ispossible. It is important tounderstand events in bothmarket and technology evolu-tion as they are equally impor-tant sources of business valueor business risk.

3. The key strategic motives forcompeting in the 21st century— time-based competition,knowledge work productivity,business agility — rely on tech-nology innovations and efficientmanagement of enterprisearchitecture (EA).

These arguments may appearinsufficient to many decisionmakers who seem to abdicatetheir responsibility for technologymanagement as if the subjectindeed was something bizarre.Nevertheless we believe this atti-tude toward IT signals an impor-tant transformation of corporatecomputing rather than its end(recently announced by thefamous IT-buster Nicholas Carrin the Spring 2005 MIT Sloan

Management Review article “TheEnd of Corporate Computing”).

As the rate of change in businesscontinues to increase, technologymanagement is clearly beingdivided into two domains. Thefirst domain is where technologybecomes part of the businessservices, products, and manage-ment processes. In this domain,technology management mustbecome integrated — not aligned— with business management,becoming one of the assets thatis consciously used as a strategicresource. The second domain isthat of solutions and technologies,which (using the rhetoric bor-rowed from Carr) are essential tobusiness continuity but bear littleor no strategic consequences. Inthis area, technology becomes aninfrastructure, and the technologymanagement is exchanged withsourcing. Additional dimension tothis picture is added by the factthat the components of enterprisearchitecture constantly migratefrom strategic to commoditydomains. The relatively short life-cycle of IT solutions and productsis further enabled by the currentgrowth of service-oriented archi-tectures (SOAs) in both customsystem development and enter-prise application vendor strategies.

The transformation of corporatecomputing can be visualized

with the help of a grid definedby Warren F. McFarlan — CutterConsortium Summit 2005 keynoterand Baker Foundation Professorand Albert H. Gordon Professor ofBusiness Administration Emeritusat Harvard Business School —plotting components of enterpriseinformation architecture acrosstwo dimensions: strategic depen-dence (how much are businessoperations and decision cyclesdependent on the availability andfunctionality of IT components)and strategic impact (how bigis the current competitive advan-tage provided by the capabilitiesdelivered by IT components).(See Figure 1.)

The important question is whichmanagement practices areappropriate for organizations thatexperience the effects of transfor-mation. The main coordinationmechanisms implemented inrecent years to manage corporateIT have been focusing on aligningIT capabilities to business require-ments by dictating cost structures,service levels, and deadlines.The transformation of corporatecomputing requires a more diver-sified approach to be developed,resulting in sourcing-orientedpractices in the commoditydomain and integrated business-IT planning practices in the strate-gic domain. The strategic domainis where enterprise architecture

VOL. 8, NO. 9 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]. Managing Editor:Cindy Swain, 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 makean excellent training tool. For information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or [email protected].





roadmapping (EARM) takes itsrole. This approach was detailedin the Executive Report “ApplyingEA Roadmapping: An SOARoadmap” [5].

In this Executive Report, wepresent a technique — a setof steps to be followed and arti-facts to be used — supportingthe development of the enter-prise architecture roadmap.The approach presented is notintended to be a substitute forformal enterprise architecturemanagement (EAM) methodolo-gies. Our goal was to design anagile approach that can be seenas a “core” or “governing” processfor EAM. This core process canbe extended and formalized ifneeded or can be used as isto achieve quick, but valuable,results. To give the reader someidea of how the approach can beused in various contexts, at theend of the report we present casestudies of projects where theprinciples of EARM have beensuccessfully adopted.

THE QUESTION

The “correctness” of the idea ofenterprise architecture manage-ment very often is not a goodenough argument for investingin a management practice whenyou are confronting the fear ofbureaucracy, uncertainty aboutgoals, and doubt about benefits.While in some cases such con-cerns could be valid, this doesnot necessarily have to be true ingeneral. Let us borrow anothermetaphor from the world created

by Douglas Adams: the UltimateComputer.2 The UltimateComputer is a powerful IT artifactdesigned to deliver the “UltimateAnswer” — explaining Life, theUniverse, and Everything. It did itsjob well, delivering the answer,which happened to be “fortytwo.”3 It was then that its makersrealized that the answer makesno sense unless you know pre-cisely what it is you are asking.And coming up with the right

question is often much moredifficult than coming up withthe right answer. Similarly,admirable concepts such asenterprise architecture frame-works created by thought leaderssuch as John Zachman or BernardBoar are only successful to theextent that the purpose and goalsfor their implementation are welldefined and understood. Sobefore explaining details aboutthe EARM process, it is worth-while to understand what kindsof questions this “answer” isaddressing.

Enterprise architecture roadmap-ping is the discipline of planningthe evolution of enterprise archi-tecture in a way that anticipatesand enables business changesand maximizes the opportunitiesprovided by the technologyinnovations. The process is

©2005 CUTTER CONSORTIUM VOL. 8, NO. 9

EXECUTIVE REPORT 33

Low High

Factory

Strategic

Support

Turnaround

Low High

High

Low

1990

2010

Factory

Strategic

Support

Turnaround

Low

High

Strategic impact

Strategic impact

Strategic dependence

Strategic dependence

Figure 1 — Transformation of corporate computing.

2For those unaware, according to Adams’sHitchhiker’s Guide to the Galaxy, researchersfrom a pan-dimensional, hyper-intelligentrace of beings construct Deep Thought, thesecond-greatest computer of all time andspace, to calculate the answer to the UltimateQuestion. After seven and a half million yearsof pondering the question, Deep Thoughtprovides the answer: “Forty-two.”3A curious reader might try the query “whatis the answer to life the universe and every-thing” (enter exactly as written here, but with-out the quotes) with Google or MSN Search.Apparently the Web is as good as the UltimateComputer.



intended to facilitate the commu-nication necessary to integratebusiness and technology manage-ment. It is inspired by researchand a growing practice of technol-ogy roadmapping, which encom-passes methods, techniques,and tools for strategy developmentin environments with high ratesof change. It is not intended toreplace architecture frameworksor EAM methodologies, but ratherserves as a technique that enablestheir efficient implementation.EARM consists of the followingthree components:

1. A planning framework, whichlays out the key “dimensions ofknowledge.”

2. A roadmapping technique (orprocess), which implementsthe planning framework.

3. Roadmap templates, which arefocused on the key themes inenterprise architecture evolu-tion. Templates support thequick creation of company-specific architecture roadmaps.

While our previous Cutter reporton EARM focused on the first andthird aspects of the approachabove [5], this report gives a moredetailed overview of the EARMtechnique (process) and presentscase studies illustrating the actualimplementation. The process isfocused on extensive communi-cation involving business andtechnology experts providing thefollowing critical ingredients:

Shared area of knowledge —basis for communication;common understanding offundamental concepts

Common means of commu-nication — agreed artifactsallowing the use of sharedconcepts in order to buildnew ones

Method for dealing withproblems — accepted way ofproceeding to solve a definedproblem

The EARM technique forms aframework for running commu-nication, enabling integratedbusiness and technology manage-ment. It structures communicationas well as forms a language neces-sary for communication. But mostimportantly, its relative simplicityand iterative characteristics allowit to receive valuable results with-out falling into excessive and time-consuming activities.

SHARED VISION

Achieving such results requiressome shifts in the basic conceptsof describing a company’s infor-mation environment and itsdynamics. Traditionally, the infor-mation environment has beendescribed by modeling its infor-mation systems, applications, andbusiness processes. Moreover, abusiness user has been forcedto understand and use such adescription method in communi-cating with IT; otherwise, IT couldnot fulfill the business user’srequirements.

As long as such effort was to bedone only once, it was regardedas a necessary evil. Unfortunately,business processes have becomeso volatile and informationsystems so complex that themethod becomes unproductive:its use requires huge overheadjust for the maintenance of mod-els. This slows down, or eveninhibits, the communication nec-essary for an integrated planningof business and technology. Inthe following sections (and in theaccompanying sidebars), we pre-sent practices used in EARM tospeed up and simplify the com-munication. Cutter ConsortiumSenior Consultant Scott Ambler’sExecutive Report “An AgileApproach to EnterpriseArchitecture” provides usefuladvice concerning the way mod-eling techniques can be used inan agile, adaptive manner [1].

Business Cycle

The process defined as asequence of interrelated taskspresents only one possibility thatthe company should be gearedup for. What builds the company’scompetitive advantage is its abilityto reorganize tasks, or groups oftasks, based on an emerging busi-ness requirements context andaccording to its time frame.It means the ability to find anddefine business tasks’ modules,which could be executed in thesame manner regardless, to someextent, of the context. Moreover,within each module, the companyshould be able to make decisions



EXECUTIVE REPORT 55

based on gained experience(see sidebar “Capturing BusinessProcesses”).

Based on such an approach, thecompany’s business would beperceived as running many

interrelated business cycles, eachhaving a purpose and regular set ofsteps. Additionally, some form of

CAPTURING BUSINESS PROCESSES

PROCESS FRAMEWORKSThomas Davenport, in a recent Harvard Business Review article [3], argues that effective outsourcing requires the develop-ment of a “broad set of process standards” that will enable “plug-and-play” outsourcing. There are areas where such stan-dards are indeed emerging, a good example being the Supply-Chain Operations Reference (SCOR) model developed by theSupply-Chain Council. Such process frameworks can be used in various contexts as the inventory of activities that can beeither quickly evolved into specific models or used as is for various cross-reference activities (such as identification of EAcomponents supporting a given business area).

VALUE CHAIN TEMPLATESMany approaches to strategic management define a simplified yet comprehensive model of business activities in the form ofvalue chain templates. Such templates are included in methods promoted by such management gurus as Robert Kaplan andDavid Norton [4] and Michael Porter (the value chain framework [8]).

An important class of value chain templates are the templates describing various kinds of end-to-end business cycles (suchas order-to-cash, requirement-to-resource, or new product development). These may be very useful tools for analyzing howinformation architecture affects the capabilities related to time-based competition.

SERVICES: FOCUSING ON BUILDING BLOCKSIn an organization where processes and organizational charts often change, the focus on “building blocks” may sometimesenable us to capture a portfolio of activities that serve as “bricks” from which processes are constructed. These often comein the form of services. This kind of approach to process modeling may be useful for front-office organizations (such as cus-tomer service and sales) and internal units that are defined as “shared services centers.” Services can be captured quicklyand relatively easily with a small subset of standard UML modeling techniques (e.g., use cases and component models). Itmay also be useful for immature organizations that have not developed internal rules and procedures but have a clearlydefined interface to their environment.

BUSINESS RULES MODELINGModeling processes as workflows or document flows is time-consuming in part because a process model often comprises alarge amount of heavily interrelated diagrams and definitions, especially when there are many exceptions and potentialways of doing things. These can make even a relatively simple process look complicated and require a lot of effort to build.An alternative approach comes from the business rules community. Rules are a powerful yet simple method for defining theway business activities are performed. Arguably, business rules are also more powerful — considering the underlying seman-tic and formal aspects — than most workflow modeling languages. At the same time, business rules can be directly mappedon the technical architecture with the use of specialized middleware — rule engines. The price tag for this approach isrelated to the fact that the simplicity of defining individual building blocks for processes (the rules) needs to be balancedby the complexity of managing large sets of interrelated rules.

ORGANIZATIONS AS VALUE NETWORKS Research in the area of social networks reveals the hidden structure dwelling under the cover of an official org chart. Manyknowledge-based organizations are de facto value networks, comprising groups, teams, and units that exchange servicesand information in order to create value for the customers. The approaches listed above are well suited for modeling suchenvironments, by defining service portfolios and associating them with rules that define their internal and external behavior.



feedback should be included ineach cycle to allow decisions to bemade based on gained experience.

The detailed analysis and defini-tion of business processes is inmost cases a very tedious exer-cise, which, from the viewpoint ofresults expected from enterprisearchitecture management, oftenproves to be unproductive. This isnot to say that having a detailedbusiness process map doesn’tdeliver any advantages; it is onlythat, given the complexity and therate of change in modern busi-ness, the effort required to definemodels that truly reflect businesspractices and intentions andmaintain their currency is inmost cases too large to justify thepotential benefits.

It is therefore necessary to usea tool that gives a simplified yetgood enough view of how busi-ness activities are organizedand supported by IT services.

Our experience shows that asimplified view of end-to-endprocesses (aka business cycles)proves to be good enough even infairly complex environments suchas a telecommunications com-pany or a large governmentagency.

Let’s now take a closer look atbusiness cycle anatomy. The mostimportant characteristic is its tim-ing — the time frame in which theindividual cycle iteration is to becompleted, as required by busi-ness constraints. Each businesscycle represents a sequence oftasks being done for a particularpurpose (see sidebar “BusinessCycle Classification”) and within aparticular time frame.

The adaptive process model weuse in the business cycle analysis— the so-called observe, orient,decide, and act (OODA) loop —comes from US Air Force ColonelJohn Boyd, who used it to presentconcepts of maneuver warfare.Boyd disseminated his ideasthrough numerous briefings tomembers of the defense commu-nity. The content of these briefingshas changed over time, echoingthe evolution in Boyd’s thinkingabout competitive strategy. OODAhas been introduced in briefingstitled “Patterns of Conflict” and“The Essence of Winning andLosing,” later becoming one ofthe focal points for a series ofbriefings called “A Discourseon Winning and Losing” [2].

OODA and maneuver warfare havebeen adopted in modern militarythinking as well as in business andinformation technology. One of themost interesting applications ofOODA to strategic IT planningcomes from Boar, who has formany years been among the pio-neers of enterprise architecturemanagement (see Figure 2).

The components of OODA —observe, orient, decide, and act — are the four critical areas ofany adaptive process based on a“sense and respond” model. Theflow of information among theseareas, along with actions specificfor each of the areas, creates aseries of loops shaping the behav-ior of an entity in a competitiveenvironment, be it a fighter pilotengaged in a dogfight or an orga-nization involved in a highly com-petitive market.

Several of Boyd’s observations areworth considering (these comefrom Boyd’s writings and from thebriefings as they are reported byhis biographers and acolytes):

From the perspective of theOODA model, the key to win-ning a competitive game is tobe able to execute the OODAloop faster than the opponentor competitor.

The heart of the OODA loop isthe orientation phase; it is herethat data is transformed to ameaningful picture of realityenabling meaningful actionsto be taken in order to exploitopportunities or take evasive

BUSINESS CYCLECLASSIFICATION

Business cycles are the equivalent ofend-to-end processes: sequences ofactivities, triggered by a businessevent, that deliver some businessvalue. Often-cited examples ofbusiness cycles include:

Sales cycle (order to cash)

Procurement cycle (procure to pay)

Service cycle (demand to service)

New product/service developmentcycle (concept to market)

Innovation cycle (idea toimplementation)



EXECUTIVE REPORT 77

actions to mitigate risks. Theorientation phase exploits vari-ous mental and formal modelsto evaluate information andfilter events on which someaction should be taken.

The fastest loops are those thatdo not require explicit decisionmaking. Implicit guidance andcontrol or reflex-like behaviorthat can be achieved throughautomation, training, and distri-bution of the decision-makingprocess lead to the best com-petitive performance, as longas the “reflexes” are relevant.

The reasons why even the bestmodels become obsolete stemfrom changes in the environ-ment and from the changingrules of competition. An oppo-nent may fly a better aircraftnext time or might be bettertrained. A competitor may copyand improve our ideas andproducts, change, or success-fully use emerging technologyto disrupt the entire market,

changing the basis ofcompetition.

If orientation is the heart of theadaptive loop, then thoroughunderstanding of the evolvingrequirements and motivationsconcerning various aspects ofenterprise architecture (such asflexibility, cost of ownership, andinformation quality) is needed tomaintain the business value of thetechnology investment portfolio.The roadmapping process canprevent a situation in which theIT legacy becomes unmanaged —a situation where the constraintscreated by technology over-shadow any benefits and opportu-nities. Such a situation — a “badlegacy” — represents a friction inthe architecture, impairing theagility of an enterprise. The fric-tion manifests itself in issues suchas the need for reconciliationof inconsistent or absent data,growing integration spaghetti,unwanted latency, and so on.

VALUE CHAIN

In reference to Figure 2, onecycle’s “act” task results couldbe a trigger for another cycle’s“observe” task. This defines a waybusiness cycles can cooperate —a way of describing volatile busi-ness rules. For example, let’sconsider two cycles: demand toservice and order to cash. Thefirst observes the market tocreate new services; the secondobserves service requests toensure they are paid. Each time anew service is created in the firstcycle, it should be included in theset of services observed by thesecond cycle. Such relationsamong business cycles create avalue chain in which each cyclein the chain adds value to theorganization (see Figure 3).

The value chain presents a goodview of business rules dynamicsin the enterprise and thus couldbe regarded as an applicablemeans of describing dynamics

Observe Orient Decide Act

ObservationsDecision

(hypothesis)

Action

(test)

Unfolding

circumstances

Outside

information

Implicit

guidance and

control

Implicit

guidance and

control

Feedback

Feedback

Feed

forward

Feed

forward

Feed

forward

Unfolding

interaction

with

environment

Unfolding

interaction

with

environment

Culturaltraditions

Geneticheritage Analyses

andsynthesis

Newinformation

Previousexperience

Figure 2 — OODA: the adaptive loop [2].



instead of business processes.This is the first ingredient of effi-cient communication betweenbusiness and IT.

Logical Architecture

The business is not concernedwith systems technology, data-base structures, or data models.Instead, business users quite eas-ily understand system functions,simplified to some extent, anduse them quite appropriately.Describing each information sys-tem by means of its main func-tions — or rather services — issufficient to give business users aview of the information environ-ment that allows them to commu-nicate unambiguously. The set ofservices offered by each informa-tion system forms a base for thelogical architecture.

From the EA point of view, a logi-cal architecture represents themost precise level of detail in thearchitecture description on whichits elements’ categorization(grouping and layering) is still pos-sible. This categorization shouldbe based on elements’ features —for example, presentation featuresshould be grouped into the pre-sentation layer, while businesslogic features should be groupedin the business logic layer. Thisis the level on which most archi-tecture patterns are applicable.Logical architecture elements(architecture blocks) shoulddescribe precisely the purposeof a particular service and its fea-tures creation, refraining fromtalking about a particular technol-ogy or software package. Sincelogical architecture is the EAlanguage, this level of abstraction

should be of the highest impor-tance to enterprise architects.

Since understanding logical archi-tecture components and the over-all logical architecture conceptforms a good basis for communi-cation, it could be regarded asthe second ingredient of efficientcommunication between businessand IT. In combination with thebusiness cycles concept, the over-all information environment couldbe understood by business usersand thus create communicationlanguage. In this language, ser-vices defined within the logicalarchitecture are being used withinbusiness cycles, and all architec-ture features important for busi-ness become visible, especiallycapabilities and constraints.

As an example for the languageuse, consider real-time ratingrequirements for a telecommuni-cations operator. The ratingprocess assigns a price to eachtelecom service usage data. Itrequires the collection of call datain the form of call data records(CDRs) from network elements.These CDRs are processed inorder to be presented to the tele-com customer. As the collectioncycle is the only one that cannotbe run in a real-time manner, thisis the place where developmenteffort should be put. Such state-ments are understood to businessusers without lengthy discussionson rating systems capabilities, andthey are understood to technicalpeople as well.

Support

Activities

Primary

Activities

Customer

need

identified

Customer

need

satisfied

Firm infrastructure

HR management

Technology development

Procurement

Inboundlogistics

OperationsOutboundlogistics

Marketingand

salesService

Identifythe

market

Createproduct/serviceoffering

Build theproducts/services

Deliver theproducts/services

Service thecustomer

Innovation process Operations process

Postalserviceprocess

Michael Porter’s value chain model

Kaplan and Norton’s generic value chain model

Figure 3 — Value chain examples.



EXECUTIVE REPORT 99

COMMON ARTIFACTS

Business cycles and logical archi-tecture should be used as meansof communication with the busi-ness, but the result is not yetbusiness-IT alignment. Stayingwithin the set of concepts, thegoal for architecture managementshould be closing and shorteningbusiness cycles according to busi-ness requirements. So the ques-tions to be answered could bestated as follows:

How should we build cycles?Which components of logicalarchitecture should be used toachieve the desired result?

How should we close cycles?How do we connect compo-nents of logical architecture toachieve feedback?

How should we shorten cycles?What cycle elements shouldbe modified to achieve therequired timing?

The answer to each of these ques-tions could be as straightforwardas the real-time rating examplepresented above. What’s mostimportant is that both parties —business and IT — understandthe change required in the samemanner and do not force theother party to get deeply into itsarea of expertise. So the goal forcommunication between businessusers and IT would be answeringquestions like the ones above.

To sum up, with reference to thegeneric EA planning framework,the goal of IT communication with

the business is to understand whyand to define what. To be precise,the means of communicationdescribed above touches on twoaspects of enterprise architecturemanagement:

1. Know why (business inten-tions, objectives, and impera-tives) — understanding thecycles, their relations, and thevalue chains these relationscreate; we call it businessarchitecture.

2. Know what (EA, its compo-nents, and capabilities) —describing architecture compo-nents, services offered to theinformation environment; wecall it logical architecture.

Furthermore, in order to define EA,there are three remaining aspectsthat should be determined:

3. Know how (patterns,standards, and tools) —determining the way

architecture capabilities shouldbe implemented; we call ittechnical architecture.

4. Know when (timing) —assessing the time relationstime frames for rollout ofabovementioned aspects.

5. Know who (organization, peo-ple, and partners) — assigningroles and responsibilities toapplicable activities.

The EA planning framework isderived from the technology plan-ning framework presented inRobert Phaal, Clare Farrukh,and David Probert’s “Fast-StartTechnology Roadmapping” [6]and shown in Figure 4.

What any business would cer-tainly request as the result ofinterrogation is a high-level plandetailing when its requirementswould be fulfilled — a “schedule”showing IT initiatives being takento achieve business objectives

Know Why

Know What

Know How

Know When

Know Who

Business level

EA level

Technology level

Goal

to

impact

Potential

to

opportunity

Time

Project teams Competency centers Vendors

Focus: agility, opportunities, risks, processes, time advantage, efficiency

Process: strategic scenario planning, business development, enterprise risk management

Focus: EA building blocks — applications, platforms, services; service levels

Process: EA management, application development and integration, IT operations

Focus: best practices, architecture patterns, technology lifecycle

Process: standards management, technology management, component management, training

Figure 4 — EA planning framework.



marked with delivery time andthe “relations” describing how theinitiatives support business objec-tives. This is an almost completedefinition of the technologyroadmap.

According to Phaal, Farrukh,and Probert:

The generic roadmap is atime-based chart, comprisinga number of layers that typi-cally include both commer-cial and technologicalperspectives. The roadmapenables the evolution of mar-kets, products and technolo-gies to be explored, togetherwith the linkages betweenthe various perspectives. [7]

Roadmaps can take various forms(see sidebar “Examples of VariousRoadmap Visualization Forms”),from which the service/capabilityplanning roadmap is closest to theEA planning framework concepts.

Hopefully, at this stage, the applic-ability of roadmapping in commu-nication between business and ITis not being questioned. Now, itis high time to get to the EARMtechnique and present the stepsby which IT understands why,describes what, determines how,and assesses when.

The EARM technique descriptionis based on some basic conceptsand is described using a step-by-step approach — from

determining the list of modifica-tions in EA, through sequencingthem in alignment with businessobjectives, to creation of theroadmap itself.

Before going deeper into themethod, it should be stressed thatthe method is iterative, and themain result — the roadmap —should be regarded as a livingdocument. Each shift in businessobjectives or architecture capabil-ities could result in running thenext EARM technique, resultingin a roadmap update.

ROADMAP DEVELOPMENTMETHOD

As presented in Figure 5, theEARM method consists of the

EXAMPLES OF VARIOUS ROADMAP VISUALIZATION FORMS

As presented in [5], depending on its purpose, the roadmap can take some visual forms. For instance, consider the followingexamples:

Product planning roadmap. This is by far the most common type of technology roadmap, relating to the insertion of technologyinto manufactured products, often including more than one generation of the product. Consists of the product layer andtechnology layer. Relations between the two layers show the link between planned technology and product developments.

Service/capability planning. Similar to the product planning roadmap but more suited to service-based enterprises, this focuses onhow technology supports organizational capabilities. Consists of triggers, business and market drivers, capabilities to meet drivers,and technology developments layers. Shows organizational capabilities as the bridge between technology and the business, ratherthan products.

Strategic planning. This includes a strategic dimension, in terms of supporting the evaluation of different opportunities or threats,typically at the business level. Consists of market, business, product, technology, skills, and organization layers. Focuses on thedevelopment of a vision of the future business in terms of markets, business, products, technologies, skills, culture, and so on.Gaps are identified, and strategic options are explored to bridge the gaps.

Knowledge asset planning. This is used to align knowledge assets and knowledge management initiatives with business objec-tives. Consists of knowledge-related processes, knowledge management enablers, leading projects and actions, business objectives,and knowledge asset layers. Enables organizations to visualize their critical knowledge assets and the linkages to the skills, tech-nologies, and competences required to meet future market demands.

Program planning. This is the implementation of strategy and more directly relates to project planning (e.g., R&D programs).Consists of technology developments, key decision points, project milestones, and project flow layers. Shows the relationshipsbetween technology development and program phases and milestones.

Integration planning. This centers on integration and/or evolution of technology in terms of how different technologies combinewithin products and systems, or to form new technologies (often without showing the time dimension explicitly). Focuses ontechnology flow, showing how technology feeds into systems, to support goals.



EXECUTIVE REPORT 1111

following generic steps drivingthe roadmap development:

1. Capturing current architecturedefinition

2. Creating architecture vision

3. Determining list of requiredarchitecture changes

4. Prioritizing changes

5. Adding time scale to theprioritized list

As a result, a target roadmap isbeing created. Each step in themethod is discussed in moredetail in the following sectionswith respect to its goals, itsdescription, tools and techniquesused, and the result or expectedoutcomes.

1. Capturing CurrentArchitecture Definition

In this step, the current architec-ture should be documented to beavailable for comparison with thearchitecture vision.

Goal

The goal of this step is to under-stand the current architecture interms of logical and technicalarchitecture components. For theEARM process, it is typically notnecessary to obtain a completeIT infrastructure assets inventory.The documentation created in thisstep follows the principles of agilemodeling; that is, it should bebarely sufficient to allow futurematching of existing IT capabilitieswith the desired business vision.

Description

For the EARM method, thedescription of the current archi-tecture includes both a logicaland technical view. The logicalarchitecture of the current IT infra-structure comprises existing com-ponents grouped according tobusiness features they perform.It focuses on logical componentsand abstracts from concreteimplementations; it presents a“relational database” instead ofa “database provided by supplierX.” It is important at this stage toacquire a thorough understandingof the dependencies between dif-ferent architecture components. Ifit is possible, the logical architec-ture could present services beingoffered by current IT systems.

The technical architecture pre-sents technical components ofthe IT infrastructure currentlyin operation (e.g., particular[named] application serversor databases).

While assessing current logicaland technical architecture, careshould be taken not to lose rela-tions between logical architecturecomponents and their implemen-tation — technical architecturecomponents.

The EARM process does notrequire that particular models beused to describe either of thearchitectural views. The types ofmodels and the amount of infor-mation captured for the purposeof getting an understanding of thecurrent IT infrastructure dependon the type of roadmap beingdeveloped, its scope, and itsfuture purpose. In practice, eventhough capturing the existing ITarchitecture is shown as the firststep of the EARM process, in sub-sequent steps it is often necessaryto augment the collected infor-mation with the missing data thatmight be required to do, for exam-ple, a gap analysis.

Currentarchitecture

Architecturevision

Roadmap

Vision workshop Variants workshop Roadmap workshop

Architecturechanges

Priorities Time frame

Business

domain

vision

Business

cycles

OODAVariants

selection

criteria

List of

changes

Strategic

goals

Other

business

drivers

Business

constraints

Changes

sequenceChanges

schedule

Figure 5 — EARM method.



Tools and Techniques

In processing this step, the follow-ing tools and techniques could behelpful:

Logical and technicalarchitecture models

Architecture patterns —presenting a generic view forsolving some common archi-tecture problems

Result

As a result of this step, currentarchitecture blueprints should becreated on logical and technicallevels of description. If this is notthe first time the EARM cycle isbeing run, such a descriptionshould already exist.

2. Creating Architecture Vision

In this step, the architecture visionis created to be available forcomparison with the currentarchitecture.

Goal

The goal of this step is to create avision of the required architecturewithin the scope of the architec-ture roadmap to be created.

Description

In the EARM method, the architec-ture vision is described in terms ofits business and logical view. Thebusiness view of the architecturepresents a set of activities that areperformed within the businessarea defined as the scope of the

architecture roadmap creation.These activities are the result ofbusiness value chain analysis —each business area is representedas a chain of interconnected busi-ness cycles that is further decom-posed using the OODA model.Such decomposition maps busi-ness activities onto OODA tasks(see Figure 6). For each OODAcycle step, the business cycle taskis described, time constraintsrequired for the cycle to runappropriately are defined, andthere is an explanation of theissues concerning task timingrequirements and systems to beinvolved.

Since time frames are definedfor each OODA cycle, the timeregime required for business

Business cycle: demand to service (operational cycle)

OO

DA

Observe

Description Timing

Time-based

issues Systems Remarks

Catch event

describing service

order arrival

Online Order management

takes care not to

put delay in service

delivery process

Order management,

configurator

Decide Configurator

decides on

configuration

implementation

based on

available resources

Online Configurator

Online integration

between order

management and

configurator

necessary

Orient Preparation

of network

configuration

and checking

for resources

availability

Online No delays between

network inventory

and configurator;

automatic request

processing

Configurator,

network inventory

Online integration

between

configurator

and network

inventory necessary

Act Decision is passed

to activator taking

care of service

delivery

Online No delays in

communication

between

configurator

and activator

Configurator,

activator

Online integration

between

configurator

and activator

necessary

Figure 6 — OODA cycle decomposition matrix.


activities implementation could beeasily determined within the busi-ness architecture. The decomposi-tion of the business cycle intoOODA steps can be seen as a kindof “validity” test that determineswhether the actual selection ofparticular business cycles for thegiven value chain does indeedbuild required business value.If the business cycle cannot bedecomposed, it might needreconsideration.

The logical architecture view forthe architecture vision describesthe same concepts as those usedin the logical architecture view ofthe current IT infrastructure —components and their features —but with respect to the architec-ture vision being created. It isbased on business domain knowl-edge (regarding, for example,state-of-the-art architecture pat-terns and future trends) anddeveloped further according tobusiness architecture require-ments. Components of the logicalarchitecture vision should presentarchitecture blocks (classes oftechnology solutions). These com-ponents should be functionallyconnected according to thesequence of business activitiesmapped onto OODA tasks. Eachbusiness cycle mapped ontoOODA tasks presents time con-straints for the running of thatcycle. This, in turn, presents atime regime, in which architecturecomponents must operate to ful-fill business requirements. Careshould be taken to properly

classify components’ features andorganize them accordingly (e.g.,into layers). In such an approach,each logical architecture compo-nent should offer services imple-menting business activitiesmapped onto OODA tasks, ableto run within the time regimerequired by the business cycleto be executed.

The creation of a complete archi-tecture vision requires extensivecommunication with businessusers; in practice, several facili-tated workshops are needed toachieve the goals of this step. Insome cases, during such work-shops the current architecturecould be discussed and clarifiedas well.


In processing this step, the follow-ing tools and techniques couldbe helpful:

Business cycle classification— defining parts of the valuechain in the organization

Architecture patterns —presenting a generic view forsolving some of the commonarchitecture problems

OODA cycle — defining tasksbeing performed in each busi-ness cycle

Result

As a result, architecture visionblueprints are created on businessand logical levels of description.

3. Determining List of RequiredArchitecture Changes

In this step, the current architec-ture is compared to the archi-tecture vision to create a list ofrequired architecture changes.

Goal

The goal of this step is to deter-mine the list of changes requiredin the information environmentbased on a comparison betweenthe current architecture and thedesired architecture vision. Duringanalysis, implementation variantsare evaluated and the optimalvariant is chosen.

Description

A comparison of the current archi-tecture and the architecture visionis done using a gap analysis tech-nique. A set of services, togetherwith time regimes, implementedin the current architecture is com-pared to the services required toachieve the architecture vision.Typical questions asked during thecomparison of the current archi-tecture service with the architec-ture vision service focus on:

Existence of applicable logicalarchitecture service for eachtask in each OODA cycle

Applicability of time regime fora particular service

Existence of required logicalarchitecture service in thecurrent architecture



Need for modification of cur-rent architecture service inorder to fulfill requirementsderived from the architecturevision

Ability to cut out some currentarchitecture services withoutnegative impact

While proceeding with the gapanalysis, quite often additionalfeatures are discovered: optionalservices, components, or their fea-tures that could extend the valueof the architecture. Such addi-tional features could be incorpo-rated into the architecture visionas a logical architecture variant.These variants are evaluatedaccording to business constraints,and an optimal variant shouldbe chosen. In case there are nostraightforward criteria for variantselection, such decisions shouldbe made together with businessusers during a variants selectionworkshop.

Results of the comparisonbetween the current logical archi-tecture and the optimal variant ofthe logical architecture vision —decisions regarding adding, modi-fying, or deleting particular logicalarchitecture services — are docu-mented in the form of a list. Ifapplicable, architecture patternsare assigned for each change to beimplemented. Usage of architec-ture patterns results in better EAorganization and control. In addi-tion, it simplifies EA description.

Changes in the logical architec-ture are subsequently mapped

into changes in the technicalarchitecture. For each change(addition or modification) in thelogical architecture, the applicablecomponent of the technical archi-tecture is determined. This iswhere “adding database service”is changed into “adding instanceof database provided by supplierX”; this presents real changes tobe done to the information infra-structure. Each component ofthe logical architecture could beimplemented by many technicalcomponents (e.g., the applicationserver could be implemented asJ2EE or .NET application serverssupplied by one of the available ITvendors). All variants of the tech-nical architecture and all technicalvariants for each logical compo-nent implementation are docu-mented. Finally, an optimal variantis selected; conflicting variants areeliminated, and unification shouldbe enforced (e.g., applicabletechnical standards).



Gap analysis matrix —comparing current architec-ture and architecture vision

Architecture variantspresentation

Result

As a result of this step, the list ofchanges to be implemented isdetermined. Additionally, optimal

technical architecture implement-ing required changes to EA isbeing selected, and usable archi-tecture patterns are determined.

4. Prioritizing Changes

In this step, the list of architecturechanges should be sequenced toreflect business priorities andtechnical dependencies.

Goal

The goal of this step is to prioritizethe list of changes prepared in theprevious step; the changes mustbe prioritized according to busi-ness drivers and technicaldependencies.

Description

The priority of changes to the ITarchitecture typically dependson business issues, but sometechnical dependencies or con-straints could also have an impact.Prioritization is based on anassessment of to what extentthe changes support strategicgoals as well as their level of sup-port for other business driversapplicable to the business area(product strategy, legal obligation,operational necessity, etc.). Suchordering can then be modified bytechnical dependencies betweenrequired changes.

Therefore, each change isassessed as to whether itsupports each of the strategicgoals. This assessment is doneusing a weighted scores matrix(see Figure 7). Each strategic goal




is assigned a weight: for example,3 = must have; 2 = should be;1 = nice to have; and 0 = notimportant. Next, the level of sup-port is quantified to create a sup-port scale: for example, 0 = nosupport; 1 = partial support; and2 = strong support. The supportlevel of each change for eachstrategic goal is then assessedand placed on the support scale.Weighted support is calculated assupport scale value multiplied bystrategic goal weight. Finally, theoverall change score is calculatedas a sum of the weighted supportlevels. The changes are sorted indescending order by the overallchange score with the mostimportant changes at the top of

the list; this forms the base priori-tization scheme.

In most cases, some additionalbusiness drivers influence therequirements for architecturechanges. Each set of the businessdrivers (e.g., product strategyor legal obligations) could beassessed using the same weightedscores matrix. The result wouldthen be presented in the form ofshifts in the required ordering ofthe architecture changes togetherwith its explanation.

During the analysis of additionalbusiness drivers and changes inordering, some additional busi-ness values could be discovered;

particularly the prioritization ofchanges could represent newcompetitive advantage that wasnot visible before. This representsvariants of the architecturechanges ordering. Each variantshould be assessed in order toselect the most promising one; forexample, using SWOT (strengths,weaknesses, opportunities, andthreats) analysis technique. Basedon the assessment, the optimalvariant is then selected. Businessusers should decide if the reasonsfor the shifts in ordering are impor-tant enough to accept them, asthey change the business value ofthe strategic goals. Such decisionscould be made during a roadmapworkshop.



Strategic goals

Arc

hit

ectu

re c

han

ges

Networkinventoryconsolidation(EAI-based)

Salesonline

One ID forcustomer

Real-timecredit check

Customersatisfaction

Costreduction

Single andseparate orderand problemmanagementplatform(EAI-based)

Order

management

starts the

whole cycle

Order

management

manages

singular

customer ID

Order

management

simplifies

order proc-

essing and

credit check

Effective

order tracking

Order

management

reduces

manual

work costs

Coherent xDSLconfigurationmechanism(EAI-based)

Configurator

makes the

activation

process totally

automated

Order

management

manages

singular

customer ID

Effective

order tracking

Network

operations

costs

decrease

Unified billingmethod insidecompany

Rating and

billing support

unified

customer

identification

Rating and

billing systems

integration

supports

single credit

limit

Single and

coherent

billing

information

presented to

customer

Network

management

simplification

— cost

reduction

18

13

2

11

1

3

2

0

0

2

3

2

0

3

1

1

0

0

3

2

3

2

0

1

1

2

3

2

0

Figure 7 — Weighted scores matrix.

Once architecture changes areordered according to businessgoals, it is then examined as towhether such ordering is techni-cally feasible — whether thereexist technical dependencies orconstraints, which would modifythe optimal sequence of architec-ture changes. It is determinedwhether a particular changedepends technically on anotheror whether some changes have

common areas of implementa-tion. Besides obvious technicaldependencies, some additionaldependencies could be discov-ered when looking at the archi-tecture changes from a particulararchitectural viewpoint (see side-bar “Architecture Views”). Everydependency discovered is identi-fied and documented. The opti-mal sequence of architecturechanges resulting from the

business goals assessment is thenanalyzed with respect to technicaldependencies. Each shift in theoptimal sequence resulting fromtechnical dependencies is docu-mented and communicated tobusiness users; if accepted, itmodifies the final ordering ofchanges in the architecture.



Weighted scores matrix —providing synthetic assessmentof each change’s impact onbusiness goals rollout

SWOT matrix — giving analyti-cal business variant assessment

Result

As a result of this step, the listof changes is ordered accordingto strategic goals and other busi-ness drivers. This list incorporatestechnical feasibility dependenciesas well.

5. Adding Time Scale to thePrioritized List

In this step the sequence ofchanges should be assigned timeframes based on business goalsand known constraints.

Goal

The goal of this step is to preparea roadmap — to add time scale tothe sequence of changes in thearchitecture prepared previously.



ARCHITECTURE VIEWS

The following represent the different architecture viewpoints:

Business architecture view — focuses on the functional aspects of the systemfrom the perspective of the users of the system. It addresses the concerns of theusers and includes consideration of people, process, function, business information,usability, and performance.

Enterprise security view — focuses on how the system is implemented from theperspective of security and how security affects the system properties. It examinesthe system to establish what information is stored and processed, how valuable itis, what threats exist, and how they can be addressed.

Software engineering view — focuses on the fact that building a software-intensive system is both expensive and time consuming. Because of this, it isnecessary to establish guidelines to help minimize the effort required and therisks involved.

System engineering view — focuses on how the system is implemented from theperspective of hardware/software and networking. It typically is concerned withlocation, modifiability, reusability, and availability of all components of the system.

Communications engineering view — focuses on how the system is implementedfrom the perspective of the communications engineer. It typically is concerned withlocation, modifiability, reusability, and availability of communications and network-ing services.

Data flow view — focuses on understanding how to provide data to the right peo-ple and applications with the right interfaces at the right time. This view deals withthe architecture of the storage, retrieval, processing, archiving, and security of data.

Enterprise manageability view — focuses on understanding how the system ismanaged as a whole and how all components of the system are managed. The keyconcern is managing change in the system and predicting necessary preventativemaintenance.

Acquirer’s view — focuses on understanding what building blocks of the architec-ture can be bought and what constraints (or rules) exist that are relevant to thepurchase.


Description

Assigning time frames to thesequence of architecture changesis initially based on businessmilestones. This timing couldbe modified by results of roughtime estimations preparedfor each architecture changeimplementation.

Aligning architecture changeswith time is like scheduling inter-related tasks of a project. All thedependencies among the archi-tecture changes represent inter-relations, while time estimationfor a change implementation rep-resents duration. Strategic goalsare usually long-term issues, andas such they have no strict dead-lines defined. In the case ofbuilding a roadmap withoutany additional business con-straints, adding time frames tothe sequence of architecturechanges is quite straightforward.Other business drivers couldunderpin some time constraints(milestones), which should beevaluated, whether architectureis able to fulfill them or not.

In cases where the business con-straint could not be fulfilled, itshould be communicated to busi-ness users along with a descrip-tion of the reasons. If accepted,it modifies the final time framesof the architecture changesimplementation.

The final sequence of architecturechanges together with expectedtime scheduling is documented inthe form of a roadmap (see Figure

8). Additionally, each requiredarchitecture change is docu-mented based on informationcollected: its goal, description,dependencies, business justifica-tion, and estimations.



Roadmap presentation —giving a template of roadmapvisualisation

Architecture changedescription — giving atemplate for documentingrequired architecture change

Result

As a result of this step, a completeand final roadmap is created. Itpresents a time-framed sequenceof changes in the architecturealigned with business goalsand incorporating technicaldependencies.

EA MANAGEMENT ANDEA ROADMAPPING

As stated above, EARM proposesa technique for EA planning,according to the EA planningframework, and the resultingroadmap itself is applicable as aconceptual tool for communica-tion between business and IT tobetter align their activities. SinceEA management is a more gen-eral concept, it is worthwhile tounderstand how EARM couldsupport a broader EA initiative.

Most approaches to EA manage-ment are designed as an iterativeeffort, with incremental advance-ment from “as is” toward a “to be” state. Typical EA manage-ment iteration starts with defining(updating) an architecture vision,proceeds through a brief compari-son with the current architecture,planning for changes migration,and ends with some kind ofimplementation governance. Incomplex organizational and ITenvironments, the planning effort



Pro

du

cts

Serv

ices

Tech

no

log

ies

Event-based

billingVideo over xDSL

VoIP,

bandwidth

on demand

New billing

methods,

new service

platforms

New billing

methods,

new service

platform

Credit account

services

New service

platform,

bandwidth

on demand

Activation and

technical

feasibility services

Configurator

Order manager,

configurator,

and activator

integration

IAAA,

credit account

Configurator

extension –

bandwidth on-

demand services

Figure 8 — Roadmap presentation.

may need to be executed on mul-tiple levels. An example shown inFigure 9 illustrates a process thatconsists of two levels. High-level(strategic) planning transforms thestrategic intentions into a set ofmajor IT initiatives (such as a cus-tomer relationship managementprogram, a distribution channelintegration program, or a consoli-dation of IT resources). This maybe complemented by series ofoperational plans representinghow business objectives are deliv-ered by transforming the architec-ture toward the “nearest” set ofhigh-level milestones.

In such situations, the major chal-lenge is to capture and managechanges resulting from the com-plex relationships between thechanges in business environment,technologies, and componentsof the IT puzzle. A well-designedset of roadmaps, developed in acollaborative process, may helpconceptualize, capture, and com-municate these relationships ina way that improves the capa-bility to absorb changes without

creating chaos in the enterprisearchitecture.

This strategic plan could be pre-sented in the form of a strategicEA roadmap. EA managementcycles are executed, each con-taining its own planning activitiesregarding the scope of changes tobe implemented in that cycle. Asa result, each EA managementcycle delivers an operationalroadmap. Each time an opera-tional roadmap is created, thestrategic roadmap may beadjusted — changing timing orsome other aspects of architec-ture vision. The strategic roadmap,however, should be a stabilizingfactor as long as the businessmotives on which the long-termarchitecture vision has been builtare stable.

What should be stressed at thisstage are the iterative characteris-tics of both EAM concepts andEARM. Iterations in roadmap cre-ation and adjustment allow youto correct plans as new issuesemerge. These issues could

regard both technical and busi-ness aspects impacting theroadmap. The iterative natureof EARM results in the ability tointroduce refactoring cycles, inwhich changes made to the archi-tecture in previous cycles couldbe lined up and made commonor shared.

This leads to a generalized “proce-dure” of EARM cycle scope selec-tion, which plays an importantrole in the method rollout. Themain assumption for the methodis that it is hardly possible to cre-ate a complete architecture visionfor the entire enterprise. It is pos-sible, however, to identify somebusiness areas, in which architec-tural work could be done and inwhich “interfaces” with otherparts of the company businessare quite able to be defined. Sucha business area with its interfacecould be regarded, with somedegree of simplification, as thescope of an EARM cycle. Suchan approach makes it possibleto conduct EAM on an area-by-area basis.

Another concept permitting thenarrowing of the scope of an indi-vidual EARM cycle is the architec-ture view. It could be regardedas a representation of the overallarchitecture that is meaningfulto one or more stakeholders. Itenables the architecture to becommunicated to, and under-stood by, all the stakeholders andenables them to verify that it willaddress their concerns. The archi-tecture could be seen through, for



…

Results of strategic roadmapping

EA planningiterations

Operationalroadmaps

Currentarchitecture

Architecturevision

Strategic roadmap

Figure 9 — Strategic and operational roadmaps.


example, enterprise security, sys-tem engineering, manageability,procurement, or particular systemowner views. Each of these views,or a set of them, could create ascope for the EARM cycle run.

It should be noted that each timethe scope of an EARM cycle isnarrowed, some aspects of thearchitecture vision could bemissed. This is the tradeoff neces-sary for the work to be effectiveand efficient. As a contingency tothis drawback, refactoring EAMcycles can be introduced after anumber of regular EAM cycles.

The EARM cycle scope selectionprocedure mentioned above takes

these two dimensions and selectsthe scope of the individual EARMcycle, adding concepts of the EAplanning framework to them. Toselect the scope, the businessarea should be identified andapplicable architecture views anda level of description (know why,know what, know how) should bedecided (see Figure 10). It couldbe a quite common case, wherethe strategic roadmap presentsoverall EA migration, while eachcycle operational roadmap EARMcycle should take care of the indi-vidual business area to be cov-ered. In other cases, the resultcould be perceived as a broaderframework for thinking about EA.Its main purpose is to prepare a

roadmap, but particular steps,tools, or techniques could be usedeven without the roadmap goal inmind. Depending on the scope ofthe EARM cycle, its steps could beprocessed or not. For example,(see Figure 11), if the scope ofthe EARM cycle is defined as dis-covering “know why” and “knowwhat” for many business areas, notechnical solutions or time framescould be determined. In that case,the roadmap is of a less precisenature, but it could be made moreprecise in subsequent EARM cycleiterations being run for each busi-ness area to determine “knowhow” and “know when.”



Know Why

Know What

Know How

Know When

Know Who

Area 1 Area 2 Area 3 Area n...

Business areas

EA

pla

nn

ing

fra

mew

ork

EARM cycle scope:

• Business areas

• EA planning framework dimensions

• Architecture view

• Resulting artifacts

Figure 10 — EARM cycle scope selection.

(Text continues on page 21.)



Know Why

Know What

Know How

Know When

Know Who


Business areasE

A p

lan

nin

g f

ram

ew

ork

Iteration 1

Iteration 2 Iteration 3

Iteration 5

Iteration 4

Figure 11 — EARM cycle scope: broad business, precise technical.

Know Why

Know What

Know How

Know When

Know Who


Business areas

EA

pla

nn

ing

fra

mew

ork

dim

en

sio

ns Iteration 1

Iteration 1

Iteration 2 Iteration 3

Iteration 6

Iteration 4

Iteration 5

Figure 12 — EARM cycle scope: technical for many business areas.


In another example (see Figure12), if the variants of the technicalarchitecture are too complicatedor could affect other businessareas’ architecture, the currentEARM cycle could be finishedwithout roadmap creation andthe next cycle could be started inorder to assess the impact ofchanges on other business areasin order to select the optimal vari-ant of the technical architectureand create a roadmap based onthat optimal variant.

EXAMPLES

This section follows the abovediscussion with some real-worldexamples.

Integration Architecture

The first project has been exe-cuted for a telecommunicationscompany that has been in theprocess of business and technol-ogy consolidation with its mobilesubsidiary. The process beganwith offering common products totheir customers, which requiredsome integration of the two com-panies’ IT environments. The goalof the roadmapping project was

to propose an integration architec-ture in four business areas (seeFigure 13). Four business areaswere chosen for the purpose ofdetermining the optimal integra-tion architecture. The projectwas successfully completed insix months.

The first business area (customerself-care) regarded common carefor a customer having businesswith either of the two companies.This area had been deeplydefined in terms of technicalsolution; we started with broadcustomer-care business vision,identified applicable logical



Know Why

Know What

Know How

Know When

Know Who

Customer

self-care

Usage data

processing

Provisioning

control

layer

DSL-based

products

Business areas

EA

pla

nn

ing

fra

mew

ork

Iteration 1

Iteration 1:

• Business

architecture

vision

• Logical

architecture

vision

• Architecture

patterns

• Technical

architecture

vision

Iteration 2:

• Logical

architecture

vision

• Architecture

patterns

• Technical

architecture

vision

Iteration 3:

• Logical

architecture

vision

• Current logical

architecture

• Architecture

patterns

Iteration 4:

• Business

architecture

vision

• Logical

architecture

vision

Iteration 5:

• Technical architecture vision

• Roadmap

Figure 13 — Integration architecture: scope of EARM iterations.

(Text continued from page 19.)

architecture and some architec-ture patterns, and finally definedthe technical architecture forthat area.

The second business area (usagedata processing) concerned uni-fied mediation, rating, and billingfor both voice and IP servicesbilling data. Since businessarchitecture was quite well-defined here, we focused onlogical architecture and technicalarchitecture patterns.

The third business area (provi-sioning control layer) describedthe way services provisionshould be controlled in order toachieve a smoothly running andtransactional provisioning process.Since we quickly discovered thatit strongly depends on the servicesplanned to be provisioned in thenear future, we decided to splitthis business area analysis intotwo iterations. Within the first one,we defined architecture on thebusiness and logical level withsome applicable architecturepatterns. The second one wasdecided to be postponed untilthe next business area wasprocessed.

The fourth business area (DSL-based products) concerned theroadmap definition respondingto business plans regarding DSLtechnology-based products andservices. We focused here onbusiness architecture and definedlogical architecture as well. Aswe discovered previously, this

business area roadmap had beenstrongly correlated with provision-ing control features implementa-tion, so we decided to build acommon roadmap for the thirdand fourth business areas.

The roadmap created was basedon the fourth business area busi-ness architecture and concernedconsolidated logical architecturesresulting from the third and fourthbusiness areas analyses. For suchscope, we defined the technicalarchitecture vision and a roadmappresenting the way in which bothprovisioning and services platformtechnology should support busi-ness plans regarding the rollout ofnew products.

eGovernment Gateway to Poland

In 2004, the Polish governmentdecided to run an initiative forbuilding electronic access topublic administration services inPoland. One of the challenges wasto define the overall architecturefor such an initiative, aligned withthe grassroots initiatives accom-plished by some local govern-ments. The architecture neededto find a balance for the role ofprovider of integrated interagencyservices with the role of support-ing infrastructure and aggregatorof services developed by indepen-dent local governments and non-governmental organizations.Adopting the EARM principlesenabled the team to define thearchitecture on business and logi-cal levels (see Figure 14) andbuild a strategic roadmap on the

business architecture level in justtwo months.

One of the key architectural prin-ciples employed in the gatewaydesign was the assumption thatthe gateway will serve differentroles depending on the level ofintegration and the amount ofbespoke business logic requiredby a given service. These rolesformed an evolution path startingfrom a simple directory providinga single entry point for informa-tion browsing, through a gatewayrole extending the directory withidentification services and finish-ing with notifier and coordinatorroles, in which the eGovernmentGateway mediates messagesbetween government agenciesand citizen (G2C) and among gov-ernment agencies (G2G), respec-tively. Based on that businessarchitecture vision, we developedthe logical architecture vision,optimized to support the businessarchitecture vision evolution.

The result of the project was anarchitecture vision defined onbusiness and logical levels and anarchitecture roadmap presentingthe increments of eGovernmentGateway. Additionally, a catalogof architecture patterns wascreated to assist the design of e-government implemented onthe Gateway platform.

CONCLUSIONS

The EARM method affords anopportunity for rapid creationof valuable results in the field of




integrated business-IT planning.Decision-making time couldbe of essence, so the fact thatthis method focuses on the mostimportant issues and reduces thenumber and volume of artifacts toa necessary minimum makes ithighly usable, effective, and effi-cient in the field of EA changesplanning.

The method presented in thisreport proposes a framework forconsciously simplified thinkingabout changes to EA. Strategically,this method allows you to plan formedium- and long-term modifica-tions in the information environ-ment on a level that gives you theability to justify and communicatewith the business, without getting

into deep and broad businessanalyses. More importantly, themethod gives answers on thestrategic level — whether tech-nology is able to support companystrategy or not. From an IT opera-tional point of view, the resultsproduced by the EARM cycleallow you to place IT endeavors incontext of the architecture visionmore broadly than the individualtechnical area. As a result, invest-ment decisions can be madefaster and can more accuratelyreflect the changing business andtechnology environment, support-ing the time-based competitivestrategies so typical for modernbusiness and for improving capitalefficiency.

EARM is in many respects an agileapproach to integrated business-ITplanning and management. Itallows you to focus on themost important issues, adapt tochanges rapidly, and does notrequire extensive effort for pro-ducing valuable results. The basicconcept of iterations affords thepossibility to adapt and react,while selecting the scope of theEARM cycle gives the opportunityto focus on important pieces ofbusiness. These iterative charac-teristics form a basis for the self-healing features of the EARMcycle — refactoring cycles couldbe introduced in case of a risk ofno compatibility among previouslyfinished EARM cycle results.



Roles:

Pre

se

nta

tio

nM

idd

lew

are

Se

rvic

es

Acce

ss c

ha

nn

els

Po

rta

l m

od

ule

s

Po

rta

l

Co

nte

nt

inte

gra

tio

n

Content

adapter

Public admin.

unitAccess platform Middleware platform SDK

Off

ere

d s

erv

ice

s

Ce

ntr

al

ap

plic

atio

ns

Ap

plic

atio

n

de

ve

lop

me

nt

en

vir

on

me

nt

Se

rvic

es

inte

gra

tio

n

Service

adapter

Internet DMZ Central platform Intranet/VPN

Directory GatewayNotifier and

coordinator

Figure 14 — Polish eGovernment Gateway evolution.

This method, however, shouldnot be considered (and was neverintended to be) an “UltimateAnswer” (in Adams’s terms) toall architecture problems. Its endresult depends strongly on thecontext of EARM cycle processing,the correctness of its scope selec-tion, and the company culture inwhich the method operates. Itgives means of communication,but communication itself requirespeople to cooperate.

Last, but not least, this methodis a tool to be used by an awareenterprise architect. It does notrequire formal organizationalstructure like an architectureoffice. Nevertheless, in case theorganization wants to build anarchitecture office, EARM can beused successfully in such organi-zational frameworks as well.

ABOUT THE AUTHORS

Bartosz Kiepuszewski is aSenior Consultant with CutterConsortium’s Agile ProjectManagement and EnterpriseArchitecture Practices. He is alsoa Senior Consultant at Infovide, theexclusive representative of CutterConsortium in Poland that special-izes in EA consulting and imple-mentation. Dr. Kiepuszewski, whospecializes in J2EE architectures,workflow systems, and agile soft-ware development, holds a Ph.D.from Queensland University ofTechnology, where he workedon theoretical foundations forworkflow modeling languages.

Before joining Infovide in 2001, heworked for five years in Australia,first at the Distributed SystemsTechnology Centre as a researchscientist, and later at MincomLtd. as a Senior J2EE Architect.Dr. Kiepuszewski has authorednumerous research papers, pri-marily in the workflow area,and he is a frequent speaker atnational and international confer-ences, seminars, and trade shows.He can be at [email protected].

Sebastian Konkol is a SeniorConsultant at Infovide. He iscoauthor of the EAM approach atInfovide. He splits his time amongrunning strategic IT consultingendeavors, performing projectmanager duties, and being anEAM expert. Before joiningInfovide in the beginning of 2003,he worked in a mobile telecomoperator company as programmanager responsible for runningprojects aimed at the creation ofGSM VAS (value-added services)offered to the mass market.Mr. Konkol has authored numer-ous publications dealing withIT and telecom information envi-ronment management and ITorganization management.

Wojciech Ozimek is a SeniorConsultant with CutterConsortium’s Business-ITStrategies and EnterpriseArchitecture Practices. He isalso the R&D Director at Infovideand principal and cofounder of

one2tribe. Mr. Ozimek began hiscareer at Polish Telecom, wherehe was involved in the design andimplementation of high-availabilitydistributed systems, OO method-ologies, and human-computerinteraction design. In 1998,Mr. Ozimek joined Infovide, wherehe has participated in numerousprojects as consultant, architect,and project manager. As R&DDirector, he has focused on strat-egy and business development.Today Mr. Ozimek’s responsibili-ties include exploring new busi-ness areas for the company aswell as performing high-levelarchitecture and strategy consult-ing for select Infovide clients. In2003, Mr. Ozimek foundedone2tribe, a small companythat specializes in creating largemobile communities. He is theauthor of many articles for Polishbusiness and IT publications andis a frequent speaker at confer-ences, seminars, and trade shows.Mr. Ozimek can be reached [email protected].

Borys Stokalski is a SeniorConsultant with CutterConsortium’s Business-ITStrategies and EnterpriseArchitecture Practices and isa cofounder and principal ofInfovide. Mr. Stokalski began hiscareer in 1985 as a researchworker and then as a lecturer inthe area of human-computerinteraction at Warsaw University.Today his primary responsibilitiesinclude business development,




innovation, and strategy. He takesan active part in Infovide initia-tives targeted at new serviceareas and consulting products.Mr. Stokalski occasionally takesthe opportunity to perform high-level consulting and coachingfor select Infovide clients. Hefrequently publishes articles onenterprise architectures, business-IT alignment, IT strategy, and IT-based innovations, and is a fre-quent speaker at conferences andseminars. He can be reached [email protected].

REFERENCES

1. Ambler, Scott. “An AgileApproach to EnterpriseArchitecture.” Cutter ConsortiumEnterprise Architecture ExecutiveReport, Vol. 7, No. 5, 2004.

2. Boyd, John. “A Discourse onWinning and Losing,” 1996(www.d-n-i.net/second_level/boyd_military.htm#discourse).

3. Davenport, Thomas. “TheComing Commoditization ofProcesses.” Harvard BusinessReview, 1 June 2005.

4. Kaplan, Robert S., and David P.Norton. The Balanced Scorecard.Harvard Business School Press,1996.

5. Kiepuszewski, Bartosz, MichalPaluskiewicz, Borys Stokalski,Sebastian Konkol, and MaciejRuszynski. “Applying EARoadmapping: An SOARoadmap.” Cutter ConsortiumEnterprise Architecture ExecutiveReport, Vol. 7, No. 9, 2004.

6. Phaal, Robert, Clare Farrukh,and David Probert. “Fast-StartTechnology Roadmapping.”Department of Engineering,University of Cambridge, 2000.

7. Phaal, Robert, Clare Farrukh,and David Probert. “TechnologyRoadmapping: LinkingTechnology Resources toBusiness Objectives.” Centrefor Technology Management,University of Cambridge, 2001.

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

RESOURCES

Orr, Ken, in collaboration with BillRoth and Ben Nelson. “BusinessEnterprise Architecture Modeling,”Cutter Consortium EnterpriseArchitecture Executive Report,Vol. 8, No. 3, 2005.



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 Enterprise Architecture Practice offer continuous research into the latestdevelopments in this area, including Web services, enterprise applicationintegration, XML, security, emerging and established methodologies, Model DrivenArchitecture, how to build an enterprise architecture, plus unbiased reports on thevendors and products in this market. Consulting and training offerings, which arecustomized, can range from mapping an infrastructure architecture to transitioningto a distributed computing environment.

Products and Services Available from the Enterprise Architecture Practice

• The Enterprise Architecture Advisory Service• 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:

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


the hitchhiker's guide to enterprise architecture roadmapping

Documents