Cutter - cdn.ttgtmedia.comcdn.ttgtmedia.com/rms/computerweekly/DowntimePDF/pdf/SOA_goven… · Ed Yourdon,Cutter IT Journalis one of Cutter’s key venues for debate. The monthlyCutter

The Journal of Information Technology Management

Cutter IT Journal

Vol. 20, No. 6June 2007

Service-Oriented Architecture andIts Implications for Governance

Opening Statementby Tom Welsh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Governing the Legacy-to-SOA Transformationby Michael Kunz, Dirk Krafzig, and Dirk Slama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Who Cares About Governance and SOA?by Jorge V.A. Ronchese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

The Key to SOA Governance: Understanding the Essence of Businessby Keith Swenson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

SOA Governance: Building on the Old, Embracing the Newby Tushar K. Hazra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

SOA Governance Using the Universal Business Identifierby Hao He and Brett McDowall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

The Tao of SOA Governanceby Piotr Szabelak and Jan Topinski, with contribution from Borys Stokalski . . . . . . . . . . . . 34

Automated Management

A successful SOA initiative soon brings forthdozens, or even hundreds, of services. Nohuman being can possibly keep track ofhow all these are working. SOA governancerequires powerful suites of tools to monitor,record, and analyze service traffic in order toidentify bottlenecks, clashes, and dependen-cies before they cause serious problems.

A Meeting of Minds

SOA involves an apparent contradiction.Services can only be implemented bottom-upby developers, but they must be specifiedand fine-tuned top-down by business pro-fessionals. The only solution is to place anintelligent layer in the middle to reconciletechnical means with business ends. Thatintelligent layer is SOA governance.

“If we accept that SOA is theroyal road to better align-ment between business andIT, we must face the ques-tion: exactly how will thisalignment come about?”

— Tom Welsh,Guest Editor

http://www.cutter.com



Cutter IT Journal®

Cutter Business Technology Council:Rob Austin, Ron Blitstein, ChristineDavis, Tom DeMarco, Lynne Ellyn,Jim Highsmith, Tim Lister, LouMazzucchelli, Ken Orr, Ed Yourdon

Editorial Board: Larry L. Constantine, Bill Curtis, Tom DeMarco, Peter Hruschka, TomooMatsubara, Navyug Mohnot, RogerPressman, Howard Rubin, Rob Thomsett,George Westerman

Editor Emeritus: Ed YourdonPublisher: Karen Fine CoburnGroup Publisher: Chris GeneraliManaging Editor: Karen PasleyProduction Editor: Linda M. DiasClient Services: [email protected]

Cutter IT Journal® (ISSN 1522-7383)is published 12 times a year by CutterInformation LLC, 37 Broadway, Suite 1,Arlington, MA 02474-5552, USA(Tel: +1 781 648 8700 or, within NorthAmerica, +1 800 964 5118; Fax: +1 781648 1950 or, within North America,+1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com).

Cutter IT Journal® covers the softwarescene, with particular emphasis on thoseevents that will impact the careers of ITprofessionals around the world.

©2007 by Cutter Information LLC. All rights reserved. Cutter IT Journal®is a trademark of Cutter Information LLC.No material in this publication may bereproduced, eaten, or distributed withoutwritten permission from the publisher.Unauthorized reproduction in any form,including photocopying, faxing, imagescanning, and downloading electroniccopies, is against the law. Reprints makean excellent training tool. For informationabout reprints and/or back issues of CutterConsortium publications, call +1 781 6488700 or e-mail [email protected].

Subscription rates are US $485 a yearin North America, US $585 elsewhere,payable to Cutter Information LLC.Reprints, bulk purchases, past issues,and multiple subscription and site licenserates are available on request.

Part of Cutter Consortium’s mission is to fosterthe debate of, and dialogue on, the businesstechnology issues challenging enterprisestoday, to help organizations leverage IT forcompetitive advantage and business success.Cutter’s philosophy is that most of the issuesthat managers face are complex enough tomerit examination that goes beyond simplepronouncements. Founded in 1987 asAmerican Programmer by Cutter FellowEd Yourdon, Cutter IT Journal is oneof Cutter’s key venues for debate.

The monthly Cutter IT Journal and its weeklycompanion Cutter IT E-Mail Advisor offer avariety of perspectives on the issues you’redealing with today. Armed with opinion,data, and advice, you’ll be able to make thebest decisions, employ the best practices,and choose the right strategies for yourorganization.

Unlike academic journals, Cutter IT Journaldoesn’t water down or delay its coverage oftimely issues with lengthy peer reviews. Eachmonth, our expert Guest Editor delivers arti-cles by internationally known IT practitionersthat include case studies, research findings,and experience-based opinion on the IT topicsenterprises face today — not issues you weredealing with six months ago, or those thatare so esoteric you might not ever need tolearn from others’ experiences. No otherjournal brings together so many cutting-edgethinkers or lets them speak so bluntly onissues such as:

Proving the value of IT ROI

The give and take of offshore outsourcing

The value of high-quality data

The evolution of agile project management

When and how to kill a dying project

Cutter IT Journal subscribers consider theJournal a “consultancy in print” and likeneach month’s five or six articles exploring asingle topic to the debates they participate inat the end of a day at a conference — withevery participant in the conversation forcefullyexpressing his or her viewpoint, backing itup with data and real-life experience.

Every facet of IT — application integration,security, portfolio management, and testing,to name a few — plays a role in the successor failure of your organization’s IT efforts.Only Cutter IT Journal and the Cutter IT E-MailAdvisor deliver a comprehensive treatmentof these critical issues and help you makeinformed decisions about the strategies thatcan improve IT’s performance.

Cutter IT Journal is unique in that it is writtenby IT professionals — people like you whoface the same challenges and are under thesame pressures to get the job done. TheJournal brings you frank, honest accountsof what works, what doesn’t, and why.

Competition remains intense in the high-techworld. Budget cutbacks and short deadlineshave become the norm. You need advice andexperience you can rely on. Put your IT con-cerns in a business context. Discover thebest ways to pitch new ideas to executivemanagement. Ensure the success of your ITorganization in an economy that encouragesoutsourcing and intense international compe-tition. Avoid the common pitfalls and worksmarter while under tighter constraints. You’lllearn how to do all this and more when yousubscribe to Cutter IT Journal.

About Cutter IT Journal

Cutter IT Journal


mailto:[email protected]


mailto:[email protected]

Opening Statement

3Vol. 20, No. 6 CUTTER IT JOURNAL

Service-oriented architecture (SOA) has been the hottesttopic in software for the past two or three years, and itlooks as though it will continue to enjoy that status forsome time to come. Like Java, XML, and Web services,it has attained buzzword superstardom — membershipin that select clique of terms that seem fated to be con-tinuously analyzed and debated by analysts, bloggers,and the media. Under the circumstances, software ven-dors have naturally hastened to talk up their products’potential contribution to SOA success.

Unlike most innovative ideas, however, SOA is deemedto be of immediate and pressing interest to businessdecision makers, from CxOs on down. This is because(in spite of its name) it is not just another softwarearchitecture, but a new and powerful way of reorganiz-ing business enterprises. The theory is that, with SOA,all corporate software applications are decomposed intologically related groups of services. Each department ordivision — HR, finance, marketing, purchasing, and soon — takes responsibility for creating and maintainingthose services that implement its business activities.

With the advent of SOA, it is harder to consign alltechnical questions to the IT department and leave itto work away in isolation. Indeed, this should theoret-ically be impossible, as services cannot be properlydesigned or administered without substantial inputfrom the relevant business groups.

SOA is intrinsically distributed, whether network-widewithin an enterprise or reaching out beyond the fire-wall to embrace external partners, suppliers, and evencustomers. Moreover, SOA experts stress the impor-tance of breaking up the monolithic control that centralIT has usually exercised over corporate computing inorder to put separate divisions, lines of business, anddepartments in charge of their own services. For thesereasons, together with its strategic nature and thesize of the investments likely to be required, SOA isbelieved to encourage convergence between businessand IT planning.

Thus, SOA is deeply linked with enterprise architecture(EA) and governance. Indeed, it could be seen as the

answer to an enterprise architect’s dream, as it comescomplete with answers to many knotty questions thatwould otherwise have to be worked out ad hoc. If youhave a robust, viable SOA that is capable of growingin response to corporate business requirements andopportunities, you automatically have most of yourenterprise architecture, too.

All this is well and good, but if we accept that SOA isthe royal road to better alignment between businessand IT, we must face the question: exactly how willthis alignment come about? How can we establishSOA governance so that business and IT professionalscooperate smoothly to deliver maximum business valuewhile minimizing risk?

SOA governance is an extremely important, and highlysensitive, topic. After all, it sits at the intersection oftwo zones of controversy, neither of which has yetbeen resolved. On the one hand, we have SOA — a newtechnology revolution that poses difficult IT problemsand even more exacting organizational ones. On theother, we have IT governance, a discipline that, to bepolite, we may characterize as still more of an art thana science. Neither can get by without the support ofthe other. IT governance is being transformed by theradically new demands of service-based IT, and SOAcannot hope to succeed without firm and consistentgovernance.

Given that SOA compels business and IT to cooperateorganically, it follows that SOA governance must alsoblend requirements, processes, and techniques fromboth these domains. Questions inevitably arise as to thedistribution of responsibility, the degree and manner ofcooperation, and the ways in which decisions are madeand — just as important — enforced. At one extreme,a committee of business managers might interview ITspecialists before deciding what services are needed,how they are to be funded and built, and what feedbackmetrics are to be obtained. At the other — a far morefrequent scenario — business groups inform the ITdepartment of their requirements and then leave the“techies” to do the rest. Between them, the authors of

by Tom Welsh, Guest Editor

Get The Cutter Edge free: www.cutter.com


©2007 Cutter Information LLCCUTTER IT JOURNAL June 20074

the six articles that make up this issue of Cutter ITJournal thoroughly address all these questions.

Michael Kunz, Dirk Krafzig, and Dirk Slama proceedfrom the logical view that SOA governance cannot bedealt with as a static issue. Instead, they describe theongoing challenges posed by a legacy-to-SOA trans-formation, noting that “effective governance raisesthe probability of SOA success because it enables bigorganizations to conduct change programs over manyyears.” Not only does enterprise SOA force a reevalua-tion of how IT interacts with business, it also imposesorganizational changes.

According to the authors, the transformation to SOAtakes place on six levels: business, organization, people,IT processes, functional architecture, and technicalarchitecture. They provide a sustainable roadmap forthe transition to SOA at each of these levels and claimthat this framework helps enterprises take a holisticapproach to SOA adoption. This contention is sup-ported by a brief case study of an international services

company whose reuse rate in IT projects rose by120% in a single year after it decided to take a globalapproach to SOA.

In our second article, Jorge Ronchese takes a step back toget a broader perspective on the origin and desirabilityof SOA governance initiatives. As every organizationdoes not necessarily need SOA, he proposes eight crite-ria for assessing the likely benefits. There follows ananalysis of inadequate reasons for embracing SOA gov-ernance, such as a desire to impose stronger controls orto compensate for weak management without rufflingtoo many feathers. Resistance to change is inevitable,but, Ronchese argues, it is not necessarily a bad thing.He explains how listening carefully to people’s objec-tions can be the first step toward defining problems andfinding solutions to them, and he shows how the Theoryof Constraints can help with this analysis. Given that“SOA governance is important if it solves some of theproblems or constraints that are preventing your com-pany from reaching its goals,” Ronchese concludes byasking bluntly, “Do you have them clearly identified?”

Keith Swenson, VP of R&D at Fujitsu’s EnterpriseSoftware and Solutions Group, states a vital prerequisitefor effective SOA creation: understanding the essence ofthe business. After all, without a clear insight into theenterprise’s purpose and core activities, how can anSOA even be designed? Gaining that insight in turndemands a shift in the way business and IT worktogether. To this end, Swenson tells us, “Companiesneed to build an architectural roadmap with SOA gov-ernance woven into the fabric of daily operations.” Inshort, someone must understand what the business isdoing well enough to see changes coming, and thenunderstand IT well enough to adapt the SOA accord-ingly. The trick is to make top-down business goalsmesh with bottom-up IT development, which Swensoncontends is the role of SOA governance. He also urgesthe instrumentation of SOAs with appropriate toolsin order to know which services are available, who isusing them, which services depend on others, and whatquality of service is being provided.

So far, we have seen a variety of different approaches.Cutter Senior Consultant Tushar Hazra seeks to knitthese together. He begins by comparing SOA gover-nance with corporate governance, EA governance, andIT governance, seeing to what extent these existing dis-ciplines can be co-opted to support the new dispensa-tion. One clearcut distinction is that SOA governancehas to cope with the impact of distributed servicesacross one or more business organization(s), based onservice-level agreements. Hazra agrees with Swenson

IN NEXT MONTH’S ISSUE

How Should IT Enable Business Strategy?Guest Editor: Victor Rosenberg

Back in the 1990s, IT was considered the genie in thelamp. Want to revise a business process or achieve someother information goal? Just turn the problem over to IT,which will somehow magically make it happen.

Over a decade later, the bloom is definitely off the rose.Today there are many views as to how involved IT should bein business strategy. Nicholas Carr and his acolytes say IT’srole is merely to do what the business says should be doneas cheaply and efficiently as possible. Others believe that ITcan enable competitive advantage by converting new capa-bilities into better products faster than competitors and byquickly translating know-how into business value.

Join us next month as we debate the ways IT can — orcan’t — enable business strategy. Learn how to determinewhether your IT organization is a strategic enabler or atactical one — and how those roles can change over time.Discover how one IT group went from providing basicservices to participating in a true business partnershipthanks to its “well-formed strategy statements” and savvyindustry scanning. If you’d rather be contributing innova-tive ideas instead of simply executing what you’ve beenhanded, don’t miss next month’s issue!

5Get The Cutter Edge free: www.cutter.com Vol. 20, No. 6 CUTTER IT JOURNAL

that SOA governance should form a connecting layerbetween the complementary and equally importantbottom-up and top-down approaches. After surveyingsome useful policies, principles, and best practicesbased on his own practical experience, Hazra offerssome advice about the tools and techniques availablefor implementing governance processes.

At first glance, Hao He and Brett McDowall seem not tobe addressing SOA governance itself, as their chosentopic — the Universal Business Identifier (UBI) — hasmore to do with technical architecture. On closer inspec-tion, it turns out that the UBI has a significant contribu-tion to make. He and McDowall start from the thesisthat the goal of SOA governance is to align the businesswith IT by providing a suitable decision framework. Thesharing of models between business and IT, especiallya common taxonomy, materially contributes to thatalignment. What He and McDowall propose is that theUniversal Resource Identifier (URI), which we routinelyuse to specify Web addresses, should be co-opted in theguise of the UBI. They argue that “absolutely anythingimportant in an enterprise should be identified by aURI.” At a stroke, this would fulfill a number of SOArequirements, such as identification, addressing, owner-ship, resource lookup, and transparency. Above all, theUBI would help to keep things as simple as possible.

In our last article, Piotr Szabelak, Jan Topinski, andCutter Senior Consultant Borys Stokalski identify afundamental polarity between the formal, orderlyprocesses of EA management and the innovative,potentially chaotic forces of SOA, which they dub the“yin” and “yang,” respectively, of corporate computing.Indeed, the mere introduction of SOA can lead to grow-ing demand for changes in governance, as establishedprocesses no longer cut the mustard. For example, manyorganizations currently seeking to roll out SOA havefound themselves forced to rely on traditional tech-niques such as large-scale release management. These,however, militate directly against the fine granularity,ad hoc nature, and responsiveness that are supposed tobe among SOA’s greatest strengths.

This can be avoided, say the authors, by restructuringIT governance and EA processes along SOA lines.Everything — from business planning to softwarerelease processes — must fit in with the servicesmetaphor. Trickiest of all, practices should be devisedthat allow project teams to coordinate their work on

services without introducing any cumbersome andrestrictive corporate chokepoints, and the servicesportfolio must become a truly shareable IT asset.

Some key ideas recur in article after article. Almosteveryone emphasizes the fact that SOA’s reason forexistence is to further corporate business goals — soSOA governance must be based upon a thoroughunderstanding of those goals. There is also a strongconsensus that building an effective enterprise SOAcannot be done piecemeal; instead, it should flow froma coherent central plan. On the other hand, the wholethrust of SOA is to accommodate different platforms,languages, and protocols. So we arrive at the classicdichotomy between top-down design and bottom-upimplementation, with SOA governance as a “glue” layerin the middle holding it all together.

While tools are necessary for effective SOA governance,they are definitely not sufficient. As governance reliesheavily on the behavior and decisions of human beings,it cannot be wholly automated. Moreover, the part of itthat can be automated is, as we might expect, the lower-level, relatively mechanical aspects.

Whatever your interests and concerns or the specialrequirements of your particular organization, there issure to be something in this issue that will interest andinform you. You may also discern some overlap and,perhaps, a measure of constructive disagreement. Butthat is inevitable, as the art of SOA governance is stillin its infancy. One thing is for sure: if you are responsi-ble for setting up or administering a corporate SOA,you will find stimulating and useful ideas aplenty inwhat follows.

Tom Welsh is a Senior Consultant with Cutter Consortium’sEnterprise Architecture advisory service and former Editor of CutterConsortium’s monthly Web Services Strategies. He is an indepen-dent consultant and analyst specializing in middleware, object tech-nology, and software engineering. At Digital Equipment Corporation,Mr. Welsh was a hardware technician, software support specialist,corporate software developer, and senior technology consultant beforetaking on the task of marketing Digital’s OO software products in theUK. In his role as a principal analyst at ComputerWire, Mr. Welshhas been a leading contributor to Client/Server Tools Bulletin,Internet Tools Bulletin, and Object-Oriented Tools Bulletin. Hehas written many reports and papers as well as chaired and spoken atconferences and seminars. Since 1992, Mr. Welsh has closely followedthe work of the OMG and its specifications, including CORBA, UML,XMI, and CWM. He can be reached at [email protected]


ENTERPRISE SOA AND WHY IT MATTERS

For decades now, IT experts have been devising newconcepts and methods for improving the structure ofapplication systems in order to get a better grip onthe ever-increasing complexity found within them. Weinvented hierarchical, relational, and object databases tomanage persistent data more efficiently, and we couldobserve how the evolution of programming paradigmsfrom structured over functional to object-oriented pro-gramming introduced new ways of improving the man-agement of complex application systems.

However, a new programming paradigm is unlikelyto help us in managing the complexity that is foundin today’s historically grown, highly heterogeneousapplication landscapes, simply because the cost andrisk of replacing all the existing application systemsis too high. Even if these systems are badly structuredand costly to maintain, they are working — and that iswhat matters.

Enterprise service-oriented architecture (SOA) offersan architecture blueprint that is specifically designedto work on the enterprise level — not on the level of

individual applications — to help improve the overallstructure of heterogeneous application landscapes. Inan enterprise SOA, basic services provide a core set ofrelatively stable application functionality, which is thenaggregated to provide individual application services(see Figure 1). Enterprise SOA is based on the assump-tion that business processes drive this aggregation.Business process management (BPM) is a key conceptof SOA. It helps make business processes explicit,which is the basis for managing, monitoring, and con-tinuously optimizing them. Business rules management(BRM) allows for centralized control over the way busi-ness decisions are made within these processes. Becausestable code in basic services is separated from more fre-quently changing business process definitions and busi-ness rules, changes in these critical areas can be mademuch faster, and business stakeholders have more con-trol over these areas.

As we can see, the benefits of an enterprise SOA aremanifold. However, transforming an unstructuredlegacy application landscape into an enterprise SOAis not an easy task, and perhaps more importantly, it isnot a technical task alone.


Governing the Legacy-to-SOA Transformationby Michael Kunz, Dirk Krafzig, and Dirk Slama

PYRAMID SCHEME

Application

Services

Process

Services

Intermediary

Services

Process

Efficiency Continuous Improvement

Explicit Business

Process and Rules

Shared Services

• Control/management through business stakeholder• Process monitoring, analysis• Continuous improvement

• Sharing, reuse• Encapsulation• Real-time access• Consistency• Reduced complexity

Agility• Incremental expansion• Short feedback look/visibility• Risk reduction

GUI Batch B2B

P.-CentricService

BPMSBusiness

Rules

TechGateway Adapter

Facade

Data-Centric

Function-Centric

Basic

Services

Figure 1 — The conceptual view of enterprise SOA facilitates communication between various stakeholders in the enterprise and fosters business/IT alignment.


Enterprise SOA has a fundamental impact on the orga-nizational structure of an enterprise. Take, for example,the transformation from functional to object-orienteddesign and programming. This was a methodologyshift that happened predominantly within the develop-ment organization. Enterprise SOA, on the other hand,requires fundamental changes on the organizationallevel in many areas. Consider the introduction of busi-ness rules management. BRM not only requires us tocarefully separate business rules from applicationcode and manage it under the control of a businessrules management system (BRMS), it also requiresus to redefine the way IT interacts with business. Busi-ness stakeholders are suddenly much more directlyinvolved in the management of application systems,because they take on direct ownership of the businessrules. Furthermore, changes to business rules are typi-cally executed within a matter of days. While this newlevel of agility and flexibility is great from a businesspoint of view, it will have a dramatic impact on the IToperations side, which is used to release cycles that arecounted in months, not days.

Let’s take another example — the reuse of applicationlogic, which is one of the holy grails of SOA advocates.Many articles on SOA describe how reuse in an SOA canbe achieved by managing SOA interfaces and other arti-facts in shared registries or repositories. However, his-tory has proved that reuse is typically not achievedthrough goodwill or information sharing alone. In 1968,Melvin Conway made an observation that we believe isstill true today. According to Conway’s Law, organiza-tions are constrained to produce designs that are copiesof the communication structures of these organizations.For instance, if you have four groups working on a com-piler, you’ll get a four-pass compiler. Conway’s Law

argues that enterprise architecture cannot fundamentallybe changed unless the IT organization is changed in par-allel. The IT organization, therefore, not only conductsthe transformation, but is also subject to it.

Taking into account that many application landscapescomprise several hundreds or even thousands of differ-ent applications and an almost unmanageable numberof logical and technical dependencies between theseapplications, it becomes obvious that modernizing theseIT landscapes is an enormous challenge that could takemany years and will require the full dedication of the ITorganization to accomplish. Effective governance raisesthe probability of SOA success because it enables bigorganizations to conduct change programs over manyyears. Governance is therefore the umbrella that makesenterprise SOA feasible.

THE LEGACY-TO-SOA ROADMAP

In our experience, the transformation of an applicationlandscape into an enterprise SOA requires a holisticview of various aspects of an enterprise’s business, orga-nization, people, IT processes, functional architecture,and technology (see Figure 2). Also, it is important tounderstand the dependencies between the businessarchitecture, the SOA architecture, the software architec-ture, and the technical system architecture. These depen-dencies have to be identified for the “as-is” architecture,and potential changes on all levels have to be reflectedin the “to-be” architecture. The transition from as-is toto-be then has to happen on the business, organizational,people, IT process, functional architecture, and systemlevels. In this section, we will provide a brief overviewof some key aspects of each of these levels.

As-Is Architecture To-Be Architecture

Business

SOA

Software

System

Ente

rpri

se Business

Organization

People

IT Processes

Functional Arch.

Technical Arch.

Strategy + SponsorshipBusiness Processes

Governance + IT OrganizationBoard and Steering Committees

Skills + Culture + EducationRoles + Communication

Requirements + DevelopmentOperations + Project Management

SOA Reference ArchitectureDomains + Services + Processes

Runtime Engines/ContainersRepository + Middleware + ESB

SO

A

Figure 2 — A sustainable roadmap for the renovation of existing enterprise application landscapes must cope with challenges on several levels.



Business

To see how SOA impacts the business level, we considertwo examples:

1. IT funding. Traditional funding models for enter-prise IT typically distinguish costs for maintenanceand projects on the one hand and costs for infrastruc-ture and business functionality on the other. Thebudgets for infrastructure (such as mainframes, net-works, or operating systems) are typically located inIT, while the budgets for the development and main-tenance of business functionality are owned by busi-ness lines. SOA destabilizes the equilibrium of thesecost categories because reusable SOA assets do not fitinto this schema. SOA services have characteristics ofbusiness functionality and infrastructure at the sametime. Traditional funding models are therefore notprepared to allocate the costs of SOA properly.

2. Process orientation. Process orientation would beextremely useful for the efficient implementation ofSOA. Explicit process models enable service design-ers to develop service functionality that can be reusedacross several processes. For obvious reasons, processorientation hardly makes sense as a pure IT initiative.On the contrary, it is the business side that mustdrive any process initiative.

Organization

As we mentioned above, the IT department is not onlythe driver of the legacy-to-SOA transformation but alsothe subject of this change process. We usually seechanges on three levels:

1. SOA board. A successful SOA organization is typi-cally governed by an SOA board. The SOA board isan executive team, composed of business and IT man-agement. It acts as the steering committee for theSOA program. The goals of the SOA board includealigning business and IT strategy, assessing projectproposals, ensuring that SOA relevance and impactare considered appropriately in IT projects, and prior-itizing business initiatives and opportunities for SOA.

2. SOA competence centers. The day-to-day work isdone by SOA competence centers. By definition, acompetence center is a team that represents leading-edge knowledge and differentiated capabilities. AnSOA competence center is responsible for providingstrategic SOA skills. It functions as a resource poolthat can be tapped as new SOA projects arise.

3. Maintenance teams. The most far-reaching decisionwould be the setup of permanent maintenance teams

for shared SOA services. While SOA boards and SOAcompetence centers are complementary to existingorganizational units, setting up maintenance teamsfor SOA services would impact the structure of estab-lished departments.

People

Obviously, an SOA initiative requires support of theorganization’s employees. It is not surprising that thissupport does not come for free. SOA can have a dra-matic impact on many individuals, and thus SOA ini-tiatives must be carried out with both empathy andsystematic change management.

Let us again have a look at an example. A typical COBOLdeveloper in the maintenance organization of a bigenterprise is usually responsible for a piece of businessfunctionality and a specific end customer. He takesresponsibility for the complete IT process chain, includ-ing requirements gathering, design, development, test-ing, and deployment. Furthermore, he is responsible forall layers of the software stack, from 3270 presentationdown to VSAM files. In a service-oriented world, the jobprofile of this person changes dramatically. This must notbe underestimated, because many people may react fear-fully to change or be paralyzed by it. It is therefore vitalthat those conducting an SOA initiative take explicitmeasures to gain the support of all stakeholders.

An SOA initiative must be accompanied by an infor-mation campaign. This campaign can involve regularnewsletters, road shows, intranets, and so on. The mainobjective is to keep the staff informed and promotethe ideas of SOA and its benefits for the organization.Education programs are also necessary. These programsshould involve both technical and communication skills.For example, your average COBOL developer will haveto acquire skills in new technologies such as WSDL ormiddleware, and she also has to learn how to collabo-rate with new team members, such as repository admin-istrators or developers of service consumers. From theperspective of the HR department, these changes wouldalso involve the definition of new role profiles, updatedincentive schemes, and so forth.

IT Processes

With the increasing progress of the legacy-to-SOA trans-formation, the IT processes have to be adapted to theneeds of SOA — particularly due to reuse, the smallersize of projects, and the role of the service contract.

While reuse is more or less an incidental event in tradi-tional IT environments, it is a key objective of SOA.


Writing software with reuse in mind is different fromwriting software for one specific use case. Writingreusable software requires, for example, broaderrequirements gathering and/or designs that takedifferent concurrent usage patterns into account.

The average size of projects also plays a major role. Inan SOA world, the average size of projects is shrinking.This has two major consequences. First, the overheadcosts for project initialization have to be reduced.Second, many design activities have to be moved fromthe projects to program management.

The third driver for change is the service contract.The service contract is a specification document thatdescribes the interface and purpose of an SOA service.In traditional projects, data models and GUI specifica-tions are often the major design artifacts that are used tomanage the implementation process. In an SOA envi-ronment, the service contract can provide a worthwhileadditional contribution, if managed properly.

So let’s consider, for example, the relation of an enter-prise customer and a provider of implementation ser-vices. Traditional work orders were often related toparticular applications that should be developed orchanged in self-contained projects. A great deal of theresponsibility for the architecture was delegated to theimplementation partner. In a service-oriented world, therelation between these partners and the processes inquestion will change significantly. This is particularly thecase because in a service-oriented world, the responsibil-ity for the high-level architecture remains with the endcustomer. As a consequence, the high-level architecturebecomes a major milestone in service-oriented projects.

Functional Architecture

Well-designed domain architectures for a large enter-prise typically comprise about 20 functional domains.Each functional domain represents a major concept ofthe business and encapsulates both functionality anddata that are related to this business concept. A domainalso provides SOA services that allow service con-sumers to access the functionality and the data of thedomain. Any executable programs, such as user inter-faces or batch programs, are separated from the SOAdomains.

Nowadays applications are fundamentally differentfrom SOA domains. A typical application is a mixture ofseveral domains, various user interfaces, and batch pro-grams. Different applications often implement function-ality and data redundantly.

The major goals of SOA are to:

Work toward the alignment of applicationsand SOA domains

Extract service functionality out of applicationsand move it to proper SOA services

Reduce redundancies and inconsistencies

Technical Architecture

Last but not least, the legacy-to-SOA roadmap has to beapplied on the level of the technical architecture. AnEnterprise Service Bus (ESB), for example, is a new typeof middleware that enables efficient communicationbetween the various communication end points withinan SOA (e.g., SOA services or business processes).

ESB product vendors typically argue that the first steptoward an SOA is the implementation of an ESB infra-structure. Once this infrastructure is in place, they say,enterprises can start implementing services on top ofit. Unfortunately, the situation is much more complex.Typically, enterprises already have several middlewareproducts in their infrastructure portfolio. Each middle-ware product is deeply integrated into the existingapplication landscape and cannot be replaced overnight.At the same time, many of these products provide theirown migration path toward ESB technology. This isone of the reasons why enterprises will have to manageESB heterogeneity in the future as they have managedtraditional middleware heterogeneity in the past. Themodernization and consolidation of the middlewareportfolio toward a standardized ESB infrastructure isconsequently an incremental, long-lasting undertakingthat must be governed properly.

All these goals cannot be achieved in an instant.Addressing the most pressing issues on each of thesix levels of the legacy-to-SOA transformation takesconsiderable time. SOA governance is needed to guidethis undertaking.

CASE STUDY: SOA IN A GLOBAL COMPANY

In 2002, a major international company in the serviceindustry launched regional SOA initiatives for severalcountries. Aiming to address the problems caused by

In an SOA world, the average size of projectsis shrinking.



its heterogeneous, nonstandardized IT landscape, thecompany tried to increase standardization substantiallyand to improve efficiency within IT.

Building on the success of the local SOA initiatives,management decided later to take the SOA approach tothe global level, aiming to address global harmonizationand integration issues. As the regional SOA initiativeshad done, the global SOA project started with the devel-opment of improvements on the technological andarchitectural levels. These included the development ofa service repository and the fully automatic configura-tion of the global runtime infrastructure by means ofmodel-driven software development.

While this new approach had many technical benefits,adoption in the different country organizations wasslow. In order to improve the adoption rate, manage-ment decided to launch a global IT architecture board,which had the task of coaching the different countryorganizations on the use of the new SOA infrastructureas well as reviewing all projects with respect to architec-tural compliance. In order to enforce the SOA conceptsmore rigorously, architectural compliance was alsoincluded as a key performance indicator (KPI) in thebalanced scorecard the company used to measure thesuccess of individual IT projects.

In parallel, management launched an enterprise archi-tecture management (EAM) initiative, which aimed tohelp increase transparency and align business and ITmore closely by defining mappings between businessand software architectures. The concept of SOA wasincluded as a key instrument for structuring the busi-ness and software domain architectures.

Finally, management reviewed the project portfoliomanagement and demand management processes.Previously, projects were seen as largely independent,which prevented the company from identifying areas ofpossible reuse between different projects. The companyleveraged the information created in the EAM initiativeto identify dependencies between different projects onthe functional and technical levels. This was done onthe level of granularity of SOA domains.

Today the company is able to identify potential syner-gies between projects in the planning phase and to reactto this information much more efficiently. For example,

it might split two planned projects into three projects,where the first project delivers reusable SOA functional-ity that is then used by the other two projects. Over thelast year, the company has improved its reuse rate in ITprojects by 120%.

CONCLUSION

SOA provides a set of very powerful tools, but it canonly be implemented efficiently if it is addressed on thetechnical level and the business and organizational lev-els. The six levels of the legacy-to-SOA transformationprovide a proven framework that guides enterprises ontheir way toward SOA adoption and helps them to takea holistic approach.

Probably the most critical element of the legacy-to-SOAtransformation is the organizational level. As Conway’sLaw dictates, organizations are constrained to producedesigns that are copies of their communication struc-tures. Consequently, the successful adoption of SOArequires would-be adopters to very carefully reviewtheir own organizations.

Since finishing his studies of business management in Cologne,Germany, Michael Kunz has worked for eight years as an architect,consultant, project manager, and general manager in the IT industry,working for both IT service providers as well as independent softwarevendors (ISVs). His main vertical focus is in the insurance industry,where he worked for several years in the life and property and casualty(P&C) areas, managing complex projects and developing modernarchitectures. Mr. Kunz has been focusing on EAM and SOAs since1997. Mr. Kunz can be reached at [email protected].

Dirk Krafzig has worked for more than 15 years as an architect, con-sultant, and manager in the IT industry, both for IT service providersand ISVs. Dr. Krafzig focuses primarily on the insurance industry,particularly the life, health, and P&C areas, where he has managedcomplex projects and developed modern architectures. Since 1996,he has focused on EAM and SOAs. Dr. Krafzig holds an MScand PhD in computer science. Dr. Krafzig can be reached [email protected].

Dirk Slama holds an MSc in computer science from TU Berlin, aswell as an MBA from IMD International in Lausanne, Switzerland.Mr. Slama has more than 12 years of international IT experience, hav-ing worked in the US, the Asia/Pacific region, and Europe. Mr. Slamahas helped customers such as Boeing, AT&T, NTT DoCoMo, andHalifax Bank of Scotland to implement large IT projects. Mr. Slamacan be reached at [email protected].

The term “SOA governance” is appealing. It seems likesomething good to have. Are you attracted by these twowords, “SOA” and “governance”? Do you think thatthey naturally fit each other nicely? Do you think thatyour company needs SOA or governance to improve?

If you feel the temptation to push forward and start anSOA governance project, I recommend you think twice.There are two main sources of any SOA governanceinitiative. Either IT pushes it because adding gover-nance to an SOA initiative makes it sound less riskyand should assure the company’s involvement, or thecompany pushes it because the SOA initiative is notwell suited to the situation, it’s risky, or it’s not totallyunderstood, and the company wants to better control it.These are just two sides of the same coin. Both are clearsymptoms that something is not going as expected. AndI would bet the initiative has not started properly.

Let me share with you some thoughts and experiencesabout how, if needed, you should handle your SOAgovernance initiative.

FACE REALITY FIRST

I have found that SOA produces mixed feelings in ITdepartments. Can you divide your personnel into SOAfanatics and SOA skeptics? Have you done it already?Have you heard the skeptical arguments properly?

Your homework starts with discussing those issueswith your team or teammates. Face them as your firstexercise. They are a source of invaluable informationthat neither vendors nor consultants can provide.

To the rest of the company, SOA still sounds like tech-nical stuff (i.e., not related to their jobs or concerns).Our gut feeling tells us that nobody in the company reallycares how we deal with technical complexity, or which threeletters we use to name our new silver bullet. It is part ofour job description. As IT professionals, we might alsobe tired of the “Three Letters Syndrome” (TLS) in the ITmarket, but SOA still seduces us in one way or another.

Sooner or later, we will start to spread the word ofthe newest panacea to our internal clients (name it the

“business side” if you feel that your IT department isoutside the business). Have you done it already? Whatreactions did you get?

THE “REAL” PROBLEM

The SOA concepts and paradigm assume some condi-tions, which I was not able to find in every organizationundertaking SOA. Before pursuing an SOA initiative,you should first check to see whether these assump-tions are valid for your company:

There are processes defined. Someone understandsthem with a global view and, ideally, owns them.

The internal client sees his processes change fasterthan IT might be able respond to them.

Internal clients dislike the current informationsystems.

Internal clients understand that there is a problemto solve.

It is a well-known fact that external customers experi-ence some unpleasantness dealing with the companydue to “disconnected” processes or systems.

Internal users have to access several applications todo their jobs.

Internal users have to access external applications(from customers, suppliers, or services companies)to do their jobs.

Future needs are not easy to predict.

I could continue listing more assumptions, but I thinkwe can agree that these describe the situation you maybe facing today. Some of the problems listed might besolved by a service-oriented architecture or other alter-natives. However, is it critical to solve them as soon aspossible? Are these problems real problems or merelysymptoms?

Face it: first, you have to understand clearly which problemsyou are facing in your daily and future business environ-ment. In terms of priorities, SOA could come in secondplace, or maybe third. It will naturally fit if it is really


Who Cares About Governance and SOA?by Jorge V.A. Ronchese

SOA MEETS TOC



needed. Instead of trying to solve every problem asseparate entities, my colleagues and I recommend usinga systemic approach or method for discovering them.The Current Reality Tree (CRT) diagram from theTheory of Constraints’ Thinking Processes (TOC TP)1

can be used to help you discover the root causes of yoursymptoms or problems by means of cause-effect-causerelationships (see Figure 1). The process of building theCRT is best done in a working meeting with the peoplewho are experiencing the problems. You have to listento them carefully when they express their claims.

Avoid the mistake of selling a solution to no one’s prob-lem. Remember the old adage: “People who buy shovelsare not interested in shovels; they want to make holes orto fill in holes as quickly and easily as possible.” Whatwould occur if you went ahead with the SOA messagewithout considering the real problems that need to be

solved? What will occur? Will your internal clientsunderstand why you are talking about it?

Eventually, the inevitable happens: someone begins tosee black holes, black boxes, security threats, and maybea new workload for her department. She faces you, oreven quarrels with you, because you are trying to changeher way of doing things without any good reason.

You are facing resistance; people are raising obstacleson your way. They can appear in the form of any com-pany process to review (and thus delay acting on) yoursuggestions. Can the company’s procedures be a realobstacle to brilliant ideas?

You can find resistance at different levels, which impliesdifferent levels of understanding about your initiative.Maybe people don’t see that there is a problem to solve,or they understand the problem but feel that this initia-tive doesn’t solve it, and so on. The Negative BranchReservation (NBR) diagram from the TOC TP can beused to help you understand how others see your solu-tion driving negative results or undesired consequences(see Figure 2). Once this relationship is clear, you canwork out ideas to solve or mitigate these consequences.

Resistance these days is hidden behind the newest holygrail, something that everybody seems to look for butnobody is able to find: governance. When someone men-tions it, suddenly any initiative is diverted onto a corpo-rate, bureaucratic path. You may feel this as a break incommunication, a misunderstanding, a conflict that putsIT and the so-called business areas on opposite sides.

The Cloud diagram from the TOC TP can be used tohelp you understand the components of the conflict(see Figure 3). Questioning the assumptions hiddenbehind the arrows will help lead you to solutions forthis conflict.

TO GOVERN OR NOT TO GOVERN?

The inherent complexity and risks of service-orientedarchitectures automatically recall to everybody the con-trol aspect of governance. This response is disappoint-ing to SOA proponents, who want their business clientsto appreciate the potential benefits of the initiative. Isthis reflexive focus on control a sign that they haven’trealized SOA is beneficial for the company?

Fortunately, good governance mechanisms and struc-tures are beneficial for IT and non-IT areas (and, ofcourse, for the company). Unfortunately, few companieshave embraced governance objectives as a whole. Most

Root

Cause

Symptom or

Undesirableeffect

Fact

Goal notreached

Goal notreached

Fact

Fact

ANDAND

AND

Symptom or

Undesirableeffect

Figure 1 — A CRT diagram can help you find root causesfrom symptoms or problems.

Idea ofsolution

(Injection)

Undesirableeffect

Negative

Consequence

Fact

AND

Fact

AND

Figure 2 — An NBR diagram can be used to clearly understandnegative consequences of an idea.

1The Theory of Constraints and the thinking processes were originated by Dr. Eliyahu Goldratt.


of them fund governance for compliance reasons; othersconfuse it with security or even auditing; and my col-leagues and I have also found some enthusiastic compa-nies that identify governance as the source of qualityrequirements. Sometimes talking about governance is adiplomatic way to analyze and uncover weak manage-ment practices within a department.

Every company redefines the meaning of governance. Ini-tially, governance addressed the steering and controlmechanisms within the company, but Sarbanes-Oxleyefforts reinforced the control view. Then, good gover-nance meant having an adequate balance of risk andvalue in any company initiative. Lately, governanceincludes decision-making and conflict-resolutionprocesses and structures.

But why do we need governance in the first place?We need it because it helps direct the company’s effortsto achieve its goals while taking risks into account.(Remember, goals are important!) Having good gover-nance means that we put in place processes and struc-tures to establish the rules, directions, and controlsneeded to execute what has been agreed upon and tojudge and resolve the conflicts that will arise. To beof any good, governance should help the company toachieve the goal of value while also caring about theassociated risks.

SOA environments introduce a whole new set of governancequestions that need to be answered. Who owns the ser-vices? How do we select services? Which services dowe publish to the external community? How should theservices be orchestrated? How do we control the serviceoperation? How do we control the service lifecycle?And so on.

Why can we not conclude that SOA governance is a verystrong value proposition? Have we clearly defined theproblem(s) that SOA governance processes will solve?

SOA needs to be identified as necessary before we openthe governance door. We want to introduce SOA gover-nance as something that is good to have, not as a meansof delaying the SOA initiative or avoiding having todeal with IT’s suggestions. We also need to separatecompanies’ IT governance processes and structuresfrom our internal IT management practices.

THE EVIL INSIDE

How can we return our focus to the business benefits ofour SOA initiatives so we can work out the objectiveswith our business peers (and then all be part of thebusiness)? Maybe we should look back and rememberthat neither SOA nor governance is a good startingpoint for business improvement initiatives or for better-ing the business-IT relationship. While SOA can have apositive business impact, it remains a technical conceptthat our business partners may have trouble grasping.

This means we need to get back to basics and figure outhow to talk in business value terms about SOA. We alsoneed to show that we welcome risk concerns. Then wecan move forward together in a joint effort to establishbetter governance of the solution. From this point on,we can be walking on the strategic alignment side of thegovernance concept and delving into the ways we candeliver real value for the company. While these are noteasy tasks for most IT departments, the Future RealityTree (FRT) from the TOC TP can be used to help youshow how your solution drives positives or desiredeffects in the company (see Figure 4).

AMinimumcommonobjective C

RequirementNecessary

condition to A

EAction to fulfill C

(Cannot coexist with D)

Hidden

Assumption

Conflict

HiddenAssumption

HiddenAssumption

BRequirementNecessary

condition to A

HiddenAssumption

HiddenAssumption

DAction to fulfill B

(Cannot coexist with D)

Idea (injection) to invalidateone of the assumptions

Figure 3 — A Cloud diagram can be used to better spot wrong assumptions and find alternatives for solving conflicts.



One step further is what I have named the Future ValueTree (FVT), which pushes the cause-effect relationshipuntil we understand which key process indicator (KPI)we are affecting with the solution or which tangiblemeasurement(s) will be improved (see Figure 5). Youcan later use this diagram to feed your business case.

If SOA is good, we should be able to realize it. For thatpurpose, we need the non-IT areas to assume their rolesand responsibilities. How do we do this?

The Prerequisite Tree (PrT) from the TOC TP can beused to help you involve everyone who should dosomething to implement the solution. The process ofbuilding the PrT should be done in a working meetingwith all of needed participants (see Figure 6).

All this being said, we should realize that we are ourown major obstacle to doing the right things. Our wayof thinking and communicating our ideas or solutions isthe biggest impediment to implementing them whileinvolving others. As I have pointed out, we in IT oftenunderestimate the real critical problems of our companyby not facing them properly — that is, together with thebusiness areas. Consequently, we are not able to posi-tively overcome the resistance we encounter.

As shown in Figures 1-6, the use of TOC tools andprocesses can help business and IT tackle business prob-lems in a systematic way, better define the solution soas to avoid any negative effects, and find an effectivepath to make it happen. The detailed explanation ofeach TOC thinking process is outside the scope of thisarticle, but you can find a rich explanation in [1].

RESISTANCE IS GOOD

Resistance to change has a meaning, and you have todiscover it in order to produce effective and lastingresults. Facing resistance is good, because it gives usthe opportunity to better define our problems and findmore effective solutions.

The Theory of Constraints identifies six layers of resis-tance to change. Each one of them reflects the stage ofunderstanding and involvement your peer or client has.Each layer comes with a thinking process to overcomethe resistance in a proper manner, one that moves youcloser to a change with a positive impact on the goals ofyour company. You will have to learn to walk througheach one of the layers, as any shortcuts will put yourfuture project at risk.

Each of these layers is related to the following threemajor questions:

Idea of solution(Injection)

desirableeffect

Fact

desirableeffect

Objective Objective

Fact

Fact

Figure 4 — An FRT diagram can be used to better show thedesirable effects that will result if the solution is implemented.

Idea of solution(Injection)

desirable effect

Fact

desirable effect

Objective Objective

Fact

Fact

TangibleBenefit

TangibleBenefit

Business GoalReached

Figure 5 — The FVT shows the expected business outcome if the solution is implemented.

Intermediate Objective(once reached overcomes

the obstacle)

IntermediateObjective




Obstacle

ObstacleObstacle Obstacle

Objective(Idea or

Injection)

Obstacle Obstacle

Figure 6 — A PrT diagram can help you develop an agreed-uponproject strategy for realizing the solution.


1. WHAT to change?

2. TO WHAT to change?

3. HOW to cause the change?

The easiest way to determine what layer you are stuck inis to identify the concerns and questions of each one.

Layer 1: WHAT to Change?

Facing Layer 1 resistance, you will find disagreementabout the problem. Conversations will include expres-sions like “What is this for?”; “Why should we botherabout this?”; and “We cannot do anything.” At thislayer, forget about business benefits or features andfunctions. You need to reach an agreement on what theactual problem is.

Layer 2: From “WHAT to Change?” to “TO WHAT to Change?”

Facing Layer 2 resistance, you will find disagreementabout the initial conceptual idea of the solution. Youwill hear expressions like “Why do you say this willhelp?”; “How this can help us?”; or even “Is this thenewest IT trend we must follow?” (At least you haveagreement on the problem, don’t you?)

Layer 3: TO WHAT to Change?

Facing Layer 3 resistance, you will find reservationsabout the results to be obtained because of the solutionfound. You will know you are at this layer when youhear things like “Will it really impact our numbers (orgoal)?” or “Maybe it will never work, just like the lasttechnology migration.” You will have to find a way torelate the solution to the future reality you predicted(“desirable effects” in terms of TOC).

Layer 4: TO WHAT to Change? (Part II)

Facing Layer 4 resistance, you will find constructivecriticism. Don’t give up! It should be constructive,after all. People at this layer are worried about negativeside effects. This is their way of expressing risks (“unde-sirable effects” in terms of TOC). When evaluating thechances of the solution, they might say, “Yes, but …”or “Company X has thrown a humongous amount ofmoney at the solution to make it work.” You will needto work out the “but …” part in order to overcome thislayer of resistance and complete your solution.

Layer 5: From “TO WHAT to Change?” to “HOW to Cause the Change?”

Facing Layer 5 resistance, you will hear people tellyou why the solution will never be achieved in your

environment. Don’t panic. This information is very use-ful. You need to involve everybody to find the obstacles(which is the proper TOC term). Two heads think betterthan one. Welcome obstacles and involve people to helpyou overcome them.

Layer 6: HOW to Cause the Change?

When exhibiting Layer 6 resistance, people will finddifficulties in collaborating with others to get the jobdone. This means that it is not clear yet how everybodyshould act and what tasks should be done by whomand why.

Each of the TOC TP tools mentioned above is meant tobe used at a particular layer of resistance (see Table 1).

Of course, there are some assumptions used by themethod, too:

Your company or business area has a clear goal.

You will involve other people in the improvementprocess, working together as a team through eachlayer of resistance to change.

You are an open-minded person, able to find rootcause problems and work out solutions that may bedifferent from your initial ideas.

RESPONSIBILITY MATTERS

Chances are the problems your company is facing canbe solved via a service-oriented architecture, and thatto make it a good solution, some minimal governancerequirements must be fulfilled. However, followingthe method outlined above is not a way to “overcomeresistance to a SOA governance project.” Rather, it is a

TOC TP Tool Layer of Resistance

Current Reality Tree(CRT)

Layer 1: You work to understand the root problem.

(Evaporating) Cloud Layer 2: You work to find a real solution.

Future Reality Tree(FRT)

Layer 3: The solution produces the desired effects.

Negative Branch Reservation (NBR)

Layer 4: The refined solution blocks or mitigates undesirable effects.

Prerequisite Tree(PrT)

Layer 5: The strategic plan helps overcome the obstacles.

Transition Tree Layer 6: Procedures are devised to clearly involve others.

Table 1 — Relationship Between TOC TP Tools and Layers of Resistance



method for understanding real obstacles to achievingyour company goals, finding good enough solutions(value), developing a plan everybody is committed toexecuting, and arriving at a clear understanding of howeverybody fits together and what has to be done inorder to make the solution happen.

Although risk and value are two sides of the same coin,the value side gives us the chance to exploit business-oriented SOA alternatives, innovate, and really nailproblems with solutions that everybody cares about.When business cares about it, we can then fill the gov-ernance holes with responsibility. As Cutter SeniorConsultant Christopher Avery says, “Taking responsi-bility is the first step in leading others and solvingproblems.” When most of us act responsibly, then ourprocesses will be effective, and good governance cantruly help us to achieve the goals of the company.

CLOSING REMARKS

If nobody cares about SOA governance within yourcompany, it could be because SOA is still perceivedas an IT issue. In this context, SOA governance means“managing the development and infrastructure proc-esses related to SOA” — which does make it soundsolely like an IT issue. Show them why it is a companyissue using business terms, not technical jargon.

If you are trying to involve people to better achieve anSOA initiative and they claim they need governanceprocesses (the ones that may not be in place), then youare facing resistance. A good understanding of the resis-tance you face is a means of improving solutions andprocesses, but it may require you to develop some newskills and be open-minded. Use the TOC TP tools to faceeach resistance level, improve the processes and solu-tions, and induce responsible behavior. Use them withinyour governance process to establish a better decision-making process.

SOA governance is important if it solves some of theproblems or constraints that are preventing your com-pany from reaching its goals. Do you have them clearlyidentified?

REFERENCE

1. Scheinkopf, Lisa J. Thinking for a Change: Putting the TOCThinking Processes to Use. The St. Lucie Press/APICS Series onConstraints Management. CRC, 1999.

ADDITIONAL SOURCES

Avery, Christopher. “Responsible Change.” Cutter ConsortiumAgile Project Management Executive Report, Vol. 6, No. 10,October 2005.

Avery, Christopher. “Responsibility Redefined: IT Leadership.”Cutter Consortium Agile Project Management Webinar, 18August 2005.

Debernardo, Héctor, and Margarita Hurtado Hernandez. El Puente. Ediciones Granica, 2006.

Goldratt, Elihayu M. It’s Not Luck. North River Press, 1994.

Goldratt, Elihayu M. Theory of Constraints. North River Press,1990.

Hazra, Tushar K. “Employing Sourcing Through an SOAModel: Utilizing Pragmatic IT Governance for Improvements.”Cutter Consortium Sourcing & Vendor Relationships ExecutiveUpdate, Vol. 7, No. 9, September 2006.

IT Governance Institute (ITGI). COBIT 4.1 (www.isaca.org/cobit).

Jensen, Bill. Simplicity: The New Competitive Advantage in a Worldof More, Better, Faster. Perseus Books Group, 2001.

Rosen, Mike. “Theory and Practice of SOA.” Cutter ConsortiumEnterprise Architecture E-Mail Advisor, 31 May 2006.

Weill, Peter, and Jeanne W. Ross. IT Governance: How TopPerformers Manage IT Decision Rights for Superior Results. HarvardBusiness School Press, 2004.

Jorge V.A. Ronchese is a Senior Consultant with Cutter Consortium’sBusiness-IT Strategies and Enterprise Architecture practices. He isalso CEO of Suivant, an Argentina-based business-IT consultingfirm, where he focuses on innovative ways to help IT departmentsin their improvement efforts and to solve complex business issueswith adequate technology. He is an international speaker and well-known consultant throughout South America in such subjects ascontinuous improvement processes, IT governance, enterprise archi-tecture, ITIL, and the Theory of Constraints as applied to the IT area.Mr. Ronchese’s wide view of IT management has inspired the SuivantUnified Model (SUM), which focuses on the evolution of IT manage-ment and related best practices. He has developed the Future ValueTree (FVT) thinking tool, which is a simple graphical method thatenables organizations to make tangible the value of projects and sus-tain successful business cases. He has served as VP of HSO BusinessSystems for Latin America; Pre-Sales Manager for South America ofAriba, Inc.; and Regional Manager of MRO Software, Inc.

Mr. Ronchese has a degree in systems information engineering fromthe Universidad Tecnológica Nacional of Rosario, Argentina, wherehe was also a professor. He has undertaken postgraduate studies inEU laws, politics, and economy (University of Padova, Italy); IT man-agement (University of Belgrano, Argentina); and business manage-ment (University of Bologna, Italy). Mr. Ronchese can be reached [email protected].

Kaname is a Japanese term meaning “essence.” In aJapanese fan, the bottom piece that keeps the fantogether is the kaname. The kaname of a business iswhat keeps it all together, what defines it, its essence.The kaname of a business must be identified so that allactivities influencing the kaname can be identified andimproved. This decomposition into individual activi-ties, into “business services,” is the first step in realizingthe benefits of a service-oriented architecture (SOA).

The promise of an SOA is a modularized system thatcan flexibly address changes, enhance business perfor-mance, and enable business agility in an increasinglycompetitive corporate climate. But determining whichbusiness services need to be created, how they shouldfunction, and how the hundreds or thousands of indi-vidual services should be managed can be a dauntingtask. Do all the services actually work together to sup-port the essence of the business?

And once the business services are created, furthercomplications arise. Which businesses are using whatservices, and which services are available to them? Arethe right people accessing the right services? Are thererules for changing, validating, and approving services?If a service is changed, who and which other serviceswill be affected? How can things be fixed if somethinggoes wrong? Are the service levels meeting the qualityof service (QoS) requirements?

Answering these questions requires adequate gover-nance. Governance is about visibility and accountabilityand involves the processes and policies of both businessand IT. In an SOA, governance becomes even moreimportant, as reusable, autonomous components arecreated to consume or be consumed by other reusable,autonomous components, potentially from other ven-dors. Issues such as security, reliability, and availabilityare also important as mission-critical applications andbusiness processes are being developed using SOA.

Determining the kaname of a business and putting inplace adequate SOA governance requires not only tech-nology, but also a shift in the way business and IT work

together. Companies need to adopt clearly defined roleswithin their organizations, allowing the stakeholders tounderstand each other’s goals and tasks. Only then canthey understand the essence of the business and putthe proper governance mechanisms in place for optimalSOA performance. Without the support and participa-tion of IT architects, managers, and development teams,an SOA initiative is likely to fail. By working together,however, this cross-functional group can develop asound strategy, best practices, and a methodology thatcan help design a flexible SOA to address change andoptimize reuse.

DETERMINING KANAME

The first step to creating an SOA is to understand theessence of the business so that a clear vision of whatthe SOA will be and what value it will provide can beestablished. Too often, companies rush to implementan SOA without clearly identifying the business valueor the ideal end state. Once expectations are misaligned,the success of the overall SOA implementation isjeopardized.

To reach this clear vision and build the many servicesthat support this vision, companies need to understandboth the human aspects of an SOA transformation andthe lifecycle management of the services. This can bedone by establishing a roadmap for processes andpolicies and by clearly defining the stakeholders andrequired architectural standards. To do this, many orga-nizations create a center of excellence or similar cross-functional group to provide resources and guidance, toserve as a repository for best-practice information, and tooperate tools that support the SOA governance process.The main function of such a group is to share thoughts,experiences, and knowledge. By improving the way theyrelate to each other and communicate, group membersare more likely to succeed in understanding the kaname,attaining the right vision for the SOA, and establishingadequate governance to ensure success.


The Key to SOA Governance:Understanding the Essence of Businessby Keith Swenson

THE NAME OF THE GAME: KANAME



A recent article in Bank Systems & Technology describesBank of America’s approach to governance and quotesBill Conroy, the bank’s enterprise architecture seniorbusiness executive:

Bank of America delegated governance for SOA to thefour CIOs within the organization, the bank’s Conroysays. An architecture council, which Conroy chairs, madeup of the CIOs controls new technology and new prod-ucts. “We’re very controlled on the products we let in —we let in on a very specific business case,” he relates,adding that new technology has to pass a litmus test: Ithas to drive a significant amount of revenue, reduce a sig-nificant amount of risk or clean up the environment. Nonew technology can be purchased throughout the bank ifthe council has not approved it, Conroy stresses. [1]

Companies need to build an architecture roadmapwith SOA governance woven into the fabric of dailyoperations, using both a top-down business approachfor understanding business goals and a bottom-up ITapproach for building individual services (see Figure 1).This requires new organizational models for bridgingthe gap between business and IT; it also means beingable to visualize the fundamental structure and behaviorof the business to understand what changes occur,quickly identify the changes, and just as quickly adaptthe system to the changes.

At this stage, management support is most crucial,since management drives IT strategy. Therefore, a clearbusiness and financial case that accurately maps to thereality of the business is essential. To achieve this, thestakeholders must:

Reach a consensus on the essence of the business

Visualize and model the business using processsimulation to estimate efficiencies

Construct the system so it closely reflects the businessmodel in an architecture that is responsive to changes

VISUALIZING THE ESSENCE

The essence of a business can be identified only througha common understanding of the business objectives(increasing revenue, complying with regulations, con-tending with globalization, promoting corporate andsocial responsibility, etc.) and the related IT systems(see Figure 2).

A primary goal at this stage is to understand how peo-ple work, who owns what responsibilities, and whichinterdependencies link business processes and ITresources. The goal is for business people to discuss andagree on the business elements of an application and forthe IT people to discuss and agree on how to managethe technological underpinnings. The outcome of suchdiscussions should form the roadmap for the SOA solu-tion. The value of this approach is that it doesn’t startout focused on IT and the integration of systems, butinstead focuses on understanding what the business isor wants to be — in other words, the kaname.

BUILDING UPON THE VISION

Once an architecture roadmap of the solution is agreedupon, processes and services that align to the businesscan be built out. This includes not only processes thatgovern how systems interact, but also processes that

Management/Business

Business

IT System

[Key Activity]

Consulting

Business Process Modeling

Business Data Modeling

Service Architecture Modeling

Planning

BusinessImprovement

Modeling

IT ImprovementModeling

DesignConstruction

Operation

Figure 1 — Business goals drive IT models.


govern and reflect how people work — the human-centric business processes. A process-driven approachuses modeling tools targeted at the business analyst,tools such as Visio and IDS Scheer’s Business Architect,or business process modeling (BPM) vendor-specificdesign environments that not only include a BPMnotation–based modeling tool, but also:

Execution of the model

Process performance monitoring and analysis ofthe actual running business process or a simulatedbusiness process

Optimization for interactive process improvements

These tools enable the business to define the human fac-tors involved in a business process, and these activitiescan then be decomposed into reusable, autonomous ser-vices that can be orchestrated and delivered back to themodeling tool.

The actual integration hooks can be created using theBusiness Process Execution Language (BPEL) for serviceorchestration or an Enterprise Service Bus (ESB) formediation. For example, consider an online store thatuses a credit card company, a shipping company, andvarious suppliers of the goods sold. The basic businessprocess of selling goods, getting paid for them, andshipping them may be fairly straightforward. But thedetails — which companies to deal with, what dataformats they use, and the precise Web address at whichthey can be reached — are very likely to change onshort notice. An IT professional can augment the busi-ness process with execution details using an ESB so

that these differences can be resolved as they becomeapparent, without any Java programming or evenrecompilation and library deployment.

The challenge is for business people to transform theirvision into processes that can be easily deployed by ITwhile leveraging their existing systems and infrastruc-ture without significant rework. A combination of BPMand an ESB does just that. BPM promotes a model thatensures business analysts can define processes in busi-ness terms, resulting in processes that nontechnicalusers can own and manage throughout the processlifecycle. This saves time and minimizes rework.

SOA: READY FOR PRIMETIME?

An SOA supports reusable services that perform busi-ness functions and provide an excellent foundation forimplementing process-driven integration scenariosthat solve complex business process management andorchestration problems. Just as business processes canleverage the services within the enterprise, these samebusiness processes can also be exposed as services tobe consumed within applications. The end result is thatBPM becomes part of the SOA fabric, in which the busi-ness processes are viewed as nothing more than a newkind of service. These reusable services may reflect busi-ness tasks, such as opening a checking account, verifyinga credit card transaction, or processing a purchase order.

Let’s take a simple example. Say you are a providerof a leading business rules management system(BRMS) in which complex rules make risk assessment

Revenue Goal(Profits)

SocialResponsibility

Regulatory/Compliance Globalization

Sales

Logistics

Development

Procurement

Manufacturing

Laboratories

Facilities

Services

Management

IT Systems

BusinessAgility

BusinessContinuity

BusinessEfficiency

Figure 2 — IT resources provide value by linking the various departments in an organization.



decisions. In order for an application or BPM product touse an existing complex rule, it needs to be publishedor cataloged so it can be discovered by rule name,description, availability, cost, or other attributes. In theold days, this kind of functionality was buried in legacycode. Any change to the rules was delayed by lengthyIT development cycles. The SOA development approachfocuses on leveraging the investments that organiza-tions have already made in technology by providing thetools required to expose both business logic and data inexisting or new systems in a standardized way. A ser-vice, such as “risk rating,” takes into considerationmany complex business rules to generate an individ-ual’s risk rating. (For example, if someone has poorcredit, has a payment history [days outstanding] ofgreater than three months, and has defaulted on a num-ber of loans, then his or her risk rating will be high.)When someone applies for a loan, the loan approvalbusiness process could make a risk rating servicerequest on demand.

Most important, if these complex rules need to change,the BRMS can manage the business rules independentof the business process or application, allowing policymanagers to make changes to the rules without heavyIT involvement. As for the business process, it doesn’tneed to know about the change if it doesn’t affect theagreed-upon service.

Leading BPM vendors have already recognized the needto expose their functionality as services for reuse. Bystructuring applications in this manner, IT assets becomemore agile, and organizations are better able to aligntheir investments in dynamic business environments.A business analyst, integration expert, or developercan then use the BPM tool to snap together businessprocesses exposed as services to create new businessprocesses, thus reusing existing investments to createnew value across the enterprise.

THE NEED FOR GOVERNANCE

As BPM and SOA provide a way to respond quickly tochanging business requirements, businesses need toquickly discover, manage, monitor, and analyze the useof SOA artifacts through a centralized SOA registry/repository. Such a repository provides a control pointfor governing service availability, versioning, and com-pliance with internal and external systems.

Take, for example, the business process just described.An existing asset is consumed, but that existing assethappens to be a business rule from a different systemthat is exposed as a service. What if this service utilizedanother business process and so on and so on? Youwould find the relationships shown in Figure 3.

Now imagine you have hundreds of services callingother services that might be legacy code, business rules,ESB sequences, or others. How do you know what isactually happening at runtime; who is actually using theservice; and what security enforcement, performanceenforcement, and availability enforcement need to bein place? You could easily end up with the situationshown in Figure 4.

An SOA repository provides a mechanism for keepingtrack of an organization’s SOA assets, including all thedependencies and relationships. Services can be pub-lished into the repository, listing them according tocategories that make sense to the organization, andthey can then be discovered via a search mechanism.Services are associated with other artifacts that aredescribed through dependency relationships andgrouped through an extensible taxonomy. Good gover-nance reduces the risk of mismatched services andredundant development efforts (see Figure 5).

As more and more demands begin to build, so willthe importance of SOA management and governance,especially when multiple providers of services makechanges. SOA repositories should allow users to sub-scribe to any SOA artifact and be notified via calloutsor e-mail of any changes to that artifact.

In addition to cataloging services to enable reuse, anSOA repository also, through corporate design stan-dards, encourages the use of common guidelines soservice development remains consistent among differ-ent architecture groups within an organization. For

Uses Uses Bank LoanBusiness Process

Risk RatingBusiness Rule

Credit CheckBusiness Process

Figure 3 — A service usage graph.

Good governance reduces the risk ofmismatched services and redundantdevelopment efforts.


example, consistency can be maintained throughout aservice lifecycle, from conception through production,by implementing appropriate approvals and attachingappropriate documentation, specs, and test plans ateach phase. Businesses should be able to configure thelifecycle of not only services, but also business rules,business processes, and basically any SOA assetthrough a set of lifecycle stages and states. The autho-rization and approvals required as a service movesthrough the different stages and states also need toinclude roles and privileges.

The SOA repository provides storage for metadata forservices and any other artifacts related to an SOA asset,including WSDLs, XML schemas, XSLT stylesheets,policies, and so on.

Once the services are invoked, organizations need tokeep track of how they are being used. Real-time track-ing of services includes monitoring of performance,availability, usage, and more, so that alerts and adjust-ments can be made. Governance becomes important toensure that a service is functioning according to defined

Rules

EnforcementValidate

New ArtifactUnderstand

Impact of Change

Approval

Alter

Verify Credentials

Change

Test/Review

Update

Enhance

Add New Service

Approval Development

Approval Business Analyst

Approval Service Librarian

Notify Subscribers

Publish

Figure 5 — The governance process is key to ensuring that only high-quality services are listed in the repository.

Some questions in an active SOA:• Which services are available?• Are all required services up and running?• Are the right consumers accessing the right services?• Are there rules to change/validate/approve services?• If a service is changed, who and which other services will be affected?• How can things be fixed when something goes wrong?• Is the required quality of service (QoS) provided?

Governance of SOA is key!

Figure 4 — A service orchestration diagram.



service levels. If not, a notification occurs to change theway the service runs. Services should be associatedwith service-level agreements that define the requiredperformance characteristics of the services and spell outpenalties for failures.

Services also require security levels to control who canuse which service for what purpose. This involvesdefining and verifying users who are authorized to usecertain services. For example, a company might definea class of users who can transfer more than $1 millionacross various accounts. Also, the privacy of sensitivedata must be protected to meet internal and externalcompliance regulations and standards that requirea complete audit trail. For example, the US HealthInsurance Portability and Accountability Act (HIPAA)requires all transactions to be SSL-encrypted.

While establishing adequate governance is not trivial,the tools do exist to provide the operational-level visibil-ity needed to make solid governance possible. The SOAdevelopment team must ensure these tools are in place.

Operational-level visibility is also important to under-standing how to manage the services at the businesslevel. For example, should a gold-level customer havepriority over other customers for certain transactions?Should there be two levels of service offered at basicand premium prices?

Because an SOA repository maintains the dependencyrelationships of services and associates all services withtheir artifacts, such as policies, it provides a level ofvisibility that enables organizations to adapt quickly to

change while minimizing risks. This results in greaterbusiness agility and cost effectiveness.

IT ALL BEGINS WITH KANAME

While SOA governance requires an investment in peo-ple and technology to establish the appropriate contextfor an SOA, the benefits of this investment are tremen-dous. The true benefits of an SOA are achieved whentop-down business goals meet bottom-up IT develop-ment, with an SOA governance and management solu-tion, such as an SOA repository, that seamlessly joinsthe two. The goal of any SOA initiative is to improvecommunication, processes, and efficiency within anenterprise to deliver superior products and services atlower costs. But the start of any SOA initiative shouldbe better collaboration and communication betweenbusiness and IT on objectives, processes, implementa-tion plans, and optimization. Only then can the kanameof a business be understood. And only when thekaname is understood can an organization developa consistent vision and methodology throughout theprocess and ensure that the services composing theSOA will optimally support the business.

REFERENCE

1. Feig, Nancy A. “New Foundation: SOA Implementation andBank Transformation.” Bank Systems & Technology, 30 March2007 (www.banktech.com/news/showArticle.jhtml?articleID=198700451&pgno=4).

Keith Swenson is VP of Research and Development in FujitsuComputer Systems Corporation’s Enterprise Software and SolutionsGroup. He is known for having been a pioneer in Web services, andhe has helped the development of standards such as WfMC Interface 2,OMG Workflow Interface, SWAP, Wf-XML, AWSP, and WSCI.He is currently working on standards such as XPDL and ASAPand is the chairman of the Technical Committee of the WorkflowManagement Coalition. Mr. Swenson can be reached at FujitsuComputer Systems Corporation, 1250 E. Arques Ave., Sunnyvale,CA 94085, USA; Tel: +1 800 831 3183; E-mail: [email protected].

The true benefits of an SOA are achievedwhen top-down business goals meet bottom-up IT development, with an SOAgovernance and management solutionthat seamlessly joins the two.


FULL SERVICE

A plethora of publications today emphasize the signifi-cance of business drivers in adopting service-orientedarchitecture (SOA). It is also evident that embracingSOA requires significant (if not equal) investments oftime and energy on the part of decision-making busi-ness leaders and IT practitioners. Hence, practitionersneed a mechanism (aka governance) to consistentlyorchestrate and execute the activities that can helpthem manage, monitor, and maintain SOA initiatives,while aligning their business goals with IT servicesand solutions. This mechanism consists of two primaryelements: a methodology defined by the business andIT leaders and a process that can be automated toemploy the mechanism in practice.

The first part of this mechanism is usually substantiatedby a set of procedures, policies, industry standards, andbest practices. For the second part of this mechanism,many leading software vendors today either directlyor indirectly support SOA governance with their tools.I strongly believe, however, that SOA governance can-not be achieved by simply using commercial tools. Ithink it is important to revisit the basics of IT gover-nance already in place for many midsized and largecompanies. In my opinion, IT governance provides thefoundation for enterprise architecture (EA) and SOAgovernance. I submit that it is essential for us to recog-nize: (1) the uniqueness of the mechanism, (2) majorcomplexities and challenges involved in using themechanism, and (3) the processes practitioners plan touse in order to leverage the mechanism, before gettingstarted with SOA governance. Most available tools canthen enable practitioners to expedite the performanceof their governance activities.

ORGANIZATION

Over the past five years, I have assisted many practi-tioners from a number of midsized and large companiesand US government agencies in establishing their SOAgovernance. During this period, I have witnessed fewdistinct situations in which visionary leaders opted for

a “strictly” consensus-driven approach to defining orformalizing their SOA governance. In most other cases,it was not so much about formalizing the SOA gover-nance as recognizing the practical challenges associatedwith it — and then making decisions to transform theorganization’s existing governance principles to accom-modate SOA. In this article, I will draw upon my ownexperiences to address five questions related to SOAgovernance:

1. What is unique about SOA governance?

2. What must be done to transform corporate IT gov-ernance in order to deal with SOA governance?

3. How does SOA governance handle most changesinvolved with business (in practice)?

4. What are some of the policies, principles, and bestpractices known today for SOA governance?

5. What do most available tools offer that can expeditethis governance?

WHAT MAKES SOA GOVERNANCE UNIQUE?

In order for us to obtain a clear, consistent, and yetpragmatic perspective on SOA governance, I feel com-pelled to review some terms (see Table 1). While it maybe difficult to acquire a consensus amongst practition-ers about these definitions, at least they provide a base-line for discussion.

I have observed from experience that SOA governancecan coexist with corporate, IT, and EA forms of gover-nance. In some cases, it has grown organically from ITand EA governance. In many cases, companies havetheir SOA governance interact with existing EA gover-nance and support overall IT governance.

Figure 1 presents a simplified, high-level view ofthe connection SOA governance has with EA, IT, andcorporate governance. As SOA is more of a business-driven approach, it has direct responsibilities to recog-nize the business strategies, values, and goals of an

SOA Governance: Building on the Old, Embracing the Newby Tushar K. Hazra



Table 1 — Governance-Related Terms

Governance The word “governance” is often used synonymously with “government.” Therefore, fundamentally it is more of a political concept than a technical or business-oriented one. Many dictionaries define governance as an exercise of authority or control — a method or system of government. Some definitions emphasize the people and process aspects, too.

Corporate Governance

Wikipedia defines corporate governance as a set of processes, customs, policies, laws, and institutions affecting the way a corporation is directed, administered, or controlled. Corporate governance typically includes the relationships between and among various stakeholders and the goals for which the corporation is governed. The principal stakeholders are the share-holders, senior management, and the board of directors. Other stakeholders may include employees, suppliers, customers, banks and other lenders, regulators, the environment, and the community at large.

IT Governance Wikipedia defines IT governance as a subset discipline of corporate governance. IT governance focuses on information technology assets and systems and deals with their performance and risk management issues, as well as compliance with various government regulations and industry mandates. In their famous book IT Governance, Peter Weill and Jeanne W. Ross define IT governance as “specifying the decision rights and accountability framework to encourage desirable behavior in using IT” [2].

EA Governance For most midsized and large companies, EA governance builds upon the corporate and organizational culture in delivering corporate business value. In general, EA governance primarily presents new or future technology blueprints and enterprise-wide reusable standards and develops EA compliance policies and procedures. EA governance helps in the review of service-level and contractual agreements with vendors and IT partners and recommends capital investments for IT to the company’s senior leadership.

SOA Governance According to Wikipedia, SOA governance is an emerging discipline that enables organizations to guide and control their SOA initiatives and programs. I suggest that SOA governance provides a key element for the success of any SOA initiative. It governs the interaction between business and IT teams (as well as between two or more IT teams) as they incorporate distinct policies, procedures, and best practices that are applicable to services throughout the entire SOA initiative lifecycle.

CorporateBusiness Value

OtherStakeholders

CorporateGovernance

PrincipalStakeholders

ITIT

GovernanceBusiness

EAGovernance

SOAGovernance

delivers

participates

participatesparticipates

influences

follows

serves

interacts

engages

Figure 1 — A simplified view of various governance structures.


enterprise. So what really makes SOA governanceunique? From a business perspective, SOA governanceemphasizes guidance and control of the pay-per-useconcept of invoking a service, while formalizing thepolicies and procedures that enable service consumersand providers to connect with each other and conductbusiness using a set of standardized principles. Anotheraspect of this pay-per-use concept relates to discovering,identifying, and procuring a suitable service, and thensubsequently determining if the service provider is reli-able enough to be trusted for use.

Once a service is procured, other issues such as version-ing, upgrading, or retiring a service must be addressedas well. When dealing with internal service providers,this part of formalizing the contract or service-levelagreement (SLA) could be relatively simple. With exter-nal service providers, the contract may not be so easyto formulate. From a technical perspective, SOA gov-ernance focuses on the service design, development,and deployment aspects of SOA. It also relates to for-malizing the coupling and interfaces between services.Therefore, SOA governance is unique in the way it con-centrates on the impacts of distributed services acrossmultiple (or a single) business organization(s) basedon specified SLAs.

First off, SOA governance provides transparency in theusage of a service. This means a service consumer cansearch for, discover, and locate a desired service andobtain consistent service (response) from any specificservice provider. Second, SOA governance offers thebusiness flexibility in choosing a service from a multi-tude of services catered to meet the same businessrequirements with the desired quality of service (QoS).And finally, SOA governance offers a mechanism tohelp practitioners carry out three major activitiesthroughout an SOA initiative lifecycle (“lifecycle” hereincludes design as well as runtime use of SOA):

Providing oversight of associates or employeesinvolved in business and IT alignment efforts

Maintaining continuity of business operations and/or supporting disaster recovery projects for the entireorganization

Reducing the associated cost of operations whileexisting infrastructure is transformed to support SOA

After looking at both business and technical perspec-tives, I submit that SOA governance is really uniquebecause of its theme — service, and more specificallybusiness service. For SOA governance, a business ser-vice must be the “unit of work.” And SOA governance

will be unique only if the practitioners can harness thepower of existing kinds of governance while reusingbusiness services across the business organizations,and, subsequently, across the enterprise.

CONNECTIONS WITH EXISTING FORMS OF GOVERNANCE

In their famous book IT Governance, Peter Weill andJeanne W. Ross define IT governance as “specifyingthe decision rights and accountability framework toencourage desirable behavior in using IT” [2]. Accord-ing to the authors, use of IT encompasses achievingcorporate performance goals. I interpret the conceptof desirable behavior in terms of people and how thedelivery of business value is promised, proposed, andthen delivered by IT. I visualize the decision rights andaccountability framework as a part of the process andmethodology instilled in the enterprise by the gover-nance body. Finally, I find that available tools and tech-niques can facilitate delivering this desirable behavior.

In a recent Cutter Consortium Executive Report, Idiscussed EA governance in terms of its significancefor people, process, and technology [1]. Practitioners useEA governance to go beyond their strategic principles(i.e., “doing the right things”) to actually deliveringeffective solutions (i.e.,“doing things right”) for theirbusiness operations. The EA governance board (anorganizational structure with members from variousbusiness and IT organizations, and the senior leadershipteam) usually formalizes a charter that includes a setof EA principles, frameworks, reference models, andstandards. The EA governance mechanism can offerthe appropriate practitioners a means of monitoring thecompliance of a specific organization with these prin-ciples, frameworks, reference models, and standards.Furthermore, the metrics associated with EA gover-nance can be directed toward influencing enterpriseapplication projects to follow the established principleswhile delivering efficient business solutions.

In working with IT and EA governance teams, I observethat SOA governance has multiple links to the existingforms of governance:

IT governance focuses on utilizing IT assets todeliver business value. Subsequently, EA gov-ernance has gotten more specific about utilizingstandards, best practices, and IT policies to deliverenterprise-wide business value. SOA governance isa natural extension of and progression from both ITand EA governance. It delivers business value byfocusing on business services.



For most companies, IT governance is heavilyinfluenced by the business organizations. To besuccessful, EA governance also engages businessorganizations from the early stages of its lifecycle. Ofcourse, SOA is a business-driven initiative to beginwith, so it is not necessary for practitioners to makeSOA governance a brand-new affair. Nevertheless,SOA governance must have more business influenceand ownership than IT governance.

IT and EA governance mechanisms have evolvedover the past few years. In comparison, SOA gov-ernance is a relatively new concept. Therefore,practitioners can leverage their experience withexisting governance concepts to build effective SOAgovernance.

Without a doubt, SOA harnesses a new “service-centric” mindset. However, the need for IT and EAgovernance structures is not going away anytimesoon. Unless and until all the business functions in anenterprise can be delivered as services (which is veryunlikely), there will be other IT assets that must begoverned using IT and EA governance policies.

In the final analysis, SOA governance will always belinked with IT and EA governance principles, policies,and best practices — if not with their organizationalstructures. And in most companies where stable IT andEA governance practices already exist, practitioners willbenefit from their prior experience with these existingtypes of governance. Over a period of time, practition-ers can transition their current governance principles tocreate an SOA governance mechanism.

FROM THE TRENCHES

As I’ve mentioned, SOA is a business notion to beginwith. Over the past few years, most corporate envi-ronments have been undergoing progressive change.Greater competition, faster and more effective interac-tions with customers, and stricter government regula-tions and industry mandates are among the factors thatare driving the change. Most companies try to copewith these challenges by becoming more responsive,innovative, and agile, and service orientation is the lat-est means for doing so. The SOA approach offers seam-less integration (and interaction) of business services inorder to deliver the desired flexibility to the enterprise.Therefore, it is imperative that the inception of SOAgovernance be business-driven, its vision be business-focused, and its mission be business-oriented.

For most companies, service orientation starts withidentifying candidate business functions that can betransformed into business services. Once transformed,these business services can deliver more efficient andeffective results. The key impetus for creating theseservices is that they can be reused and shared acrossmultiple organizations.

As a number of services are created, the need arises toorganize and manage these services using a registry orrepository. Most companies establish SOA governanceto define a mechanism that helps practitioners governthese services. However, it is worth mentioning thatthe reusability and sharing of services require a changein organizational mindset. This mindset is businessservice–centric and not technology-driven. As a result,one of the primary responsibilities of SOA governancein practice is directed toward formalizing policies thatdeal with the existing or new organizational culture toembrace the concept of business services. The next setof responsibilities for SOA governance involves creatingpolicies and principles for service design. Once the ser-vices are designed and developed, they can be deployedin any SOA environment — whether it be heteroge-neous, distributed, or federated. The SOA governancepolicies must account for the deployment. Finally, SOAgovernance must address the challenges of employingservices in business operations and necessary business-IT alignments.

During the past few years, while working with otherpractitioners in the field, I have cultivated a very simplemodel for SOA governance (see Figure 2). As shown,once the SOA governance policies, principles, andguidelines are created, they are handed over to SOAmanagement. SOA management is responsible forenforcing any necessary changes to existing organiza-tional policies for individual SOA initiatives. Based onexperience with individual projects, SOA managementcollects best practices and instills them in the gover-nance mechanism. SOA management activities are syn-chronized and supported by the portfolio managementoffice. SOA management and SOA governance worktogether concurrently and synchronously with individ-ual SOA initiatives. SOA management enforces newgovernance policies or changes to existing ones on indi-vidual SOA initiatives. Meanwhile, SOA initiativesinfluence changes to SOA governance policies, princi-ples, or practices as appropriate by connecting directlywith SOA governance.

In addition to enforcing compliance, this model pro-motes communication and collaboration between theindividual SOA initiatives and the SOA governance.


This in turn makes businesses more flexible and helpsthem cope with change together with IT.

POLICIES, PRINCIPLES, AND BEST PRACTICES

From my experience, I have found that companies thatare successfully establishing SOA initiatives usuallyinvolve both top-down and bottom-up approaches con-currently. The top-down approach allows the companyto incorporate strategic business objectives, goals, andvisions, as well as to plan for specific business needs.The bottom-up approach involves service developmentat an organization level. These approaches are then con-nected or intertwined via SOA governance and manage-ment with a set of policies, principles, and best practicesto deliver the goals of SOA (see Figure 2). While I amfocusing on the significance of SOA governance in thisarticle, I would like to point out that SOA managementalso plays an important part in SOA initiatives. It isaccountable for successfully employing the policies,principles, and best practices across the organization(s).

Policies

I have noticed that most companies working on SOAgovernance establish policies in four major areas:

1. Reuse. In my opinion, this is one of the most impor-tant policies. It encompasses not just how the servicesmust be designed to meet certain specific businessneeds, but also how services may interoperate witheach other. As a result, organizations can avoid creat-ing multiple versions of the same service. Such a

policy can also make sure that existing services areused before new services are built to meet the sameor similar business needs.

2. Security. This is another important policy thatdefines how a service can be accessed, who canaccess the service, and when one can access the ser-vice. This policy also prescribes the security stan-dards that must be incorporated while designing anddeveloping services. In some cases, the security pol-icy also identifies how various security-related riskfactors can be recognized and the measures that canbe taken to mitigate such issues.

3. Compliance. There are at least two major complianceaspects addressed by this policy. One aspect is relatedto various government regulations, industry man-dates, and business constraints that the organiza-tion must follow (business point of view). The otheraspect is related to various industry standards otherpractitioners follow in designing and developing ser-vices (technical point of view).

4. Alignment. This policy is related to building thecollaboration and understanding between businessand IT. While most companies have a strategic planin place for establishing business-IT alignment, itis important to lay out a set of rules or contractsbetween the business and IT while building businessservices to be utilized in an SOA environment.

Most practitioners prefer to refine these policies itera-tively and incrementally over multiple SOA initiatives.

Provides SOA Policies,Principles, and Guidelines

Instills SOABest PracticesPrinciples:

• Business• Corporate• Technical• Industrial

Policies:• Reuse• Security• Compliance• Alignment

Influences Change

EnforcesChange

Individual SOAInitiative

Individual SOAInitiative

SOAGovernance

SOAManagement

Figure 2 — A simplified view of SOA governance in practice.



Principles

SOA governance principles are mostly guidelines thatare established to support various SOA-related activitiesacross the business organizations. Obviously, theseprinciples are directed toward achieving certain specificobjectives. I categorize them under four major focusareas:

1. Business goal–specific. This set of principles isessential to ascertaining the capabilities that IT mustpossess in order to address strategic business goals.These principles are primarily focused on supportingthe business management teams in making their deci-sions. They consist of processes to utilize resourceseffectively to continue business operations, to supportdisaster recovery, and to meet government andindustry regulations.

2. Corporate process–specific. These principles arerelated to corporate policies, procedures, and stan-dards relevant to formalizing contractual agreementswith service providers (internal or external partners).Many companies start with a small set of contracts(i.e., SLAs) that ultimately encompasses the evolvingneeds of services enterprise-wide.

3. Technology-specific. These principles concern thearchitectural and other IT asset–related requirementsfor an SOA initiative and how organizations mustembrace them. I have seen companies create technicalprinciples formalizing the level of reuse, granularity,and coupling of services. I have also noticed compa-nies creating metrics to measure the way services areused or shared across the organization(s). Some com-panies also consider a set of technical principles tointegrate existing technology investments with SOA.

4. Industry-specific. These principles are important forestablishing mechanisms to share services across mul-tiple business entities and also to create compositeservices from multiple basic services. In some cases,practitioners utilized these principles to manage theentire lifecycle of a service and measure the serviceperformance as appropriate. In my opinion, industry-specific principles are most useful in building a set offrameworks that can be reused by multiple organiza-tions across an industry for deploying repeatable busi-ness services with minimal or no significant changes.

I find these SOA governance principles extremely use-ful in spreading the use of SOA across multiple linesof business (where the same business function can bereplicated as a service) or across the same business

domain (where one service can be used multiple times)while complying with a set of consistent business rules.

Practices

Earlier, I mentioned that it is imperative that the incep-tion of SOA governance be business-driven, its vision bebusiness-focused, and its mission be business-oriented. Iwould like to substantiate my comments with a set ofbest practices that I have collected from the trenchesover the past few years:

1. Get business engaged from the beginning. Sincebusiness owns the processes and the functions thatare potential candidates for services, it is essentialthat the business drive the SOA governance. Mostcompanies start their SOA governance small and thenlet it evolve as the business requirements grow.

2. Establish regular business and IT collaboration.Since business formalizes the corporate vision and ITenables the business, frequent collaboration betweenthe two is imperative. The vision of SOA governancemust be aligned with the business needs and mustsupport the business vision.

3. Formulate policies, procedures, and frameworksto support business goals. Reuse of services isextremely important in achieving such business goalsas competitive advantage, cost reduction, and cus-tomer satisfaction. SOA governance must promoteservice reuse to fulfill its mission to deliver businessflexibility.

4. Capitalize on emerging standards incrementallyand periodically. SOA is evolving, and so arethe industry standards associated with it. It is essen-tial to take the time needed to absorb the lessonslearned in order to better understand the SOAand its governance.

5. Prepare a set of SOA governance processes andprocedures to expedite the change in organizationalculture. While SOA is evolving, existing IT assets andinfrastructure can be utilized and leveraged for initialSOA initiatives. Yet the change in organizational cul-ture is inevitable and must not be ignored.

I strongly believe that SOA governance is about (toparaphrase Weill and Ross) “encouraging desirablebehavior in using business services.” For this to happen,companies must make consistent use of a set of policies,principles, and best practices.


TOOLS AND TECHNIQUES

SOA governance involves a combination of two con-current functions. The first one allows practitioners toestablish the processes that can help them make the rightdecisions. The other function involves the use of tools toimplement the processes defined by the practitioners, sothat their decision making can be expedited throughoutthe service lifecycle (i.e., during design, deployment, andruntime use of a service). Many commercially availableSOA governance tools can help practitioners createvisual models; monitor service performance; or control,maintain, or modify a service. Another set of tools isavailable to support using service registries for serviceregistration, discovery, or binding. These registries mayalso connect to Enterprise Service Bus (ESB) productsto support SOA integration with existing technologies.Another emerging area of focus for SOA governancetools is service-level management. These tools enablevarious activities such as monitoring, optimization, andcontrol of SLA-based use of services that are registeredwith a registry across the organization(s).

Although most leading SOA vendors claim to offer toolsthat either directly or indirectly support SOA gover-nance, most of these tools only support a small part ofthe overall governance mechanism. While assistingvarious companies with their SOA governance efforts,I have had experience with Systinet’s SOA governancetools, webMethods’ X-Registry and X-Broker, andLogicLibrary’s Logidex. Practitioners using the above-mentioned products have achieved satisfactory resultsin delivering necessary governance support, visibility,and oversight to their customers. Many other vendorsare pursuing the development of similar registries andrepositories to allow practitioners to enforce and auto-mate policies during the service lifecycle. Some of theseproducts are also worth considering for SOA gover-nance support.

CONCLUSION

Here are some of my observations on SOA governance,which may resonate with your own:

It is unique in the sense that it primarily focuseson business services. However, the concept of gover-nance is nothing new to the business and IT commu-nities. In fact, most of the tenets of corporate, IT, andEA governance are extremely useful for buildingSOA governance.

SOA governance is a practice that is evolving. Whileit involves a number of business-driven policies,principles, and established best practices, it is notfully mature. In crafting an SOA governance mecha-nism, practitioners will want to take advantage oftheir prior knowledge of and experience with existinggovernance mechanisms.

Most available tools support only a small part ofthe solution. While most of the techniques derived orsimply employed from these tools offer satisfactoryresults, they must be integrated with a multitudeof practices (i.e., best practices that work in a specificenvironment) to make them highly effective andscalable in delivering true SOA governance.

It is clear that most of the policies, principles, and bestpractices pertaining to SOA governance are built uponthe premise of leveraging existing business investmentsand IT assets. However, as the business environmentcontinues to evolve and new technologies emerge,SOA governance will mature, and it will strengthenits already prevalent position in pursuing business-driven SOA initiatives.

REFERENCES

1. Hazra, Tushar. “Getting Your Enterprise Architecture MetricsRight.” Cutter Consortium Enterprise Architecture ExecutiveReport, Vol. 9, No. 9, September 2006.

2. Weill, Peter, and Jeanne W. Ross. IT Governance: How TopPerformers Manage IT Decision Rights for Superior Results. HarvardBusiness School Press, 2004.

Tushar K. Hazra, PhD, is a Senior Consultant with CutterConsortium’s Enterprise Architecture and Sourcing & VendorRelationships practices. In December 2000, Dr. Hazra foundedEpitomiOne, a strategic consulting company specializing in EA, SOAdeployment, portals, Web services development, model-driven solutiondelivery, IT governance and service delivery management, and globalsourcing strategy facilitation. Dr. Hazra has 16 years of practicalexperience in developing and integrating service-oriented enterprise(SOE) and mission-critical component-based systems in collaborativeenvironments for the insurance, healthcare, retail, banking, telecom,and aerospace industries.

During the past 12 years, Dr. Hazra has served as CTO and VP ofseveral Fortune 100 companies. Currently, as President and CTO ofEpitomiOne, he helps business and IT leaders incorporate their strate-gic sourcing visions for enterprise-level initiatives while complyingwith commercial and government standards, best practices, and man-dates. As a hands-on practitioner, Dr. Hazra gets involved in every-thing from building strategies to developing EA and SOA to guidingand deploying MDA-based application integration initiatives. He canbe reached at [email protected].



NATURAL SELECTION

In recent years, service-oriented architecture (SOA) hasbecome the hottest topic in the industry because of itspromise of reuse, cost savings, and faster time to market,all of which are very appealing to a highly competitivemarketplace. While the promises touted by SOA are notnew — as older generations of technologies such asCORBA remind us — the means of achieving thosegoals through SOA must be fundamentally different.If they are not, SOA will be limited to providing somebetter plumbing for enterprise application integration.

The recent focus of SOA has been on providing a stan-dard way to integrate existing systems and applicationswith Web services. Although this is a necessary steptoward an SOA, many issues have been encountered aswell. For example, it is quite common that many Webservices have been created by individual projects butreuse has been very low. Frequently, the major issue isthat those new Web services applications lack businesscontext and are system-centric. Even if someone tries toreuse these Web services, he would find it very difficultto understand the business context and system-specificsemantics — not to mention the poor interoperability. Itappears that the effort needed to reuse these services isstill greater than the effort required to reimplementthem. Thus, the whole purpose of SOA is defeated.

The answer to the problem described above, accord-ing to many, is SOA governance. As one industryresearcher observes, “Doing lots of little Web servicesprojects all over the place with no governance isn’tSOA, it’s just playing” [5].

THE ROLE OF GOVERNANCE AND ENTERPRISE ARCHITECTURE

The goal of SOA governance is to align the businesswith IT. By providing a decision framework rather thanmaking actual decisions, good SOA governance helpsindividuals make sound decisions more easily. Thisleads to consistent results that meet the expectations ofthe business while at the same time complying withpolicies, regulations, and other constraints set byauthorities. To pull this off, SOA governance must:

Be able to manage the full lifecycle of services, fromtheir inception, design, development, deployment,and operation to their termination

Ensure accountability, which means that roles andresponsibilities, ownership, and processes must bewell defined

However, these are hard things to do. SOA is new, butgovernance is not, and people try to use the traditionalgovernance approach for SOA. This leads to the follow-ing issues:

Lack of trust between the business and IT. The busi-ness always feels that IT is lagging behind and isunsure of what IT can and cannot do.

Silo development is rampant. Each business unitdoes its own development, and there is little or nocoordination at the enterprise level.

Lack of accountability. If something goes wrong, it iseither everyone’s fault or nobody’s fault.

Some have argued that enterprise architecture plays animportant role in SOA governance because it encom-passes both business architecture and technical architec-ture. It defines the roles and responsibilities for people,who will then make decisions and implement IT sys-tems according to the architecture roadmap. In order toachieve this goal, the following factors are important:

Providing a common model and shared understand-ing between the business and IT

Clearly identifying ownership for each business asset(i.e., anything valuable in a business, including busi-ness data, processes, capabilities, and people)

Promoting transparency across all processes andartifacts

BUILDING A COMMON MODEL BETWEEN THE BUSINESS AND IT

When building a common enterprise model, it is intu-itive to think about creating an enterprise taxonomyso business entities can be modeled with a common

SOA Governance Using the Universal Business Identifierby Hao He and Brett McDowall


understanding. However, this is very difficult to do inpractice because of the need to agree on a single taxon-omy while business continues as normal. The fact is thatalmost every business domain has its own taxonomy,and mapping between a domain taxonomy and anenterprise taxonomy is a nontrivial task. So instead ofworking with a common taxonomy, what else can westart with?

If someone has worked in the content managementspace, she will know that the single most critical ele-ment is having a unique identifier for any content tobe managed. The importance of this identifier far out-weighs that of metadata, because once a piece of contentis identified, it can be located and retrieved. Similarly,before describing business entities with a taxonomy, itis far more important to identify each of them with aunique identifier.

This may sound trivial, since surely there is an ID foranything in just about any system. Of course there is,but it is native to each of the hosting systems and can-not be shared outside of the system boundary. In addi-tion, since SOA governance is not just about systemsand applications but also needs to work for people,those IDs must be meaningful to humans.

In other words, we want a universally distributed iden-tifier. Coming up with a scheme to create those IDs isnot so easy, but luckily this problem has already beensolved. The Universal Resource Identifier (URI) wascreated for exactly this purpose and has proven to behighly successful on the Web [1]. Imagine trying todefine a taxonomy or model for information on theWeb! Instead, as Tim Berners-Lee has pointed out:

The most fundamental specification of Web architecture,while one of the simpler, is that of the Universal ResourceIdentifier, or URI. The principle that anything, absolutelyanything, “on the Web” should [be] identified distinctly byan otherwise opaque string of characters (a URI and possi-bly a fragment identifier) is core to the universality. [3]

Following the same principle, anything, absolutely any-thing important in an enterprise should be identified bya URI. The immediate benefits are obvious:

Once a business asset in an enterprise is identifiedwith a unique URI, it becomes an enterprise resourcethat can be managed.

As Berners-Lee has written, “Great multiplicativepower of reuse derives from the facts that all lan-guages use URIs as identifiers: This allows thingswritten in one language to refer to things defined inanother language. The use of URIs allows a language[to] leverage the many forms of persistence, identity

and various forms of equivalence” [3]. We canrephrase this as “Great multiplicative power of reusederives from the fact that all systems, applications,and people use URIs as identifiers: This allows thingsdefined in one business domain to refer to thingsdefined in another business domain. The use of URIsallows systems, applications, and people to leveragethe many forms of persistence, identity, and variousforms of equivalence.”

Once an enterprise resource is given a URI, its owner-ship is also identified, because the structure of a URIexplicitly supports the notation of authority. Clearownership improves accountability and can be read-ily reassigned.

Just as with the Web, an enterprise resource with aURI should be provided with a representation thatothers can GET (the very simple action with whichone opens a URI with a browser). This reduces theenterprise taxonomy problem because multiplerepresentations can be provided at the same URI.Additional semantics can be derived from links toother enterprise resources. This also prompts trans-parency because enterprise resources are no longerhidden deeply behind a system or systems.

An enterprise can leverage many of its existing toolsand infrastructure elements to manage enterpriseresources. This eliminates the need for a centralizedservice registry and catalogs.

The common model can be built by resource ownersproviding links to other resources incrementally. Thisreduces the burden on a centralized enterprise inte-gration center. More importantly, this allows resourceowners to negotiate relationships among each otherfor maximum profits, which is also an importantaspect of SOA governance [4].

To make the URI friendlier in a business environment,let’s create a new convention and call it the UniversalBusiness Identifier (UBI). Figure 1 highlights how theUBI provides a standard addressable container for allaspects of the business asset, as against a Web service,which is much more complicated. The UBI approachprovides the basis for standardizing how all of the

Before describing business entities with ataxonomy, it is far more important to identifyeach of them with a unique identifier.



different aspects of an asset are handled and, in thesame way as the Web, allows convergence on standardprotocols, naming schemes, and so on.

By contrast, think about what is needed to access abusiness asset (e.g., a customer account transactionresource) using a Web service. While the underlyingcommunications and data-handling protocols are wellsupported by TCP/IP and protocols such as SOAP,there is a still a lot to do to negotiate between the sup-plier or owner of the business asset and the consumer.The Web service must know a range of system-specificaddresses, how to access information on that specificsystem, and which set of steps to follow to locate thedesired resource and then access it.

Of course, there is no magic involved here, and theUBI approach doesn’t make these things disappear. Itdoes, however, allow us to provide useful defaults socomplexity can be hidden and dealt with where it needsto be. A UBI can have useful and extensible defaultsfor all the aspects that define a business asset, and bothpeople and systems can go straight to an asset if theyhave the full address (as in a Uniform Resource Name[URN]), or they can use default search and get proper-ties if they don’t.

WORKING WITH THE UBI

Given that a UBI is just like a URI, it would consist ofthe following parts:

http://{business sector domain name}.{enterprise domainname}/{business domain name}/{sub business domainname}…/{business resource id}

The first part is a top-level business domain, and thesecond part is the usual enterprise domain name. TheURI path contains a number of sub-business domainnames, forming a hierarchy. The last part of the UBI is

an ID referring uniquely to a business resource. Forexample, the following UBI:

http://retailbanking.bigbank.com/customer/1234

uniquely identifies a customer of bigbank. Dependingon who is opening the UBI, the most appropriate repre-sentation is returned. For example, if the URI is openedby the customer it refers to, then an HTML page show-ing the customer’s profile is returned. If the URI isopened by a service, an XML document about the cus-tomer details is returned. By default, if any part of theUBI is missing, a list or a search view is returned. Forexample, the following UBI:

http://retailbanking.bigbank.com/customer/

would return a search form for a bigbank staff memberso he can search for a customer. If the same UBI wereaccessed by a system, it would return an XML docu-ment with a list of UBIs to individual customers. Acommon practice could be that the document only con-tains a preset number of customers and the list can bepaged through by supplying a start parameter, whichmeans that default behavior is both sensible and useful.

Among the good things about the UBI is that it enablespartial understanding and free extension — the veryelements that enabled the rapid evolution of the Web[2]. People can create their own UBIs. If they don’tunderstand an existing UBI, they can either study it byopening the UBI or just ignore it. Over time, the most-used UBI will become the standard, while the least-usedUBIs will simply die out.

Another interesting attribute of UBIs is that they canlink to each other just as Web pages do. Let’s considera case in which a customer deposits some amount ofmoney to her account. This simply means that a linkis created between two UBIs — a UBI pointing to thecustomer and a UBI pointing to her account. In a moretraditional approach, such links are actually created

Web Service UBI

System IP AddressService Name

Search Method NameGet Method Name

URN

3AE8974F7A734290A633E727665DE218

URL

http://retailbanking.bigbank.com/customer/account/

29A6734902Semantics

Vocabulary

Attributes

Protocol

Data

Owner

Service Levels

Business

Asset

Context

Figure 1 — A UBI provides a standard container for all aspects of a business asset.


implicitly in systems but buried deeply in system logsthat no one can easily inspect.

With UBIs, the immediate concerns for IT and thebusiness are the same: business resources and theirrelationships. In other words, business resources andrelationships become the first-class citizens of enter-prise architecture instead of systems and applications.This decouples the lifecycle management of businessresources from that of systems and applications. Fromthe business’s point of view, the essence of governanceis only to do with the lifecycle management of businessresources.

So what does this mean for governance? Standardiza-tion is one of the great friends of compliance, the cor-nerstone of governance. With more visibility, betterdefault behavior, less complexity, and more business-oriented computing solutions, both SOA and enterprisegovernance become much easier. More interestingly,this results in an enterprise that is like a healthy, self-governing ecosystem — new development and initia-tives will concentrate around business assets thatdeliver real value to the business. Those that don’t willbe selected out, thus improving the agility of the enter-prise. The task of enterprise governance also becomessimpler, as its focus is now on channeling funding toaccelerate innovations while doing less policing. Afterall, the best governance is the one of which the peopleare least aware, as Lao-Tse said a couple thousandyears ago.

CONCLUSION

The need to define every aspect of interfaces, protocols,and models is a facet of SOA that is often ignored.There is a common feeling that interfaces can hideeverything, but the reality is that the interfaces mustpass data, agree on attribute names, agree on the con-text of data, and agree on the protocols for using spe-cific services. All of this is a severe impediment to theadoption of SOA and, in a typical enterprise, the majorbarrier to adoption.

While the ways to transition most effectively to thismodel are a subject for another day, there is little doubtthat the current possibilities offered by SOA and mod-ern Web technologies need to be used in a way that fitsin with the business and IT realities of the modernenterprise. Adopting the UBI approach will allow thesort of evolutionary explosion we have already seenwith the Web.

REFERENCES

1. “Architecture of the World Wide Web, Volume One.” W3C,15 December 2004 (www.w3.org/TR/webarch).

2. Berners-Lee, Tim. “Evolvability.” W3C, March 1998(www.w3.org/DesignIssues/Evolution.html).

3. Berners-Lee, Tim. “Web Architecture from 50,000 Feet.”W3C, September 1998 (www.w3.org/DesignIssues/Architecture.html).

4. Wall, Quinton. “Rethinking SOA Governance.” Arch2Arch, 14 March 2007 (http://dev2dev.bea.com/pub/a/2007/03/soa-governance.html).

5. Windley, Philip J. “Governing SOA.” InfoWorld, 19 January2006 (www.infoworld.com/article/06/01/19/73698_04FEsoagov_1.html).

Hao He is a Senior Architect and an expert in SOA and Web architec-ture with Object Consulting, Australia’s leader in delivering enter-prise business solutions using component-based technologies such asEnterprise Java, .NET, and open source. Dr. He is also experienced inJava/J2EE, XML, and all major XML-related technologies. He has asolid application modeling background using UML and has extensiveknowledge of access control, cryptography, and system security.Dr. He is experienced in software design and verification and devel-opment process optimization. He is currently a member of JSR 311,which produces a new API for creating RESTful Web services; hewas also a contributing member and editor of W3C’s Web ServiceArchitecture Group during its existence. Dr. He can be reached [email protected].

Brett McDowall is an expert in the fields of enterprise architecture,distributed Internet-based systems, and object-oriented systemsarchitecture. He is currently Chief Architect at Object Consulting.Mr. McDowall has been with Object Consulting for 15 years andhas over 20 years’ experience in the visioning, architecture, analysis,design, management, and implementation of major projects. He is aspecialist in telecoms and distributed systems, with experience span-ning the insurance, banking, finance, and government sectors. Hehas also played a major role in the creation and ongoing developmentof Process MeNtOR, Object’s world-class software engineeringmethodology.

In his current role, Mr. McDowall plays a major part in the architec-ture and development of enterprise systems. He liaises between busi-ness managers, software developers, and project managers at largeorganizations to help them understand the applicability of new tech-nology to their business. He assists in making recommendations onif, and when, to adopt new technologies and creates appropriate newtechnology architectures where required. Mr. McDowall can bereached at [email protected].



THE WAY OF SOA

Enterprise architecture management (EAM) andservice-oriented architecture (SOA) mark two disci-plines that belong to the IT plat du jour. Many organi-zations across the world are trying to implement SOApatterns and EA practices to reap the fruits promisedby both disciplines. A typical implementation path forsuccessful SOA adoption leads inevitably from theworld of technology (using services as just anothermechanism for implementing functional requirements)into the realm of architecture patterns that supportstrategic business-IT alignment (see [2, 3] and the “SOARoadmap Template” sidebar). Yet when participatingin large services portfolio implementations in complex,modern organizations, we have seen the gap that opensbetween EAM practices, such as enterprise releasemanagement, and the dynamic process of enterpriseservices portfolio development. One can experiencethe gap even in the case of a relatively agile approachto EA, based on iterative releases of enterprise archi-tecture. Arguably, the disciplines in question havedifferent origins that make them the “yin” and “yang”forces in the enterprise.

THE YIN AND THE YANG

EAM as a discipline was founded in 1987 by JohnZachman. The client-server revolution and then theInternet resulted in a radical change in perception as tothe impact IT has on business. Zachman argued that inorder to regain control over the flood of IT investment,we have to understand the relationship between com-ponents that constitute the virtual architecture of anenterprise. This means that those who participate in ITinvestment decision making should be able to answerbasic questions related to information assets and proj-ects at various levels of detail. Thus, EA is seen (oftenrightly) as a “yin” force that subjects innovation to cen-tralized decision making, or (often not so rightly) as aforce that trades off creativity and tempo for stabilityand order.

In contrast, the biggest motivation behind the SOAmovement is to provide IT users the means for moreproductive, faster, simpler business innovations. Ser-vices enable organizations to increase the granularity ofIT investment, introducing standardization of softwaredesign and promoting reuse of functionality — includ-ing the functionality that has been long hidden insideintricate monolithic legacy systems. Standardizationmay sound like another “yin” initiative, but the symp-toms of a successful SOA implementation are justthe opposite. Once users understand that the serviceseffectively change the complex IT landscape into aset of LEGO1 blocks that can be quickly combined todeliver value for the organization and its customers,the demand for new services increases radically, oftenbeyond IT’s ability to manage it. Thus, SOA becomes the“yang” of corporate computing, promoting innovation,change, and — if not handled properly — chaos.

It is obvious that these disciplines have to be balancedto support a healthy process of enterprise innovation. Itis less obvious how to do it. Let us shed some light byreviewing the challenges of SOA governance from theperspective of two key roles in the process: the solutionarchitect and the enterprise architect.

THE SOLUTION ARCHITECT’S PERSPECTIVE

An organization emerges from the initial stages of SOAimplementation (i.e., service delivery and service inte-gration) having assembled an early services portfolio —the initial set of “software LEGO” pieces. The set usu-ally consists of a number of business services pluggedinto a service bus built on top of robust applicationintegration technologies. At this point in the SOAimplementation, the organization may already haveexperienced benefits such as improved productivityin delivering new business functionality (see the“Managed Services Portfolio” sidebar on page 36).

The Tao of SOA Governanceby Piotr Szabelak and Jan Topinski, with contribution from Borys Stokalski

1LEGO® is a registered trademark of the LEGO Group.


SOA ROADMAP TEMPLATE

Each milestone in the SOA roadmap template relates to different categories of architecture management issues and results in specificbusiness benefits and opportunities.

SERVICE DELIVERY

Service delivery starts with applying service orientation on the application level. At this stage, services are just another way ofdelivering software functionality across the network, and the benefits of the investment in mastering the new paradigm are verymuch application-specific.

SERVICE INTEGRATION

To realize the broader benefits of SOA, it is important to change the focus of service implementation efforts from applications to theenterprise architecture. The first area in which the investment starts to pay off is the reuse of existing application functionality in new,composite applications. This step results in the assembly of service portfolios, defined and published using enterprise-level standardsand mechanisms.

SERVICE INTEROPERABILITY

Once a productive SOA environment is in place, assembling new business functionality from existing services will often prove to becheaper, faster, and more reliable than other approaches. This will lead to the creation of application ecosystems — sets of applica-tions that share a significant portion of their functionality within the confines of the “value network,” linking the enterprise withcustomers and business partners.

SERVICE MANAGEMENT

The effective and efficient collaboration of services across many, often unforeseen, contexts creates demand for more elaboratedefinition of service capabilities. Apart from the interface definition, which is the fundamental SOA metadata, applications have tobe able to determine capabilities such as performance, reliability, and/or cost of service.

ADAPTIVE ENTERPRISE ARCHITECTURE

Adaptive enterprise architecture is a vision of the enterprise in which business processes, information, and knowledge assets can bequickly and effectively (re)organized and (re)deployed to support business decisions.

Reach of Services Adoption of SOA in Enterprise Architecture

Benefits Driving SOA Adoptions

Open Value Network

Enterprise Ecosystem(Value Network)

Enterprise

Application Ecosystem

Utility Services

Applications

Opportunistic Systematic Pervasive

Undefined Reuse BPM Adoptability

Service

Interoperability

Service

Integration

Service

Delivery

Service

ManagementAdaptive

Enterprise

Architecture

Figure A — SOA roadmap template.



MANAGED SERVICES PORTFOLIO

The services portfolio needs a solid architecturalfoundation to meet high and broad enterprise-level quality requirements related to availability,performance, and/or fault tolerance. Such afoundation (including the capabilities of theenterprise application integration platform) isoften called an Enterprise Service Bus (ESB). TheESB and the portfolio of managed services arestrategic IT assets shared between applications,connected through adapters and channels.

Services as seen in the “concentric model” of anESB (see Figure B) are built in one of four tiers:

1. The Managed Services layer defines businessservices and implements message routing andtransformation.

2. Adapter Services form the foundation forevery service, connecting integrated systems to the ESB.

3. Channel Services translate native system invocations into enterprise service “language.”

4. Composite Applications, an optional part of the architecture, are sometimes required to provide some additional functionality ontop of the Managed Services and Adapter Services layers.

Complementing ESB with additional components and tools that support service lifecycle management leads to the pattern defined asManaged Services Portfolio. The complete Managed Services Portfolio architecture, including the service lifecycle repository, is shownin Figure C.

Portfolio

Runtime

ESB Infrastructure

Application

Adapter

Managed

Service

Channel

Composite

Application

Figure B — The “concentric model” of Enterprise Service Bus.

Access

Service Invocation (Instance)

Contract QoS Monitor Resources

Business Logic (Semantics)

Business Interface

Physical Interface

Service-Level Requirement

Usage Context

Provider

Consumer (client)

SLA

Services Directory Portfolio Runtime (Provisioning Infrastructure)

Repository

Ser

vice

Def

init

ion

Figure C — The complete Managed Services Portfolio architecture.


As the pressure to leverage the asset increases, newreleases of the enterprise architecture will include moreand more requirements for new and improved services.The most immediate outcome is the increased complex-ity of the services portfolio. A less obvious result is thegrowing complexity of the process that is deliveringservices — more projects, more vendors, more subtlecoordination requirements. SOA exhibits its transform-ing power by enabling very focused, agile process inno-vations, yet at the same time it is often constrained bythe EA practices that promote monolithic releases ofinterdependent functionality. In a complex SOA envi-ronment, you eventually reach the limitations of man-agement approaches that seemed to work before youachieved a certain complexity.

Consider the example of one major telecommunicationscompany, which — two and a half years after startingits SOA program — now manages a portfolio of morethan 200 services. The portfolio integrates functionalityfrom 15 major systems (such as billing, CRM, provision-ing platforms, and/or revenue assurance) and has beenused as a foundation of a couple of nontrivial compositeapplications. Each release of the enterprise architecture(synchronized around CRM functionality) affects 30-50services, including both new services development andchanges in existing services. Apart from internal ITstaff, there are some five major vendors responsible forvarious projects within the scope of each release.

If your organization is driving its SOA effort towarda point of similar complexity (which, you’ll recall, is abyproduct of successful uptake of services by the busi-ness users), you’ll need to understand some challengesin order to address them properly.

Understanding Service Usage Patterns

IT managers are often concerned about the quality ofcapacity planning. In the case of SOA, a reliable predic-tion of usage may not be possible by those who designand implement it. If the services really support businessinnovation, then they may often be used outside the ini-tially envisioned usage context — after all, this is whatinnovation is about. That is why a well-designed portfo-lio allows for the collection of usage data in such a waythat service architects may simulate potential effects ofchanges in the services portfolio and better forecast therequired changes in services portfolio infrastructure.Apart from having access to usage data, a solutionarchitect needs to understand the capabilities andarchitecture of the services portfolio.

Understanding the Services Portfolio Architecture

The production environment may be really well orga-nized and services well described and structured, butin a complex SOA environment, you are likely to dis-cover that to be productive, you need more informationon the services portfolio than you actually get. Apartfrom knowing what services are available, you mayneed to know what kinds of commitments (scope offunctionality, service levels, usage constraints) are asso-ciated with them. As a service developer, you mightalso be interested in tracking known issues in servicesthat are outside your own scope of work. Equallyimportant is visibility into the development andplanning stages. If SOA is about reuse, then we mustremember that a prerequisite for reuse is awareness ofreuse opportunities.

Understanding the Service Lifecycle

Visibility into the service development process leadsus to the next issue. As SOA progresses within an enter-prise, applications become decoupled into services,event-response patterns, and processes. If this is doneright, these objects are to a large extent independent, sothat one is able to manage them separately. The troubleis that few enterprises are capable of providing the fine-level project granularity enabled by SOA. Typical ITprojects involve much coarser scope definitions. Thesame applies to releases of the enterprise architecture,which are usually managed as programs — sets of proj-ects supporting high-level goals (see Figures 1 and 2).The style of central coordination applied in such situa-tions can only be efficient if the requirements and thesolution architecture are well aggregated. Such a pro-gram coordination style implicitly forces the projectsto adopt a waterfall process even if an agile processwould be more appropriate on the project level.

A Silent Game

Let us try to wrap up the issues. In order to take fulladvantage of the productivity and flexibility gains

SOA exhibits its transforming power byenabling very focused, agile process inno-vations, yet at the same time it is oftenconstrained by the EA practices that pro-mote monolithic releases of interdependentfunctionality.



EnterpriseArchitecture v.1

EnterpriseArchitecture v.2EA Increment Program

App A

App B

App C

App D

App E

App A

App B

App C

App D

App E

Figure 1 — Release management is simpler if the architecture consists of relatively coarsely defined, independent building blocks.Project-level interdependencies are simple and do not result in significant friction.

EnterpriseArchitecture v.1

EnterpriseArchitecture v.2EA Increment Program

App A

App B

App C

App D

App E

App A

App B

App C

App D

App E

Shared SharedSh ed

ServicesSServicesc Shareded

ServicesSeervices

Figure 2 — If applications use and share a large number of interdependent services, then program-level coordination results in less-than-optimal efficiency of release management, due to deadlocks caused by complex project-level interdependencies.


offered by SOA, the delivery of interdependent servicesshould be managed separately. Yet in large efforts, suchas business-critical releases of the enterprise architec-ture, this is usually not happening. Such releases aremanaged from the top down. In an attempt to retaincontrol, program management and enterprise architectsdivide the work into coarse chunks they can easilyunderstand — that is, projects with a waterfall struc-ture, synchronized by traditional program and projectmanagement rituals.

As a result, instead of asking, “Is the service xyz specifi-cation completed?” in most cases we can only ask, “Hasproject ABC completed its specification phase?” And ifwe need to call a service xyz from the ABC applicationdelivered by another project, we cannot learn whichversion of service xyz we could use in our release, asthe only information available for “other projects” is theversion in the entire ABC application. It just seems somuch simpler if, instead of analyzing complex relation-ships within the services portfolio, we could reduce themanagement effort to only a couple of applications anda dozen services included in our assignment. Unfortu-nately, this is not how it’s done, and thus we trade realagility — the ability to optimize the progress of workbased on detailed design information shared betweenprojects — for what pretends to be “more mature”management. This is just as if we asked a bunch ofkids to jointly build a castle sharing the same set ofLEGO blocks but ordered them not to talk to oneanother. Instead, they are just to talk to dad or mum,who is coordinating the construction. It might work,but it has little to do with either productivity or fun.

THE BUSINESS ARCHITECT’S PERSPECTIVE

Business architects use architecture concepts and pat-terns as organizing principles for key architecture build-ing blocks, abstractions used primarily for decisionmaking and — to some extent — high-level design.An important aspect of such tools is their ability tofoster communication between the users and providersof technology. It is worth saying that concepts such as“services” and “services portfolios” seem to be equallyappealing to business and technology communities,which is rather a rare case. Another appealing factor isthe relative simplicity of the service metaphor, whichmakes it broadly applicable for various aspects ofbusiness-IT alignment.

But SOA is much more than just a metaphor. It is beingdirectly implemented, and this implementation con-sumes resources — capital, money, effort. Thus, from the

point of view of governance principles, one must startby asking some fundamental questions related to twobasic “outcome areas” within a traditional IT governancemodel (as defined by the IT Governance Institute) [1]:

1. What value is being delivered by SOA?

2. What are the associated risks?

It is absolutely crucial to identify the business case forthe SOA implementation, since (as with any other proj-ect) the identified requirements and SOA stakeholdersare the starting and ending points for all SOA gover-nance issues. An SOA roadmap template [2] is an exam-ple of an intellectual framework that can be used toaddress these fundamental questions.

An insightful reader may have already noticed how“frontline experience” shows that introducing SOAleads to a point when the evolution of architecture maydemand a change in some established practices used forgovernance. We believe that this can only be achieved ifthe service metaphor is used consistently in all aspectsof governance and EAM. Let us review some major actsperformed by the enterprise architect in his or her work.These are: decomposition, abstraction, coordination,standardization, consolidation, and reuse.

Decomposition

Services can be a very powerful tool for process decom-position and modeling. Processes can be decomposed atall levels of the enterprise architecture. This should bedone mainly on the basis of the business operationsmodel. If decomposition is done by business (which isseldom the case — formal modeling is usually part ofthe esoteric lore performed by business analysts withinIT), problems may arise on different grounds:

Lack of clear delegation of responsibility for the busi-ness activities comprising a service (business silosand uncoordinated redundancy of work) leads toproblems in service decomposition.

The same lack of clearly defined responsibility forbusiness tasks also impedes services identification

This is just as if we asked a bunch of kids tojointly build a castle sharing the same set ofLEGO blocks but ordered them not to talk toone another.



and reconciliation in the “white spaces” betweenfunctional silos.

A legacy of misalignment between IT and businessmay result in serious difficulties in matching businessservices with the applications or functions imple-mented in IT systems.

A high level of “projectization” (work executed mostlyas projects with few routine, process-oriented activi-ties, objectives, and responsibilities) may underminethe identification and/or decomposition of services.

Implementing SOA is a transforming initiative. Servicesprovide the foundation of the customer relationship,serve as the business process building blocks, and areoften sourced from vendors and business partners. Theycan be measured, orchestrated, and benchmarked. Theycan be improved, recombined, and reconnected to sup-port innovation and agility. If this is the vision, and itis generally accepted by the organization, then there isfertile ground for using IT architecture patterns suchas Managed Services Portfolio to support such a transfor-mation. (For a description of the Managed ServicesPortfolio pattern, see the sidebar on page 36.)

Abstraction (Decoupling)

If an organization recognizes the benefits of service-oriented architecture and accepts the consequences of thechange it involves, abstraction becomes a critical act. Itenables the organization to identify its core buildingblocks — its “functional DNA.” This painstaking andcrucial task may involve internal politics and consensusbuilding. It is targeted at maximum decoupling of thedefined services to allow them to be managed separately,to untie the existing organizational and functional knots,and to form a clear and uniform classification of services.This is the transition from a subjective view of services(typical for business stakeholders) to a logical view thatconstitutes a well-architected services portfolio.

As with decomposition, tensions may arise becauseof decisions made in decoupling services. Some exam-ples are:

Redundant functionalities in the current IT environ-ment may require decisions not based on bilateral IT-business contacts, but rather on a business–ITdevelopment–IT operations triangle. Special gover-nance solutions may need to be implemented toencourage IT development and IT operations toresolve their issues before beginning a discussionwith business.

Decoupling may reveal “orphan functions” in ITsystems that create costs but have no business owners— or that have a business owner who does not acceptthe level of costs “discovered” at this stage.

During initial portfolio creation, many existing areasof interest may intersect, leading to turf conflicts anddifficulties in appointing and sharing responsibilities.

Coordination

Managed Services Portfolio, as a core SOA pattern,can be applied in many ways. Its most important rolefrom a governance perspective is to support decisionmaking related to changes in enterprise architecture.Decoupling leads us to a definition of a service back-bone. This backbone — if well defined — serves as amanagerial tool and is reflected directly in IT architec-ture. We believe that the service backbone could be thecoordination axis for all levels of abstraction withinthe EA model, a sound basis on which to plan and/orimplement business process changes, define service-level management parameters, and so on.

There are two reasons why EA initiatives — as seenfrom the frontline perspective of the solution architect— seem to ignore this role of the services portfolio.First, the services portfolio is a shared asset, and enter-prises have little experience in solving the problemoften described in management literature as the“tragedy of the commons.” Second, the initial contentof the services portfolio is usually relatively weak. Mostof the support required by business is traditionally pro-vided by other building blocks of the IT architecture —traditional, monolithic, isolated business applications.Thus, the goals of EA increments are not primarilyassociated with the evolution of the services portfolio.Portfolio infrastructure that could support the agileprocess of service delivery is not adequately supportedby capital investment and management attention. As aresult, the actual productivity trajectory related to EAtransformation diverges from the optimal one.

Most of the issues the solution architect faces (as wediscussed above) are found in the area of coordination.

The services portfolio is a shared asset, andenterprises have little experience in solvingthe problem often described as the “tragedyof the commons.”


Many governance issues can also be addressed here.Some examples are:

Difficulties in providing an adequate servicebenchmarking framework and low awareness ofreuse opportunities undermine the usefulness ofthe services portfolio as a decision-making tool.

Organizations have difficulty assigning clear businessresponsibility for the quality, content, flexibility, andother important characteristics of the services portfo-lio (not just individual services).

SOA must be integrated with the paradigms, method-ologies, and approaches that have come before andremain in place (EA models, ITIL service-level agree-ments, etc.).

Standardization

In the process of decomposition and decoupling, a setof criteria for defining the services emerges. Supportedwith additional requirements (terms definitions, archi-tecture rules, formats and notation definitions, etc.), itcan be converted into a consistent and efficient set ofstandards and patterns.

The need to achieve both consistency and efficiencymakes this task nontrivial. In the act of establishingstandards, an enterprise architect forges tools thatshould help the organization bridge the gap betweenmetaphor and the complexity of a real-world enter-prise. Business users are confident in using the servicemetaphor, visualization (general business graphics), andnumbers (budgets, business performance metrics), butthey are not willing to handle formal architecture mod-els such as UML constructs. On the other hand, any def-inition of services portfolio architecture must go beyondPowerPoint slides if it is to have any value for thosedoing the actual implementation work.

Thus, any set of standards developed for an enterprise-scale SOA implementation should support and promotebasic motivations behind such initiatives (agility, reuse,efficiency, accountability, etc.). It should also promote— from the very beginning — the message that the ser-vices portfolio is a shared asset that can create valueonly if leveraged. Some relevant issues here are:

Standards are required to share critical design andstatus information between projects at a level of gran-ularity that supports grassroots coordination betweenprojects. This mechanism will not work properly ifproject- and program-level governance promotes iso-lation of projects or, still worse, competition betweenprojects and vendors.

Introduction of optional-scope contracts for work onthe services portfolio may optimize the businessvalue that SOA projects deliver over time.

Involving many vendors in an SOA program neces-sitates negotiations among many parties. Suchnegotiations are time-consuming and requirediplomatic skills.

Consolidation

Coordination is the act of synchronizing disparateinitiatives that transform the enterprise architecture.Standardization supports this act by creating anenvironment where design- and implementation-leveldecisions can be efficiently negotiated by the implemen-tation teams. Consolidation is the act of implementingthese mechanisms, patterns, and standards in order todeliver an integrated portfolio of manageable servicesthrough architecture, design, and implementation. Thisinvolves using release management for managing thesubsequent increments of the envisioned enterprisearchitecture.

At this point, we believe that SOA governance shouldbe supported on the project/release level by aninformation-sharing infrastructure, including:

A UDDI-compliant service repository that is welldocumented, searchable, and user-friendly

Automated design/deployment polices that supportthe chosen service lifecycle model, providing trans-parent access to project and service status information

Runtime polices that enforce and measure serviceusage

Other features such as automated services testingand versioning

Not all aspects of this act can be easily considered inadvance. It is worth taking the time to recognize asmany of them as possible and to build them into yourSOA governance. Some examples are:

In multibranch/multinational companies, it isnot always clear how to implement standards.

Any definition of services portfolio architec-ture must go beyond PowerPoint slides if it isto have any value for those doing the actualimplementation work.



Complex organizations will require a balanced mix ofapproaches — consensus building, negotiating, andsometimes even arbitrary decisions — in order toestablish standards.

If a company outsources selected operations or hasclose interactions with its clients or contractors, thesystem of communicating standards becomes quite achallenge (including indicating the responsible rolesand their duties).

Not all enterprise initiatives or existing solutions willbe compliant with the centralized rules or standards.Despite the migration plan to the new standards, anarchitectural dispensations management approachshould be implemented.

Planning and implementing a system of restrictionsfor organizations, projects, and/or roles that do notcomply with standards is a sensitive issue and shouldtake into account a general future approach andcurrent governance rules.

Reuse

In the course of an SOA initiative, an organization willneed to understand the many interdependencies relatedto its applications, systems, projects, and so forth. Itmay find that some solutions are redundant, some areorphans (and thus can be abandoned or radically sim-plified), and some will present opportunities for reuse.Apart from the suggestions we made above about treat-ing the services portfolio as a shared IT asset, there aresome other governance structures and standards thatshould be established to accommodate service reusedecisions at a higher level:

Because it is not always clear when some service witha local or regional scope can/should be promoted,the organization should define a set of criteria formaking this determination or, alternatively, appoint aperson/role to do so.

Some business services are so common and basic thatthey can be perceived as a part of the enterprise infra-structure rather than the business portfolio. Again, a

set of criteria should be established for making thisdecision.

TOWARD SERVICE-ORIENTED GOVERNANCE

Employing large-scale release management to developthe enterprise architecture seems to be the state-of-the-art in EAM programs. As helpful as this technique isin synchronizing large development and deploymentefforts, it forces an aggregation of the complex web ofdependencies between services into much-simplifieddependencies between components. As a result, other-wise independent building blocks often need to wait forone another, while some sophisticated interdependen-cies of requirements get lost in a crude “division oflabor.” The outcome is friction — in the form of qualityproblems, integration problems, and time wasted indelays caused by late delivery of components. And fric-tion is the main enemy of agility.

One can view the problem as an unavoidable side effectof the complexity of modern IT architectures. Surelywithout the current discipline of release management,we could hardly hope for any systematic delivery of ITcapability on the enterprise level. But is this really stilltrue? What if what we have here is really a situation inwhich executive-focused management practices got outof sync with the new architectural paradigms broughtabout by the advent of enterprise SOA?

The dependencies between systems make typicalreleases what they are — complex and scary manage-ment and technical endeavors. As long as systems weremostly monolithic, we could reduce the managementcomplexity by recognizing dependencies between appli-cation versions and related high-level business require-ments. As we have said before, with SOA governancein place we might attempt to “zoom in” the scope tothe level of dependencies of particular functionalitieson particular components. Apart from the potentialheadache we can get trying to imagine the graph ofinterdependencies, such radical growth of scope com-plexity could actually blow up the release-based man-agement system by making it too costly and inefficient.Furthermore, ignoring the opportunity of service-leveldependency management creates inefficiencies in thedevelopment work.

We need to work this problem out in three steps:

1. We need to organize the IT governance and EAprocesses around the service metaphor. It is

The dependencies between systems maketypical releases what they are — complex andscary management and technical endeavors.


comprehensible for non-IT people, it provides a goodintellectual framework for all areas of governance,and it maps directly into software architectures andIT organizational principles and methodologies. Onecaveat is that such an approach will work only wherethis metaphor is adequate for the business style andarchitecture of a particular organization.

2. We have to introduce governance and managementpractices (business responsibility, funding mecha-nisms, operational responsibility, service benchmark-ing, etc.) that will make the services portfolio a trulyshareable IT asset. The open source community mayprovide good examples of such collaborative manage-ment practices.

3. We need to establish operational practices that enableproject teams to coordinate their work on the servicesportfolio without the involvement of program man-agement bodies. This involves some technical solu-tions that enable collaboration on a shared IT asset(e.g., service repositories, shared regression testingenvironments, shared generators) as well as manage-ment solutions that will reduce the risk of inducingunethical or counterproductive behavior among theparties involved in service development (e.g., a feder-ation of architects to establish and enforce standardson SOA projects).

This is the tao of SOA governance.

REFERENCES

1. IT Governance Institute (ITGI). Board Briefing onIT Governance, 2nd ed. ITGI, 2003 (www.itgi.org).

2. Kiepuszewski, Bartosz, Michal Paluskiewicz, Borys Stokalski,Sebastian Konkol, and Maciej Ruszynski. “Applying EARoadmapping: An SOA Roadmap.” Cutter ConsortiumEnterprise Architecture Executive Report, Vol. 7, No. 9,September 2004.

3. Topinski, Jan, Bartosz Kiepuszewski, and Borys Stokalski.“Service-Oriented Integration: A Report from the Trenches.”Cutter Consortium Enterprise Architecture Executive Report,Vol. 9, No. 5, May 2006.

Piotr Szabelak is a Senior Enterprise Architect at Infovide-Matrix. Hespecializes in enterprise architecture and has worked on several suc-cessful EA implementation projects. He previously worked in IT ingovernment, where he gained a background in EA, project manage-ment, project portfolio coordination, IT security, and data warehous-ing/BI. He can be reached at [email protected].

Jan Topinski is a Senior Consultant at Infovide. Mr. Topinski adviseson QA management and automation. He also works as an architect,specifically for integration platforms and SOAs. Mr. Topinski is anexpert on development process automation environments and frame-works. He can be reached at [email protected].

Borys Stokalski is a Senior Consultant with Cutter Consortium’sBusiness-IT Strategies, Enterprise Architecture, and Innovationpractices. He is VP of Infovide-Matrix S.A., a Polish company special-izing in architecting and implementing IT-based business innovations.Infovide, which is the exclusive representative of Cutter Consortiumin Poland, is ranked among the top CSI (Consulting & SolutionImplementation) organizations in that marketplace.

Mr. Stokalski takes an active part in Infovide-Matrix initiatives tar-geted at new service areas and consulting products, such as adaptivebusiness strategies and architectures, knowledge management, collabo-ration architecture, and training programs for IT managers. One ofhis top responsibilities is the stimulation of growth and efficiency inthe Infovide-Matrix innovation network, an essential part of which isthe knowledge collaboration with Cutter Consortium. Mr. Stokalskifrequently shares his experiences and insights through articles andconference appearances on topics such as innovation management,the business impact of technology change, and EAM. He can bereached at [email protected].


Cutter IT Journal

About Cutter ConsortiumCutter Consortium is a truly unique IT advisory firm, comprising a group of more than100 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, groundbreakingwork in organizations worldwide, helping companies deal with issues in the core areasof software development and agile project management, enterprise architecture, businesstechnology trends and strategies, enterprise risk management, 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’s happening inthe marketplace. With Cutter Consortium, you get the best practices and lessons learnedfrom the world’s leading experts, experts who are implementing these techniques atcompanies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats, including contentvia online advisory services and journals, mentoring, workshops, training, and consulting.And by customizing our information products and training/consulting services, you getthe solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for all enterprises,or all departments within one enterprise, or even all projects within a department. Cutterbelieves that the complexity of the business technology issues confronting corporationstoday demands multiple detailed perspectives from which a company can view itsopportunities and risks in order to make the right strategic and tactical decisions. Thesimplistic pronouncements other analyst firms make do not take into account the uniquesituation of each organization. This is another reason to present the several sides to eachissue: to enable clients to determine the course of action that best fits their uniquesituation.

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

The Cutter BusinessTechnology CouncilThe Cutter Business Technology Councilwas established by Cutter Consortium tohelp spot emerging trends in IT, digitaltechnology, and the marketplace. Itsmembers are IT specialists whose ideashave become important building blocks oftoday’s wide-band, digitally connected,global economy. This brain trust includes:

• Rob Austin• Ron Blitstein• Tom DeMarco• Christine Davis• Lynne Ellyn• Jim Highsmith• Tim Lister• Lou Mazzucchelli• Ken Orr• Ed Yourdon




Documents

Cutter - cdn.ttgtmedia.comcdn.ttgtmedia.com/rms/computerweekly/DowntimePDF/pdf/SOA_goven… · Ed Yourdon,Cutter IT Journalis one of Cutter’s key venues for debate. The monthlyCutter