The problem is actually more far-ranging than this manifestation alone, and is at an altogether more fundamental level - at its heart it is all about the business audience not appreciating the value of SOA.
There have been a range of approaches to justifying SOA to business users (as opposed to the technical community) over the last few years. Some of the more popular have been
- SOA delivers business agility
- SOA reduces time-to-market for new projects
- SOA reduces costs by reducing application maintenance and new development effort
The second point reflects the reduced development and testing times coming from the combination of a cleaner architecture which reduces complexity and hence makes change easier, and the reuse aspect of SOA that improves code quality and limits the amount of new code required for each project. Finally, there is the reuse factor itself. Elimination of redundant code, replacing it with a single SOA service, reduces the overall code needing to be maintained and hence lowers maintenance costs, while development costs are reduced through the ability to satisfy new project needs through a combination of existing components and minimal new code.
On the face of it, these seem powerful arguments. But the fact is that these messages are not gaining traction. Looking at things from the business audience perspective gives valuable insight into why these types of justification aren’t working, and perhaps hints at how the problem can be overcome.
The main problem is, the business user has heard it all before. How many times has IT come to the table promising more agile systems, better responsiveness, faster delivery, more flexibility, reduced costs and so on? Remember EAI? Web Services? OO? For many users, there has also been a constant background theme of enterprise architecture renewal in general. But each one of these miracle cures seems to have come up short, requiring considerable investment without delivering the promised benefits. In essence, business users have become far less trusting of grandiose IT-driven promises.
Exacerbating the situation is the fact that many of the SOA benefits discussed earlier are dependent on a critical mass of SOA deployment already having taken place. So, to get the desired agility, time-to-market and cost improvements, it is necessary to both have enough SOA services defined and built to start to generate returns from service reuse, and also to have enough processes converted to SOA to gain flexibility and adaptability at a practical level. This leads to a chicken-and-egg problem - investment has to be put in to create critical SOA mass, but during this period returns will be no better, and may even be worse. This, combined with the general level of distrust from business people over IT-generated ‘jam tomorrow’ business cases, is the major cause of SOA slowdown.
However, some people are starting to see light at the end of the tunnel. There is an argument for SOA that appeals to the business audience and is not as tied up with the need to achieve a critical mass of services before the benefits start to flow. It’s all based around business visibility.
Stripping away all the hype and spin, SOA is actually not that dissimilar to the major IT architecture initiatives of the past. Functionality is packaged into building blocks, as recommended for years by structured programming advocates. These packages are invoked in a standard fashion through a clean interface, as object-oriented programming recommends. Connectivity is provided by using EAI-type technology. But the new piece is that these SOA services are based on business boundaries, not technology ones. Therefore, where previously the building blocks might have been OO objects, carrying out some set of technical operations, with SOA the services represent discrete business functions.
This simple change has profound effects, particularly in the area of business visibility. Since a service represents a piece of business functionality, even in a single project the use of SOA services turns what seems to the business observer to be an inscrutable set of IT program executions into a set of calls between business process steps. Therefore, it now becomes possible to manage and monitor real-time execution in terms of how the steps of the particular business process or sub-process are behaving.
For example, some SOA tools allow service-level agreements (SLAs) to be defined for each service, enabling the business user to specify acceptable behavior with warnings generated when business operations are in danger of being compromised. Similarly, some toolsets offer the ability to monitor service execution in terms of volume and response-time measurements. Not only can this help to ensure smooth operational performance at the business level, but it can make compliance much easier to monitor because instead of IT operations being exhibited as a black box with one input and one output, the moving parts in terms of business operations are visible.
Most technically-minded IT professionals see value in the clean architecture and opportunities for reuse offered by SOA, but getting the business side of the house on board has proved to be an intractable problem for many. But perhaps the benefit of business visibility is the key to moving the SOA agenda forward, offering business users the ability to take a much greater degree of control over business performance and governance. In addition, since visibility benefits start to flow from the first project, as opposed to having to wait for a critical mass of investment, this may help the SOA log-jams to be broken down, allowing widespread adoption and finally delivering the agility, efficiency and effectiveness that all businesses want.
Steve Craggs is a director of Lustratus, a leading infrastructure software market analyst and consultancy firm.
Comments