Services are very important parts of the ArchiMate modelling language. This blog shows some ways we can represent and utilize services.
The Difference Between A Service And A Product
Its important to understand the difference between a service and product. I have seen in many places those terms have been interchanged. Product management must have a common understanding to architects, although this doesn’t mean we necessarily need to expose ArchiMate to Product managers. The whole point of ArchiMate is to provide a common modelling language to enable clear communication.
A product is a collection of services and a contract. A product element lives in the business layer. Normally we connect our services to the outside world through the business layer.
Products are composite elements that aggregate or compose any of these elements in archimate:
- Business Service
- Application Service
- Technology Service
- Business Passive Structure Elements
- Data Objects
- Technology Objects
They are pretty clearly defined in Chapter 8 of the ArchiMate Manual.
A business service represents an explicitly defined exposed business behavior.
Although services are also defined in the ArchiMate Manual I don’t think it does them justice.
In point of fact all services are explicitly defined exposed behavior; be it a business service, an application service or a technology service. These services are very important in large organisations. Take a look at this layered view. Its a typical layered view used to show how the Business, Application and Technology fit together for a fictional web hosting service.
It doesn’t show a complete picture – because of course actors and processes in the business layer are likely to connect into the other layers. We do not have to put every element on every view – we use what we need to tell a story. To work more directly with services we can abstract out from the view above:
In figure 3 we are showing only services, and its important to understand the relationships here, and the concepts. You can see A platform service is realized by either Microsoft Azure or an Amazon Web Service. I could have said they were both specializations of a platform service. I prefer to do use the realization because it would have meant drawing specialization relations in the opposite direction which isn’t as intuitive to read.
In Figure 3 the platform service is abstract. We only want to represent just enough architecture. Azure & Amazon Web Services have commonalities. They use virtual machine managers, and virtual hard disks to realize virtual servers. You can see this in figure 4:
The technology view is showing a number of things. If we had not abstracted to convey this information we would have to create two separate views – One for Microsoft Azure & one for Amazon Web Services. We want to avoid this.
Having that level of abstraction makes it easy to add a new technology service and enables us to be flexible. Lets modify figure 3.
You can see we added Google Cloud and System Centre. Rather than having to create two additional technology views, we need to do nothing, because we have defined the platform service in figure 4.
Over Engineered Products
In big organizations its very easy to get to a point where you are over engineering. In the examples i have shown so far I have been showing a single business service (web hosting service). You can see, that regardless of which platform is used, or which technology, we still only need a single business service, because what we deliver is the same.
In some organizations the product portfolio can be overly complex. For example I have seen limitations in financial models which have lead to breaking things down into products where perhaps they should not be. In Large organizations different services are often provided by different business units which can mean that because of the different units having different levels of responsibility, products might be created in each unit. Something like this can happen:
Because product management processes tend to specify a need for business services we can end up having to unnecessarily create products and business services. This can be a huge cost and complexity overhead. All services need established interfaces, all products have their own team of staff, and services need interfaces defined between each other.
Figure 6 could have existed in an undocumented way. Drawing a view like this makes it clear where complexity exists that does not need to and is one way an EA can show value – reducing unnecessary services and better defining interfaces between the services at the different layers.
When we have taken away the detail and drawn our services like in figure 5, it becomes significantly more easy to figure how we want to bill things. If we start from figure 5 we might end up representing our pricing components as below
Back in Figure 2, we showed some interfaces. At a business level our website hosting service is accessible via Email or Web Portal. The Web Portal is realized by a application interface (HTTP Interface) into the website application service. In this case what we are saying is the business service does nothing except expose out the application services.
In the examples I have shown its clear that interfaces should exist for some of the services. that I haven’t detailed in. When I create a layered view I am typically picking and choosing elements, rather than using all connected elements to a service. Other views, such as service realization views, or application cooperation views may show how these interfaces to services exist in more detail.
Functions are internal behavior units that we do not expose to the outside world. In figure 4 we showed how a technology service was realized. Such a view may have been created by our internal platforms team. The Virtual Machine Manager Function might be very important to talk about to that internal team but would not be something that the sales or product development team need to talk about. If we were to need to relate the virtual machine manager to another team, then we would have created it as a service.
Summing It up…
In future blogs I will be building a lot on the usage of services, because there’s a huge amount that can be done with them. This blog only scratches the surface. Services can be used to reduce complexity and make architecture more light weight and agile. They enable us to focus our architecture efforts. If you are practicing any kind of large scale architecture they are essential.