Returning to basics, SOA is a type of architecture. Using this architecture, it is possible to build many types of system that can deliver benefits, but it is the way the architecture is used that provides these benefits rather than the architecture itself.

SOA permits projects to deliver benefits due to the characteristics that the architectural style possesses. The primary characteristic of SOA that influences the types of benefit that can be delivered is that it enables and encourages the reuse of business logic. In order to deliver value from an investment in SOA, the organization must also use innovation to deploy projects that will exploit these new capabilities.

As has been pointed out many times, we have been reusing business logic in different ways for several decades, but this has been despite the IT architectural styles deployed, rather than because of them. SOA, when well implemented, makes reusability extremely cost-effective. Although every organization will have a legacy that is unique, and some of these will be more difficult than others to enable as a set of technology-independent services, it is demonstrably achievable.

The more difficult step is justifying the costs involved because, as we have just discussed, simply implementing SOA will not bring the scale of benefits required. We therefore need to ask what types of use can be made of SOA to determine the strategy that is most appropriate.

The types of project that have resulted from successful SOA deployments include business process management, composite applications, application integration, event-driven processing, mashups, B2B partner connectivity, redundant application removal, business process outsourcing, and provision of enhanced real-time information. Each one of these can be achieved without SOA, but if SOA has been implemented, each of these becomes simpler, faster, and more cost-effective.

It is often the case that the initial project is required to carry much of the up-front costs of implementing SOA, and this will often mean that the project is more costly and long-winded than using established practices and architectures. However, ongoing projects reap the benefit of the enablement work already carried out, and can show extremely large cost-benefits – but only if the prior SOA-enablement has been conducted with general use in mind rather than the tight constraints of the initial project.

For many organizations, though, escalating SOA to the level of corporate strategy – a requirement if it is to be funded at corporate level rather than by individual project budget-holders – is problematic. Because SOA delivers a capability level rather than a specific benefit, it is necessary to educate business executives in the strategy – and IT has never been good at explaining its potential in business terms.

One way of overcoming resistance to SOA is to conduct a workshop with business and IT executives brainstorming the different ways in which the agility brought about by the reuse of functionality can be exploited. The workshop could then assign actual values to these different benefits, together with evaluating the degree of business visibility and the estimated time to value for each of these. This provides a sound basis for prioritizing projects around SOA, and a more holistic view of the return on investment that should be expected.

All of this pre-supposes that SOA will be implemented in such a way that the reuse of functionality across projects will be achieved in practice, and for this, organizations are advised to use a proven methodology that puts in place the required roles and governance practices.

Source: OpinionWire by Butler Group (www.butlergroup.com)