Setting SOA Expectations
It’s been a while since I’ve blogged (a really nasty sinus infection contributed to that), so this comic seemed appropriate.
Anyway, I, like many other people, did a double-take after I read this blog post from Anne Thomas Manes of the Burton Group. In it, Anne states:
It has become clear to me that SOA is not working in most organizations. … I’ve talked to many companies that have implemented stunningly beautiful SOA infrastructures … deploying the best technology the industry has to offer … And yet these SOA initiatives invariably stall out. … They have yet to demonstrate how all this infrastructure yields any business value. More to the point, the techies have not been able to explain to the business units why they should adopt a better attitude about sharing and collaboration. … Thus far I have interviewed only one company that I would classify as a SOA success story.
I’ve always believed that the changes associated with SOA adoption were a long term effort, at least 5 years or so, but it was very surprising to only see Anne only find one success story, although further comments indicated she had only talked to 7 companies. 1 out of 7 certainly feels right to me. Things became even more interesting, though, with some comments on the post which indicated that Anne’s definition of success was, “Has the initiative delivered any of the benefits specified as the goals of the initiative?” She indicated that every company said that their goals were cost reduction and increased agility. My question is how did they measure this?
Another recent post that weighs into this was Mike Kavis’ post on EA, SOA, and change. Mike quotes Kotter’s 8 steps for transformation which include creating a vision and communicating a vision. Taking this back to Anne’s comments, if a company’s SOA goals are increased agility, my first question is how do you measure your agility today? Then, where do you want it to be at some point in the future (creating the vision)? If you can’t quantify what agility is, how can you ever claim success? Questions about success then are completely subjective, rendering surveys that go across organizations somewhat meaningless. While cost reduction may appear to be more easily quantified, I’d argue that many organizations aren’t currenlty collecting metrics that can give an accurate picture of development costs other than at a very coarse-grained level. It would be very difficult to attribute any cost reduction (or lack thereof) to SOA or anything else that changed in the development process.
This brings me to the heart of this post- setting expectations for your SOA efforts and measuring the success of your SOA journey is not an easy thing to do. Broad, qualitative things like “increased agility” and “reduced costs” may be very difficult to attribute directly to an SOA effort and may also fail to address the real challenge with SOA, which is culture change. If culture change is now your goal, then you need to work to describe the before and after states, as well as some tactical steps to get there. In a comment I made on one of my own posts from quite some time ago, I spoke of three questions that all projects should be asked:
- What services does your solution use / expose?
- What events does your solution consume / publish?
- What business process(es) does your solution support?
The point of those three questions was that I felt that many projects today probably couldn’t provide answers to those questions. That behavior needs to change. Now while these were very tactical, they were also easily digestible by an organization. The first step of change was simply to get people thinking about these things. The future state certainly had solutions leveraging reusable services, but I didn’t expect projects to do so out of the gate. I did expect projects to be able to tell me what services and events they were exposing and publishing, though.
This type of process can then lead to one of the success factors that Anne called out in her comments which was the creation of a portfolio of services. Rather than starting out with a goal of “cost reduction” or “increased agility”, start out with a goal of “create a service portfolio.” This sets the organization up for an appropriate milestone on the journey rather than exclusively focusing on the end state. Without interim, achievable milestones, that end state will simply remain as an ever-elusive pot of gold at the end of the rainbow.
5 Responses to “Setting SOA Expectations”
Leave a Reply
Good article. I think the big issue here is many comapnies don’t have a compelling business case. They sell SOA on agility and reuse, things that are hard to quantify.
http://blogs.ittoolbox.com/eai/madgreek/archives/making-the-case-for-soa-23213
It sums it up really. SOA is really nothing new. It maybe gives IT a focus and lots more $$$ but it’s plain wrong to treat SOA as a panacea. SOA is an extension to IT dreams and goals, some right and some wrong.
Interesting comments from Anne. I’m not sure talking with 7 companies of which probably have a relationship with Burton is overly scientific but still probably not far off the mark. SOA is starting to kind of remind me of a recession. Nobody is sure when you are in one and nobody is really sure if it is a good thing or bad thing.
Todd, You outline three great questions (i.e. 1.What services does your solution use / expose? 2.What events does your solution consume / publish? 3.What business process(es) does your solution support?
) which should be incorporated in every project architecture design review and hopefully lead to a service portfolio perspective.
Anne and I have talked with hundreds of companies over the last five years. The companies encompass well-known industry brand names across financial services (i.e. banking, insurance), retail, telecommunications, airline, hotel, government, education, and health care verticals. In the past, client conversations revolved around us answering tactical and strategic stakeholder questions (i.e. What ESB is right for me? How should I implement SOA security? What is a good roadmap?) and only indirectly gained insight into the ‘health’ of the organization’s SOA initiative. A snapshot of our recommendations was published in the SOA Enterprise Roadmap document which is available for free download.
We are taking a different path this quarter to interview clients and let them do most of the talking about their SOA initiative, roadmap, success, and challenges. Yes, the sample size using the current methodology is small, but the conversations we are having today don’t contradict hundreds of prior conversations over the last few years. Our ‘state of the union’ message published in July 2005, ‘SOA Reality Check’ where we stated ‘SOA requires good planning, and it requires a willingness to change.’ still holds true.
We have talked with bright, articulate, and successful individuals who have established certified SOA platforms, built services, and had success with opportunistic Service-Oriented Integration. SOA initiatives are having modest success measured in IT technology infrastructure wins (selecting and deploying next generation middleware) and enabling interactions between systems (e.g. Service Oriented Integration). We are finding that progress towards SOA nirvana is as slow as expected – as Todd mentions, no surprise. But we are also astonished that many IT executives are repeating the ‘reduce cost and increase agility’ mantra without instituting formal metrics.
If your SOA initiative has truly delivered measurable agility improvements and significant cost reduction, we would like to discuss your experience. All conversations are kept confidential. You can reach me at chaddad@burtongroup.com
Stay tuned for more findings……
[…] a solution for my stakeholders and my users, and not think about anything else. In past posts (here, here), I’ve talked about three simple questions that all projects should start thinking […]