SOA Components

Just wanted to share some of my thoughts on what are key components of a Service Oriented Architecture. When I am with customers I will often sketch on the whiteboard, mapping SOA onto their existing IT landscape and identifying where they may want to investigate further. The pictures I draw tend to look quite similar to the one below.

The components are as follows:

Services

Services are the one thing every customer already has, although they may not know it. Existing applications provide the raw material from which services are created. Some applications already expose a service interface, others need one crafting either through an off the shelf adapter or through direct file, queue or database access. We will return to this topic in another entry.

Orchestration or Process Layer

Orchestration is crucial to SOA and allows the composition of new services (composite services) and new applications (composite applications) b y threading existing services together in new forms. The process layer allows us to automate the business processes that thread together the services into manageable business process.

Access Framework

When creating new composite applications they will need a user interface and possibly some additional business logic. These applications may be written within J2EE or .Net technologies and will take advantage of existing services. The use of existing services and loose coupling between the front end and these services makes it feasible to rapidly develop new composite applications, one of the supposed benefits of SOA.

Business Activity Monitoring

The orchestration layer allows us to monitor the state of individual processes, where they are and what they are doing.  However it is not a good tool for seeing what is happening across multiple instances of a business process, for that we need Business Activity Monitoring to tell us things about sets of processes.  This information may provide the basis for dashboard reports and alerts for the business.  This type of visibility can add real value to the business and is a great way for IT to sell the business on the benefits of moving down a SOA path.

Operational Data Store

Access services could get all their reference data such as customer lists, product lists from individual back end services, but this is not a natural way to retrieve data and the tools to support this are weak compared to the tools for querying a database.  An Operational Data Store (ODS) may be used to provide a real time synchronised view of data from multiple services.  This data needs to be cleansed and any changes need to be bi-directionally synched with every instance of the data in the back end services.  Use of an ODS decouples our access layer from the services providing the data and allows migration of services from one provider to another.

Business Intelligence

Moving to SOA carries with it the threat of a fragmented data architecture.  This probably has to be accepted but the consequences of such an architecture do not have to be accepted.  The need for a reporting capability does not go away with SOA but there is now the question of what do we report against.  This is where the value of an ODS can come in for reporting on cross-service data.  Business Intelligence provides traditional and end-user reporting capabilities against historical data in contrast to BAM which provides real time event driven reporting.

Security

Moving to SOA makes security even harder because we are breaking the link between the service requestor (ultimately an end user usually) and the service being requested.  We need to propogate security contexts across multiple services to ensure access controls are honoured and an audit trail back to the request initiator is in place.

Management

The most functional IT systems are useless if they are not available or performing poorly.  The loose coupling of SOA makes management more complicated and at the same time more essential.  Operators should be able to monitor end to end system status and performance and be warned of potential problems such as capacity crunches before they occur.

Partners

Not all clients of a service are within the enterprise, and not all services are provided by the enterprise.  All the requirements above apply equally to partners, suppliers and customers.  It is necessary to enforce security constraints whilst allowing efficient access to and from partner systems.  This provides yet another challenge in our SOA.

Summary

There is more to SOA than a bunch of loosely coupled services.  Moving to SOA cannot be done in a big bang.  Fortunately SOA lends itself well to a phased approach with particular technology solutions being introduced piecemeal into specific parts of the business.  So SOA may be an elephant, but it can still be eaten one bite at a time.