“You don’t get SOA-based flexibility merely by building a library of services,” says Randy Heffner, an analyst at Forrester Research based in Dallas, Texas. “AT&T learned this with its initial try at a Web services strategy, which took AT&T from having a bunch of disconnected, incoherent integration interfaces to having a bunch of disconnected, incoherent ‘standards-based’ interfaces.”
But if the key to realizing the promise of SOA is not in the most obvious implementation, then where is it?
Right Key, Wrong Lock
Merely collecting services is not enough, says Heffner. To succeed with an SOA strategy, enterprises have to shape their service creation efforts within the context of business design and governance.
IT departments must approach the problem from a business-oriented perspective, rather than a technology-oriented one. “Quality management in SOA is not defined as how many defects per line of code you find, but how well the service meets the business requirements,” says Sandy Carter, vice president of SOA and WebSphere strategy at IBM, in Somers, NY.
For example, an enterprise considering SOA must first ascertain whether an existing business process — such as automated credit checking — has already been created by another department in the company or another member of the IT staff. If this service already exists, a company can save time and money by avoiding redundant development efforts. If, on the other hand, IT finds that the automated credit check service doesn’t exist, they can then begin to develop, create and test one.
“By identifying a coherent body of services needed for a given business domain, and by designing each service to deliver a clearly scoped, complete business unit of work, you create an inventory of business services that, in effect, provides a digital model of your business capabilities,” Heffner explains.
Break Down the Business Functions
“Understanding how the business functions is key to identifying which services will succeed in an SOA environment,” says Columbus, Ga.-based Frank Braski, manager of IT Applications Services at insurance giant Aflac. Braski breaks down what he calls “the business taxonomy” into seven data concepts, among which an enterprise “can practically model and define anything,” he says. Those concepts are:
- Relationships
- Parties (people)
- Products (things)
- Agreements
- Locations (places)
- Attributes
- Financial instruments
Unearthing artifacts is essential in every case. Artifacts are the instructions that explain specific business processes and services. This information includes: who owns the service, the performance requirements for the service in production, the current usage of the service, which applications are using the service and who can see the service.
“The key to understanding what business processes exist and how to create new ones is to ensure that the instructions are available in a repository and are easily understood by different parts of the organization, both business and IT,” says Carter.
Successful Services Reuse
Once you have identified the services to be reused and shared, consider refining a common service rather than simply duplicating it. “The best way to get to plain-and-simple ‘use’ instead of the typical so-much-copying-and-pasting ‘re-use’ scenario is to K.I.S.S. — Keep It Simple and Smart,” advises Braski.
“Think Legos,” Braski explains. “Given just a handful of basic building blocks with a couple different styles and colors — presto! You can pretty much create anything you can imagine. Good Lego designers eventually discover a common set of basic ‘tricks’ or ‘patterns’ which they can apply time and again to solve problems common to many building challenges. In systems development, services can be as basic as those plastic building bricks.”
K.I.S.S. also entails keeping the core definition of the service intact. “Designing a limited set of interactions as messages that are completely abstracted from any implementation or technology underpinning allows other technology-centric configuration and policy elements to change around them,” says Sandra Rogers, IDC Program Director, SOA, Web Services and Integration in Framingham, Mass.
As artful as the end product may be, it must still face a reality check. “When several team members revise a document, it soon looks nothing like its original form. A similar situation can occur once a service is in production,” says Carter. “This is why IT needs to conduct continuous monitoring to make sure the service meets the established business requirements.”