arquitectura empresarial

Enterprise ArchitectureTrends 2007

by Michael Rosen, Director, Cutter ConsortiumEnterprise Architecture Practice; with contributionsfrom Scott W. Ambler, Tushar K. Hazra, WilliamUlrich, and Jim Watson, Senior Consultants,Cutter Consortium

While 2007 looks like another interesting year for enterprise

architecture, what will be most important? What are the trends?

To answer these questions, this Executive Report assembles a

collection of articles from several Cutter Senior Consultants on

some of the more important topics.

Enterprise Architecture

Vol. 10, No. 1

http://www.cutter.com

About Cutter ConsortiumCutter Consortium is a unique IT advisory firm, comprising a group of more than 150 internationally recognized experts who have come together to offer content,consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, ground-breaking work in organizations worldwide, helping companies deal with issues inthe core areas of software development and agile project management, enterprisearchitecture, business technology trends and strategies, enterprise risk management,business intelligence, metrics, and sourcing.

Cutter delivers what no other IT research firm can: We give you Access to theExperts. You get practitioners’ points of view, derived from hands-on experience withthe same critical issues you are facing, not the perspective of a desk-bound analystwho can only make predictions and observations on what’s happening in themarketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats includingprint and online advisory services and journals, mentoring, workshops, training,and consulting. And by customizing our information products and training/consultingservices, 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]

Welcome to 2007. It promises tobe another exciting and busy yearin architecture. To start the yearoff, we’re going to take a lookahead at what’s likely to be impor-tant in enterprise architecture (EA)this year. This report takes a differ-ent approach from most CutterExecutive Reports by offeringyou insights from several CutterEnterprise Architecture SeniorConsultants. As a result of thesevaried perspectives, this reportexamines a broad range of EA top-ics, including identifying importanttrends in service-oriented architec-ture (SOA), EA programs, businessarchitecture (BA), collaboration,and mobility, and makes recom-mendations for how to addressthese issues in EA to deliver value.But before we get to all of that,I start us off by getting right to

what we see happening in thecoming year.

I’ve divided this look ahead intofour main topic areas:

1. More of the same. Some top-ics in 2007 will be a continua-tion of those of previous years.I look at what important thingsfrom last year are still impor-tant this year.

2. Struggling to see value. ManyEA programs are strugglingto demonstrate value. In thissection, I look at importantapproaches for making archi-tecture more successful.

3. Bigger and better. At thesame time, many programshave been successful. I discusshow they’re building on that

success and what new areasare being explored.

4. New demands. IT and EA con-tinue to have new demandsand expectations placed onthem. I examine some of thenew technologies and otherareas that now need to beconsidered in EA.

More of the Same

In 2006, we saw a lot of activity inenterprise architecture programs.Much of the EA activity continuesto be driven by the US federal gov-ernment and its mandate for EAprograms in every governmentdepartment. But EA programsflourished in private industry aswell. Fueled by increased com-plexity, EA is a common approachto try and make some sense of

Enterprise Architecture Trends 2007ENTERPRISE ARCHITECTUREADVISORY SERVICEExecutive Report, Vol. 10, No. 1

THE YEAR AHEADby Michael Rosen, Director, Cutter Consortium Enterprise Architecture Practice


VOL. 10, NO. 1 www.cutter.com

22 ENTERPRISE ARCHITECTURE ADVISORY SERVICE

the mess enterprises get them-selves into after years of uncoordi-nated IT development and as aresult of mergers and acquisitions.New demands for accountabilityand new regulations for compli-ance also have thrown a mon-key wrench into the IT works ofmany organizations. Finally, globalcompetition has raised the baron efficiency and has also raisedcustomer expectations for consis-tency and integration.

Of course, SOA dominated archi-tecture news in 2006, with thehype machines still running inoverdrive. On the positive side,SOA is no longer consideredsynonymous with Web services.Although that is the most likelytechnology for implementation,there seems to be a generalunderstanding that SOA is much,much more than just technology.Unfortunately, exactly what thatmight be is still elusive. Somelikely candidates are governance,business process management(BPM), and architecture. It alldepends on who you listen to,and since most of the hype isdriven by vendors, it is oftenproduct-related.

Governance was a big topic in2006. In SOA, we often discussgovernance in terms of threedifferent aspects of a service’slifecycle:

1. Runtime governance — poli-cies that affect the binding ofconsumers and providers

2. Design-time governance —policies and procedures toensure that the right servicesare built and used

3. Change-time governance —policies and procedures thataffect the design, versioning,and provisioning of serviceenhancements

Not surprisingly, the emphasis ongovernance is driven by vendorsthat sell governance solutions.Runtime governance is imple-mented by registries that canapply the governance policies atbinding time. We can come upwith lots of great potential appli-cations for runtime governance,dynamic binding, and the like, butthe fact remains that only a verysmall percentage of current SOAenvironments use these tech-niques, including second- andthird-generation applications. Sofar, they haven’t been necessaryfor most enterprises.

Design-time and change-time gov-ernance depend on a combinationof policy, process, review, andrepository. Again, most of thenoise in this area comes fromrepository vendors who seem tothink that a technology solution(the repository) will be the answer

to achieving service reuse. Well,they are partly right; the repositoryis a useful component to servicereuse, but only if it’s implementedaround a business model, struc-tured with a service taxonomy,augmented with appropriatedevelopment and review proc-esses, and supported by organi-zational and reward structures.While governance is still importantfor a complete SOA program, Ithink it will become less of a dis-traction in 2007, as initiatives focuson more immediate successes.

Of course, achieving service reuseremains one of the most difficultand important aspects of deliver-ing value and agility with SOA.Overall, the industry has beenlearning, but it’s easier said thandone. (See the section on “Reuse”in [1].) This will continue to be animportant aspect of SOA in 2007and beyond.

Yet another view of SOA comesfrom the BPM arena. In 2006, theindustry experienced a tremen-dous amount of consolidationbetween BPM and SOA products.This will continue in 2007, as willthe learning curve about what itall means. There is overall agree-ment that services provide animportant enabling layer for busi-ness processes. Yet the implemen-tation of this layer in the tools isweak at best, demonstrating a

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]. ISSN: 1530-3462. ©2007 by Cutter Consortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, image scanning, and downloading electronic copies, is against the law. For information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail [email protected].





©2007 CUTTER CONSORTIUM VOL. 10, NO. 1

EXECUTIVE REPORT 33

lack of understanding (or at leastimplementation) of the architec-tural characteristics or complexi-ties of the layers. Fortunately,another approach to the problemis being driven from the businessarchitecture side. As SOA is mixedin with BPM, the added opportu-nity and complexity is drivingmany to look for a more system-atic enterprise-wide approach tothe overall solution. This repre-sents a great opportunity for EAin 2007, which will be takenadvantage of by some of themore advanced enterprises.

The consolidation craze has hadmixed results. Many think that thenew SOA/BPM product suites havegotten too complex and too big.The complexity is a reflection ofthe fact that these platforms havebeen built based on acquisition,rather than on any architecturalor product-line foundation. It gen-erally takes 18-36 months to pro-vide a seamless and coherentintegration of products, so we’vegot another year or two to wait.As for size, the capabilities of thenew product suites seem to haveoutgrown the coherency of theirarchitecture, and the features havedefinitely outgrown the needs andsophistication of their customers.Time will tell if they are just tooadvanced for the current marketor somehow further off the mark.Nonetheless, it will be up to EAgroups to make some sense ofthese SOA platforms, fit them intotheir overall environments, andrecommend how and whataspects of them should be used.

Despite the advances and hype(or perhaps because of them), theconfusion and misunderstandingabout SOA remain major issues in2007. Most companies still don’tknow what SOA is, how it deliversvalue, how to use it, how todesign it, how to implement it,or how to manage it. Already,market watchers report that SOAtechnology has slipped into thedreaded “trough of disillusion-ment” as evidenced by SOA ven-dor sales figures. Guess what?SOA isn’t something companiescan just buy from a vendor. Yetagain, technology is not the solu-tion for complex enterprise prob-lems. Are we really surprised?

For the past year or two, architectshave been saying just that. SOA isabout architecture, not technol-ogy. It’s not something you buy;it’s complicated and has manydifferent aspects. And to getenterprise value, consistency, andagility from SOA requires enter-prise architecture. So SOA willcontinue to play a large role in EAin 2007. Here, EA groups have theopportunity to demonstrate theirvalue by making some sense of itall, showing how SOA fits into theoverall enterprise, showing how itis driven from business require-ments, showing how to achieveservice reuse, showing how totake advantage of SOA platforms,and making development orga-nizations successful using andbuilding services.

The Cutter EA advisory serviceprovided a wide variety of

information on SOA in 2006.Indeed, half of the EA ExecutiveReports in 2006 were on oneaspect of SOA or another. Whilewe will continue to keep up todate on SOA with EA ExecutiveUpdates and E-Mail Advisors,for 2007 we will be addressing amuch wider variety of EA topics.

Struggling to See Value

As with SOA, many EA programsare struggling to demonstratevalue. Organizations are beginningto lose patience with EA pro-grams. Developers see no use inthe specifications and models thatEA produces. Business ownerssee no value from EA and ignoreor pay lip service to it. In someorganizations, 80% of projectsreceive exceptions from compli-ance to architecture. So what’sgoing wrong?

Too many enterprises or agencieshave focused on the architectureprogram itself. While this is cer-tainly an important aspect of EA,problems arise when the programbecomes the end rather than themeans. As architects, we shouldnever forget that our job is tocreate value with architecture.Creating architecture (and pro-grams), although required, pro-vides no value. Value only comesfrom applying architecture toinfluence projects.

In 2007, we will see many EAorganizations refocus their effortson delivering value by helpingprojects and development teamsuse architecture to design and

implement projects. For example,with SOA, the focus will be onmaking SOA practical. Somespecific actions might be:

Focusing on services that havethe most impact to importantprojects and the enterprise

Providing enterprise semanticand responsibility models thatguide interface design

Providing standards, templates,guidelines, and examples forservice interfaces

Working directly with businessand system analysts

Establishing minimal gover-nance policies and develop-ment practices (with anemphasis on minimal)

But having architecture work withproject teams won’t be limitedto SOA. The same concepts willapply to providing value regardlessof the project type. In recent years,a contributing factor of developersignoring architecture has been theadoption of agile and similar proj-ect development techniques. Asthe techniques continue to gainmomentum in 2007, it’s incum-bent upon EA to accommodatethem. While it’s true that somedevelopers have (mis)used thesetechniques as an excuse to avoidarchitecture and design, it’s morefundamental than that. Just asoften, architecture has providedadditional burden and processto projects, without providingcorresponding value. Fortunately,when you take a step back from

the mismatch, you see that there’snothing necessarily incompatiblebetween agile and EA. However, itdoes require a different approachby both sides [3].

In the first contributing article,Scott Ambler provides excellentadvice on how to get agile andEA teams to work together. Hedescribes how agile is different interms of requirements, collabora-tion, and testing and what thatmeans for agile/EA interaction.Next, he describes five specificareas in which EA can provideassistance to agile projects. Justas important, he describes threeareas in which agile teams don’twant EA processes imposedon them.

Another area that will be used toaddress the gap in EA value willbe metrics and maturity. We willbegin to see metrics become anintegral part of EA and SOA pro-grams. Again, we need to makesure we mean the same thingwhen we talk about metrics. Whatexactly are we measuring? In EAprograms, we’ll see developmentsin three areas:

1. Architecture — metrics tomeasure the quality, complete-ness, correctness, and flexibilityof the architecture itself

2. Program — metrics to measurethe efficiency, effectiveness,and influence of the architec-ture organization and program

3. Effects — metrics to meas-ure the value and effect of

architecture on projects, enter-prise initiatives, and outcomes

In all of these areas, metrics willbe used to measure maturity, ormore specifically, to support amaturity model. In other words,a range of scores across a varietyof measures will indicate howmature the architecture or pro-gram is. Most maturity modelsgrade on a zero-to-five scale.Enterprises will use this maturityrating to measure year-to-yearimprovement toward specificshort-term and long-term goals;in other words, to establish quan-tifiable targets for determiningprogress.

More sophisticated models willevaluate the strategy and goals ofan enterprise and its complexity tocome up with a target-level matu-rity. Not all enterprises need to beat level five. More importantly,most enterprises can’t afford toreach that level of maturity. So thesecond variable in determiningthe target will be to factor in anexpected ROI for reaching a par-ticular maturity level. The enter-prise will then try to optimize theEA program to reach the maxi-mum value point beyond thematurity required to handle theenterprise’s complexity andachieve its goals.

In the next article, Tushar Hazradescribes the current state of EAmetrics and where he sees itgoing over the coming year. Hedescribes how metrics can beused to quantify the business




value of architecture and to moti-vate its practitioners and users.Hazra goes into depth on whatshould be measured in the criticalareas of governance, manage-ment, infrastructure, operations,and EA maturity.

Bigger and Better

Of course, not all EA programs arestruggling. Some, in fact, are doingquite well and have been success-fully delivering value for years.Many of these organizations havemanaged to get the IT infrastruc-ture under control and haverealized significant cost savingsthrough standardization. In doingso, they have developed proc-esses and procedures for creating,following, and verifying thosestandards and have introduceda culture of “enterprise require-ments” into parts of the devel-opment process. Perhaps thearchitecture organization regularlyprovides input into the IT budget-ing process. Quite often, the archi-tecture group has participated insome significant success, such asa single enterprise-wide customeror enterprise-wide process. All ofthis provides a basis for movingEA to the next level.

Yet with all this success, one areais still lagging: the ever-elusivebusiness-IT alignment we’ve sooften talked about as a benefitof EA. While many EA programsconceptually support the seg-mentation of EA into business,information, application, andtechnology architectures, mostare very weak in business

architecture. One of the mostimportant trends in EA in 2007will be the emergence of BA as apractice in its own right, as well asits role in establishing alignmentand delivering value.

However, business architectureis a big and not yet well-knownfield. What exactly is businessarchitecture? In the next articleof this report, William Ulrichdescribes it as “the ongoing prac-tice of visualizing and aligningorganizational governance struc-tures, business data, businessprocesses, and business rulesacross the extended value chain.”He goes on to explain how busi-ness architecture helps to visualizeand create tangible ways to alignthe business with IT, specificallyaround the areas of organizationalinfrastructure and governance,process models and businessrules, and the virtual enterprise(alignment with external entities).

As organizations begin to enhancetheir EA practices in 2007, we canexpect business architecture tofocus on aligning business strategywith IT implementation by:

Identifying goals and strategy

Identifying organizationalstructures and governanceand their impact on strategy

Applying the strategy acrossthe entire enterprise andvalue chain

Aligning with external entities— the virtual enterprise

Identifying quantifiable out-comes to measure the strategy

Identifying processes, rules,and information necessary tosupport the outcomes

Managing and synchronizingthe process model, businessrules model, and informationmodels

Applying a BA context toindividual projects

Acting as a bridge betweenenterprise context and individ-ual project requirements

Working with business analystsand the project team in thedesign of business models toensure that enterprise require-ments and concerns arecorrectly incorporated

In other words, the business archi-tecture translates the businessstrategy into actionable processes,what Cutter Fellow Ken Orr calls“the missing link” in the architec-tural puzzle. When we look at thedetails, we see that the overallbusiness architecture can bedivided into two main parts basedon the scope of the architecturalconcerns. Enterprise businessarchitecture (EBA) applies at theenterprise level and deals with thegoals, strategies, outcomes, andthe common information, rules,and processes. Application busi-ness architecture (ABA) applies atthe application or project leveland deals with individual applica-tions, processes, and systems.


EXECUTIVE REPORT 55

Ideally, there will be an area ofoverlap between them where theenterprise business architecturedrives common processes, rules,and information and affects theapplication business architectureand the applications themselves.Unfortunately, in many enter-prises, there is a distinct gapbetween enterprise concerns andIT systems rather than an overlap.It is this gap — the missing link — that business architectureaddresses. To truly get business-ITalignment, a focus for EA in 2007will be to understand the differ-ence between enterprise businessarchitecture and enterprise ITarchitecture (EITA) and how touse EBA to drive requirementsfor EITA [2].

Business architecture will beone of the major focus areas forCutter’s EA practice in 2007. Lookfor us to explore topics such as:

What is BA?

The relationship between BAand SOA

The link between BA andinformation architecture

BA-driven modernizationand transformation

Creating BA programs

Training business architects

New Demands

In addition to a new focus onbusiness architecture, EA willneed to address changes in thebusiness environment and tech-nology. In particular, significant

opportunities exist for consolida-tion of regulatory complianceefforts. Often, in an effort to meetdeadlines, Sarbanes-Oxley (SOX)and other regulations have beenimplemented haphazardly, inde-pendently, and differently forevery line of business. As newregulations pile up, a betterapproach is required. In 2007,we will see more enterprise-wideimplementations of regulatorycompliance, shepherded by EAand driven by BA.

Another major change in the busi-ness environment is the enterpriseresource planning (ERP) land-scape. Three major players arebattling for the future of ERP. SAP,the 800-pound gorilla in the enter-prise market, has spent threeyears and untold billions of dollarsto revamp its product line. In thefirst quarter of 2007, SAP will offi-cially announce its completelyreengineered, SOA-based suiteof applications targeted at mid-market companies, due in early2008. There are obvious SOArepercussions for traditional SAPcustomers. Any enterprise that ispursuing an SOA strategy and thathas SAP must take this new prod-uct into account in its business,information, and SOA architec-tures, its plans, and its roadmap.

Medium-sized companies look-ing to acquire ERP will have todecide if they should wait orchoose one of the other alterna-tives from Oracle or Microsoft.Oracle will take an aggressivetactic with its Accelerate product,targeting small and medium-sized

businesses in five key verticals:financial services, utilities, com-munications, retail, and tax.

And then of course there’s theother 800-pound gorilla, Microsoft.It is set to release CRM 4.0, code-named Titan, as a complete soft-ware-as-a-service (SaaS) offeringthis year with improved integra-tion with Great Plains ERP andMicrosoft Office. This integratedproduct set will be important for(medium-sized) enterprises thatrely heavily on Microsoft applica-tions. But regardless of Microsoftproducts, all enterprises need tounderstand the new SaaS busi-ness model and factor it into theirenterprise architectures.

Finally, we cannot overlook newand emerging technologies. EAmust not only reduce costs andimprove alignment, but it mustalso drive innovation and under-stand how new or disruptive tech-nologies create opportunities.Radio frequency identification(RFID) will continue to play animportant role in some marketsegments, with new applicationsfor the technology occurring allthe time. For example, pharma-ceutical manufacturers are investi-gating RFID tags in individual pills(of sufficient value, of course) tocombat counterfeiting. High-endclothing manufacturers sew RFIDtags directly into their creations.Certainly, the potential is therewell beyond the supply chain andneeds to be followed by the EAorganization. But the new kids onthe block this year are collabora-tion and mobility.




Collaboration is a way of enablingemployees to work together ona process or project regardlessof their physical locations, timezones, and so forth. It can beachieved using a combinationof Web 2.0 and other capabilities(such as instant messaging, blogs,and wikis). There are severalimportant aspects to the problem,but the architectural thoughtprocess ought to seem familiar.Understand the enterprise envi-ronment, constraints, culture,and so on. Understand the busi-ness and the business processes.Determine what new capabilitiesand technologies fit the environ-ment, constraints, and culture.Use the new capabilities toimprove business processes,communication, and efficiency.

But it’s not that simple. A funda-mental element that enables col-laboration at a business level andthat must be accounted for inarchitecture is “capabilities man-agement.”1 Collaboration archi-tectures that neglect this aspectignore how the user fits within thesystem to provide the fullest value.Instead, the user becomes the ITdepartment, debugging why appli-cations do not work as expected,or, worse, getting “surprises”when things behave differentlywhen chained together in morecomplex tasks. The crux of theproblem is that capabilities areoften mismatched; instead, partof one capability (for example,spreadsheet handling) and part of

another capability (for example,document editing and formatting)and yet another (for example,report prepublication preparation)need to be coordinated as “man-aged capabilities.”

Let’s take a simple example: twocoworkers intend to collaborate,and one is working the numbersof the spreadsheet while the otheris writing the report. In a collabo-rative environment, the reportwriter should have the spread-sheet updating in near real timeas the changes are made, so thathis or her reporting capabilitydoes not have to stop and wait forthe spreadsheet to be complete(and all the potential changes andedits required).

Hence, the collaboration architec-ture must understand the conceptof “ownership.” If the spreadsheetis “owned” by a worker and thedocument editing by another, thedocument editor must not be ableto change the spreadsheet con-tents yet must be able to usethe spreadsheet as an objectfor formatting in place within thedocument. In other words, theownership takes place withinthe context of a collaborativeprocess. So another requirementfor collaboration architecture is anunderstanding of workflow andbusiness process management.

The richest areas to enhance col-laboration rest with mobile tech-nologies. The concept of beingconnected on the go and still able

to participate within a workflowwith coworkers provides businessopportunities that have yet to betapped. Instant messaging and e-mail have been a growing trend,but mobile devices and their inte-gration into specific activities havelagged behind (with the exceptionof sales force automation, whichis one success area of mobility-enhanced collaboration). Mobiletechnology remains the singlemost underused technology that isreadily accessible to the corporateenvironment.

In the final article of this report,Jim Watson discusses the goalsand dimensions of mobile com-puting. He proposes that RSS(Really Simple Syndication) willbe the killer app for mobile com-puting. In the future he paints,mobile devices, within the contextof one or more processes, will becombined with specific locationinformation and RSS informationflow to provide real-time, context-,and location-sensitive informationanywhere and anytime.

Clearly, the opportunities pre-sented by collaboration andmobility need to be consideredand understood. They need to befactored into the business archi-tecture, into business processes,into information architecture, intoapplication architecture, into userinterface design, into technologyplatforms, into security architec-ture; in other words, into allaspects of EA. We think thesewill be major areas of innovation


EXECUTIVE REPORT 77

1The thoughts on collaboration and mobility were greatly influenced by Cutter Senior Consultant Arun K. Majumdar.

in EA in 2007, and Cutter plans to

make them areas of focus in our

2007 EA publications.

The Year Ahead

So far I’ve given you a preview of

what we think will be important in

EA this year. Our focus for the rest

of the year will be to elaborate on

the key areas we’ve discussed.

Expect to see reports and updates

on topics such as:

Business architecture

Business modeling

Best practices in information

architecture

Linking EA segment

architectures

EA metrics and maturity

Governance and compliance

Agile EA

Collaboration

Mobility

Security

And let us know if there’s a topic

you’d like us to cover. We’re

always interested in what you

have to say and what topics are

of interest to you. Send com-

ments, suggestions, and requests

to [email protected]. Thanks

for joining us, and we look for-

ward to another year of sharing

information with you. Now, onto

the rest of the articles.

References

1. Rosen, Michael. “Designing

Service-Oriented Applications:

Part I — Architecture and

Methodology.” Cutter Consortium

Enterprise Architecture Executive

Report, Vol. 9, No. 10, 2006.

2. van Tyn, Jeroen, and Michael

Rosen. “Enterprise Architecture:

It’s Not Just for IT Anymore.”

Cutter Consortium Enterprise

Architecture Executive Report,

Vol. 9, No. 6, 2006.

3. Watson, Jim, Michael Rosen,

and Kurt Guenther. “Are Agile

Methods and Enterprise Archi0tec-

ture Compatible? Yes, with Effort.”

Cutter Consortium Agile Project

Management Executive Report,

Vol. 8, No. 11, 2005.



AGILE STRATEGIES FOR ENTERPRISE ARCHITECTSby Scott W. Ambler, Senior Consultant, Cutter Consortium

Contrary to popular belief, agile

software developers, at least the

smarter ones, invest time in identi-

fying a potential architecture for

their system. This isn’t well under-

stood by traditionalists, in part

because modeling is one of those

topics that agilists don’t like to

talk about, and in part because

our architectural strategies differ

from traditional strategies. Agilists

will do some architectural model-

ing up front, just enough to iden-

tify a viable strategy, during the

initial iteration of a project. The

details, and arguably the architec-

ture itself, emerge over time as

the project progresses. Because

our project-level architecture

efforts are different, the way that

enterprise architects interact with

agile teams must also vary.

In this article, I describe why

the agile architectural approach

typically differs within agile

teams, what agile teams need

from enterprise architects, and,

more importantly, what they don’t

need. My hope is that this advice

will provide insights into how you

can tailor your EA processes for

effectively supporting agile soft-

ware development teams.

Agile Is Different

Agile software development

teams choose to work to a

different set of philosophies than

traditional teams, and as a result,

enterprise architects must interact

with them in new ways. We rec-

ognize the following ideas:

Requirements will change

throughout the lifecycle. We

embrace change and have

adopted techniques that reflect

this. Although we may model

a bit up front [1, 3], we know

that any investment in detailed

documentation risks being

wasted, and therefore we

minimize this sort of work.

We have adopted techniques

such as test-first design [7]

and refactoring [5, 9], which


reduce our need for detailedup-front modeling.

Collaboration is critical toour success. We find waysto reduce barriers to commu-nication and collaborationwherever we can, preferringface-to-face interaction overartifact handoffs [8]. The higherlevels of communication andcollaboration within agileteams result in less relianceon detailed documentationand models; everyone onthe team understands thearchitecture because they wereactively involved in its develop-ment throughout the project.Furthermore, if someone is totruly have an effect on an agileteam, including enterprisearchitects, then that personneeds to be part of the collabo-rative effort.

We focus mercilessly onquality. Agilists are “testinfected,” taking a test-firstapproach whenever possibleand refactoring our code tokeep it of the highest qualitypossible at all times. This high-quality code will be looselycoupled and highly cohesive,enabling us to easily evolve it asthe requirements evolve.

What Agile Teams Need

Agile teams can benefit from anEA program just like traditionalteams, but we need enterprisearchitects to work with us ina manner that reflects agileapproaches to software devel-opment [2, 11]. Here is what

agilists expect of effectiveenterprise architects:

Hands-on involvement. Agileteams expect enterprise archi-tects to be active members ofthe project team, to not onlyhelp us architect the systembut to also develop high-qualityworking software that meetsthe changing needs of ourstakeholders. Enterprise archi-tects must be willing to rollup their sleeves and get theirhands dirty building software,and to do so regularly.

Straightforward guidance.Agile teams believe in followingcommon standards and guide-lines, particularly coding stan-dards, because consistency isa contributor to quality. Enter-prise architects can and shouldbe a good source of such guid-ance and must be prepared tomaintain and collaborativelysupport it [6]. This guidancedoesn’t need to be perfect, butit should be concise, under-standable, and easily available.

Overview diagrams. Weneed “maps” that overviewthe vision that we should beworking to for the technical andbusiness aspects of the organi-zation. We don’t need muchdetail — we’ll work closely withthe enterprise architects whoknow that information — butwe do need a few key diagramsto occasionally reference. I per-sonally find that a high-levelenterprise domain model, aUML deployment diagram

providing a high-level overviewof the technical infrastructure, afree-form “architectural stack”diagram, and a high-level enter-prise business process modelare very useful for businessapplications.

Reference architectures. A ref-erence architecture is a work-ing example of a critical aspectof your enterprise architecture,such as an end-to-end techni-cal prototype of a J2EE applica-tion, an example of how towork with your organization’smessage bus, or an example ofhow to work with your busi-ness rules engine. Enterprisearchitects should provide theseconcrete examples to guidedevelopment teams in correctlybuilding applications withinyour organization.

Mentoring. When enterprisearchitects are working onagile development teams,they will actively share theirskills and experiences withteam members. This includesmentoring in architecturalconcepts, modeling, design,and in other systems withinyour organization.

What Agile Teams Don’t Need

It’s also important for enterprisearchitects to understand whatagile teams don’t need fromthem. In particular, this includes:

Detailed documentation.We need high-level overviewsand direct access to the enter-prise architects, not access to


EXECUTIVE REPORT 99

detailed documentation that islikely out of date; even if it isn’t,we’re not likely to fully under-stand it if we read it anyway.Documentation is one of thepoorest ways to communicateinformation [8], and relyingon it to communicate criticalarchitectural information isfoolish at best.

Authoritative governance.Agile teams work best with acollaborative approach to gov-ernance, not a command-and-control one. If your goal is toget development teams undercontrol, to get them to conformto your will, or to get them tosimply do what they’re told,then chances are pretty goodthat you’re going to be ignoredby the teams (be they agileor not). I highly suggest CutterFellow Jim Highsmith’sAdaptive Software Development[10] for a very coherent discus-sion about the challengeswith traditional command-and-control approaches.

Reviews. In the highly collab-orative environments typicalof agile teams, we find thatreviews often prove to be “toolittle, too late”; if anyone couldpossibly add value in a review,then they should have beenactively involved with thedevelopment of the artifactin the first place. In fact, Ihave argued that reviews are“process smells”; if holding a

review makes sense, then it’san indication that you’ve verylikely made a serious mistakeearlier in the developmentprocess that, once addressed,will alleviate the need for thereview [4].

Enterprise architects have it reallytough these days because theyhave to support traditional, agile,and even hybrid developmentteams. The implication is thatenterprise architects need to beflexible and to be prepared toadapt to the situation at hand.Development teams should not berequired to adapt, at least not sig-nificantly, to meet the needs ofenterprise architects. In my expe-rience, the surest way to failure isto have the enterprise architecturetail wag the development dog.

References

1. Ambler, Scott W. “AgileArchitectural Modeling.”Ambysoft, updated 29 April 2006(www.agilemodeling.com/essays/agileArchitecture.htm).

2. Ambler, Scott W. “AgileEnterprise Architecture.”Ambysoft, updated 3 December2006 (www.agiledata.org/essays/enterpriseArchitecture.html).

3. Ambler, Scott W. “AgileModel Driven Development(AMDD).” Ambysoft, updated 28January 2007 (www.agilemodeling.com/essays/amdd.htm).

4. Ambler, Scott W. “ModelReviews: Best Practice orProcess Smell?” Ambysoft, updated3 April 2006 (www.agilemodeling.com/essays/modelReviews.htm).

5. Ambler, Scott W., and Pramod J.Sadalage. Refactoring Databases:Evolutionary Database Design.Addison-Wesley Professional, 2006.

6. Ambler, Scott W., JohnNalbone, and Michael J. Vizdos.The Enterprise Unified Process:Extending the Rational UnifiedProcess. Prentice Hall PTR, 2005.

7. Astels, David. Test-DrivenDevelopment: A Practical Guide.Prentice Hall, 2003.

8. Cockburn, Alistair. AgileSoftware Development: TheCooperative Game. 2nd Edition.Addison-Wesley Professional, 2006.

9. Fowler, Martin et al.Refactoring: Improving theDesign of Existing Code. Addison-Wesley Professional, 1999.

10. Highsmith III, James A.Adaptive Software Development:A Collaborative Approach toManaging Complex Systems.Dorset House Publishing, 1999.

11. McGovern, James et al. ThePractical Guide to EnterpriseArchitecture. Prentice Hall, 2003.





EXECUTIVE REPORT 1111

TRENDS IN ENTERPRISE ARCHITECTURE METRICS: YEAR 2007 AND BEYONDby Tushar K. Hazra, Senior Consultant, Cutter Consortium

During the past few years, it hasbecome evident that enterprisearchitecture has been gainingpopularity in the IT community.One of the primary reasonsbehind this popularity is the factthat EA is as much a businessaffair as it is a technical one. Formany practitioners, EA offers ablueprint for their IT strategies thatcan subsequently help them alignthe enterprise-wide IT initiativeswith their business organizationsand respective functions. Ideally,EA engages both the business andIT teams from the beginning of itslifecycle. As a result, the EA met-rics present a consistent vehicle tomeasure most of the critical ele-ments or parameters of businessvalue and span from a business toa technical perspective.

Today, many visionary leadersin the IT community have beenactively promoting the concepts ofinnovation, collaboration, and exe-cution for business solution deliv-ery. As these words become morepopular and practitioners acrossthe industry worldwide continueto use these buzzwords to theiradvantage, a vital need arises formeasuring the impacts of innova-tion, collaboration, and executionon the delivery of business valuefor an enterprise. Furthermore,it seems essential to explore twospecific focus areas: (1) to recog-nize the true meaning of quantifi-able business value and (2) toencourage or motivate practitioners

in utilizing the practicalities of inno-vation, collaboration, and executionappropriately, that is, to deliverdesired and finite business valueperiodically, often in a repeatablemanner. In practice, recognizingthe business value relates to defin-ing and identifying the IT metrics,whereas encouraging or motivatingpractitioners to leverage innovation,collaboration, and execution intheir IT initiatives translates to mea-suring, monitoring, or controllingthe progress of business solutiondelivery. In general, a set of IT met-rics encompasses many businessvalues, such as cost reduction andsavings, business continuity, oper-ational excellence, performanceand productivity improvement,enhanced responsiveness, and thereturn on technology as well ashuman capital investments. Whilemost of these key elements can beinterrelated, there is no single set ofmetrics that can allow practitionersto track, measure, and managetheir progress in achieving the busi-ness results.

In my opinion, EA metrics canpresent some of the basic infor-mation necessary to measure,manage, and monitor IT metrics.In some cases, they can alsohelp us derive the key parametersof the IT metrics. For large andmedium-sized companies, EAoffers practitioners: (1) the abilityto create a map of existing andprospective IT assets includingbusiness processes and (2) a set

of governance principles that canbe used to align IT with the busi-ness strategy and express busi-ness values through IT. I haveobserved, both in government andcommercial arenas, that EA met-rics are already used innately todefine and manage the key ITmetrics. For most companies andgovernment agencies, EA metricsalready offer a foundation to getstarted with delivering “faster,better, cheaper” IT solutions.

I submit that EA metrics are forreal. My reasons are as follows:

They can provide a baselinefor many IT metrics related tobusiness-IT alignment.

They can help set the rightexpectations for both businessand IT from the beginning.

They can deliver tangible andquantifiable enterprise-levelbusiness results for manycompanies (all sizes — small,medium, and large).

However, the trends in EA metricsduring the year 2007 and beyondmust be viewed from the perspec-tive of evolving changes in the EAspace of the industry today. In thisarticle, I present some of the cur-rent challenges experienced bypractitioners in establishing andusing EA metrics today and offeran account of how these chal-lenges may be resolved in thenear future.

It’s Not Going to Be Easy

Modern advances in the field ofintegration technology usuallyrange from using a set of flexiblemiddleware to more recent con-cepts of service-oriented architec-ture. Whatever the case may be,practitioners are finding newways to design more agile, moreresponsive, and more collabora-tive enterprise architectures thatcan provide the type and extentof value business organizationshave been anticipating from IT.No doubt, with the help of thesenew architectures, IT can enableits business counterparts to deploynew business capabilities in atimeline and environment thatbusiness can understand.However, there is no easy orsimple way of managing or main-taining the EA metrics and theirrelevant parameters to some ofthe complexities these technologi-cal advances entail. I would like topoint out four major focus areasthat are either already being con-sidered or must be reviewed fromthe EA metrics perspective:

1. Fostering business-driven SOAto augment EA initiatives

2. Promoting event-driven EArealization

3. Employing a Model DrivenArchitecture (MDA) approachto develop EA

4. Establishing collaborative EA toleverage a global workforce

First, business-driven SOA essen-tially requires services to repre-sent specific business functions

— not technology components.Although the concept of definingservices as EA components isnothing new, creating a mindsetfor the IT teams to enable busi-ness users to work with the ser-vices in their own language andculture is. This obviously createsa new level of understandingbetween business and IT teams — and hence the complexitiesinvolved with the associatedEA metrics. On the other hand,business-driven SOA allows ITto build and deploy enterprise-level applications quickly becausecomplex and well-orchestratedinterfaces can allow users toconnect to the services withouthaving to know the technicalimplementation details of the ser-vices. As the technologies, frame-works, and standards behind SOAmature, the associated EA metricswill be simplified to improve effi-ciency of service delivery.

The concept of an event-drivenapproach to delivering enterprisearchitecture involves using varioussystems or applications to monitorspecific business processes forevents. Once an event is detected,the system or application maytrigger a set of services or func-tions to start. For example, short-age of a particular product maytrigger the inventory to replenishfor a retail store. This may be avery simple form of event-drivensystems. For complex enterprises,realizing event-driven EA is noteasy. However, together, servicesand events revolutionize theway EA is designed. They can

definitely offer a new kind of flexi-bility and value that senior execu-tives both in business and IT havebeen seeking. Today, event- andservice-driven approaches add anew dimension of complexity toestablishing and managing the EAmetrics, and yet they can enhancethe agility and responsiveness ofIT to handle business needs.

The third focus area — use ofan MDA approach to deliveringsolutions — has been around for awhile. Given that conforming to aspecific visual modeling languagemay not be the focus for any busi-ness organization, creating busi-ness services that business userscan understand is a significantattribute of MDA. The EA metricsfor business modeling, transforma-tion, and deployment of businessservices is not necessarily complexusing an MDA approach. In fact,the trends in the industry exhibit apositive sign of adoption for MDAamongst practitioners familiar withUML or similar notations.

Finally, the globalization of theworkforce impacts how theenterprise-level systems are devel-oped, integrated, and used todayor will be used in the future. Withglobal sourcing also comes a newset of measures to adjust the cul-tural values for defining service-level agreements (SLA) and theircompliance. For practitioners indifferent organizations, it may benecessary for EA metrics to factorin the use of certain tools, tech-nologies, standards, frameworks,or reference models. For some




companies, there may be a needto establish a specific set of col-laboration tools and techniques toconnect, coordinate, communi-cate, and commit to EA principlesand strategies.

Measure, Monitor, and Manage

From my experience, proactivemeasures taken by practitionersthroughout the EA lifecycle usingEA metrics as an aid can boost therate of progress for an enterprisein its business application integra-tion initiatives tremendously. Frommost of my engagements in thegovernment as well as commer-cial arena, I strongly feel thattoday, and in the near future, EAmetrics must be measured, moni-tored, and managed essentially infive key areas:

1. EA governance

2. EA management

3. Infrastructure support

4. Operations support

5. EA maturity

EA Governance

EA governance can offer a mecha-nism to manage the compliance ofvarious EA principles, frameworks,reference models, and standardsin a business-like manner. The EAmetrics associated with gover-nance must be directed towardinfluencing enterprise applicationprojects to follow the establishedprinciples in delivering efficientbusiness solutions. EA governancemetrics should address:

New or future technologyblueprints and enterprise-widereusable standards

— How many blueprints andreusable standards arenecessary?

— What impact do these arti-facts and work productshave on the enterprise —financially and operationally?

— What savings do they holdfor the organization andsubsequently for the entireenterprise?

EA compliance policies andprocedures

— How many projects arecurrently under review?

— What is the process forreviewing the policies andprocedures?

— What are the cost benefitsof these reviews?

Plans for compliance enforce-ment — waivers, correctivemeasures, and extensions(and the processes to revieweach case for individualprojects/applications)

— How many individual proj-ects are considered forwaivers, corrective meas-ures, or extensions?

— What financial impact dothey have on the enterprise?

— What cost savings do theyprovide to the organizationor the enterprise?

A review of SLAs and contrac-tual agreements with the ven-dors and IT partners

— What impact do theseSLAs have on the bottomline of the individual orga-nization and then to theentire enterprise?

— Who is responsible formanaging the contracts andassociated relationships?

— How often are these SLAsbeing reviewed?

— What improvements or mod-ifications are being made?

Recommendation of capitalinvestments for IT to the seniorleadership of the company

— What are the existing values,and what will new IT assetsprovide to the enterprise?

— What are the practical costbenefits of the new develop-ments? Or ROI?

— What performance improve-ments are anticipated anddemonstrated?

— What are the long-termbenefits expected from theinvestments?

— How may the capital invest-ments provide or promise toprovide long-term benefits?

EA Management

EA management can facilitatebusiness-IT collaboration andalignment. Its primary objectiveis to offer strategic guidance and



technical direction to ongoing ITinitiatives and prospective teams,as well as to help the review ofcurrent projects or programs.Accordingly, the metrics related toEA management involve parame-ters for measuring the collabora-tion of business and IT teams,their efficiency in improving theoverall performance, and supportfor the program managementoffice (PMO). EA managementshould address:

Key elements of current enter-prise technology blueprints

— Is an inventory of IT assetsavailable?

— Do these current assets haveany associated projects? Ifso, do these projects inter-operate? At what level?

Major projects, applications, orprograms (of projects or appli-cations) that impact strategicbusiness goals

— What IT guidelines, frame-works, standards, and refer-ence models do they follow?

— What impacts do theseapplications have on day-to-day or tactical businessoperations?

Essential business and IT col-laboration for strategic andproject-level alignments

— What are the collaborationrequirements?

— What are the strategic SLAsin place between businessand IT or the business andthe IT vendors?

Core IT strategy, technicaldirection, and overall corporateIT guidance

— What are the principal ITstrategy elements? How welldo they match up with thecorporate business goalsand objectives?

— What are the lessonslearned from implementingprevious IT strategies?

Infrastructure and OperationsSupport

While EA governance and man-agement are usually viewed asstrategic initiatives, infrastructureand operations support are meas-ured and managed on a dailybasis. The infrastructure and oper-ations support areas concentrateon EA qualities related to businessoperations and the enterpriseinfrastructure, including disasterrecovery, business continuity,application lifecycle management,service delivery oversight, andnetwork reliability. Informationin these areas should include:

Network requirements and thecurrent infrastructure featuresavailable

Server consolidations, redun-dancy, and clustering goals

Enterprise-level securityand user access controlrequirements

Information assurance and dataintegrity needs for individualorganizations as well as theentire company

Enterprise-wide system flexibil-ity, scalability, availability, andperformance requirements

Disaster recovery and businesscontinuity plan — essentialelements

Key application lifecycle man-agement criteria — database,archive, and other data accessneeds

Lessons learned and best prac-tices captured from currentoperations

Operational excellence andperformance goals

Oversight on daily businesssolution delivery and systemdevelopment (or integration)

EA Maturity

Last but not least, the importantbasis for measuring, monitoring,and managing EA metrics is EAmaturity. In this area, the enter-prise needs to look at:

EA activity management

— How well are the activitiesmanaged?

— What benefits (cost andperformance) do EAactivities offer?

EA governance processes

— How well are the processesfollowed in individualprojects?

— What cost savings dothese processes helpthe enterprise deliver?




Use of standards and bestpractices

— At what level are industrytrends being incorporated?

— Technology, techniques,and tools

Assessment of maturity

— Individual elements of therelevant technical and busi-ness architecture (compo-nents and services)

— Artifacts and their reuseacross the enterprise

Overall value proposition forthe enterprise in achievingfinancial and performance-related goals

— Architecture qualities,features, and constraints

— Future anticipatedimprovements

The well-coordinated maturity ofEA can offer a pragmatic means toestablish and improve EA metrics.It can and will help practitionersto manage the risks associated

with the compliance of govern-ment mandates, industry regula-tions, and corporate policies andprocedures. EA maturity whenmaintained properly will also bevery effective in auditing, verifying,and validating different businessand IT alliance and performancelevels. In the long run, EA maturitywill substantiate EA metrics formeasuring the results producedby innovation, collaboration, andexecution together.



THE IMPORTANCE OF BUSINESS ARCHITECTUREby William Ulrich, Senior Consultant, Cutter Consortium

Business architecture is theongoing practice of visualizingand aligning organizational gover-nance structures, business data,business processes, and businessrules across the extended valuechain. While BA is an evolvingcollection of disciplines, organi-zations that formalize businessarchitecture as a vehicle to under-stand and align core and periph-eral business disciplines canbenefit substantially.

Business architecture allowsan organization to envision andarticulate the essence of its orga-nization while creating tangibleways to align the business archi-tecture with the IT architecture.BA enables a business to visualize,analyze, redefine, and reengineerthe way it functions and commu-nicates internally, with businesspartners and with IT. Specifically,any enterprise that is retooling,

reorganizing, realigning, or other-wise streamlining its businessand/or IT infrastructure can bene-fit from a formal business archi-tecture. Areas of focus include:

Organizational alignment andgovernance

Process model and businessrule model management andsynchronization

Alignment with external entities— the virtual enterprise

Business-IT architecturealignment

Synchronizing multidimen-sional disciplines

Let’s look at each of these areasin depth.

Organizational Alignmentand Governance

There are two types of enterprisegovernance models. There is the

formal organizational chart, typi-cally made up of boxes arrangedin a hierarchical structure, andthere is the actual governancestructure, which is not docu-mented but comprises the realDNA of the enterprise. The formalorganizational chart is made up offormal reporting structures thatspan business unit silos. It is, atbest, a way to assign and trackresponsibilities and, at worst, away to discourage collaborationand protect fiefdoms.

Business architecture encouragesthe acknowledgement, visualiza-tion, and alignment of “shadow”governance structures thatreflect real-world collaborationand infrastructure. This includesthe use of collaborative organiza-tional models as well as exposingand reconciling functional redun-dancies, inconsistencies, andother pathologies that hinder

efforts to streamline operationalefficiencies and effectiveness.Governance modeling and visual-ization dovetails with efforts tosynchronize and align businessprocess, business rule, and busi-ness data modeling initiatives.

Business Model Managementand Synchronization

Organizations are overflowingwith models. This is true not onlywithin IT but also more recentlywithin various business units. Asvarious business units and projectteams expedite efforts to deployprocess models, rule representa-tions, and data models, they mustidentify ways to address the over-lap and interdependencies amongthese models. If this does notoccur, standalone business mod-els will become increasinglyredundant, disconnected, andirrelevant.

Consider a situation where anenterprise has three separatebusiness units, all of which haveresponsibility for managing billingand customer support functions.Now further consider that a corpo-rate strategy involves document-ing, retooling, and automatingbusiness processes and businessrules with the goal of increasingoverall efficiency and effective-ness. Each business unit willinvariably create models thatcontain and expose redundantand inconsistent processes, rules,and data.

Without higher-level models toroll up these granular views to an

organizational level, segregatedteams may never realize thatthese redundancies and inconsis-tencies exist. This in turn couldtorpedo subsequent retoolingefforts while further disruptingdownstream activities such asfunctional consolidation and ITarchitecture alignment. Businessarchitecture provides the disci-plines to allow management tocollaboratively synchronize repre-sentations of processes, rules, anddata via high-level visualizations.

The visualization aspect of BAis particularly important. The proc-ess of exposing redundancies alsoexposes inefficiencies. For exam-ple, a large telecommunicationscompany exposed redundanciesthrough bottom-up analysis ofbusiness processes that werethen rolled up to a more strategiclevel. This allowed executives tostreamline and consolidate busi-ness roles in a way that containedemployee growth even as theenterprise expanded its revenues.This had a direct benefit of facili-tating revenue growth while con-taining the costs of delivering thisadditional revenue.

Virtual Enterprise Alignment

Business processes, rules, anddata collectively flow beyond thebounds of the formal enterprise,spilling into business partner,supplier, and outsourcingdomains. However, the inability tounderstand or articulate internalflows, particularly as these flowsextend to the hundreds or thou-sands of touchpoints to external

entities, can stymie an enterprise’sability to streamline and managethe virtual enterprise.

Documenting the extended enter-prise is best accomplished from aBA perspective that can reconcileor accommodate redundanciesfrom a more strategic perspective.These visualizations can synchro-nize internal governance struc-tures, processes, rules, and data inways that allow for the increasedstreamlining of supplier-partnerrelationships, elimination of costlyand error-prone redundancies,and the flattening out of overlycomplex process flows across thevirtual enterprise.

Business-IT ArchitectureAlignment

One important benefit of businessarchitecture involves the articula-tion of business requirements to ITand the provision of formal sup-port for business-IT architecturealignment. In many organizations,it is painfully apparent that IT itselfand the business community thatIT is intended to serve are poorlyaligned. In some cases, businessand IT are almost at odds with oneanother, thinking that each has abetter understanding of what theenterprise requires and how todeliver on those requirements.

Visualizing the as-is BA and for-mally articulating how the BAmust change to support businessstrategy is key to driving changesin IT architecture. IT architecturesinclude data and applicationsthat, even in the best-managed




IT organizations, are highly redun-dant, are heavily segregated, anddo not fulfill many basic businessrequirements. In addition to stud-ies confirming this claim [1], oneonly needs to consider how manybusinesses work around formalIT systems using spreadsheets,PC databases, and manual work-arounds to see an example ofbusiness-IT misalignment.

Consider the previous billing unitexample. It is likely that the threeredundant billing units align withredundant billing applications anddata structures. IT cannot andshould not launch a data andapplication architecture consoli-dation initiative without aligningdisparate business data, rules, andprocesses across these businessunits. Business units, however,can work with IT to formalize acommon set of business modelsthat IT can use to establish adata and application architectureconsolidation roadmap. In theabsence of BA formalization andalignment, IT is merely fishing forthe right solution without knowingif it is going in the right direction.

Synchronizing MultidimensionalDisciplines

Business architects and analystsare practicing business architec-ture today but tend to work fromthe bottom up without employingcomprehensive BA representa-tions. Process modeling tends tostart at very granular levels, asdoes business rule analysis, whileignoring governance issues. Thereis a clear need for strategic para-digms that can be used to facilitatethe consistency, synchronization,and deployment of these businessmodeling disciplines.

It is interesting to note that thepractice of creating low-levelmodels without tying thesemodels together parallels thegrowth of architecture within theIT industry. In the 1970s, programdesign paradigms emerged andwere followed by systems designparadigms. Over the past 25 years,IT architecture concepts maturedinto increasingly more compre-hensive representations that sup-port high-level visualization aswell as the ability to drill downto more granular views within

that same architecture. Businessarchitecture must meet thesesame requirements — only froma business perspective.

Business architecture not onlyraises the visibility and under-standability of cross-disciplinarybusiness models but also tiestogether disciplines that havebeen evolving independently.Consider that business processesand business rules tend to evolveindependently and lack a formalconnection to business data. BAis the glue that brings togethercross-disciplinary models in waysthat facilitate holistic approachesto streamlining governance struc-tures, process, rules, and IT align-ment. Business architecture willtake on an increasingly vital rolein leading enterprises in the com-ing years.

References

1. Hess, H.M. “Aligning Technologyand Business: Applying Patternsfor Legacy Transformation.” IBMSystems Journal, Vol. 44, No. 1,2005 (www.research.ibm.com/journal/sj/441/hess.pdf).



NOT YOUR FATHER’S (OLDS)MOBILEby Jim Watson, Senior Consultant, Cutter Consortium

Mobility, in a single word, some-how seems to capture the quin-tessential goal of the intersectionof people, technology, and infor-mation. The idea that one can bein any location, or even in transit,and have experiences similar tothose in a given fixed locationdesigned for those experiences is

as intriguing as it is challenging.However, mobility, like any high-tech endeavor, is a complicatedissue and won’t really becomemainstream until there is technol-ogy that the mass public can useand some kind of killer app thatmotivates people to make thetransition to the technology.

There are many dimensions to“mobile computing” or, moresuccinctly, mobility. Mobility, inbroad terms, does not necessarilyrequire computers — consider theearly cell phones (would these becalled “classic” or “legacy”?) —but the interdependence betweenmobility and computing is now

unavoidable. One dimension ofmobility is about the devices used,such as a cell phone (that maybe able to run applications andaccess the Internet) or a PDA(that may be able to make phonecalls). Of course, an importantmobile device is the laptop com-puter, which is also able to trackyour personal data and makephone calls (and be wireless).There is an additional layer in thisdevice dimension that is now sep-arating the “core device” from the“interface device,” as evidencedby Bluetooth headsets, speechrecognition interfaces, RFID tags,and so on. There will inevitably bea lot of advancement in devices,the batteries that power them,and the antennas, microphones,buttons, and styluses that inter-face them, but that is not ourmain focus here.

Another dimension of mobility,and the focus of this segment, isthe mobility killer app; that is, thatapplication that is so compelling,yet simple and accessible, thatthere is a large adoption, resultingin not only a sense of value butalso of wonderment of how wemanaged without it. There is moreand more evidence that technol-ogy tends to remain in the realmsof geekdom until such a killer appappears. We speculate that themobility killer app is RSS and fur-ther that utilization of RSS will bea major trend in 2007.

RSS and Mobility

At a technical level, RSS is an XML-based technology that allows

content providers to describethe content, changes, and pub-lication schemes via updatestreams or feeds. The geeks arehappy; all the pieces are cominginto place — standards, architec-tural approaches (including SOA),bandwidth, registration, securitymechanisms, and so forth.But more important is what ishappening above the geek levelat the mainstream level.

RSS’s utilization at the mainstreamincludes:

A desktop metaphor. Maccomputers and now the cross-platform Google Desktopemploy the concept of “gad-gets,” which are composableapplications that access infor-mation via RSS (and othermeans, but RSS will likelyultimately dominate).

A business dashboard.Business users (that is, more“mainstream” than us tinker-ers) can tap into various met-rics maintained by disparateinformation systems andcompose an RSS-baseddashboard of text, numbers,streams, and benchmarks andhave it updated in real time.

General syndication andaggregation. All users can reg-ister interest in various topicsor specific content providersand get the information (news,blogs, music, community inter-est groups, and so forth) thatthey want.

While the above items weredescribed individually, they canbe, and often are, combined. Sothink of RSS as the means toaccess information of interest(whether work or play, social orpersonal, urgent or mundane).Add in the fact that since it isXML-based, the underlying tech-nical issues can be largely auto-mated to make delivery of theinformation to a device (that is, anRSS-rendering platform) straight-forward. Then consider that thesedevices are very portable. Andtogether, you have very transpar-ent access to information that youneed, as defined by what youwant to accomplish, not whereyou are — hence, mobility.

Example of Mobility in Business

Consider the mission-specificdevice that package delivery orga-nizations like UPS and FedEx useto extend the business to theirmobile workforce. Route plan-ning, scheduled deliveries andpickups, changes to schedule,status, location, package tracking,and signatures are all done viathe device. Combined with aninterface to the truck, mainte-nance, gas, and efficiency infor-mation is obtained. Combinedwith an interface to traffic infor-mation, routes can be replanned.Combined with an interface tolaw enforcement, suspects can befound (for example, AMBER Alertsto find kidnapped children).Combined with an interface toweather, personal schedule, andthe ability for a relative to reachyou (or know where you are),




there becomes little differencebetween the information experi-ence in the truck and that in theoffice or on a home PC.

This combination of informationand device will be generalized sothat it is no longer related directlyto a mission-specific device butinstead related to the informationneeds as specified by the user.The result is access to informationregardless of location.

Of course, not every business haspeople in trucks. But some havepeople in meetings, at confer-ences, in airport lounges, onplanes, at home, and so on. Sothere is a general appeal to com-posing information while mobile.While the context and informationsought will change, the overallneed for a transparent mobileexperience will remain the same.

The Mobile Ecosystem

Above we have focused on theimpact that RSS will have onmobility as a potential killer appli-cation. But there is more to mobil-ity than that, and there are someadditional important trends thatwe should at least mention in thisshort segment, including:

Device form factor. Oneexciting technology is flexibleLCD screens, essentially allow-ing for a comfortably sizedscreen (think laptop, not PDA)

to be rolled into the form factorof a compact umbrella andopened as needed. Integratedwith wireless access to theInternet, you can read the elec-tronic daily paper as you readthe physical paper today.1

Terabyte with you. Extrapo-lating from iPods and thumbdrives, soon you will be able tohave the data you want withyou at all times in a small size— not just music and picturesand not just locked to a singledevice. Call it your personal,mobile, network accessiblestorage (NAS).2

Context-aware computing.An active research areainvolves the development ofsoftware that understands thecontext the user is in (whichis important and changing inmobile applications) and tailorsthe software to that context.For example, when in yourcar you may want differentfeeds (such as music, voice-generated reading of e-mail/news, and navigationguidance) than when you arein your office (where you maywant meeting reminders, salespipeline information, status ofhome improvement project,and so forth).

Knowing where you are.Mobility is, by its nature, aboutbeing on the move, and the

continued growth of GPS-enabled devices and location-encoded information willmean that there is no differencebetween being at some “homebase” or elsewhere. You will beable to get information in thecontext of where you are.

Looking Ahead to 2007

As described above, RSS may bethe killer app for mobility, allowingpeople to have fairly seamlessaccess to information regardlessof location but, at the same time,in the context of their location(and activity, goals, tasks, and soon). RSS empowers the readyaccess and composition of infor-mation that ultimately drives thiscapability. But mobility exists inthe broader context of businessapplications and the architecturesthat support them. So to effec-tively support mobility, we expectto see the following broaderactivities:

Business architectures beingused to identify those proc-esses that are applicable toremote (mobile) interaction,leading to a need for a concep-tual technical architecture thatadequately supports RSS-basedcomposability.

RSS as a major thrust that,given its focus on componenti-zation and composability, willbe common within enterprisearchitectures.



1See DisplayBlog entry (http://displayblog.wordpress.com/tag/rollable-display).2See Keith Shaw’s “SanDisk Adapter Helps You Keep Up with Format Changes” (www.networkworld.com/community/?q=taxonomy/term/298) andCarlos E. Perez’s “What Happens When You Have A Terabyte Of Personal Storage?” (www.manageability.org/blog/stuff/what-happens-when-you-got-too-much-storage).

Given the ease at which RSS-based services are defined

and then composed into largerapplications, RSS will fit well

within trends toward moreagile development.



ABOUT THE AUTHORS

Scott W. Ambler is a SeniorConsultant with CutterConsortium’s EnterpriseArchitecture and Agile ProjectManagement practices. He isa Fellow of the InternationalAssociation of Software Architectsand the practice leader behindAgile Model Driven Development(AMDD), the Agile Data (AD)method, the Agile Unified Process(AUP), and the Enterprise UnifiedProcess (EUP). Mr. Ambler is theauthor or coauthor of several soft-ware development books, includ-ing Agile Modeling, The Elementsof UML 2.0 Style, The EnterpriseUnified Process, and RefactoringDatabases. He is also a contribut-ing editor with Dr. Dobb’s Journaland author of their monthly AgileEdge column. Mr. Ambler hasspoken at a wide variety of inter-national conferences includingXP200n, Software Development,UML World, Object Expo,JavaOne, and OOPSLA, and heworks with clients around theworld to improve the way theydevelop software. He can bereached at [email protected].

Tushar K. Hazra, PhD, is aSenior Consultant with Cutter’sEnterprise Architecture andSourcing & Vendor Relationshipspractices. In 2000, Dr. Hazrafounded EpitomiOne, a strategicconsulting company specializing

in EA, SOA, portals, Web services,model-driven solution delivery, ITgovernance, service delivery man-agement, and global sourcingstrategy facilitation. Dr. Hazra has16 years’ experience in developingand integrating service-orientedenterprise (SOE) and mission-critical component-based systemsin collaborative environments forthe insurance, healthcare, retail,banking, telecom, and aerospaceindustries. During the past 12years, Dr. Hazra has served asCTO and VP of several Fortune100 companies. At present, asPresident and CTO of EpitomiOne,he helps business and IT leadersincorporate their strategic visionsfor EA and SOA initiatives (bothcommercial and governmentagency clients) while complyingwith commercial and governmentstandards, best practices, andmandates. Dr. Hazra is a hands-onpractitioner who gets involvedfrom building strategies to devel-oping EA and SOA to guiding anddeploying MDA-based applicationintegration initiatives. He can bereached at [email protected].

Michael Rosen is Director ofCutter’s Enterprise Architecturepractice and Senior Consultantwith its Business-IT Strategiespractice. He has more than 20years’ technical leadership experi-ence architecting, designing, and

developing software productsand applications. Currently, heprovides expert consulting ser-vices in the areas of EA, SOA, andMDA. Previously, Mr. Rosen wasCTO at M2VP, Inc., a consultancyconcentrating in IT architecture,where he developed the com-pany’s practice area using MDAto specify and implement EA.He also was Chief EnterpriseArchitect at IONA Technologies,PLC, where he was engaged inthe development of the overallproduct architecture for IONA’snext-generation Web services plat-form and in the creation of thereference architecture for buildingapplications on that platform. Priorto joining IONA, Mr. Rosen wasChief Enterprise Architect atGenesis Development Corp.,where he provided architectureconsulting on largescale applica-tions and infrastructure for Global1000 clients in insurance, finance,and telecommunications. While atGenesis, he led the developmentand formalization of a genericenterprise architecture and soft-ware development practices usedthroughout the company. Beforejoining Genesis, Mr. Rosen wasa product architect, technicalleader, and developer for numer-ous commercial middlewareproducts for vendors includingBEA and Digital. His involvementin product development includes




Web services, Java, CORBA, COM,messaging, transaction process-ing, DCE, networking, and operat-ing systems.

Throughout his career, Mr. Rosenhas been a frequent technicalspeaker and author. He has pre-sented keynotes, tutorials, andseminars at conferences in theUS, Europe, and Asia and hasarticles in publications includingWeb Services Journal, EAIJournal, Software Magazine,and Enterprise Development.He is coauthor of Developing E-Business Systems andArchitectures: A Manager’s Guideand Integrating CORBA and COMApplications, which grew out ofhis contributions to the OMGCOM/CORBA interworking spec-ification. He can be reached [email protected].

William M. Ulrich is a SeniorConsultant with Cutter’s Business-IT Strategies and EnterpriseArchitecture practices. He servedas Guest Editor of Cutter IT Journaland has been a speaker at CutterSummits and symposia. Mr. Ulrichis President and founder ofTactical Strategy Group, Inc., amanagement consulting firm spe-cializing in information and busi-ness planning strategies. He hasmore than 25 years’ experiencein the information managementfield. His system transformationstrategies have been the basis formigration projects worldwide. Asauthor of TSRM, a widely deployed

redevelopment methodology,Mr. Ulrich is viewed as the leadingauthority on systems transforma-tion for the IT industry. He hasadvised Fortune 1000 companies,government agencies, high-techcompanies, and consulting firmson information management,legacy transformation, IT organiza-tional change, business continuityplanning, supply chain manage-ment, market deployment, partneralliance, and Y2K strategies.Mr. Ulrich previously served as areengineering products directorat a software company where hehad international responsibilityfor the company’s reengineeringproduct solutions. Prior to that, heserved in a senior managementcapacity at KPMG. Mr. Ulrich haslectured internationally to thou-sands of business and IT profes-sionals and has consulted andtestified as an expert witness onthe use of intellectual propertywithin the computer field.Mr. Ulrich has authored hundredsof articles appearing in major pub-lications on IT and managementtrends. His latest book is entitledLegacy Systems: TransformationStrategies. He can be reached [email protected].

Jim Watson, PhD, is a SeniorConsultant with Cutter’s EnterpriseArchitecture and Agile ProjectManagement practices. He hasmore than 15 years’ technicalleadership experience architecting,designing, and developing soft-ware products and applications.

Dr. Watson was VP Engineering atIONA Technologies, PLC, where hemanaged the overall architecture,implementation, and delivery ofproducts. Prior to that position,he was IONA’s first TechnicalDirector, where he led a majorrefactoring project and providedoverall architectural direction forIONA’s Integration Product Suite.Dr. Watson led the adoption of XPand Interaction Design (ID). Priorto IONA, he was Founder andPrincipal Consultant of AuroraTechnologies, Inc., a 10-personboutique consultancy for customapplication development and inte-gration projects. While at Aurora,he worked with various Global2000 clients in manufacturing,telecommunications, finance,and government. Dr. Watson wasa co-architect for one of the firstdistributed simulation environ-ments developed for the US mili-tary. His involvement in productdevelopment includes Web ser-vices, J2EE, Java, C++, CORBA,COM, messaging, realtimesystems, and design patterns.Throughout his career, Dr. Watsonhas been a frequent technicalspeaker at various trade confer-ences. He has produced anddelivered training for both techni-cal and management audiences,ranging from integration, patterns,and product technologies.Dr. Watson holds a PhD in elec-trical engineering. He can bereached at [email protected].

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 Project Management • Business Intelligence• Business-IT Strategies• Business Technology Trends & Impacts• Enterprise Architecture• IT Management• Measurement & Benchmarking Strategies• Enterprise Risk Management & Governance• Sourcing & 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• Mark Choate• Max Dolgicer• Don Estes• Pierfranco Ferranato• Clive Finkelstein• Kurt Guenther• Michael Guttman• David Hay• Tushar K. Hazra• J. Bradford Kain• Bartosz Kiepuszewski• Sebastian Konkol• André LeClerc• Jean Pierre LeJacq• Arun K. Majumdar• Thomas R. Marzolf• Jason Matthews• James Odell• Viktor Ohnjec• Ken Orr• Wojciech Ozimek• Oliver Sims• Borys Stokalski• John Tibbetts• Sandy Tyndale-Bisco• William Ulrich• Jeroen van Tyn• Jim Watson• Tom Welsh• Bryan Wood


arquitectura empresarial

Documents

cutter consortiumwhile

cutter consortiums philosophy

business technology

enterprise architecturetrends

enterprise architecturevol

enterprise risk management

business intelligence

unique situation