nologies that will stymie future interoperability or expansion.

Taking inventory is a multistage process. First, you need to document the data sources and existing applications that will be involved in your initial deployment — remembering to identify partner services outside the firewall that you may need to connect with and to catalog those services as carefully as you do internal ones. Second, take stock of technology you have on hand that will play a role in your SOA. Yes, this is a big job, and no, it’s not necessary to complete it before moving toward an initial project. But neither can it be ignored if SOA, rather than a limited project, is your goal.

An SOA involves a sprawling set of technologies. The short list: tools to build or provision those services; a registry in which to expose them; a messaging infrastructure over which services and applications will communicate; a means of orchestrating services; and some sort of services management involving intermediaries. Application-layer networking 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 take a hard look at the Web services interfaces of your commercial enterprise apps.

That’s quite a stack of stuff, but you don’t need to make sweat-inducing technology decisions about what you’ll change, add, or keep quite yet. You’ll be busy enough figuring out how to map and normalize data among the 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 that metadata is hard, tedious work.

If you’re not an SOA expert and are leery of hiring a consultant, don’t despair. There’s no need to run to the Learning Annex for a crash course. Get as far as you can. If your enterprise consists of little custom code and mostly off-the-shelf software, contact your software vendors one at a time. Ask about their SOA plans and capabilities. Often, you’ll be pleasantly surprised by their direction — and you may obtain valuable information that will affect project scheduling and future platform choices.

“We moved our product portfolio towards SOA specifically because our customers asked us to,” says Dwain King-horn, CTO of Altiris, a large manufacturer of asset, net-

work, and security management platforms. “It allows our customers to free themselves from our management consoles. They can now grab specific pieces of management data and incorporate those into any SOA-based management dashboards they may have developed on their own.” — Oliver Rist

 

Steps to SOA No. 4:

Connect your first services

Time to get your feet wet. Take that whiteboard map and focus on one area as a pilot project. Identify a key point of redundancy in your set of related applications, spec out your first service, decide who will build it with what tools, and start provisioning. After testing, you can start modifying apps to call your new, shared service.

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

Scott Thompson of H&R Block learned the value of the coarse-grained approach the hard way. “I think in our early design, we tended to develop services that were more in tune with our object layer than they were true business services, and so the reusability of those wasn’t quite as high as what we had liked it to be,” he says. “So we’ve gone back and redesigned a lot of our services to be more reusable, not only to a specific project but really more in tune with the business purpose that they were designed to serve.”

Several stovepipe applications, for example, may have their own way of opening a customer account. Create a single coarse-grained service that each application can call on to open an account, and you eliminate redundancy and reduce application maintenance. Along the way, you may be able to glean other benefits: better compliance information, more security across a single repository rather than multiple data dumps, and better Web site management.

Typically, services are published as Web services —- which promises the greatest potential for reuse because the