Example Services and Capabilities with Meta-Model

Introduction

This blog on Services and Capabilities came out of thinking about a few related subjects:

1. How to use Archimate to model Capabilities as this is not directly supported in Archimate terminology.

2. On how Services relate to Capabilities. These seems to be a lot of discussion about this on the EA forums.

3. How all of the above should all be modeled in an Enterprise Architecture Model using any tool that supports Archimate.

4. How Architects who model hierarchical nested diagrams of one type (e.g. Application services) can see how this would still be possible.

So I thought the best way of explaining how I believe it should be modeled was to model one example situation in each domain for the following:

1. The Business domain – Business Service & capability – Route Planning example

2. The Application Domain – Application Service & capability – that supports Route Planning example

3. The ICT Domain – ICT Service & capability – the Database service that supports the above two.

Enterprise Service Model

So below is the Enterprise Service Model. It shows the typical structure of a whole Enterprise Services model.  The services on this diagram (shown in green) give you one Business Service, one Application Service and one ICT Service; one service from each domain. On it I have only shown what has been modeled in the separate Models / diagrams in the sections below as well as any ‘used by’ services or ‘related’ showing service dependencies.

Route Planning – Business Service & Capability Example

This model below is the Business Service and related Capability to support the ‘Route Planning’. Route planning comes from the notion of a travel agency establishing tailored itineraries for prospective customers.  As you can see the Capability is shown as a ‘Business Interaction’ and is a collection of Roles, Actors, Processes, Artefacts, Locations and events, that all make up the Capability. The Business Service also depends in a large part on some Application Services.

Route Planning – Application Service & Capability Example

The Route Planning Application Service is shown here in more detail. It shows the Application Services with it various Application Interfaces (some System/Machine and some Human). It then shows the Application Capability, again using an Application Interaction as the wrapper for all items that make up the capability, such as locations, Application Collaborations and Application Components. Each of these elements relies on ICT Services such as servers, desktops and other technology.

Database Server (for Route Planning DB) service – ICT Service & Capability Example

This is one Service of many that support the Application Service and its Capability elements. Again following the pattern of a Service having an Infrastructure interface and saying what should be done not how it should be done. The Capability expands on the detail of how it is realised. This is where I felt there should possibly be the same notion of an Infrastructure Interaction entity but Archimate does not seem to support that. This model also shows how the layers above it interact with the ICT Service, e.g. that the DB SQL Server (software) service relies on a DB Server (O/S & hardware) service.

 

Meta-Model that brings it all together

While not wanting to re-invent the Archimate Meta-Model, I wanted to show the groups, and inter-relationship that this would build up in an EA Model of the organisation if we were using a tool to support this. The top part is the Portfolio and Programme office controlling the work-packages to do a transformation. They would need to understand the As-is and various Tranches of work per gap to get to a To-Be state. This they would primarily do of the higher level services, but could also go down to more detailed Capabilities to see the deltas between the various as-is and to-be plateaus.

 

Other Model Views

It seems to me that many EA initiatives love to show the breakdown hierarchically of one Architecture building block type, e.g. Principles, or Organisational Business units, Services, etc. in isolation. I wanted to show by doing the above that all this information would be gathered in any case by working to build up these models. They would just be a by-product of gathering the above information.

The real value is to be derived from the interconnections and relationships in the meta-model of all of these elements below, including the entity instances themselves so that we always know what our inventory of them is so as not to forget things in doing analysis. The impact and dependency analysis is only obtained by connecting up the relationships between entities, provided it is done at a course grained enough level and we don’t try and model the whole world in great detail.