November 07, 2005

Steps to SOA No. 2: Go to the whiteboard

It all starts with breaking processes into services in concert with business stakeholders -- before you make any technology decisions

You can’t expect to dissect business processes and see what makes them tick all by yourself. In collaboration with business stakeholders, review and rationalize the processes in the domain you’ve identified. Often, much of the heavy lifting will be done by the business guys, as they scratch their heads and figure out how to restructure processes -- and you determine the breakdown collaboratively and decide where new automation can make a difference.

“We started our process mapping by meeting with each agency individually,” says Dan Thomas, director of the DC Stat program at the Office of the Chief Technology Officer in the District of Columbia. Thomas’ ambitious program is tying together the data repositories of 65 separate D.C. government agencies to give senior officials transparent, up-to-the-minute information with which to make policy decisions.

Thomas’ team met with each agency to map out its data-gathering policies and to find out how that data was distilled for presentation. “It’s a time-consuming process,” he says, “but we didn’t try for all 65 agencies out of the gate. We pared 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 professional services to government agencies, he’s logged an impressive amount of whiteboard time. “We go through full domain decomposition before we even think about services,” he says. At the same time, “you also start looking at what is out there that you might be able to reuse. And then you go into mission or process identification, getting down to a specific thing you want to tackle.”

After the scope is defined, Vibbert says, it’s important to determine who the participants will be. “And once you define those, you start building use cases. Then you start decomposing the use cases. And then you get into resource allocation and data allocation, start naming your services at a high level, and also talk about the data that flows,” he says, emphasizing that these steps are iterative, with multiple passes required to create the right plan of attack.

Every SOA initiative is unique, so the duration of the planning process varies wildly, but Vibbert provides a hint of how long you’ll be sniffing dry-erase marker: “If you already have some pieces of an SOA in place, you can trim down the time frame relatively quickly. An SOA from scratch … it could take months if not longer.”

Sign up to receive Architecture Resource Alerts

Subscribe to the Technology: Architecture Newsletter

The one-stop resource center for IT professionals.

©1994-2009 Infoworld, Inc.