What the hell is… Service Oriented Architecture?

Written by Joseph Waller, 07/11/2014

Further to the release of our new website I thought I might re-dedicate myself to our long neglected blog. As a first series of articles I thought I might try and address some of those terms which many of our customers, a good number of our co-professionals, seem to struggle with. Thus I begin with Service Oriented Architecture.

A few years ago we were asked to help write a Service Oriented Architecture for a major national NHS body. Despite defining the term at the opening of our report it became clear that our non-technical executive stakeholder was unable to grasp this term and requested that we avoid using it in the report. Apart from the obvious challenge that this provided it reminded me of exactly how complex and abstract SOA is for the uninitiated.

The benefits of ‘service oriented architecture’ have been widely vaunted and discussed in the ICT industry for many years. By exposing the functionality (services) which an application provides – and by doing this at the correct level of granularity – services can be re-used and then “mixed and matched” into ‘composite services’ for new and innovative uses. Some of this approach reflects previous ‘object oriented’ thinking. However, with SOA these new ‘services’ are exposed on easily accessible, cross platform, technologies. Commonly on internet based technologies. SOA enables abstraction of functions within the enterprise. This de-coupling in turn enables strategic decisions to be made about the use of the functions across that enterprise. SOA enables flexibility in large scale enterprises (because ruthless standardisation – for example of technology platforms – isn’t normally possible on a large scale enterprise). For me the benefits of SOA are a great example of the what good ICT can provide. It harken’s back to a phrase coined by that great IT trailblazer Barbara Liskov…

“Modularity based on abstraction is the way things are done”

…Barbara Liskov

SOA diagram

History and context

Service oriented architectures were first conceived of in the 1990s but became more widely understood and utilised in the 21st century following the growing prevalence of the internet and internet technologies

SOA supported principles of loose coupling, clear interface definition and the reuse of functionality. To that extent many saw SOA as an obvious extension of object oriented principles and it was some years before SOA became widely understood as an architectural approach in its own right.

To some extent SOA itself has in turn been further extended by the use of cloud technologies and the prevalence of big data. Re-usable services that would typically have exposed data within an enterprise and between organisations on a B2B basis may now be provided on a large scale to thousands or hundreds of thousands of service consumers from the cloud. However, many organisations still linger in more siloed, pre-SOA architectural landscapes while still attempting to introduce elements of cloud based infrastructure. Without traversing the natural maturity curve through service oriented architecture principles such organisations create cloud services that are poorly designed for widespread consumption and re-use. Thus they fail to realise the benefits of reuse lauded by big data and cloud enthusiasts.

The need for a Service Oriented Architecture

Many organisations have now adopted Service Oriented Architectures (SOAs) to improve the flexibility of their ICT infrastructure. Service oriented architecture creates an ICT infrastructure which is deemed more flexible, strategic and cost effective over the medium and long term. SOA based architectures also typically enable more creative use and extension of an organisation’s data.

SOA divides system functionality into discreet interfaces (services) whose granularity has been carefully considered for use beyond its initial purpose allowing them to be connected together in a variety of different ways[1]. Those services are typically enabled via homogenous technologies such as those found on the internet[2]. In turn this allows consuming systems to access the services built on a wide variety of technologies allowing heterogeneous environments (such as the plethora of systems in the NHS) to act in a homogenous manner as if they were one overall integrated system.

By connecting those interfaces (services) a consuming system can support a complete business process. In addition those services can also be used in the future to fulfil new business requirements without needing substantial change to the systems.

SOAs also create the ability to replace suppliers more easily by allowing different services to be provided by different discreet systems and indeed by allowing new suppliers to replace discreet services in a transitional manner. In other words they can reduce vendor lock-in and provide natural transition strategies.

In focussing on SOA an organisation must be willing to value strategic thinking and longer term cost savings at least in equal measure to the achievement of short term delivery milestones. The SOA manifesto sums this up by stating that an enterprise should prefer[3]:

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection

[1] A service which exposes a number of other connected services is often called a ‘composite service’.

[2] Namely, HTTP and SGML based interchange formats such as XML.

[3] October 2009, at the 2nd International SOA Symposium

Challenges of services oriented architectures

Service design and granularity

Creating service oriented architecture requires more than simply enabling an interface with modern technologies. Any particular service relies on the right data or functionality being available in the underlying system components for all consumers of that service. That often means that a system being built to service oriented principles is required to present more data or provide more functionality than might be required in the design for its initial consumer. In turn this means that an organisation must plan the creation of those components more carefully and with a serious determination to achieve the benefits of SOA. As a result there is sometimes an economy of scale under which a SOA service will cost significantly more than a proprietary service if it is fulfilling only one business need. However, it becomes more cost efficient the more an enterprise becomes familiar with using SOA techniques as well as the more business consumers a particular service fulfils.

The need for a standard internal interface (canonical) format

Good service oriented architecture relies on the use of common standards being used throughout the communicating systems and components. Ideally a canonical format is devised. The more that the canonical format or standards becomes the de facto method for creating interfaces the more readily systems will interoperate and more that innovative uses for the enterprises data can be discovered. The careful design of the canonical format is probably the single most important activity for the successful implementation of intelligent reuse through service oriented architecture.

SOA Supporting services

Successful implementation of SOA also requires the implementation of a number of supporting technical services. Service and endpoint discovery allows service consumers to rapidly build clients and then to dynamically discover the endpoint on which to call the service. In addition a number of other shared data items may also need to be provided in supporting services such as directories of users, directories of other commonly shared data[1]. Finally, the creation of a suitable shared security infrastructure is necessary for any enterprises which carry sensitive data and which span large areas.

[1] For example, in the healthcare this would include terminology / coding services.

Commercial challenges

There are a number of commercial considerations when implementing a successful Service Oriented Architecture. SOA requires that a system’s interfaces be more carefully understood and defined before suppliers are procured. Agreements with suppliers should include a reasonable definition of the customer’s expectations in relation to these interfaces. A number of factors should be considered including: conformance with the interface, performance and response times, flexibility and configuration management. It is also a natural and sensible outcome of SOA to require that your suppliers document their systems in a standard format using common tools and templates.

All suppliers asked to supply a system to the enterprise should be required to use the canonical format for communication, even between components from the same supplier. This will ensure that systems can interoperate more effectively, testing tools and methods (in particular for integration testing) will be re-used with less preparation and overhead, service staff become familiar with the canonical format and diagnostic logging and auditing become standardised and re-used.

Promotion and education of SOA

Historically, it was necessary to promote and educate an organisation on the development technologies and patterns of SOA. Given its prevalence today this is slightly less essential depending on the maturity of the enterprise. However, in many cases while technologists are familiar with the technologies of SOA the business organisation remains ignorant of the wider principles of SOA system design. This means that requirements may reach the technical architects in a state that already precludes good service oriented design, often too late in the lifecycle to easily amend the architecture.

Enterprise architecture and SOA

Good service oriented architectures require careful consideration of the way in which applications across the enterprise interact. In addition, SOA initiatives typically rely on a central body to educate and encourage SOA take-up, to ensure interfaces are properly designed using standards and to support a SOA favourable governance process. As such enterprise architecture teams often fulfil this role to support SOA efforts.

SOA principles also require organisations to value “strategic goals over project-specific benefit”. To that extent the creation of a well understood architecture strategy is often an associated activity in the fulfilment of SOA. Read more about XML Solutions approach to ICT strategy…

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *