Mike Kavis, Chief Architect, Catalina Marketing, identified eight characteristics of successful SOA implementations. If your have been 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 three years of discussion about implementing SOA.
SOA, has been a hotly debated notion, but I think most people now know SOA isn't just an IT initiative. 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."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."Just as SOA brings unique testing challenges, it changes your quality assurance requirements. 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.
Strong Executive Level Sponsorship and SOA Evangelist
Each project had strong sponsorship from high ranking individuals from the business and/or IT. This is critical for driving change throughout the organization and removing roadblocks. 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.
Educating the Business of the Value of SOA
Each one of the case studies provided an enormous amount of value to the business. In some cases, the return on investment was several billions of dollars over the course of a few years. In order to find these extraordinary opportunities and to build a business case around them, it is critical that the business becomes educated on the promise of SOA.The key to educating the business, however, is not talking to the business about the technology or even mentioning the term service-oriented architecture. 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.
Established a Center of Excellence (CoE)
Every winning case study had some form of CoE established. It may have been called something else, such as a Configuration Control Board, but all had some formal body that was responsible for governing the SOA initiative. Some of these companies already had in place an established Enterprise Architecture complete with IT governance and simply needed to make adjustments for SOA. Others did not have a formal governance plan and had to create one with enough controls in place to deliver the desired business results. The level of control and the scope of each company's governance model were unique, but every successful project sited governance as a key success factor.
Start With Well-defined Business Processes and Scale Up
In each case, candidate services were identified after well-defined business processes were established. In some cases, the business processes were already in place; in others some business processing re-engineering was required prior to creating any services. In each case, the goal was to start with some subset of business processes as opposed to trying to do it all at once. Each case study had a well-defined scope and a vision of what the future state looked like.
Define Completeness of Work within Services
A lot of thought was put into which services were critical to the key business drivers. Business services provided a complete business function.
For example, let's say a core business service identified was a shopping cart function. The goal would be to build in all of the functionality required to make the shopping cart service functional, not just a checkout service. In this example, the complete business service would also need to accept payment, communicate with shipping partners, handle discounts, etc.
Most successful SOA implementations do not have a huge number of business services. This is where a lot of SOA projects run into trouble. They try to make everything into a service, whether it provides business value or not. There is a considerable amount of overhead and costs involved with building, governing, and maintaining services. 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.
Quality Assurance Is Key
As I mentioned in a previous article. SOA creates all sorts of new challenges for the QA department. Successful SOA implementations require that proper QA best practices, such as load testing of each service, is performed. Performance, security and governance testing should be a part of your overall testing plan to ensure that both the business and technical requirements are met.
ROI Is Difficult to Achieve Initially and Is Realized Over Time
SOA is not a technology; it is an architecture. Like any other architecture, value is earned over time as the architecture expands and matures. Some of these companies were on their second or third SOA project and were realizing substantial ROI. Others were in their first iteration and did not see immediate ROI but instead were laying down the foundation for future SOA projects to maximize their ROI.
Deliver Substantial Business Value
So for all of the pundits out there who claim that you should never talk to the business about SOA or that SOA is an IT initiative not a business initiative-look at the huge ROIs of these projects and the business transformations that occurred and reconsider those stances. I rest my case!
To summarize, make sure that your SOA initiative shares some if not all of the eight characteristics of successful SOA implementations. There has been so much chatter about SOA failures as of late. Now that we have six great examples of SOA successes, we should take the best practices that these companies used and put them to use in our projects so we can get shot at next year's prize.
