SOA and the Michelin Man
December 03, 2014
Don’t be fooled by the Michelin Man (take care adding a ‘services’ layer to your model)
We all use the results of service-oriented architecture (SOA) daily. When you check the weather online to see if you need a coat, when you access your bank records to make sure you’ve got the cash to pay the plumber, or when you use the company CRM to look up a contact.
When SOA is done well we don't notice it but when it is done badly, we all know about it.
Ensuring that these business-critical processes are designed well and run smoothly is the job of the enterprise architecture team. Most standard enterprise architecture frameworks including TOGAF and ArchiMate contain some concept of 'services' – they’re an incredibly useful way of labeling things.
However, beware! Problems can arise when a meta-model design removes the direct interfaces between applications or the links between the original 'layers' in favour of inserting an abstract ‘services’ layer in between. This is a very common pitfall of meta-model design (e.g. TOGAF with its Business Service), and here we explain why it should be avoided at all costs.
How to design a meta-model with services
When the architecture team sets out to design a meta-model for SOA, they often have to decide whether to add 'services' elements between the more tangible elements in the meta-model such as departments, processes, applications and servers.
A ‘services’ concept is useful in decoupling these tangible elements or layers and allowing the model to illustrate what these more tangible elements are doing. For example the EA team can group all the CRM applications into a single CRM 'application service'. This can help them to provide a portfolio analysis of this whole CRM 'group'.
Services also allow architects to label tangible elements of their model without specifying their exact physical details. For instance, the services layer can make it clear that an application requires an IBM WebSphere Application Server 'platform service' or an EMC Symmetrix storage 'infrastructure service', not just that it runs on server XYZ1234.
An essential meta-model with services
By way of example, let’s start with a basic meta-model that includes initially just aspects of People, Process and Technology as shown in the diagram below:
In the ABACUS suite of enterprise architecture tools, we call this a ‘Phase 0’ meta-model. When you have a toolset such as ABACUS that can grow as you grow it's a fantastic place to start!
It represents the core of any enterprise architecture, and includes the following types; Departments that perform roles for Processes (which can be hierarchically decomposed), that in turn use Applications that are hosted on Servers. And additionally, Departments own Applications.
Next, we add several service types 'between' each of these layers. In our example, we’ve added Capability, Information System Service and Infrastructure Service.
DONE? Almost. The temptation to remove those ‘direct’ connections between or within the layers can undo some very effective enterprise modeling…
Watch out for the Michelin Man
When a meta-model designer removes the direct links between the original layers in favour of the ‘services’ layer some of the original structure of the architecture and the meaning of the model is lost.
For example, removing the Hosted On connections between Applications and Servers leaving just the Infrastructure Service components (and connections to them) means that unless an Infrastructure Service component is created for each and every one of the Hosted On connections you end up with a single funnel through which everything is connected.
Going back to our CRM example: we knew that the ‘CRM’ application ran on server ‘XYZ1234’, and now we also might know that the CRM application requires an ‘IBM Websphere Application Server’ platform service, but if we removed that original Hosted On connection we would no longer know which actual server it ran on, presumably to get that service!
Don’t be swayed by the argument that nobody cares which actual server it runs on. We assure you, someone does … especially when operations decides to switch the server off and the IT phone lines are overwhelmed by frustrated sales people unable to look up phone numbers of potential clients.
Resist the temptation to simplify your model by removing those direct links. You can easily lose the original structure of the architecture and create what we call a ‘Michelin Man’ model. By ‘pinching’ two rich layers through an abstraction (creating a model that ‘bulges’ above and below into puffy ‘Michelin Man’ folds) you no longer have any idea of what actual tangible elements are actually connected!
Best practice enterprise architecture
Finally, a little more about us. Our ABACUS software is designed by architects for architects and enables modeling, analysis and visualization of enterprises.
ABACUS provides straightforward data-collection, in-house configurability, best practice analytics and impressive visualizations. Our aim is to help you manage multi-faceted datasets and complex IT landscapes well, and communicate your insights effectively.
We support hundreds of frameworks and also enable hybrid-configurations (our team are experts in all industries and can quickly build a repository which is exactly right for your business, first time).
We’re available to answer any questions, provide a demonstration, or give some insights into how we have used ABACUS successfully in deployments in your industry – contact sales. You can also download a free trial of our ABACUS software.