SOA Services in ArchiMate

Nick Laqua  posted an interested discussion question on the LinkedIn ArchiMate group. It was a long post so I wont repeat it here. But it was interesting and worth responding in detail to. The key areas of the post I am looking at are

• How to model a SOA service within the application layer
• Emphasis the view of a service as defined by the behaviour and functions over the interface

The issue of governance is a larger one which really deserves its own post as the levels of governance on services will vary within organisations based on the company structures, roles, size and many other factors.

I have been doing allot of this recently, experimenting with a number of different approaches. This approach I have found most beneficial for myself and in the communication of services to others. When modelling an application service I start with behaviours. It is essential to know what has been identified as viable for automation. Remembering that all programs are simply the automation of a process, we need to clearly identify the scope of the service. In Nick's post he mentioned a Customer Management service which offers 4 operations. Create, Retrieve, Update,  and Delete. First thing that springs to mind is an Entity Service. We need to consider how granular we need to go. If we are describing a service with the CRUD capabilities for an entity we can pretty much guarantee that there will be more reads then writes, and based on different interaction needs of systems we will need to be able to show what is reading and what is writing. This level of granularity will help implement the security policy for the service, identify performance hot spots, for instance or allow improved impact analysis during the governing phases.

Are we offering one service or 4 services? At this granular level we are offering 4 services.

Fig 1 - Services as Application Services

These are all different services that the application offers. If you say, 'Well the application does offer a SOAP services isn't that the service?' the answer is yes, but it is the Technology service.

Interfaces are access points, and there may be many access points. Lets consider that the above services have been implemented via multiple interfaces.

Fig 2- Interface assignments

This clearly shows how the services are available from the CRM application via multiple access points. The interfaces here are separated only by the technology they use. It may be more appropriate to show this capability as tied to the 2 technology services, HTTP and RMI.

Fig 3 - Infrastructure Usage view

This is a good way to show what functions are tied to what infrastructure. I have left off the Assignment relationships between the component and the functions for clarity.

I prefer to use the former view with the multiple interfaces as you begin to add both more interfaces for UI and consuming applications, you will want to know which interface are they interacting with, the RMI, HTTPS/SOAP or UI? You cant do it with this view (Infrastructure Usage).

So I maintain technology referencing interfaces at the application layer. It allows me to show dependencies and function utilisation.

Fig 4 - Detailed services view 

Personally this is my preferred model. Its not always good for communicating quickly the utilisation of services as there is allot of information there to take in. By aggregating the CRUD services under single service you can get a simpler view with derived relationships.

Fig 5 - Simplified services view 

In the model the more granular services become aggregated within the larger object, but now I have lost the information about which specific services each function is using from the service and the assumption is generally the entire service.

Fig 6  - Visualiser from Archi showing element relationships are maintained 

I find the detailed view very useful for identifying gaps and changes that may need to be made. It also aids with identifying high demand services and can lead to separation of granular services into their own space for performance such as caching layers etc. While the Infrastructure Usage view is the more accurate description for the language, IMO, it is less helpful, especially for integration scenarios rather then just SOA ones.