In this post we will introduce the concept of SOA anti-patterns. Like any architecture there is a right and a wrong way to do it. SOA is no exception.
Service Orientation is more than just a distributed technology it is a decentralised technology. Enterprises are complex and in terms of IT are not often controllable from a central point, much less through a single technical architecture. As such the tendency for business units to develop services in line with local demands should be expected to be high. In fact many arguments in favour of Service Orientation use this fact and suggest that this is the natural evolutionary route to successful SOA. However, left unchecked the viral growth of enterprise services create a highly politically fragmented IT that serves the short term goals of the local BU over the long term objectives of the organisation as a whole.
So how do we counter this from happening in the first place? The CDBI recommends establishing a business group to gather the business requirement for services and services only and create a specialised development group to build it. This actually all fits in nicely with the Software Factories methodology on group make-up.
Many advocates of Service Orientation use the phrase “services are fractal” to support the notion that services can be combined to provide increasingly business aligned services.
This is fine when performed in moderation, but fractals are suggestive of much more and indicate that a system could be comprised of a myriad of interconnected services.
Service interaction is an expensive operation. Remember ‘Boundaries are explicit’ is one of the 4 tenets of SOA, and therefore service chains should not be taken lightly either. The creation of service chains or dependencies can incur further penalties such as performance, availability, reliability, versioning, maintenance and service level agreements.
When deciding to create chains, think of them in terms of house buying chains; the possibility in a break in the chain is an ever present threat and worse still with service chains you have them for life, not just for the lifetime of the transaction itself!
Most new development takes the form of a project focused on delivering a particular piece of business as described by a successful business case.
In the majority of projects there will be some need to integrate with other systems. This integration is typically performed within the context of the projects to meet the projects immediate goals.
However, this often results in a wag the dog’ anti-pattern whereby the service is now ‘owned’ by the consumer of the service (i.e. the project) and not by the service provider itself.
The problem here is that the project is ephemeral in nature, the teams will soon be disbanded, contractors will leave and domain knowledge gradually seeps away through the cracks.
A number of issues relating to reuse and maintenance can then arise as a result leading to the occurrence of stovepipe, parrot or newspeak anti-patterns, these in turn leading to service overload.
Parrot services are all about re-invent the wheel as regards service function, often as a result of using the project service anti-pattern for service design and development.
This can quickly result in a confusion of services, making consumer choice difficult and error prone.
It can lead to stovepipes, newspeak and service overload anti-patterns.
Newspeak (or forked tongue) services are services that do not necessarily speak the truth. This can occur for a multitude of reasons and often as a result of pursuing project, parrot or stovepipe anti-patterns.
It is essential for the success of services that they are trustworthy, not just in terms of security and availability but in terms of the data they share. It is surprisingly easy for services to become ‘out-of-date’. A variation of newspeak is caused as a result of allowing the multi-master service anti-pattern to occur.
Data often resides in multiple places in the enterprise. This data is often shared by process including file, batch, or manual transfer and are often the target of service definitions, but more often remains discrete in the application silo to which it is tied.
If a cohesive data integration policy is not followed then the resultant multi-master situation can pervade whereby each application silo believes it is the centre of the universe. In SOA no one is master by default and left unchecked parrot and newspeak service anti-patterns will result.
The stovepipe is a well known anti-pattern and this is just a reflection of this as related to services. The Stovepipe relates to the chimneys of wood burning stoves that due to the caustic nature of wood smoke quickly fall into disrepair and as a consequence they remain permanently unstable requiring constant patching and repairs. In terms of services the cost of constant change in terms of changing or layering on new functionality adds to the cost of the service in terms of maintenance and stability.
Primarily as the result of the parrot and project service anti-patterns, but also as a result of ‘death by success’ an underlying service provider can quickly, but quietly, become overloaded as an increasing number of consumers connect up. If this is as a result of project or parrot services this can occur be dramatic under relatively low user load as each service makes individual connections to the underlying resource be that of a database or mainframe for example.