Service-Oriented Architecture (SOA) refers to an IT
architectural style that supports Service Orientation and flexibly enables re-use.
SOA seeks to align IT Services with Business Processes to implement autonomous Services which are
composable for re-use in other Business contexts. SOA addresses the characteristics of loose-coupling,
modularity and separation of concerns and typically uses open standards for interactions between a
Service Consumer and a Service Provider. SOA interactions use a common semantic understanding and are
governed by a service agreement.
SOA is linked to Enterprise Application Integration (EAI) and can be thought of as "EAI on steroids" or
"EAI with Open Standards"
and encompasses all the complexity of integrating consumers, providers and data models on disparate
systems and technologies as though they were designed with the required interaction in mind from the outset.
SOA is a large and complex undertaking whose payback is not immediate but usually quite a way down the
track by providing the Business with the flexibility, agility and stability it requires to manage and
change according to its diverse and complex business requirments.
Services
A Service can be described as a software object that provides business-aligned
functionality (as opposed to technical infrastructure functionality) and which operates under a service contract.
Here are some SOA definitions from leading IT Organisations ...
Service Design Principles
Service Design involves bringing together functional and technical requirements in such a way
as to deliver a Service which is composable in multiple processes and can be re-used. This makes Service Design
more complex and means a higher investment earlier in the process in order to achieve savings later in the work
programme and provide flexibility to the Business. This objective is made very difficult by the absence of firm
business requirements (they usually are evolving rather than known and fixed) and may result in serveral attempts
to identify the right granularity for the Service so that it can be re-used and the benefits realised.
Here are some sound Service Design Principles ...
1. Services are loosely-coupled
2. Services are coarse-grained
3. Services are stateless
4. Services have a separation of concerns
5. Services use open standards for interfaces
6. Services are easy to consume
7. Services use document-based interactions
8. Services are resiliant
9. Services are autonomous
10. Services are business-aligned
Service Identification
Service Identification is one of the first steps in SOA life cycle. It often involves many
vaguaries and requires an iterative approach - the results of which must be qualified before any Services are
designed and built.
Service Identification comprises of a Top-down and a Bottom-up approach.
The Top-down approach will look at strategic business processes or use-cases at a particular level within
the organisation. Top-down is more applicable for wide-scale SOA undertakings (a transformation exercise) whose activities
include designing or re-designing critical business process which span multiple business domains.
The Bottom-up approach is more common and focuses on exposing existing software assets so that they can be
used in a strategic manner. Bottom-up activities usually comprise of application-level portfolio analysis to rationalise
duplicated, redundant or unnecessary functionality, business rules and sources of truth. Bottom-up will often result in
"wrapping" existing functions as a "CRUD Service" in order to use them more reliably in other business processes.
SOA Methodology and Design Techniques
Full-blown SOA projects will have to grapple with everything from Service naming conventions and granularity through to
issues of (lack of) ownership and (lack of) adequate funding and (lack of) business involvement.
SOA must address multiple architecture layers from Presentation Layer, Business Process, Service Layer, Component Layer and
back-end Operational systems whilst engaging with multiple business domains and stakeholders.
Some useful methodologies and design techniques from IBM to navigate and sift through the complexity involved in SOA are ...
SOA Hype
SOA has been around for quite a while and many say that it has failed to
deliver on its promises of composability and re-use etc. whilst blowing out the costs and complexity
of the IT landscape.
Here are some articles to consider regarding the failures of SOA ...
Some Alternatives
Fully-blown SOA and Integration do present some real challenges...perhaps your needs are better "serviced" by looking
at some alternative solutions which offer a smaller learning curve or optimal performance or which overcome a particular technical
or budgetary constraint...
Here are some alternatives worth looking at ...
