Capitalising on the opportunities of SOA

Service oriented architecture (SOA): An SOA can help IT become more responsive to business needs, but confusion about the approach means some fail to realise its potential.

tech-2_0702_150.jpg

Service oriented architecture (SOA): An SOA can help IT become more responsive to business needs, but confusion about the approach means some fail to realise its potential.

Service oriented architecture (SOA) was one of the hottest topics in enterprise software in 2005, and it is set to continue to generate a huge amount of interest in 2006, as more and more people look to it to help them deliver IT which is more responsive to the needs of business.

Although some industry analysts predict that SOA is soon to become a mainstream proposition, there is still a lot of confusion and misunderstanding in the industry about what SOA is and why it is important.

The more misunderstanding there is, the more opportunities will be missed, and the more challenges and risks will go unmanaged.

Let's start from first principles. But I won't bore you with talk of Soap, WSDL, UDDI or any one of a hundred other acronyms; instead, I want to concentrate on a broader perspective of what the "S" and the "A" in SOA mean.

Both "service" and "architecture" have meaning far beyond the context within which most discussion of SOA is taking place.

The idea of a service is something that is relevant not only to how you build, deploy and integrate application software - the "web services perspective" - it is an opportunity to capture and formalise the way in which IT in general is delivered.

Why? Because the concept of a service in the context of IT is something with a long heritage, and there are many perspectives, all of which have value and all of which are going to remain in place, even when Soap (Simple Object Access Protocol) and WSDL (Web Services Description Language) are old hat.

For example, in the world of systems management tools, there has long been talk of service management, which aims to aggregate and abstract operational system metrics to a level where they can be measured against high-level service level agreements defined for business services.

In the world of IT helpdesk tools, suppliers and users talk of service management in terms of improving how IT problems are solved by support staff. In the world of systems integration and consulting, IT services describe things like software development, integration and IT maintenance activities that are carried out by engineers.

In this context, SOA makes the most sense as a way of thinking about IT that explicitly recognises that all IT organisations are service providers, with customers that have a variety of needs. And SOA should help IT departments act in a systematic way that improves the overall quality of the service that they provide to those customers.

Soap, WSDL and their cousins may be merely the mortar that holds the bricks together that make the overall house, but it is the adoption of these standard software interface protocols by the IT industry, coupled with increasing maturity in all the areas outlined above, that makes SOA such a powerful force. SOA can, and should, encompass all the perspectives on "IT service" outlined above.

In our discussions of SOA, we distinguish three types of IT service, all of which play a role in helping organisations get business value out of IT:

  • Business function services. The content of these services is the core of what provides direct value to consumers, by automating aspects of particular business functions.
  • Infrastructure services. These services play a supporting role in delivering value to the ultimate service user, by providing the underlying platform over which business function services are delivered.
  • Lifecycle services. These are the wrapper which in the vast majority of situations provide the real services which IT users experience. Lifecycle services are responsible for the design, implementation, operation and alteration of infrastructure and business function services.

In reality, all these perspectives are interrelated in the service-based delivery of IT. They all have to be considered if SOA is going to live up to its promise of making IT more responsive to the needs of business.

There is another aspect in which the definition of service in SOA has to be carefully considered - the way in which services can represent concepts that businesspeople understand. Software services are not interesting because they can be exposed using WSDL and interacted with using Soap, or indeed using any other combination of readily-available interface definition language and communication protocol.

They are interesting because of what they can represent. Just as object orientation was valuable primarily because objects could be representations of real-world objects, service orientation is valuable primarily because services can be representations of real-world activities and capabilities of companies.

If we can use SOA to more accurately model how software systems can implement and automate business activities, SOA's potential value is really about helping IT organisations and the businesses they serve start to talk and collaborate using a common language.

Architecture is not (or should not be) just a fancy way of saying design. If we were to take that road, then SOA would just be what a lot of people think it is: a way of designing systems so that they are composed of loosely coupled units of software.

But architecture is different from design. It operates at a larger scope and scale. Architecture is about forethought and planning "in the large" - above the level of individual projects and initiatives. In the context of SOA, the role of architecture concerns setting policies and rules that govern the design of individual services and systems, to maximise the overall value of a service portfolio to the business.

This is a question of service granularity and reusability, of representations and interactions, of semantics and much more. It is also a question of strictly non-technical things like how you organise and govern the IT function, and the way that the business and IT work together to direct investment.

Fundamentally, in the context of SOA, architecture is about laying the foundations for building a common language between IT and the business. It is something you do - not something you build or implement.

Neil Ward-Dutton is co-founder of analyst and advisory firm MWD. Next month in Computer Weekly he will examine building reuse into SOA initiatives

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