ArchiMate Modeling in Practice: 3 tips for your solution models


Subscribe
Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Mar 27, 2013

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.

In the previous postings we zoomed in on developing “top-down” or “enterprise” models, laced with many practical tips to help practitioners to get started. In this post we tackle the other end of the spectrum, and discuss how to get started with “Bottom-up” or “solution” models. We will zoom in on several aspects, including structuring your models, and linking to your enterprise models. 

Structuring your models

While it may be obvious to many, recent experience in several engagements suggests that we cannot stress this point enough: there is no single best way of modeling for your solution models. Predefined viewpoints – such as the ones listed in the TOGAF® and ArchiMate® spec can help getting you started but then you’re on your own. Another fallacy that shows up a lot has to do with these lists of viewpoints: too many people seem to think that it is mandatory to create all the views from these lists of viewpoints, suggesting that this will automagically lead to better architectures. Unfortunately, this is not entirely true. It requires a good deal of judgment on the part of the architect to decide which views solve questions, and add business value. 

The question that remains is: if there is no single best way of modeling, then what advice is actually useful? 

Over the years we have (co-)created many models in many different organizations, across different continents. Based on this experience we have three simple tips that should help you keep on track: 

  1. Keep the end goal in mind: usually your models are created with a specific purpose in mind. Make this goal explicit and work your way back:
  • Are we creating a model to help someone make a decision?  Has a decision been made and are we crafting a design? Or, are we creating models to perform impact analysis, making sure we have caught all risks in our project plan?
  • Based on this information: who will look at the views? How much detail is actually required?
  • Do we need views from a single domain (i.e. process, systems, infrastructure) or is a layered view preferable?
  1. Use reference models whenever possible: Reference models come in many shapes and forms, e.g. industry specific models about business functions/processes, information structures, application components (SID/ TAM/ eTOM is a famous example in the telecom industry) or reference models in a single domain (i.e., SOA or CORBA in the information systems domain). These models can help to quickly develop your solution models:
  • Naming of your model elements
  • Catching dependencies: if your reference model suggests certain dependencies, then it is likely that your solution models should have them as well
  1. Separate function from construction: it seems that many architects have a preference for modelling ‘structure’: departments, components, nodes, that kind of stuff. The functional aspects (what does this “stuff” actually do) is often missing. Especially when reconstructing baseline models, this aspect is often skipped. 

There are, of course, many more tips and guidelines that you could use. The book by Gerben Wierda, for example, provides many excellent examples of patterns and considerations that will help in crafting your own models. In the next posting we will discuss three practical examples of solution models.

Linking to enterprise models

ArchiMate2.3enterprisevssolutionmodelAnother thing we would like to  discuss here is the link between solution models and enterprise models.

The main thing to keep in mind that these are typically separate models in the same repository. Currently, the ArchiMate standard does not support linking across models. Most tools, however, can do this. In BiZZdesign Architect we have introduced dependency relations which allow the modeler to link from one model to another as illustrated in the figure. Here we have used dependencies to show how a function from the enterprise model is manifested in a process in the solution model. Similarly, a process in the solution model can be linked to a BPMN model, or a data item might be linked to an ERD view. 

Workshops

It was already in earlier postings: we advocate using a workshop-approach. We have good experience with small teams for developing the views and a (larger) group to review / challenge the results. An iterative approach typically works best: 

  • The core team does the ground work: using brainstorms, whiteboards, flip charts a first draft is created to get a rough idea
  • This is translated into an ArchiMate model
  • The ArchiMate model is presented to, and reviewed by the other group. It is essential that this group is sufficiently diverse:
    • Process owners
    • System owners
    • Data stewards
    • Representation from HR
    • Etcetera.
  • The reviews are processed and a final view is developed.
  • This view is presented to the decision makers!

A general believe seems to be that ArchiMate views are by architects for architects. This may be true, but with some effort they can also be presented to decision makers!

In the next posting we will present three cases from our experience where we created bottom-up or solution models using ArchiMate. Stay tuned!

quick-start-video-togaf-archimate

SUBSCRIBE TO BIZZDESIGN'S BLOG

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