Initial success with a service-oriented architecture (SOA) pilot project does not necessarily mean it will easily scale up to an enterprise implementation, IBM has found based on the experiences of its 5,700 SOA customers.
"What we've been finding is clients may do very well with a successful pilot, but may wind up having problems as they go from pilot to full production," said Marie Wieck, vice president for middleware services at IBM Global Technology Services. To address this problem, IBM is borrowing terminology from the medical and fitness industries in announcing SOA Healthcheck Services.
The analogy Wieck uses is that an SOA pilot project looking at expanding to an enterprise implementation is like a person starting a new exercise program. They look at the signs on the exercise equipment in the gym that tell them they should consult their physician before starting a new workout regimen. IBM SOA Healthcheck Services offers workshops, consulting and even triage to see if the pilot project is healthy enough to move to the next level. It includes recommended best practices to get a possibly flabby project into shape to run a marathon.
Common problems that make it difficult for a pilot to scale up include not considering the hardware and software requirements of large scale SOA on the IT side and not achieving synergy between IT and business people so business needs are met, Wieck said.
On the IT side, for example, the pilot project may not have required much hardware and network infrastructure, she said, but that needs to be a major consideration when the pilot goes primetime.
"They shared a server when they did the initial service and now they're adding more and more users," Wieck said, offering a common example. "Have they accounted for the success they may have? Do they have enough database capacity? Do they have enough network bandwidth? Do they have enough server capacity? As they deploy it out are they planning for these issues?"
In this diagnostic approach, there are also questions that need to be asked about the state of the software, she said. "Are you able to use existing legacy applications? Can you take your existing packaged applications and expose them within a SOA context. In terms of the usage patterns themselves, do you know what services you have? Are they published and available and shared? Are there ways the organization can find these services and use them when they need them?"
On the business side, she said, "You have to be sure that your SOA project is driven by the business." But one of the common problems is how does IT communicate the value of SOA to non-technical business people.
"When you start talking architecture with business teams, their eyes glaze over," Wieck said.
She recommends dropping the architecture when talking to business users and emphasizing the services. It wouldn't be a bad idea to talk in terms of service orientation rather than service-oriented architecture when meeting with the business team.
"You don't need them to understand the architecture or the IT characteristics," she said. "What you really need them to understand is how we think about things as individual services, as units of work. How do you divide them up appropriately so you have the most reuse and have the maximum benefit for the business tasks?"
Wieck recommends using business process management (BPM) as a way to talk to business users about SOA. They can understand the business processes because that is what they are focused on, she said. Technical discussions of things like Web services standards and middleware can be confined to meetings of the IT team.
Based on IBM's studies of what it takes to successfully move an SOA pilot into an enterprise implementation, Wieck said, "It's clear that the right pairing of business and IT is key to best practices. It's just do you have the right language for describing that linkage between the business and IT."