archi-logo

Archi Spotlight – Archi Supports the Government of New Brunswick’s EA Program

In this Archi Spotlight, Peter Gee talks about how he introduced ArchiMate and Archi to the government of New Brunswick in Canada.

Peter, tell us a little about yourself and how this initiative came about.

Several years ago, the Office of the CIO for New Brunswick embarked on an Enterprise Architecture (EA) program. I was brought in as a consultant to help build a Business Architecture framework, which was considered to be an important foundational piece of the EA landscape. While working with them, I introduced ArchiMate as the recommended modeling notation. Since they had no “official” tool in place I also introduced them to Archi as a means to learn the language and start on the development of some Business Architecture models.

How do you find working with Archi?

Archi is very easy to install and much quicker to learn than most of the commercial tools I have worked with. It also had “just enough” functionality to support our modelling needs at the time. Archi’s CSV import/export functionality allowed us to quickly import model content from external sources as well as utilize an export-update-import approach to manage bulk updates to the model. Its support for the Open Group’s ArchiMate Model Exchange File format further guarantees the portability of model files and mitigates the risk of vendor lock-in. Its sole limitation is that it does not support external image files in a diagram.

What is the nature of the project?

The key deliverables for the project included a Business Capability Map which was developed as a hierarchical, nested diagram based on a set of ArchiMate “business function” elements. Since ArchiMate 2.1 does not include a “capability” element, we followed the prevailing practise of using the “business function” element for this purpose. We also used the Jasper Reports module included with Archi to generate a supporting Business Capability Reference document which contained the capability descriptions, as well as other supporting information.

New Brunswick is officially bilingual (English/French) so we were required to publish these deliverables in both official languages. You can view the resulting deliverables in the following links:

English Capability Map / English Capability Reference www.gnb.ca/OCIO
French Capability Map / French Capability Reference www.gnb.ca/BCSI

(the Business Capability Map and Reference Model are accessible via the “Quick Links” section on each page)

What techniques were used to produce these artifacts?

This is a summary of some of the techniques:

  • The Capability Map was created as an ArchiMate view and then the diagram was exported as a PDF file.
  • Pages that include graphics were created using blank Business Canvas pages.
  • The Provincial logo was added to the PDF using the open-source Inkscape graphics editor – https://inkscape.org
  • The Reference document was 100% generated from Archi using a customized set of Jasper control files.
  • The Jasper report was generated in MS Word format in order to fine tune page breaks and add headers and footers.
  • User-defined properties for “French:name” and “French:documentation” were added to the French versions.
  • The model was exported to CSV files, using some Excel tricks to swap the French and English values, and re-imported to Archi before repeating the above steps

Many thanks to Peter Gee for providing us with an insight into how he uses Archi and ArchiMate. It’s interesting to see from the summary of techniques used a specific work-flow emerging when using Archi. This work-flow is valuable in determining possible features in future versions of Archi.

If you’d like to share your story about how you use Archi and ArchiMate and you’d like to be featured in this “Archi Spotlight” series please contact us.

archi-logo

What is wrong with this picture? (TM)

If you know ArchiMate, there’s a good chance that you know Gerben Wierda‘s post series “What is wrong with this picture?”. This blog post is both a tribute to his work and an attempt to explain the importance of why you should be aware of the difference between core relations and derived ones.

In his book Mastering ArchiMate, Gerben presents several beginner’s pitfalls and especially the (bad) use of derived relations. I can only recommend that you follow his advice, and I will explain why, but let’s start at the beginning…

Core vs derived relations

When reading the ArchiMate Specification you might notice that the relationship tables contain a lot more relationships than those described in the metamodel pictures (such as this one for the business layer). The latter are the “core” relationships. In a detailed ArchiMate model, you could just use only these ones. But in real life, you will certainly have to create some high level views hiding some elements and using derived relationships.

In general, ArchiMate tools implement all of the possible relationships based on the tables in the Appendix of the specification, but don’t tell you which kind of relation you are creating, core or derived, and this may lead to problems.

Infrastructure Service used by Data Object

Today I was working on a model for a new project. For this, I used our standard pattern for a database:

whatswrong-dbpattern

This pattern basically shows a shared server which hosts several databases. In order to be able to move one database from this shared server to another one in the future without having to reconfigure applications using it, each database is accessed though a dedicated DNS alias pointing to the real server name (for those who know Oracle, we assume the service name and the port will not change).

Following our pattern, I then added some additional elements from the application layer, notably a Data Object realized by an Artifact. As I am testing the Archi 3 Early Access Preview, I played with the new Magic Connector functionality and found the following possible relationship – Infrastructure Service used by Data Object…

whatswrong-usedby

Wait a minute! What does “Infrastructure Service used by Data Object” actually mean? In natural language it seems to be OK because, after all, my database is managed/presented through the “DB1 (Infrastructure Service)” and therefore relies on it, so I could use it. But let’s examine this situation more closely first.

The first question to ask is whether it is a core or derived relation. That’s the easy part, the Application-Infrastructure Alignment Metamodel clearly shows that it’s not (only Realization from Artifact to Data Object is permitted). So it turns that it must be a derived relation, and we need to find it.

In order to understand what this Used By relation means, let’s start at the endpoint – the Data Object. Only a few core relationships are defined – Realization from Artifact, and Access from both Application Function and Service. A Used By relationship can only be derived from relationships having a strength at least equal to Used by, so this excludes the Access relationship.

After some time checking the Infrastructure Layer Metamodel, I ended up with the following (derived relation in blue):

whatswrong-explanation

“DB1” used by “Shared DB server”? Not what I intended to show, and clearly false in my case (there’s nothing on my database server that make use of the DB service).

Conclusion

All this came about because I used a helpful and nice feature in Archi – the Magic Connector. This can really help you a lot and shows you all allowed relationships between concepts, but it doesn’t tell you which relationships make more sense in a given context. As it is, I know ArchiMate well enough to ask such questions, but what if I were new to ArchiMate? I would have kept the Used By relationship and never have understand its real meaning, a common beginner’s pitfall.

So what can we do? As an Architect, I can make sure that I really understand what I’m doing by learning (and Gerben’s book is perfect for that). As an Archi contributor, I can suggest to enhance the Magic Connector to show me whether it is proposing a derived relation or a core one. We could also envisage that Archi could warn me when I manually create relations or reveal their nature (as with the “Show Structural Chains” option). Adding such a feature would really help a lot of Architects master ArchiMate.

Just for fun, re-examine some of your models and take 5 minutes to see how many derived relations you use, and then check their exact meaning. Do you find some strange things?