Open your eyes

There’s been a constant drum-beat around SOA for the last year or two, growing in crescendo by the day. If the claims are to be believed, SOA is the new IT-based panacea to all business problems, offering a flexible and responsive IT platform aligned tightly with business objectives, enabling companies to be more agile and competitive while improving the bottom line through increased productivity and effectiveness.

It all sounds great – and so it should, given that a lot of the marketing impetus is being driven by interested parties such as vendors with tools to sell and consultants with a new idea to preach. This may be being too cynical, but there certainly does seem to be a level of imbalance in the arguments currently put forward. Perhaps it’s time to restore this balance somewhat.

SOA is actually pretty good…

Having complained about the overly positive positioning of SOA, it may seem a little odd to start off with a recap of the advantages of SOA. However, it is important to be clear on the features and benefits of SOA in order to understand some of the risks.

SOA does, in fact, have a lot to offer companies of all sizes. The fashionable way to express SOA benefits is to focus on the grander benefits such as increased agility, flexibility and competitive effectiveness. While these benefits are very interesting, though, the cornerstones of SOA value are really the increased opportunity for reuse and the architecting of IT components and resources into business services – pieces of business operations functionality that have a clear meaning in business terms. From these two features of SOA, all the other benefits flow.

Reuse is the most important tactically, for a very simple reason. It is easy to measure, and the benefits are simple to assess. If a project can achieve a 20 percent reuse rate, then that is 20 percent of the development costs removed, more or less. At a slightly more intangible level, this level of reuse could also cut the project delivery time, although probably not by the same proportion, and this may result in bringing the project benefit stream forwards with corresponding payback.

Assembling IT resources into business services brings the great benefit of being able to get a clearer understanding of operational performance at a business rather than IT level, and also makes it possible to start assembling new operational flows by combining these business-oriented building blocks – SOA folk call this ‘composite application’ creation. This contributes to faster delivery times, increased responsiveness and better visibility and control at a business level.

So, SOA really does bring value – but what are the risks?

The risks of SOA

Primarily, there are three clear areas of risk when embarking on an SOA strategy.

Failure to meet expectations

The first area is often a direct consequence of the aggressive marketing going on all around SOA at the moment. Some executives have come to believe that this new-fangled SOA technology is going to transform business operations overnight, cutting time-to-market for new projects massively while at the same time enabling the business to respond to challenges in days rather than weeks and months. Another common belief is that SOA, perhaps combined with a business process tool, will result in line-of-business analysts being able to create new process flows without the need for IT involvement at all.

Perhaps this position is a little exaggerated, but there is no doubt that expectations of SOA can be cripplingly high. The reality is that, although it can be argued that the technology makes these things possible, there are two major problems in meeting these expectations. Firstly, the benefits stemming from reuse will grow proportionally with relation to the extent of conversion to an SOA environment. The sorts of benefits often expected will not be achieved until the entire IT installation is moved to an SOA basis. For most companies, this would take years, if it is possible at all. The cost would be enormous, and building the business case to justify the investment would be a huge undertaking.

Secondly, SOA is not just about technology – it is about transforming the way the company works. There are organisational and procedural implications of SOA. Take the example of reuse, the basis of many SOA benefits. Simply providing an environment in which services can be created in such a way that they can be reused will, in all probability, have a negligible effect on reuse levels. Programmers will build them, but will another programmer use them? Will the services be appropriate for use in an application from a different part of the business? Writing reusable code is a million mile away from seeing it actually reused. Companies need to look at cross-departmental design teams to ensure common services end up being of value to all, and then programmers need to be incented to actual reuse these services, both goals that are extremely tricky to achieve.

Impact to service levels

The next area of risk to consider is the potential impact to service levels provided by IT to the business. For a start, any time anything is changed there is a risk of introducing errors. But there are more sinister risks lurking within SOA initiatives. Perhaps one of the most insidious is the danger of addressing service definitions from the bottom up rather than the top down. Architects might get really switched on to the SOA idea of business services as reusable building-blocks, and take the view that every individual piece of business functionality should become an SOA service. Architecturally, this is a pure picture, with any operation being possible through the assembly of a range of minimum-level building blocks. But in operational terms, this could prove a complete disaster. SOA interfaces usually require information to be placed into a standard format, and may also be running remote to the requestor, with a resulting overhead. Breaking everything up into the smallest possible pieces may therefore accumulate these overheads with unacceptable results. Also, the large number of services resulting from this approach will swiftly become unmanageable, with reduced levels of reuse and a high degree of general confusion.

The trick is to always start from the business requirement and work down. In fact, considerable thought is needed about what the services to be built should be. If reuse is to happen, they must satisfy the needs of all departments, and the granularity must preserve performance levels. But there is still a great deal of risk attached to this process, particularly when the added complexity of organisational considerations is taken into account.

Disruption to working practices

All of the points made here can be seen to relate to the risk of working practices disruption. Programmers must learn to look for reusable services early in their projects, but then have some way of understanding the operational impacts of using these services. Service-level agreements may well be needed at the service level rather than a coarser application level. Governance mechanisms need to change to accommodate the complexities of trying to generate reuse across departments. Analysts may need to be educated in the use of the high-level composite application tools, but must also understand the responsibilities to other areas. Indeed, SOA success is almost certain to require a large element of education across the board.

SOA promises many benefits, but it is not without its associated risks. However, in more general terms SOA can actually have a positive effect on risk, by providing a system that is more responsive and less hostile to change. Change always brings an accompanying level of risk, whether through market or internal imperatives or external sources such as legislation and regulations, but if companies can reduce the impact of these changes, then these risks can be mitigated to some extent. The key with SOA is to cut through the hype and be realistic about the risks it introduces.

Steve Craggs is Vice-Chairman of the Integration Consortium and President, Saint Consulting Limited.