SOA In the Enterprise Lives

(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.

IONA had seen this before while working with similarly scoped projects in global financial and telecommunications companies. We have developed a customizable solution framework composed of IONA IP, best practices, and industry experience that is capable of providing the process and governance around the creating of the Interface Agreements during the requirements stage of the SDLC as well as governance of those Interface Agreements during development and testing. This framework was designed to solve just this problem.

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.