One of the toughtest aspects of the SOA industry is trying to keep track of all the acronyms. It seems like the IT Industry’s Acronym-izer is running at full capacity. Well, a few days ago I came across this article on InfoQ that helps you Make Sense of All These Crazy Web Services Standards. It’s a great article that describes all the standards within the Web Services arena as well as goes into a concise description of each of them. I’ve been looking for a list just like this for way too long…so a big thank you to Michele Leroux Bustamante for creating this article!
[ I’ve been a bit distracted over the past few weeks and haven’t been able to post much. Who knew that just coordinating to put a new roof on your house could be so time consuming (that doesn’t make me look forward to the actual ‘put on’ process). ]
It’s a common notion that things happen in threes. So when I see the same theme three times in a short period I see that as the universe telling me something. Recently, it was telling me about how to make SOA happen.
First, William Henry, a colleague of mine at IONA, found an interesting article that talks about How Sun Sells Its SOA Dog Food To Its Own Employees. While that article is a bit confusing with regards to it’s spin on Sun’s SOA solution (hard to tell if it’s author is positive or negative about Suns JCAPS) the real intent is to talk about how to present SOA to the end user. The article quotes a Senior Manager for Integration Services at Sun regarding how he talks to his internal customers about using the Sun SOA solution to enable re-use within Sun’s IT infrastructure and remove stove pipe applications. The key take away from this article is that even within a large IT Vendor, the people that own IT systems can’t always see the value of SOA. And when they do see the values (i.e., reuse, lower costs, agility) it’s hard for them to want to do SOA.
Second, another IONA colleague and I were talking about funding models for SOA. There are a number of customers that we are working with right now who are in the early stages of a SOA deployment or reaching the first release of a SOA infrastructure. Each of these customers tend to use a hybrid funding approach for SOA. A combination of ‘corporate money’ given to a centralized IT organization to jump start a SOA initiative as well as ‘project money’ or ‘LOB money’ that is used to fund the growth, maintenance, and ongoing support of the SOA initiative by the centralized IT organization. However, even with a funding model in place, a common theme across all these customers is that you need to have a top down driver for SOA within an enterprise to really gain enterprise wide adoption and receive enterprise wide value from any SOA initiative.
Third, today I read a great writeup on the Momentum SI Service Oriented Architecture blog about Talking to the Business about SOA. Jeff from Momentum SI provides a good overview of the fact that when talking to businesses about SOA, you need to talk to your current audience. Any SOA initiative at an enterprise level will cross multiple business areas within the company. Jeff does a good job of describing the differences of key business areas and how you need to keep these differences in mind when talking to them about SOA. I do see one interesting theme underlying all of the business areas discussed…a corporate drive for SOA.
To me, all three of these items point to a single fact: that there needs to be a corporate level driver for SOA in order to truly see the long term value and benefits of a SOA initiative. That doesn’t mean that SOA initiatives can’t be done in small incremental bites, but those bites will only happen if the mid-level person driving them has the political clout over peers to make them happen. Without a high level executive (or corporate) initiative saying “Thou Shall Be”, these small SOA bites will never grow into enterprise returns. The internal politics will eventually stop them dead in their tracks.
(Disclaimer: I currently work for IONA Technologies)
You hear a lot about departmental adoption of SOA and how most SOA deployments are not happening at the enterprise level (see SDTimes article about Will SOA Become The New Siloed App?). While this has been the historical status of SOA—and one of the smartest ways to migrate to SOA in a cost effective manner—there are some enterprises who are forging ahead with SOA, enterprise wide.
For the past two months, I have been working with a large financial institution on an enterprise SOA project. The goal of the project is to increase re-use within the enterprise which will help rein in the IT spend on duplicate application development and migrate code off of legacy systems through the construction of a new services based platform for the enterprise. What do I mean by large? Phase 1 has over 200 external facing services (akin to legacy “applications”) within the project and each service is composed of multiple internal services.
IONA was brought in during the middle of a development cycle to help identify and address various risk areas that were being bantered around by the various development teams. This was accomplished through the use of our Value Assessment Program that I talked about earlier.
One of the interesting things that we found was that there was a problem of trying to do integration testing of all these services. The issue was less about the services themselves and more about the Interface Agreements that governed how a service was used. Since the project was leveraging services based development that had happened in the past as well as service-enabling vendor provided applications, the aspect of service interfaces was a lot muddier than the ideal SOA implementation talked about in books.
The service providers were not creating a services and saying “here’s how you access it”. There was very complex business functionality and message passing that already existed and needed to be migrated to this new platform (which in its own right is an topic for a few discussions). So both the service provider and service consumer were working together to define the interface to a service. And then business happens: new regulations come about, improvements are thought of, changes need to be made. But there was no process or governance behind those interface changes. One side would make a change without consulting the other side. The net effect: a massive service based platform that wouldn’t work the first time it was plugged together and turned on in QA.
This is where the fun starts: internal discussions and finger pointing at where the problem originates. Since there was no process for defining and governing the interface agreements, the environment was ripe for momentum freezing politics which leads to slippages in delivery schedules.
With everything being tracked and reported on within this framework, the status of service development team’s development is visible to everyone in the organization. When politically induced tensions start to drag on the project, transparency can be one of the best solutions.