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.
In this series on ArchiMate we have so far focused on the fundamentals of the language, and on tailoring it for use in your own organization. Also we wrote about some best practices for creating effective views for key stakeholders in your organization. In our post on tailoring ArchiMate for use in your own organization we already announced the topic of this posting: patterns. In other words, the topic of this blog post is on solving common modeling problems.
It should be noted that some of the modeling issues discussed in this posting are more or less “advanced” and may be complex for the novice ArchiMate user.
Different ways to link applications
There are many different ways to model the fact that two applications “do something together”, even without using advanced concepts such as the Application Interaction and the Application Collaboration. The following diagram shows the main options:
In this example, we use two applications A and B. There are two ways to connect A and B directly, using either the flow relation – to indicate that data flows from A to B – or a usedby relation – to indicate that B makes use of A. If desired, the flow can be annotated with the (type of) data that actually flows from A to B. The three other ways to connect A and B follow the three different aspects (the “columns”) of the ArchiMate metamodel:
Behavior: application A realizes an Application Service that is used by application B
Active structure: application A has (composition) an Application Interface that is used by application B
Passive structure: application A writes (access) a Data Object that is read by (access) application B
Also, by linking the Data Object and the Application Interface (using an association relation), we can represent the fact that the Data Object flows over that Interface. Using the Label view mechanism of BiZZdesign Architect it then is possible to create views such as:
Modeling an Enterprise Service Bus
Many clients struggle with the question: how do we model our ESB. First of all, it should be noted that an ESB is an infrastructure thing. It is generally represented as a Node, containing some system software. At the logical level it can be argued that the Node realizes several services such as “reliable messaging”. Applications wishing to communicate via the ESB then use this logical service:
However, many organizations also wish to model the physical counterpart of this logical model. In that case, B calls an interface from the ESB. The ESB accesses an interface from A, that is associated with that infrastructure interface.
If necessary, the ESB can also do some orchestration by calling several application interfaces and merging the results before sending a reply to B’s request.
The topic of virtualization shows up frequently at clients as well on internet forums such as LinkedIn. Since many things can be virtualized, different modeling solutions have to be developed as well.
Hardware virtualization For hardware virtualization, the trick is to have several pieces of hardware that connect to a virtualization layer. On this virtualization layer, new “virtual” nodes can be deployed:
This model shows two pieces of hardware (D1 and D2), each with the same OS. The virtualization software connects to these OS’es. On the virtualization layer, two virtual nodes are deployed, each with their own OS. Not that each “deployment” is modeled using the assignment relation. Also, things being part of the node is modeled as a composition relation that is shown here using graphical nesting.
Let’s say we want to offer a virtualized version of application A to business users. A typical use would be the deployment of your favorite modeling tool (e.g. Architect) on a Citrix farm:
In this case, application A uses the virtualization service of the Node where the virtualization software is deployed. To model this more accurately, the artifact that realizes A is deployed (assignment) on the virtualization software. The node now exposes an interface (linked to the original application A using an association relation for clarity) that business users can use.
Linking conceptual/logical to physical models
The final pattern to be discussed in this posting is about the use of conceptual/logical models (focusing on the “what/how” of architecture) to physical models (focusing on the “with what” of architecture). In a previous posting, our colleague Raymond Slot shared his views on how to deal with this issue using a “pure ArchiMate solution”. In this posting, we use a more tool-specific version that relies on dependency relations in BiZZdesign Architect.
In Architect it is possible for a model package to consist of more than one model. Elements from models in a package can be linked using dependency relations such as “is equal to” and “is refinement of”. A typical use of this mechanism allows users to:
Model a process architecture in Architect, and refine it using BiZZdesigner
Link elements from reference models to organization specific models
Link elements from conceptual/logical models to physical models
The following diagrams illustrate how this works:
On the left we see a conceptual/logical model, on the right its physical counterpart. In the logical model, the Application Service is realized by a logical component called “DMS”. For the physical solution, the tool SharePoint was chosen. To represent this fact, the is equal to dependency relation is used. Similarly, in the logical the “storage” infrastructure service is realized by a logical node called “Storage server”. In the physical world, the SharePoint component is realized by an artifact that is deployed on a server with a single blade that runs the Windows operating system. This server is connected via the local network (LAN) to a Storage Area Network (SAN) server where the actual data is stored. The is equal to dependency relation can again be used to link the elements from the conceptual/logical model to the physical model. So far we have implemented this way of working at several clients, with great success! If you’d like to know more, or have any best practices to share: drop us a note!
If you’d like to know more, please leave a comment. The next post will be the last in this series and will give a short summary.
Archimate® and TOGAF® are registered trademarks of the Open Group.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: