All this talk about the return of SOA and its continuing importance to IT architectures of the future comes as no surprise. I’ve been arguing for a long time that the best way to architect integration is by building on a common open standards-based adapter framework.
Yes, the type of commentary that is coming out of the likes of Gartner’s Symposium last month makes a lot of sense. Organisations need to get over the hump of economic uncertainty before they will commit the upfront premium associated with architecting systems as reusable services versus the quick fix of point to point integration. And – agreed – RESTful services which are becoming popular reduce the level of that extra investment so the premium is lower.
But there’s an extra dimension to this economic argument that’s sometimes overlooked. We all know that having a standardised way of delivering integration brings a better TCO over a period of time. Taking each individual project as a one-off rather than viewing architecture as a whole is a very short-term view. But in addition most people look at point-to-point integration as a one-off sunk cost, and completely neglect the cost of ongoing support and maintenance.
That’s a big mistake. If there’s a change at one of the connected applications in a point to point integration and the developer who wrote the connecting code has moved on, you have the problem that not only does the integration no longer work, but the cost of fixing it could outweigh the cost of developing it in the first place. As SOA as a design principle matures, organisations are starting to factor in those ongoing costs, if not as a figure on a budget then as a strategic consideration at the start of the project.
And talking of strategy, there is another increasingly powerful strategic argument for the return of SOA that’s striking a chord at CIO level. It’s widely recognised that those who embrace SOA will have an easier time adopting cloud based services – for a number of reasons.
Firstly, things that are best practice when implementing SOA help you take advantage of the cloud hosted technologies. A classic example is SOA governance – this is one thing that is often neglected until a more mature user encounters an issue, but it becomes even more critical when the CIO is held to SLAs on which they rely on a cloud service provider for part of the solution.
The major headache for CIOs with cloud is that they are responsible for SLAs which they are in effect outsourcing to a cloud provider. However, what happens to the CIO when the cloud service they are using goes down (and yes we have seen outages from all of the big boys)? The business still wants its service, regardless of provider.
The integration layer is the only chance CIOs have of mitigating that risk, and gaining visibility. So it becomes a key focus area which has to remain in their control – and of course they need “hot” alternatives – such as the ability to switch over to a different service provider on the fly to mitigate the risk. It’s concerns like these that are bringing SOA to the fore again, and I welcome this renewed interest.