Last week, I shared with you how integration played a key role in the case study recently chosen as the winning entry in an SOA implementation contest sponsored by CIO.com and the SOA Consortium.
CIO.com ran an article examining the winning entry. Unfortunately, that article didn't mention the runners-up or provide any real big-picture lessons from the contest. Mike Kavis followed up late last week with a big-picture piece looking at what the entries had in common. It originally ran on CIO.com, and was republished this week on IT World.
Kavis identified eight characteristics among the contest's successful SOA implementations. If your bread and butter is following SOA, you probably won't be surprised by his findings. But, for the rest of the world, it's a really great resource that nicely addresses a lot of the ongoing debate about how to approach SOA.
In fact, this list of eight characteristics really is a sort of Cliff Notes summarizing the past two years of discussion about implementing SOA.
For instance, Kavis noted that all of the projects had strong sponsorship from high-ranking individuals from within IT or business or both. He wrote:
"Without top-level support, many SOA initiatives never get the momentum, the resources and the drive required to allow IT to deliver the promise of SOA to the business. It was also noted that a strong SOA evangelist was highly critical for each of these award-winning case studies. In fact, research shows that in instances where SOA evangelists leave a company, the company has a risk of failing with future projects or regressing back to the previous methods of delivering software."
This may seem obvious, but it's not widely practiced. In fact, one Software AG survey found that many CIOs were MIA from SOA initiatives. Research by Anne Thomas Manes had already indicated that CIOs could make a difference, but here again we have further proof that SOA needs high-level support and buy-in.
Another common factor for SOA success: educating the business about the value of SOA.
When I first started writing about SOA, this was a hotly debated notion, but I think most people now know SOA isn't just an IT initiative. I hate to say I told you so... well, no, actually I don't. I told you so. You've got to talk to the business about SOA.
Now, that's not to say you should be selling SOA per se -- education is not the same thing as marketing. As Kavis points out, you don't even have to use the words "service-oriented architecture" if you don't want to -- although, personally, I think business leaders can handle it. But you do have to get across the message that you're doing something new that will deliver long-term benefits to the business:
"Instead the business needs to understand the key business drivers that are being addressed (quicker access to information, integration with customers and partners, eliminating wasteful business processes, etc.) on how IT has some 'new methods' for helping to deliver these drivers. The business doesn't necessarily need to know how IT will do it; they need to understand which of their problems SOA solves and what is required from the business to help IT solve them."
This dovetails into another common characteristics: These SOA success stories delivered substantial business value, beyond the value experienced by IT.
People tend to think of SOA as something that's good for IT, because it will cut development time or make IT efficient in other ways. Hey, if it's good for IT, it's good for business right? Uhm, sorry -- thanks for playing, but that's not enough. Kavis found that these SOA success stories all delivered more value to the business itself than IT:
"These may have been some side effects, but the value of the IT benefits are minuscule as compared to the business benefits which in some cases were in the billions of dollars over a given time period."
The remaining characteristics include: Establishing a center of excellence. It's reassuring to know it doesn't necessarily need to be an SOA center of excellence, but some type of governing body or group that can oversee the SOA initiative. Start small, with a well-defined business process, then build up. It's important to note that each case study had a well-defined scope, but also a vision they could build up to. Define completeness of work within services. Kavis' wording is a bit confusing here, but essentially this speaks to how you define a service, which can be really tricky. The big warning here: "Successful SOA implementations focus on a small number of core business services that provide real business value and don't waste precious time and money on services that don't have the payback." Don't forget about quality assurance. Just as SOA brings unique testing challenges, it changes your quality assurance requirements. Kavis includes a link to an article offering more details about how. ROI is difficult to achieve and takes time. Gartner contends that ROI is the wrong question for SOA, but some of these companies did achieve a substantial, measurable ROI. Others did not, at least in the short term. The point here is, this is not a technology investment -- it's an architectural shift. Promising an immediate ROI is just not practical with SOA.