SOA’s Business Value (Part I of III)

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 again in 2006 as more and more people look to it to help them deliver IT which is more responsive to the needs of business. However, although some industry analysts predict that SOA is soon to become a mainstream proposition, there’s still a lot of confusion and misunderstanding out there in industry about what SOA is, and why it’s important. SOA is a big and important idea, and I’m hoping that 2006 sees a bit more reflection on the topic. The more misunderstanding there is, the more opportunities will be missed, and the more challenges and risks will go unmanaged.



With this series of articles, I hope I can help clarify the opportunities and challenges that come with embarkation on a serious SOA initiative. In each article, I’ll be looking at how organisations can use SOA to drive more business value from the IT they use and the way they use it.

Understanding the “S” and the “A” of SOA

In order to kick things off, I want to 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. In my mind, both “service” and “architecture” have meaning far beyond the context within which most discussion of SOA is taking place.

At MWD, our view is that 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”, if you like – 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 and WSDL 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 (SLAs) defined for “business services”. In the world of IT helpdesk tools, vendors and customers 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 most sense as a way of thinking about IT which explicitly recognises that all IT organisations are service providers, with customers which have a variety of needs. And SOA should help IT organisations act in a systematic way which 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, which 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 – as shown in the figure:

  • 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 services 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.
Figure: Service-based delivery of IT

As the figure shows, in reality, all these perspectives are inter-related 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’s another aspect in which the definition of “service” in SOA has to be carefully considered, and that’s the way in which services can represent concepts that businesspeople understand (we’ll look at this in more detail in a future article). Software services aren't 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're interesting because of what they can represent. Just as object-orientation (OO) was valuable primarily because objects could be representations of real-world objects, service orientation ("SO") 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.

The architecture question

Architecture isn’t (or shouldn’t 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, and no more: 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 which 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’s 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’s something you do – not something you build or implement. We’ll be exploring all these issues and more over the remaining articles in this series.

About the Author

Neil Ward-Dutton is Research Director at Macehiter Ward-Dutton, a specialist IT advisory firm which focuses exclusively on issues concerning IT-business alignment - including IT architecture, integration, management, organisation and culture. Neil is an accomplished and experienced IT industry analyst and public speaker. He advises clients on technology and management issues relating to enterprise architecture, application development, business integration, process management and application platforms. Neil has acted as an advisor to leading vendors, including IBM, Oracle, Microsoft, BEA, Hewlett-Packard, SAP, and Borland; and to large IT user organizations - particularly in financial services, government and telecommunications sectors.

More by Neil Ward-Dutton

About Macehiter Ward-Dutton

Macehiter Ward-Dutton is a specialist IT advisory firm which combines industry research and analysis with tailored consulting services, and is focused exclusively on issues surrounding IT-business alignment.

The company was formed in February 2005 by two top-level analysts formerly of Ovum: Neil Ward-Dutton and Neil Macehiter.