Use of services in Archimate

Raymond Slot
Posted by Raymond Slot on Oct 25, 2011

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

ArchiMate (see here and here) is a modeling language that has been developed specifically to describe business- and information architectures. The language was accepted by The Open Group in February 2009 which helped in its adoption by many different organizations worldwide. The language is well structured and fairly straightforward, especially for people with a technical background. Global acceptance and use of the language has grown tremendously since the language was first conceived and described. The language can be used both to describe the current, or a desired architecture which makes it a powerful tool for roadmapping and planning. It also makes it an ideal language for use with the TOGAF standard. Also, the syntax of the language has been formally described: each concept and relation has a well-defined, precise meaning.

Several ‘best practices’ have found their way into the specification of the ArchiMate language. The language supports architects by ‘enforcing’ the specific use of language concepts and constructs, which in turn leads to improved quality of architecture designs. Decoupling of specification and implementation is a prominent example. Each layer in the ArchiMate language (business, application, and technology) has a service concept that answers the what of an architecture, whereas underlying processes and components describe the how of an architecture. The following example illustrates this in the context of electronic ticket ordering:

The ArchiMate example describes three process steps, starting when a client registers for a performance up to the receipt of an e-ticket. When executing these steps, four application services are used in a specific order. These services are not webservices; they simply describe what automated functionality is needed in order to complete the process, without specifying the how. These implementation details are described in underlying application components.

Decoupling specification and implementation improves stability and understandability of architecture descriptions. Stability is improved because in general the type of automated functionality (application services) changes less often than implementation thereof (application components). Understandability is improved because the description of the automated functionality is cleaner: it isn’t mixed up with implementation-dependent details.

The above example is built around the application layer, but the same line of reasoning applies to the business layer (where business services are realized by processes or functions) and the technology layer (where infrastructure services are realized by nodes / technical components). 

A question that remains is this: are two levels of description (what and how) sufficient to effectively describe a system in a meaningful way, or are multiple levels required? We will tackle this question in the next pose in this series, which is to be published on 7th of November 2011.

For more information, leave a comment.



Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus