GET TECHNOLOGY RIGHT®November 7, 2005 b Issue 45

i INFOWORLD.COM

Creating a service-oriented architecture that drives true

business agility demands a plan.Here’s where to start

p23

TEST CENTER EXCLUSIVE

Systinet’s Next-GenerationServices Registry p56

Here at Last: SQL Server 2005and Visual Studio 2005 p14

®

JON UDELL

Innovation Toolkitsfor the Masses p55

Service-oriented architecture begins and ends with business process, marshaling

a sprawling set of technologies along the way. Don’t know where to start? Try Step 1.

BY ERIC KNORR AND OLIVER RISTILLUSTRATIONS BY RON CHAN

I N F O W O R L D . C O M 1 1 . 0 7 . 0 5 23

SSOOAA iiss aann iiddeeaa,, nnoott aa tteecchhnnoollooggyy..

True, SOA (service-oriented architecture) builds on the stackof protocols that define Web services, but it is hardly limitedto that stack and draws as much on time-honored notions ofbusiness “re-engineering” as it does on XML, SOAP, andWSDL. Simply put, SOA is a broad, standards-based frame-work in which services are built, deployed, managed, andorchestrated in pursuit of new and much more agile IT infra-structures that respond swiftly to shifting business demands.

The breadth of that vision is what makes SOA seem so mad-deningly vague. Nonetheless, the potential benefits ofreduced IT costs and greater business agility have spurredmany organizations to start down the path to SOA, to thepoint where most large enterprises now have some sort ofSOA initiative under way. One reason for that extraordinarytraction: SOA may ultimately have a transformative effect onthe entire enterprise, but in contrast to other “big bang”endeavors, most of the applications and infrastructure you’vealready deployed can remain in place.

Throughout the past two years, InfoWorld has interviewed

INFOWORLD SOA EXECUTIVE FORUM SPECIAL ISSUE24 Step 1: Think Big, Start Small25 Step 2: Go to the Whiteboard25 Step 3: Survey Your Surroundings28 Step 4: Connect Your First Services32 Step 5: Choose and Deploy a Registry or Repository32 Step 6: Start Tackling Governance34 Step 7: Lay Your Security Plans36 Step 8: Build Out Your Messaging Infrastructure38 Step 9: Deploy Service Management40 Step 10: Consider OrchestrationPLUS:45 Making SOA Work46 BAT Builds SOA One Step at a Time48 Sabre Answers to Customer Demands50 Thompson Prometric Rethinks Business Processes51 Verizon Goes Back to the Workbench

1SOA starts with a business promise: to enable enterprises tore-engineer themselves on the fly. From the outset, look foropportunities for agility. The more dynamic the business, themore it will benefit from a well-implemented SOA. And themore allies you have who share the SOA vision, the better. Inparticular, it helps to have powerful part-ners in your company’s businessmanagement who understand theultimate payoffs of cost reductionand accelerated response tochange across the organization.

“We’re actually kind of fortu-nate in that we don’t have to sellSOA,” says Ben Moreland, assistantdirector of foundation services at TheHartford, which got its SOA initiativerolling a few years ago. “Our seniorvice president, John Chu, recog-nized the benefits and thevalue of SOA.”

This shared vision may be vast, but it paysto start small. “Don’t try to do ‘boil-the-ocean’-typeprojects,” advises Ed Horst, vice president of marketing atAmberPoint, who has watched overly ambitious initiativesfalter. “I think the most successful initial projects we’ve seenare those that are small in size — about six to 10 services thatintegrate two or three things and take around six months tocomplete.”

Many organizations start by provisioning a few mission-

critical legacy applications as services, providing access toimportant data and functionality to other applications for thefirst time. Or they use shared services to eliminate redun-dancy among several difficult-to-maintain stovepipe applica-tions that overlap in functionality.

Such projects may yield significant benefits, but SOA deliv-ers the most value — and will scale far better in the future —when you begin by drawing a box around a set of related

business processes that need streamlining, ratherthan attacking technology problems first. Scott

Thompson, senior architect at H&R Block,puts it this way: “We had to switch our

mentality from just rendering data andjust making a service out of it because

we could, to asking: What’s the busi-ness problem that we’re trying tosolve, and what applicability does that

business problem have to otherareas of the organization?”

Jean-Michel Van Lippevelde,business architect at Accelior Consulting, has

reached the same conclusion. “Take a top-down approachfrom a business-process perspective,” he advises. The resultscan be highly visible, as they were in Accelior’s engagementwith ING Lease Belgium, which targeted a request-for-quoteprocess that included automatically generating contracts.Before, the process typically took days. But after streamlin-ing the process, provisioning services, and automating for-merly manual steps, the wait time was reduced to minutes.

24 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Think Big, Start Small

countless enterprise architects, developers, and officers whoare guiding their organizations toward SOA deployment —and who are learning hard lessons, gaining insight, andencountering infuriating technology gaps along the way.Many are already enjoying SOA’s early benefits of easy inte-gration and code reusability. Based on their experiences, andthe advice of industry technologists and analysts, we offer thisstep-by-step guide to planning, building, deploying, and man-aging an SOA.

As you’ll see, SOA provokes many of the same questionsthat dog most grand IT schemes. Should you buy and deploySOA-related technology from a single vendor with which you

already have a close relationship, or should you mix andmatch best-of-breed solutions? And, as with any standards-based initiative, what do you do when many of the standardsnecessary to achieve the real benefits aren’t fully cooked yet?

Such questions lack easy answers, and missing pieces oftechnology, industry disagreements, and vendor lock-in allthreaten to dampen SOA’s much-ballyhooed benefit of hyper-agility. Nonetheless, you’ll find most of the key conceptsunderlying SOA, a number of which may be familiar, righthere — although not necessarily in exactly the right order foryou. Just as with SOA itself, how you put it all togetherdepends on what you’ve got and where you want to go.

3

2You can’t expect to dissect business processes and see whatmakes them tick all by yourself. In collaboration with busi-ness stakeholders, review and rationalize the processes in thedomain you’ve identified. Often, much of the heavy lifting willbe done by the business guys, as theyscratch their heads and figureout how to restructure process-es — and you determine thebreakdown collaboratively anddecide where new automationcan make a difference.

“We started our process map-ping by meeting with each agencyindividually,” says Dan Thomas, direc-tor of the DC Stat program at the Office ofthe Chief Technology Officer in the Districtof Columbia. Thomas’ ambitious program is tying together the data repositories of 65 separate D.C. government agen-cies to give senior officials trans-parent, up-to-the-minute informa-tion with which to make policydecisions.

Thomas’ team met with each agency to map out itsdata-gathering policies and to find out how that data was dis-tilled for presentation. “It’s a time-consuming process,” hesays, “but we didn’t try for all 65 agencies out of the gate. Wepared it down to a manageable number. Now they’re getting

in line for our attention.”Timothy Vibbert, senior systems engineer at Lockheed

Martin, takes a like-minded approach. In providing profes-sional services to government agencies, he’s logged an impres-sive amount of whiteboard time. “We go through full domaindecomposition before we even think about services,” he says.At the same time, “you also start looking at what is out therethat you might be able to reuse. And then you go into mission

or process identification, getting down to a spe-cific thing you want to tackle.”

After the scope is defined, Vibbert says,it’s important to determine who the par-

ticipants will be. “And once you define those,you start building use cases. Then you startdecomposing the use cases. And then you getinto resource allocation and data allocation,start naming your services at a high level,

and also talk about the data thatflows,” he says, emphasizing that

these steps are iterative, withmultiple passes required to cre-

ate the right plan of attack.Every SOA initiative is unique, so the duration of

the planning process varies wildly, but Vibbert provides a hintof how long you’ll be sniffing dry-erase marker: “If youalready have some pieces of an SOA in place, you can trimdown the time frame relatively quickly. An SOA from scratch… it could take months if not longer.”

I N F O W O R L D . C O M 1 1 . 0 7 . 0 5 25

Go to the Whiteboard

Survey Your SurroundingsHere’s where all that process work starts to meet technologi-cal reality. Before you implement, look carefully at what youhave in place to leverage. A basic tenet of SOA, particularlyin its early phase, is to work with what you’ve got when pos-sible but to avoid locking yourself into practices or technolo-gies that will stymie future interoperability or expansion.

Taking inventory is a multistage process. First, you need todocument the data sources and existing applications that will

be involved in your initial deployment — remembering toidentify partner services outside the firewall that you mayneed to connect with and to catalog those services as careful-ly as you do internal ones. Second, take stock of technologyyou have on hand that will play a role in your SOA. Yes, this isa big job, and no, it’s not necessary to complete it before mov-ing toward an initial project. But neither can it be ignored ifSOA, rather than a limited project, is your goal.

“I think the most successful initial projectswe’ve seen [involve] about six to 10 services that

integrate two or three things.”— Ed Horst, AmberPoint

4

An SOA involves a sprawling set of technologies. The shortlist: tools to build or provision those services; a registry inwhich to expose them; a messaging infrastructure over whichservices and applications will communicate; a means oforchestrating services; and some sort of services managementinvolving intermediaries. Application-layer net-working may also play a role, and down the road,so may BPM (business process management)and BAM (business activity monitoring)applications. You’ll also want to takea hard look at the Web servicesinterfaces of your commercialenterprise apps.

That’s quite a stack of stuff,but you don’t need to makesweat-inducing technology deci-sions about what you’ll change, add, orkeep quite yet. You’ll be busy enough figur-ing out how to map and normalize data amongthe systems involved. As Timothy Vibbert of Lockheed notes,data among various systems can be “defined 15 different ways,15 different times for the same data element.” Reconciling thatmetadata is hard, tedious work.

“Take a top-down approach from abusiness-process perspective.”

— Jean-Michel Van Lippevelde, Accelior Consulting

28 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

If you’re not an SOA expert and are leery of hiring a con-sultant, don’t despair. There’s no need to run to the LearningAnnex for a crash course. Get as far as you can. If your enter-prise consists of little custom code and mostly off-the-shelfsoftware, contact your software vendors one at a time. Ask

about their SOA plans and capabilities. Often, you’ll bepleasantly surprised by their direction — and you may

obtain valuable information that will affect projectscheduling and future

platform choices.“We moved our

product portfoliotowards SOA specifi-

cally because our cus-tomers asked us to,”

says Dwain Kinghorn,CTO of Altiris, a large manufacturer of

asset, network, and security managementplatforms. “It allows our customers to free

themselves from our management consoles. They can nowgrab specific pieces of management data and incorporatethose into any SOA-based management dashboards they mayhave developed on their own.”

Connect Your First ServicesTime to get your feet wet. Take that whiteboard map andfocus on one area as a pilot project. Identify a key point ofredundancy in your set of related applications, spec out yourfirst service, decide who will build it with what tools, and startprovisioning. After testing, you can start modifying apps tocall your new, shared service.

What basic characteristics should a service have? TimothyVibbert of Lockheed lists them: “They’re reusable, they havea contract, they’re loosely coupled, they’re stateless, andthey’re discoverable.” Most SOA practitioners would add thata service should also be “coarse-grained” — that is, it shouldmap to a business process step or function rather than, say,an application component. This helps ensure reusability andavoids overlap with other functionality.

Scott Thompson of H&R Block learned the value of thecoarse-grained approach the hard way. “I think in our earlydesign, we tended to develop services that were more in tunewith our object layer than they were true business services,

and so the reusability of those wasn’t quite as high as whatwe had liked it to be,” he says. “So we’ve gone back andredesigned a lot of our services to be more reusable, not onlyto a specific project but really more in tune with the businesspurpose that they were designed to serve.”

Several stovepipe applications, for example, may have theirown way of opening a customer account. Create a singlecoarse-grained service that each application can call on toopen an account, and you eliminate redundancy and reduceapplication maintenance. Along the way, you may be able toglean other benefits: better compliance information, moresecurity across a single repository rather than multiple datadumps, and better Web site management.

Typically, services are published as Web services — whichpromises the greatest potential for reuse because the stan-dard protocols that define Web services are designed to tran-scend platforms and programming languages. In practice,however, SOAs typically expose other types of services, such as

those accessible via JMS (Java Message Service).How do you decide what type of service to use? “One thing

it depends on is the payload,” Lockheed’s Vibbert says. “If the messages you have going back and forth have relatively small data sizes, Web services are fine. Or if it’s not time-critical, Web services are probablythe best choice. But if you’ve got things thatinvolve large amounts of data goingback and forth or are time-critical, you might not go with a Web service”and instead build a service accessiblethrough JMS or some otherbinary protocol.

Services can be deployed on Java appli-

cation servers, on Windows Server, or provisioned onlegacy systems themselves — and thanks to Web ser-vices interoperability, your developers can generally

choose their favorite tools and platforms forprovisioning. “One of the things that a service-oriented architecture gives you is the benefit

of rendering that decision secondary,” saysCharles Stack, CEO of open source reg-

istry provider Flashline. “You canchange deployment platforms

at the service level withoutaffecting your service-ori-ented architecture. Ser-vices abstract that very

infrastructure level. It’s much less of astrategic decision than that sort of thing used to be.”

“We moved our product portfoliotowards SOA specifically because

our customers asked us to.”— Dwain Kinghorn, Altiris

6

5Many organizations mark the beginning of their SOA initia-tive at the point when they deployed a registry as amechanism for service discovery. At a minimum, aregistry prevents duplicative effort, a place wheredevelopers can determine whether a service hasalready been created. As Timothy Vibbert ofLockheed notes, “It could just be a Web sitethat lists [services]. It may be manual dis-covery, but they’re discoverable.”

But as the number of services and theapplications that use them grow, you’llneed a real registry. “We selected a UDDIregistry in 2003 and put it in productionin 2004,” says Ben Moreland of The Hart-ford. “We use it for the dynamic bind-ing capabilities to give us theloose coupling between the clientand the producer of the service.”

Most SOA deployments employsome sort of commercial registry or repository that offersdeeper functionality than that defined by the UDDI spec,

mainly to have a more structured way to store and manageservice metadata. To complicate matters, the distinction

between “registry” and “repository” is rather slip-pery. The common definition is that a registrycontains data about services — where they’re

located, XML schemas, and so on — whereas arepository contains the servicesthemselves. In truth, services stillrun on their deployment platform,so repositories actually contain whatamounts to a deeper level of meta-data — plus, registries generallyoffer repository capabilities. They

just don’t call them that.Choosing a registry maywell be the first SOA-specific

buying decision you’ll face.And it may also be the first time

you encounter the fundamental choice betweena single vendor’s offering and best-of-breed SOA solutions.All the big platform players, including BEA Systems, IBM,

32 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Choose and Deploy a Registry or Repository

Start Tackling GovernanceRegistries are more than just containers in which services canbe described by metadata and discovered by clients and otherservices. They are also centers of SOA governance, where ITcan list human service owners, manage versioning, ensurecompliance with enterprise requirements, and more. Thesooner you start thinking about how governance will work,the better.

Governance is best defined as a combination of workflowrules — who is responsible for what services, what happenswhen quality assurance uncovers problems, and so on — plusmanagement of service interface definitions. Those defini-tions become an analogue of an IT org chart gradually trans-formed by the disruptive effect of SOA. “The strongest way tolook at your service interfaces is that they are the design of

your business,” says Randy Heffner, vice president at ForresterResearch. “They deserve attention and governance as muchas the design of your business does.”

SOA is fundamentally a new paradigm of IT, according toa technology exec at a major financial conglomerate whoasked not to be named. “When you increase dependency andcomplexity, it presents a whole new setof problems,” the tech exec says.“The more SOA is successful, themore management becomes aproblem.” This exec believes thatgovernance should be distrib-uted rather than centralized,in a manner similar to the

relationships among federal, state, and local government ina democracy. And he means that literally: He is currentlystudying The Federalist Papers for insight.

In 2004, The Hartford formed an enterprise architecturegroup to put a “governance process around projects,” accord-ing to Moreland. In the beginning, he says, the governance

process was all about communication. “We hadarchitects talking together for the first time that

were really solving the same problems, but indifferent lines of business. Now we’re to thepoint where we will actually stop a project if itdoes not conform to the reference architec-ture or the line-of-business blueprint. And

we have the authority from upper man-agement to be able to do that.”

Moreland provides a specific exam-ple of the types of problems good gov-

Microsoft, Oracle, and Sun have their own registries or repos-itories. But pure-play vendors abound — including Above AllSoftware, Flashline, Infravio, SOA Software, and Systinet —all of which boast a unique mix of capabilities. Depending onthe product, you may discover a wealth of stuff — graphic rep-resentations of the relationships between WSDL and services,identity-based security that limits access to certain services, arules engine to help manage service policies, and more.

When it comes to registries or repositories, David Aubreytakes the single-vendor view. “If you’re using any kind offramework, they’ll push a repository,” says Aubrey, seniorarchitect at KomatiSoft, a New York-based financial applica-tion startup. “That’s one area, I wouldn’t try and force a third-party alternative unless I absolutely had to. At least not today.The key is interoperability with the framework and its rulesengine, and that’s what they’re guaranteeing. Bring in a third-party solution, and you’re putting that whole synergy at risk.”

Not surprisingly, Flashline’s Stack takes the opposite view-point. “If you’re building your infrastructure for a service-ori-ented architecture on a proprietary vendor platform, I thinkyou’re making an enormous mistake,” he says. “We caution allof our customers from the infrastructure standpoint to put apremium on openness, because otherwise you’ll have theworst case of vendor lock-in you’ll ever see.”

7Years ago, when the industry began promoting Web services,the first objection raised was: What about security? That’sbecause, back then, the emphasis was on XML integrationacross enterprise boundaries. By contrast, SOA tends to focuson the architecture of a single enterprise — or closely relatedenterprises — where the underlying assumption is that every-thing occurs within one, big trusted zone.

“Many people have this sense of, ‘When I’m doing this kindof stuff inside the firewall, based on restricted network seg-ments or whatever else, I’m OK without a deeper sort of useof security in my services environment’,” Forrester’s Heffnersays. “But the time when everybody says, ‘I have to do some-thing with security,’ is an external connection.”

Although SOA shifts the emphasis towardinternal architecture, B-to-B integration withpartners is a natural extension — and in manycases a core benefit. Across firewalls, the solu-tion can be as simple as a two-way SSL con-nection. But before you jump to any tech-nology conclusions, Heffner advises thatyou first decide whether your enterprise is a“hub” or a “spoke.”

Hubs, says Heffner, can simply laydown the law. “If you’re a Wal-Mart, then as a hub, you just saywhat the architecture is going to be … becauseeverybody’s got to do what you say.” For the rest ofus spokes, “you’ve got to look at what your partners, the peo-ple you’re going to connect to, what sort of security architec-tures they are doing. And then decide on the strategy of justpure edge security, so you’ve got an XML security gatewayand can do authentication/authorization at that level,” or adeeper level of security, where authentication travels alongwith XML documents as they move within the enterprise.

Fortunately, the industry has agreed on a simple framework

for securing XML messages beyond the time when they’re inflight: WS-Security, which is perhaps the most often usedWeb services specification after SOAP and WSDL. Today,many enterprises combine WS-Security with SAML tokensto assert user identity through every stage of a multiparttransaction — an especially useful solution for financial ser-vices organizations.

Several other security specifications are in various stages ofdevelopment. WS-Trust is an extension to WS-Security thatensures the service requestor is properly authenticated beforesecurity tokens are issued. WS-SecureConversation extendsthe trust derived from positive authentication to groups ofmessages. And WS-SecurityPolicy enables services toexchange security policies and to negotiate authentication

and authorization without user inter-vention. None of these three specs,

which will be fairly essential in aworld where XML messagesroutinely cross domains, has yet

seen widespread use.“For us, this is another area

where we’re struggling through asbest we can until new standards

and practices emerge to makethe job easier,” says Bob Laird,

IT chief architect at MCI. Mean-while, Laird is focusing on solid external defense

systems, an effort that includes making his existing infra-structure security managers aware of new traffic flows andtransactions, and purchasing dedicated SOA defense hard-ware such as XML firewalls from Sarvega.

“Something bad has to happen before SOA security toolsreally start happening,” Laird says. “We’ll see XML-basedattacks, maybe even viruses, hitting someone publicly — andthat’s what it’ll take to galvanize the industry.”

34 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Lay Your Security Plans

ernance can avoid. Recently, one business unit of The Hart-ford published a useful service in the proper SOAP format. Adifferent area of the business applied to use that service butalso requested that the service return two additional data val-ues within the XML. “The owner of that first service … said,

‘I don’t have the funding or the budget or the resources to dothat. I’m tied up with other stuff,’ “ Moreland recalls. In sucha case, he says, good governance stipulates that the service inquestion should be owned by a group with a dedicated teamthat can maintain and modify it for the entire enterprise.

“If you’ve got things that involve largeamounts of data going back and

forth or are time-critical, you mightnot go with a Web service.”

— Timothy Vibbert, Lockheed Martin

Your next crucial technology choice: how messages will besent or received among services and applications. With small-scale SOA implementations, you can often get away withdirect, synchronous XML (most often, SOAP) connectionsthat essentially assume services will be available 24/7. Asdeployments grow larger and more complex, however, asyn-chronous, reliable messaging may be required — and becausedifferent messaging schemes support this in different ways,the danger of lock-in increases.

ESBs (enterprise service buses), EAI middleware from suchstalwarts as Tibco or webMethods, and application serversfrom BEA, IBM, and Oracle enhanced with integration add-ons all provide asynchronous, reliable messaging functional-ity. All support a range of messaging protocols, includingSOAP, JMS (Java Message Service), and MQ (Message Queu-ing), and offer application adaptors for legacy systems. Today,however, each solution has its own way of ensuring the arrivalof messages, a situation that is unlikely to change even withbroad adoption of standards such as WS-ReliableMessaging.

ESBs occupy a particularly confusing area. As Ben More-land of The Hartford says, "if you get 10 architects together,you're going to get probably 11 different definitions of an ESB.Some are going to say that it's an architecture pattern; oth-ers are going to say it's a single product. Others are going tosay it's a suite of products." Even among ESB products, the

8Build Out Your Messaging Infrastructure

9If more than a handful of services are up and running, andif any are mission-critical, you need to manage themthe way you would any networkresource. Several vendors offer dash-boardlike solutions that monitor thehealth of services, maintain servicelevels, scale performance, set up fail-overs, handle exceptions, and so on.This is made possible by the wonderof XML messaging, which allowsintermediaries — services inthemselves, sometimes pack-aged in appliances — to tapinto message streams.

Intermediaries establish a new slice of functionality

between the network layer and the application layer. Amongother benefits, intermediaries virtualize services, creatingproxies that hide the details of a service’s implementation

from clients and thereby add security.They may also throw in XML firewall oracceleration features, as well as the abil-ity to modify large groups of servicesfrom a single control panel — torespond to changes in regulatorystatutes, for example, or to meet new

security requirements. Services management is slowly

moving toward standardization withOASIS’s approval of WSDM (Web Services Dis-

tributed Management) last March. A second specification,

38 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Deploy Service Management

InfoWorld Test Center encountered surprising diversity(infoworld.com/3532).

Most people have a natural tendency to stick with whatthey’ve got. Bob Laird at MCI provides a case in point. “Wewound up using WebSphere because we already had IBMMQ installed,” he says. “It just made the most sense. Plus, itallows our developers to be eased into SOA concepts throughtools with which they’re already familiar.”

Lockheed’s Vibbert says he encounters this tendency allthe time. Although he likes the lightweight, standards-basedmessaging solution offered by the JMS-based Sonic ESB, hedoesn’t try to convince clients to switch if they already havea deep relationship with another vendor providing similarfunctionality.

But some folks, especially smaller shops, take a dimmerview of the single-vendor default. “To us, flexibility is every-thing,” says Paul Lindo, a 13-year veteran of development atthe Federal Reserve and now CIO of a small New York-baseddevelopment company. “What you get with a messaging sys-tem like MQ is a rehash of older proprietary technology witha new SOA spin. For us, sticking to straight Web services stan-dards makes much more sense.”

MCI’s Laird concedes that relying on IBM may limit hischoices in the long term, but he is willing to make that tradein order to start with SOA today, enjoy a low initial platform

cost, and grow his SOA as IBM’s product set evolves. “Andplease don’t think we’re closing our eyes to ragged-edge tools,”he says. Laird indicates that MCI actually encourages itsdevelopers to try non-IBM tools as they emerge. Those thatbecome popular are purchased in small quantities first andare integrated into specific projects. If they pass that test,they’re rolled out in larger numbers. “This way, we keep ouroptions open while avoiding large-scale compatibilityheadaches,” he says.

“Most companies that have a message-oriented middlewaresystem in place are more likely than not to leverage what theyalready have because it makes little sense not to use the robustmessaging topologies that many of these companies have inplace,” Flashine’s Stack says. “So unless you don’t have one ofthose, it seems to me that the MOM [message-oriented mid-dleware] solutions are going to be the reliable messaging ser-vice — and most have announced their intent to support thereliable messaging protocols.”

A technology exec at a major financial conglomerate offerscorroboration of this perspective. His company’s asynchronousmessaging solution is a well-established EAI product, whichamong other benefits provides the binary throughput neces-sary for high-volume transactions. When asked his opinion onESBs, he replies with a question: “Why should I go for a light-weight JMS solution when I already have a heavy-duty one?”

“The strongest way to look atyour service interfaces is that they are

the design of your business.”— Randy Heffner, Forrester Research

10

40 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

WS-Management, which overlaps a bit with WSDM butfocuses on managing network hardware rather than on appli-cation-level messaging, was submitted to the DistributedManagement Task Force by Intel, Microsoft, and SunMicrosystems last June. But today, for all practical purposes,you need to use the same Web services management solutionacross your SOA deployment if you really want centralizedcontrol. As Bob Laird of MCI puts it, “It’s a big mess rightnow, and we just have to muddle through.”

Interestingly, the pure-plays — including Actional, Amber-Point, Blue Titan, and SOA Software — lead the way in Webservices management. But the big network managementplayers are catching up: BMC, Computer Associates, Hewlett-Packard, IBM, and Novell are all sponsors of WSDM and arein various stages of incorporating Web services managementinto their offerings. In addition, Cisco’s AON (Application-Oriented Networking) initiative should soon result in net-working equipment with service management capabilities.

“We use AmberPoint,” says Scott Thompson of H&R Block,although he admits he has rolled out that vendor’s solutionin a limited fashion. “We’re taking baby steps,” he says, “start-ing out with basic service-level management monitoring.Then we played with exception monitoring, but we reallywant to mature the model into managing encryption, decryp-tion, authentication, and authorization types of functions.”

Ben Moreland of The Hartford cites “the ability to be noti-fied when there’s an SLA failure or there is a failure in the ser-vice [and] the ability to enforce policies” as reasons his orga-nization deployed a Web service management tool.

Some see centralized policy management as the mostimportant promise of all. It’s relatively easy to check thehealth of Web services running locally, but to reconfigurethousands of Web services across an organization, you need astandard that works across platforms. The WS-Policy stan-dard is designed to address this, but implementation in prod-ucts remains at an early phase.

Consider OrchestrationEvery platform includes some method for orchestrating ser-vices. Whether it works well is another question. Ultimately,service orchestration will be vital for whipping up new,process-based composite applications in the dynamic man-ner promoted by the SOA vision. Few are implementing ittoday, however, because it’s complex to pull off and becausethe relatively modest SOA rollouts that generally inhabit thereal world don’t really require it.

Randy Heffner of Forrester Reasearch offers some guide-lines. “One easy entry point for thinking about orchestrationis: I have one request coming. …How should I do a full and com-plete business unit of work?” heasks. “If the answer to that ques-tion is, ‘Well, I’ve got to make sev-eral things happen in a sequenceacross multiple underlyingapplications,’ then you’ve gota scenario for orchestra-tion.” Heffner adds that orchestration also demands sometolerance for latency. “Depending on how many things youneed to have happen in lower-level applications, you’re cer-

tainly not going to be able to have an orchestration happenin a quarter of the second. You may not even be able to get itto happen in 5 seconds.”

Today, BPEL (Business Process Execution Language) pro-vides the only standardized means of orchestration,

although BPM (business process manage-ment) solutions have provided proprietaryorchestration schemes for years. “Orches-tration is trying to codify BPM,” says

Lindo, who works at a New York-baseddevelopment firm. “And that’s just unbe-lievably complex. If you point it at certainindustries like manufacturing, you canfocus enough to make the concept man-ageable. But for general business man-

agement, the relationships are socomplicated that tackling such a pro-ject from a coding or interface per-

spective is a massive bear.” Forrester’s Heffner draws a clearer distinction between ser-

vice orchestration and BPM, which has its roots in end-to-end workflow modeling. “The two are not well-connected,”

“We’re to the point where wewill actually stop a project if it does notconform to the reference architecture.”

— Ben Moreland, The Hartford

“Orchestration is trying to codify BPM...and that’s just

unbelievably complex.”— Paul Lindo, New York-based development firm

42 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Stepping Into the FutureEveryone has heard the clichés about “aligning business andIT,” as if technologists needed to be corralled into servingbusiness needs. The problem, though, isn’t the will, it’s theway. SOA provides the framework necessary for a new levelof IT responsiveness, even if some technology componentshave yet to mature.

Hooking up BPM (business process management) to largeportions of SOA infrastructure will represent one big steptoward the new era. Another will be wide deployment of inte-grated BAM (business activity monitoring) solutions, whichwill tap into SOA message streams to help determine thatprocesses and composite applications are providing the bestpossible business value. Beyond those technologies, industrySOA boosters set their sites rather high, prophesizing a self-optimizing IT nirvana in which applications and networkinfrastructures monitor and reconfigure themselves based oneasily adjusted business rules.

If self-optimizing SOAs ever arrive on a grand scale, it won’tbe in this decade. With the most advanced of today’s enter-prises barely achieving orchestration, SOA clearly needs tofill a few gaps — in security, reliable messaging, semantics,process management, and so on — and work its way throughimportant governance issues.

What’s just as clear, however, is that SOA is delivering realvalue now. “The thing that I see most folks doing across thebreadth of the industry is just getting services, of any kind, inplace,” says Randy Heffner of Forrester. “Some of them are

business services, but a lot of them are application-level ser-vices that aren’t really modeling the business per se but open-ing integration paths to applications that people couldn’t getto before.” That assessment may pale in comparison to bigpromises about hyperagility, but for IT on the ground, it’s apretty big deal.

Meanwhile, those who attack the whiteboard in earnestmay be doing more to prepare for an SOA future than earlyadopters who push orchestration to its current limits. Accord-ing to Ben Moreland of The Hartford, “from an organiza-tional perspective, the biggest issue we have is really SOAeducation and getting people to understand roles and respon-sibilities that are a little different than they were historically.There’s more of a shared responsibility. Now, you focus onyour business area, leveraging services and infrastructurefrom other [areas] where you may not have any control.” Inother words, cultural change to meet the challenge of SOAcan begin any time you like.

As Bruce Richardson, chief research officer at AMRResearch, says, “SOA is a journey, not a destination.” EarlySOA efforts are already establishing new lines of communi-cation between IT and business — and in some cases, begin-ning to affect the organization of business itself, as peoplegrow to understand how service orientation can eliminateduplicative effort and shorten development time. In theseinstances, the future is already beginning to arrive. i— Paul Krill contributed to this article.

he says. “In the modeling languages, … there’s no way to havea full view of the complete process where I just say, ‘OK, pushthese steps down into BPEL.’ I really can’t get that.”

In the opinion of Flashline’s Stack, the failure to accom-modate human interaction is a fatal weakness of BPEL.“When the industry was debating BPEL last year, I think thedecision to go with the machine-to-machine-only orchestra-tion protocol was a big mistake,” Stack says. “We don’t haveany customers that are using BPEL in anything but a trivial,experimental sense,” he adds, including sophisticated Webservices customers such as Sabre and Countrywide.

Ben Moreland of The Hartford, however, sees potential inan extension to the BPEL spec jointly proposed by IBM and

SAP. “Down the road, we have BPEL4People, which is a stan-dard that a couple of the large vendors are now pushingbecause they recognize that efficiency of workflow within theBPEL specification,” he explains. “I think that those two lay-ers, the BPEL orchestration and the BPM workflow, are goingto consolidate.”

Meanwhile, it won’t hurt to explore proprietary BPM solu-tions, as Scott Thompson of H&R Block has discovered. Iron-ically, working with Tibco’s BPM tool has helped SOA gaintraction in his company. “Until we started to orchestrate var-ious services together to form a business process, we didn’thave outright adoption of our SOA,” he says. “It was more ofa low-level IT type of project.”

implementing SOA (service-oriented architecture) is

one of the most daunting projects that an enterprise IT orga-nization can undertake. Service orientation represents awhole new way of thinking and doing, one that changes theway developers operate and interact with the business.

I spoke with IT managers from four companies abouttheir experiences implementing SOA, and each story wasdifferent. For British American Tobacco, developing a mea-sured, step-by-step approach was crucial. For Sabre Hold-ings, the unique nature of its IT environment presented thekey challenge. Thomson Prometric learned that personneland training were essential to success, whereas Verizon’sefforts took off only after it developed incentives for busi-ness units to adopt SOA.

Industry best practices are beginning to emerge (see“10 Steps to SOA,” page 23), so there’s still no easy recipefor SOA success. But as these stories show, success is with-in reach, provided companies remain focused on theirunique business needs.

Four companies explain how service-oriented architecture has transformedtheir businesses and howtheir IT departments met the challenge

BY LEON ERLANGER

I N F O W O R L D . C O M 1 1 . 0 7 . 0 5 45

GA

RY

ST

RE

NG

For British American Tobacco (BAT), SOA success came early. The

challenge now lies in determining how quickly SOA should be

scaled across the enterprise, and for which functions.

The company’s SOA journey began with a pilot project to build a

Web services-based dashboard thatcould extract real-time metrics informa-tion from legacy systems. The success ofthat pilot convinced those involved thatSOA could be the catalyst to move BAT’sIT away from siloed implementations toan agile, supply-and-demand organiza-tion, says Gavin Targonski, global sys-tems architect at BAT.

For a company like BAT, however,

with more than 300 products in 180markets and 90,000 employees world-wide, such a transformation would bea tough challenge. For one thing, BAThad more than 1,000 IBM LotusDomino applications, and many of itsdevelopers were more versed in Domi-no than Web services, .Net, or J2EE.

“We needed a way to make our exist-ing development teams productive inSOA from the word go, allowing them

“You really need the right humanresources and skills deployed.”

— Gavin Targonski, British American Tobacco

46 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

BAT Builds SOA One Step at a Time

to develop and consume Web servicesas, and when, they needed to,” Tar-gonski says.

The right toolset came in the form ofSkyway Software’s Integrated ServiceManagement platform — now knownas Skyway SOA Platform. Its Buildermodule provided developers with amodel-driven, codeless developmentenvironment that could automatically

generate standard J2EE Web services. “Skyway embeds an SOA approach in

the core of their tools,” Targonski says.“The ways in which objects are exposedand externalized to the runtime arealready SOA-enabled, so developers canbuild SOA apps without having to thinkabout all those issues, such as whatSOA means and how to do it. It makesSOA a no-brainer.”

Skyway’s product also provides SOA

Finance app

Dashboard app

Scaling Across the EnterpriseBAT’s SOA abstracts legacy system functions and data as a set of core Web services consumedby its dashboard and finance applications.

Blue Titan Director Fabric(Web services routing, mediation,and management)

Cast Iron Application Router(back-end integration)

WEB

SERVICES

Legacy system

WEB

SERVICES

Legacy system

XML/SOAP

XML/SOAP

governance and service managementtools. Rounding out BAT’s SOA infra-structure are an application router fromCast Iron Systems, which provides thestandards-based back-end integrationplatform, and Network Directorswitches and servers from Blue Titan,which provide Web service routing,mediation, and management.

Early successes have demonstratedthe value of SOA to BAT’s business.Now SOA’s proponents within the com-pany are in the process of getting thenews out to the development teams andbusiness units, including providing areference implementation to make SOAdevelopment an accepted practice inthe organization. According to Targon-ski, that can’t happen fast enough.

“We need to get better at getting thegood news out more quickly. It’s easyto forget the value we’re addingbecause of the speed in which we’redeveloping applications, providingprototypes, and approaching newbusiness requirements with a differentperspective,” Targonski says.

Targonski also points out that withsuch quick development cycles it’simportant to get a handle on how farSOA should go — and how quickly. “Dowe charge on or make sure the opera-tional aspects are in line first? Wedecided we have to be certain that whatwe create is supportable and maintain-able and that we can manage servicesfrom birth to death. It’s easy to forgetthe guys who have to support this stuffand make the datacenter work,” he says.

One side effect of scaling SOA hasbeen that BAT’s IT organization hashad to start reinventing itself. “All of asudden, you don’t have a database guy, anetwork guy, and a mainframe guy allworking on their own,” Targonski says.“All their skill sets have to be pulledtogether because a Web service has so

GA

RY

ST

RE

NG

Some of those customers becamebeta testers, migrating from Sabre’sdesktop products or their own screen-scraping desktop applications to prod-ucts that could consume Web services.Meanwhile, Sabre started analyzing itscustomer usage metrics.

“We have a lot of data that helped usdetermine what might be interesting as aWeb service. Then, we’d go out and vali-date our ideas in customer meetings andtake their feedback,” Richmond says.

As it turns out, Sabre’s customerswere divided into major camps. “Somesaid, ‘Just expose each individual hostcommand as a Web service, and I’ llbuild the apps to aggregate them.’ Oth-ers said, ‘I don’t want to know about thehost and the back end. Just show methe flights, select the flight, price it, sellit, and ticket it in high-level Web ser-vices,’ ” Richmond explains.

So Sabre had to build both capabili-ties. According to Richmond, the com-pany’s first release had 30 or 40 Webservices at the low level and another 30or 40 at the high level. “Now all thosewho asked for the low level are losinginterest as they see what the high levelcan do,” he says.

The architecture is complex. Rich-mond’s team defined very terse XMLdescriptions that are passed to servicesover an IBM MQSeries message queueor within a CORBA message. Sitting ontop of the system are a set of servicesthat manage session, state, and transac-tion flow as data moves from Sabre’sIBM TPF (Transaction Processing Facil-ity) mainframes to open systems andthen back out to the customer.

So far, Sabre has done most of itsback-end integration in-house, althoughit is looking to transition to tools fromSeeBeyond — now a division of SunMicrosystems. Sabre engineers havealso developed an aggregator that takes

“We’d go out and validate our ideas incustomer meetings.”

— Todd Richmond, Sabre Holdings

48 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

Sabre Answers to Customer DemandHow does a technology-driven company with massive performance and

scalability requirements — and incredibly varied customer and supplier

bases — transition to SOA? For Sabre Holdings, the answer was a lot of

in-house development and a complex interweaving of the old and new.

many different touch points to make itwork. You really need the right humanresources and skills deployed.”

For all these reasons, BAT has beendeveloping additional services carefully,targeting key projects to drive SOA andforcing developers to deliver on ROIstatements. Some of these initiativeshave included transitioning BAT’s glob-al messaging backbone from IBMMQSeries to SOA messaging standards

and building a new finance applicationwith a Web services-based UI.

Targonski says that it has also beenimportant to make sure BAT’s SOAapproach is moving in step with that ofits largest technology suppliers, such asSAP, and vice versa. “You’ve got to becognizant that if you leave existingimplementations behind, you’re notnecessarily delivering real value,” headvises. “Evolution, not revolution.”

Sabre’s three companies include theTravelocity online travel service; theSabre Travel Network, whose GDS(Global Distribution System) connectstravel agents and suppliers with travel-ers; and Sabre Airline Solutions, whichsupplies reservations and other servicesto major airlines.

Sabre launched its SOA initiative in

2002, largely in response to requestsfrom its larger customers. “We werepushing Web services to lower ourcosts, but [customers] were major dri-vers on what functions would be first onthe list and how we’d work out securityand business issues,” says Todd Rich-mond, Sabre’s vice president of strate-gic architecture.

Sabre customer

Sabre’s SOA Takes FlightSabre’s SOA abstracts in-house IBM TPF and NonStop reservation systems and data and presents themas Web services based on the OTA’s XML standard. It also consumes and presents XML content fromsuppliers. Orchestration, management, and integration functions were all developed in-house.

Legacy TPFsystem

In-house session managerand aggregator

- Session management- State management- Transaction flow management- Rules engine- Service orchestration

WEB

SERVICES

Third-partyservice

WEB

SERVICES

Legacy NonStopsystem

Internet

Sabre customer WEB

SERVICES

an incoming request, parcels it out tothe appropriate servers and applica-tions, and uses a rules engine to tailor aresponse based on the particular cus-tomer’s contractual agreement.

Many customers receive messagesfrom Sabre as standard XML based onthe Open Travel Alliance (OTA) stan-dard (infoworld.com/3457). Others stillconnect over the same private links theyused in the past, including teletype, X.25connections, and an old UN/EDIFACT(United Nations Electronic Data Inter-change for Administration, Commerce,and Transport) standard. This mix ofnew technologies and legacy systemshas proved challenging in many ways.

“We sent our TPF and assembly lan-guage programmers to C++ schoolbecause we thought that object-orient-ed methodologies wouldn’t be difficultfor people so experienced in the appli-cation,” Richmond says. “The result isthat we made some of the commonerrors that novice object-oriented pro-grammers make and did some otherstupid things. Now, we’ve had to goback over it all and do a better job.”

Richmond says Sabre also learnedover time that someone has to have anend-to-end view of transactions inorder to ensure that infrastructure andapplication developers will worktogether to troubleshoot customer

problems. Still, many challenges still lieahead in Sabre’s ongoing SOA efforts.

“We have substantial transactionsthrough our Web services gateway,”Richmond says. “Do we push all theway off TPF or continue investing inTPF for the parts that run effectivelythere? What we do with SOA is verymuch tied to that decision. We also havea lot of mom-and-pop travel agenciesthat are not necessarily interested inWeb services and airlines with interna-tional locations [that are] still using386 systems over 2400-baud lines. Ourstrategic vision is there, but the rate atwhich we get there is in flux based onthese business realities.”

GA

RY

ST

RE

NG

“We had to do a lot of retraining and evangelismabout SOA principles.”

— Christopher Crowhurst, Thomson Learning

50 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

vices, and working out how to exposethose services in a granular, extensibleway so that you’re not constantly break-ing consumers’ interfaces — we learnedthat many people just can’t do it.”

Thomson Prometric, a division ofThomson Learning, is a leadingprovider of technology-based testingand assessment services, includingGRE, TOEFL, GMAT, and Cisco certi-fications. In total, it administersapproximately 4,000 tests to 8 millionpeople in 120 countries worldwide.

The company grew via acquisitions ofmany smaller testing companies, eachof which came with its own test centersand test scheduling and registrationsystems. Radical change was needed.

“I was sitting in a meeting with anumber of project managers talkingabout how to enable cross selling andreduce the number of contact center

Thomson Prometric Rethinks Processes

applications, when suddenly there wasa eureka moment in which we realizedwe could create an abstraction betweenall the different applications usingXML. This triggered a whole process tocomplete the design and was the gene-sis for thinking about a whole SOAenvironment,” Crowhurst says.

At first, Crowhurst presented the ideato Thomson Prometric CEO MichaelBrannick as a way to save money, butBrannick had different goals. “He under-stood the power of what we were doingand kept challenging us to do more,”Crowhurst says. “He said, ‘I don’t wantyou to save me money. I want you tomake me money.’ It was very challeng-ing, but a great time to be involved.”

As the SOA project got under way,Crowhurst’s team spent many painfulmonths analyzing core businessprocesses and attempting to identify the

services necessary to support them.Eventually, Crowhurst and his staff cameup with five services, which he calls Who,What, Where, When, and How.

“Who is the customer; What examswill they take; Where and When willthey take them; and How will we collectthe fee — all our registration systemsperformed those functions in one wayor another,” Crowhurst says.

The next step was to define an XSD(XML Schema Definition) thatdescribed those processes and to builda set of SOAP interfaces. But, accord-ing to Crowhurst, it was also tough toget everyone’s hands around REST(Representational State Transfer).

“It requires a very different skill setthan what programmers are used to,”Crowhurst says. “People kept coming upwith fine-grained RPC-style interfacesthat were no more extensible than whatthey were doing back in the CORBA,COM+, object-oriented world. We hadto do a lot of retraining and evangelismabout SOA principles.”

The orchestration tier was built inMicrosoft BizTalk Server 2004, usingits BPEL (Business Process ExecutionLanguage) tools. Tools from Actionalprovide SOA management, while secu-rity is handled by XML gateway appli-ances from Reactivity.

“At that time, all the WS-* standardswere young, so we decided to abstractsecurity, management, and orchestra-tion to the three platforms [Reactivity,Actional, and Biztalk] and let the ven-dors keep up with the latest standards.Now if someone says, ‘I want to use anew security standard,’ or ‘I want to usesurname instead of last name as adescriptor in this field,’ we can justmake a configuration change instead ofdoing a lot of recoding,” Crowhurst says.

The next step will be further consoli-dation. “We can view the business as

Customer

Integrating Disparate Systems Through ServicesThompson Prometric’s SOA abstracts five core functions from its numerous test scheduling registrationsystems and presents them to the user as a single registration interface.

Test schedulingand reservation

system

Reactivity XMLSecurity Gateway

WEB

SERVICES Microsoft BizTalk Server2004 Orchestration

Actional SOA managementframework

Internet

Customer

WEB

SERVICES WEB

SERVICES

Who, What, When,Where, How

“The biggest challenge we’ve faced in creating an SOA has been

identifying exactly what a service is,” says Christopher Crowhurst,

vice president and chief architect at Thomson Learning. “Under-

standing what the business is doing, converting that to a set of ser-

one, but there are still multiple systemsbehind us,” Crowhurst says. “We need tocollapse all those systems, migrate allthose legacy dependences into new ser-vices, and end-of-life the old registrationsystems. We’ve done that successfullywith one, and we have three more to go.”

For shops that are just getting start-ed with SOA, however, Crowhurststresses the importance of acquiring,training, and developing the right peo-ple to get the job done.

“Get a core group of architects andsenior developers to understand,embrace, and buy into the strategy,” hesays. “And train. SOA requires a com-plete change in process and thinking.”

Verizon Goes Back to the WorkbenchTo overcome its SOA roadblocks, Verizon had to build an entire SOA

operational infrastructure virtually from scratch — and it has the

patents to prove it. “As a technology, Web services are great, but today’s

standards don’t have nearly enough operational infrastructure

around them,” says Shadman Zafar,Verizon’s senior vice president ofarchitecture and e-services. “You canend up with a plethora of Web servicesbut no awareness of which of them arewhere and provide what function —and most important — which have theright kind of capacity and SLA to beusable by what and whom. The result

is that SOA risks simply becoming atoy for the developer.”

As have many other SOA implemen-tations, Verizon’s started after a merger— in this case, the GTE/Bell Atlanticmerger that created Verizon.

“I was tasked to integrate the two ITdepartments to achieve strong synergytargets,” Zafar says. “During our initial

ADVER

GA

RY

ST

RE

NG

research, we found that many of ourcore business functions were imple-mented anywhere from five to 30 timesacross different applications.”

Verizon set out to use SOA to reducesupport costs by consolidating thesecore functions from 20 or 30 imple-mentations to one or three, in each case.The first step was to spend monthsidentifying roughly 500 key businessfunctions that were used over and overagain for many applications.

“We didn’t go through 10 millionlines of code. We picked out 500 busi-

ness functions and targeted them,”Zafar says, citing examples such as thecredit check service, the telephonenumber engine that provides new cus-tomers with telephone numbers, andthe address validation service. “Anordering system might go through fouror five of these key components.”

Getting these 500 Web services builtrequired deploying SOA not just as amethodology, but as an IT governanceprinciple. “We implemented a processwhereby all development projectswould have to go through a strategicarchitectural assessment session to get

but also adds management capabilities.For example, if one development teambuilt an address-validation service thatit wanted to expose to other applica-tions, it could download a lightweightagent onto its server that would regis-ter the Web service and its capacity anddefine an SLA inside IT Workbench.

After services have been registered,developers can go to the central directo-ry to find ones with their specific require-ments. For example, they can search fora service with the capacity to support100,000 transactions per day with lessthan a two-second response time and acommitment to be available 99.8 percentof the time from 8 a.m. to 12 p.m.Accounting and billing are also in place,so the service provider can charge forusage — another incentive to use SOA.

“It started with onesies and twosies,”Zafar says. “But when it hit 10,000transactions per month, [SOA] sud-denly took off with exponential growth.Now it’s used in almost 10 milliontransactions per day.”

What’s more, any reluctance toexpose code has virtually disappeared.According to Zafar, developers arenow competing to get others to usetheir services, as a way of gainingrecognition within the company. Themost-used services are listed on the ITWorkbench portal with the author’sname and photo.

“Before, people would say, ‘This is mycode, use your own,’ ” Zafar says. “Nowthey’re reaching out to each other overthe weekends, saying, ‘Why don’t youuse this service I built,’ so they can bemore popular on the IT Workbenchportal. In fact,” he adds, “developers aretrying to push applications as Web ser-vices that are not suitable because theyhave few or no logical consumers. It’s aninteresting social phenomenon that Inever anticipated.”

“We picked out 500 businessfunctions and targeted them.”

— Shadman Zafar, Verizon

52 I N F O W O R L D . C O M 1 1 . 0 7 . 0 5

approval before they were started. Ifany of the functions were one of those500 core business functions we hadidentified, or we found another suitablebusiness object, the team would have toimplement it as a Web service. Once theproject was completed, it would gothrough a tactical architectural assess-ment session that would verify the Webservices were built before giving clear-ance to go into production,” Zafar says.

But as developers began buildingWeb services, the operational road-blocks became clear. “There was a lot of

resistance to using the services becauseof the lack of standards around fouressential operational pieces: SLAs,accounting, billing, and capacity man-agement. People weren’t willing toentrust their mission-critical applica-tions to each other,” Zafar says.

Developers were also very reluctant toexpose the code they had worked so hardto produce. In many cases, one develop-er wouldn’t even know what infrastruc-ture the other Web services were using.

To address these issues, Verizon builtIT Workbench, an infrastructure layerthat houses the Web services directory

Portals(intranet,extranet)

A One-Stop Shop for IT ServicesVerizon’s IT Workbench system allows developers to locate services and register their own, completewith service-level agreements that establish charge-back fees for service usage.

Plug-inservices- Security- Orchestration- Logging- Performance- Usage- Notification- Configuration

WEB

SERVICES

Packaged apps

Distributed runtime brokers

ERP, financials, others

WEB

SERVICES

.Net, J2EE

Verizon apps

B-to-b(apps,

interfaces)

SOAPSOAP

IT WORKBENCHSOAP

SOAP

Service consumers

Service consumers

APPLICATION FOR FREE SUBSCRIPTION

Apply online at: http://subscribe.infoworld.com

A. MAILING ADDRESS Publisher reserves the right to limit the number of complimentary subscriptions. Free subscriptions available in the U.S. (including APO and FPO) and Canada

NAME

TITLE

COMPANY NAME

DIVISION / DEPT. / MAIL STOP

MAILING ADDRESS

CITY / STATE / ZIP / POSTAL CODE

Is the above address a home address? q 1. Yes q 0. No

E-MAIL ADDRESS

BUSINESS PHONE (INCLUDING AREA CODE) BUSINESS FAX NO. (INCLUDING AREA CODE)

IT / Technology Managementq 01. CTO, CIO, CSO, Vice Presidentq 02. Directorq 03. Manager / Supervisorq 04. Network Manager / Directorq 05. Engineerq 06. Systems Analyst / Programmer /

Architectq 07. Other IT ManagementIT / Technology Professionalq 08. Consultant / Integratorq 09. Developer

q 10. IT Staffq 11. Other IT Professional Corporate / Business Managementq 12. CEO, COO, President, Owner,

Vice Presidentq 13. CFO, Controller, Treasurerq 14. Directorq 15. Manager / Supervisorq 16. Other Business Management Title

q 98. Other Title

(specify)____________________________

2. What is your primary job title? (PLEASE CHECK ONE ONLY)

General Business Industriesq 01. Defense Contractor / Aerospaceq 02. Retail / Wholesale / Distribution

(non-computer)q 03. Pharmaceutical / Medical / Dental /

Healthcareq 04. Financial Services / Bankingq 05. Insurance / Real Estate / Legalq 06. Transportation / Utilitiesq 07. Media (print / electronic)q 08. Communication Carriers (telecomm,

data comm., TV / cable)q 09. Construction / Architecture / Engineeringq 10. Manufacturing & Process Industries

(non-computer)q 11. Research / Development

Technology Providersq 12. Service Provider (MSP, BSP, ISP,

ASP, etc.)q 13. Computer / Network Consultantq 14. Systems / Network Integrator, VAR / VADq 15. Technology Manufacturer (hardware,

software, peripherals, etc.)q 16. Technology - Related Retailer /

Wholesaler / Distributor

Government / Educationq 17. Government: federal (including military)q 18. Government: state or localq 19. Education

q 98. Other

(specify)____________________________

5. What is your organization’s primary business activity at this location? (PLEASE CHECK ONE ONLY):

Software / Products / Technologiesq 01. Customer Relationship Managementq 02. Enterprise Resource Planningq 03. Business Process Management /

Outsourcingq 04. Business Intelligence / Data Mining /

Data Warehousingq 05. Portalsq 06. Financials / Payroll / Billingq 07. Performance / Application Managementq 08. .NETq 09. Other Softwareq 10. Networkingq 11. Web Servicesq 12. Content Delivery Networksq 13. Network and Systems Managementq 14. VoIP (Voice Over IP)q 15. Telecommunicationsq 16. Wirelessq 17. Remote Access

q 18. Web / Video Conferencingq 19. Storageq 20. Disaster Recoveryq 21. Securityq 22. Anti-Virus / Content Filteringq 23. Firewallq 24. VPNq 25. Identity Managementq 26. Authentication / Authorizationq 27. Intrusion Detection & Preventionq 28. Encryptionq 29. Other IT Products / Technologies

Hardware / Peripheralsq 30. Serversq 31. Notebooks / Laptopsq 32. PDAs / Handhelds / Pocket PC /

Wirelessq 33. Printersq 34. Other Hardware / Peripherals

4. Are you involved in buying, specifying, recommendingor approving the following IT products / services?(PLEASE CHECK ALL THAT APPLY):

I wish to receive a free subscription to InfoWorld. qYes q No

SIGNATURE DATE

GET TECHNOLOGY RIGHT

7. Which of the following operating systems are in useor planned for use at this location?(PLEASE CHECK ALL THAT APPLY):

q 01. Windows XPq 02. Other Windowsq 03. Mac

q 04. Linux / Unix / Solarisq 05. Other

(please specify) ___________________

B. CONTACT PREFERENCESYou may receive a renewal reminder via e-mail. May we send other information about InfoWorldproducts, services, or research via e-mail? q 1. Yes q 0. No

We occasionally send our subscribers email messages with news about technology solutions andspecial offers from qualified third parties. Would you like to receive these messages?

q 1. Yes

IT / Technology Functionsq 01. Executiveq 02. Department Management - ITq 03. Networks / Systems Managementq 04. Applications Developmentq 05. Management of Enterprise Applications

(CRM, ERP, SCM, etc.)q 06. Research / Development Managementq 07. Consultant / Integratorq 08. Other IT Functions

Corporate / Business Functionsq 09. Executiveq 10. Department Management - Businessq 11. Financial / Accounting Managementq 12. Research / Development Managementq 13. Sales / Marketing Managementq 14. Other Business Functions

q 98. Other Functions

(specify)____________________________

3. Please indicate your job function(s)? (PLEASE CHECK ALL THAT APPLY):

1. Over the course of one year, do you buy, specify,recommend, or approve the purchase of the followingproducts or services worth: Please include amounts for all locations of your organization. Consultants: please include what you recommend foryour clients as well as what you buy for your own business.

01. $100 million or more02. $50,000,000 to $99,999,99903. $30,000,000 to $49,999,99904. $20,000,000 to $29,999,99905. $10,000,000 to $19,999,999

06. $5,000,000 to $9,999,99907. $2,500,000 to $4,999,99908. $1,000,000 to $2,499,99909. $600,000 to $999,99910. $400,000 to $599,999

11. $100,000 to $399,99912. $50,000 to $99,99913. Less than $49,99914. None

Product category Write code in boxLarge systemsClient computersNetworking / Telecom (including servers)WirelessInternet / Intranet / ExtranetSecurityStoragePeripheral equipmentSoftwareService / Support / Outsourcing

q 1. 20,000 or moreq 2. 10,000 - 19,999q 3. 5,000 - 9,999q 4. 1,000 - 4,999

q 5. 500 - 999q 6. 100 - 499q 7. 50 - 99q 8. Less than 49

6. How many people are employed at this organization,including all of its branches, divisions and subsidiaries?(PLEASE CHECK ONE ONLY):

PRIORITY CODE: WW5PDF