Getting more than integration from SOA

More than merely linked web services, SOA has the potential to enable IT and the business to talk and collaborate using a common language

1403P32_150.jpg

More than merely linked web services, SOA has the potential to enable IT and the business to talk and collaborate using a common language.

Service oriented architecture is about much more than integration using web services technologies - it has the potential to enable IT and the business to start to talk and collaborate using a common language.

There are four steps involved in getting to this common language: using SOA to increase software flexibility, increasing software reuse, increasing the comprehensibility of IT to the business, and increasing the visibility of the value of IT.

The first two steps are the most talked-about aspects of SOA, and they are closely related. The first is basically about using SOA simply as a way to carve up existing applications, and develop new systems in a modular fashion, so that changes are potentially localised and the impact minimised. The second is about organising a portfolio of services so that as many of them as possible can be shared across multiple systems.

However, contrary to what might seem to be the case based on suppliers' marketing material, implementing an SOA initiative will not automatically yield improved software flexibility and reuse - there are important principles and practices which need to be applied and which have nothing to do with technology per se.

A big part of the value of service orientation is the ability of services to represent what a business does. If you do not understand the nature and structure of the business processes that are going to make use of software services once they are published, those services do not stand a chance of fitting the needs of the business.

The nature of SOA is such that individual services can, and should, be applicable to more than one system and more than one business process. This is a big part of the reuse promise of SOA. But it means that looking at service requirements purely within the context of a short-term system or business process requirement will miss wider opport- unities to generate value from your investments.

To ensure that broader and longer-term requirements are taken into account when services are being designed, full-time skilled architects who are available to all integration and development projects in your SOA initiative should be engaged.

The architects must be more than glorified software designers: they must have the responsibility of balancing short and long-term business requirements in the context of your IT delivery capabilities, which means they must sit squarely between IT and the business, talking to and understanding the needs of both.

And along with that responsibility, they must have the authority to influence the way that services are implemented and deployed. In other words, an architecture team that is seen purely as a "team of clever people we can ask questions of" is not going to be nearly enough.

Given the potential of SOA to make IT as a whole more service oriented, it might be tempting to attempt to recast the whole of your IT organisation's application portfolio as networks of collaborating, loosely coupled services. But this way lies madness.

You must focus on the domain in which SOA can yield real benefit, and that is in the area where business meets IT. This domain is increasingly being modelled as sets of clearly defined business processes, which are partly automated through the use of integrated business application software functions.

The ideal "service domain" where you focus your SOA efforts should not extend, initially at least, too far down into business functionality that is already implemented in application software. It should focus on the interfaces between those software functions and the business processes that need to make use of them.

It should also focus in areas where IT flexibility, rather than cost and efficiency, are paramount. That is likely to be in support of business activities and process which differentiate the business.

There are two principles which help to improve the flexibility and reuse of systems and services that are particularly suited to SOA initiatives.

First, create well-defined and distinct layers of services, each of which is responsible for a particular set of tasks (for example, information access logic, business rules, navigation logic, and user interaction and presentation logic), and each of which delegates responsibility for some tasks to the layer below.

Then discover and refine requirements for the overall system, understanding the business processes which will drive the system and its services. Start a "first cut" design with definitions of services within each layer according to the natural boundaries of steps in those business processes.

This will yield an important category of software reuse as a side-effect: reuse of a clearly designed set of infrastructure services (such as state persistence management, identity and access management, workflow, and platform administration and monitoring). These are often delivered within the boundaries of business applications.

The outcome of this "stovepipe infrastructure" is that islands of technology develop which constrain interoperability, inhibit employee and administrator productivity, and make things such as regulatory compliance painful to deal with.

SOA initiatives enable us to deconstruct these application stovepipes, and so redesign the way that infrastructure services are delivered - operating common infrastructure services which work consistently across large parts of the organisation. This aspect of software reuse is one of the important but often-ignored benefits of SOA.

Reuse of existing services in support of new system and business process requirements will not happen by accident - your analyst and development teams will have to take explicit steps to work together to foster reuse throughout the lifecycles of systems and services.

Additional time spent collaborating will cost money, as will tools to facilitate consistent sharing of service analysis, design and implementation information. You need to take some time early on in your SOA initiative to understand how much, and make budget adjustments accordingly.

Neil Ward-Dutton is co-founder of analyst and advisory firm MWD. Next month in Computer Weekly he will examine managing services and service-based systems throughout their lifecycles

Feature article: Clear path to SOA

Leader article: Building an SOA without the hype


 

Read more on Web software

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchCIO

SearchSecurity

SearchNetworking

SearchDataCenter

SearchDataManagement

Close