Steps to SOA No. 3: Survey Your Surroundings
Take careful inventory of existing resources, determining which applications and data sources will be involved in your first deployment.
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 Kinghorn, CTO of Altiris, a large manufacturer of asset, network, 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.”
Eric Knorr is executive editor at large at InfoWorld. Oliver Rist is senior contributing editor of the InfoWorld



