Crossing the EA Chasm: ArchiMate 3.0, fix it or re-purpose it?

COPYRIGHT © 2016-2017 by Michael Herman, Toronto, Canada. All rights reserved.

It is the end of January 2017 and, recently, there has been a lot of discussion in the LinkedIn ArchiMate group about the ArchiMate language for enterprise architecture (EA), its “idioms”, usability, adoption, etc.

In addition, in the article Crossing the EA Chasm: Reflections on the Current State of ArchiMate, I asked some questions related to ArchiMate’s purpose and whether it is adequately addressing all of enterprise architecture’s stakeholders’ needs. Crossing the EA Chasm: Re-visioning the ArchiMate Specification is a related article.

These discussions led to this short-form question, the key topic for today:

ArchiMate 3.0, fix it or re-purpose it?

Fixing ArchiMate

On the “fix it” side of the discussion, people will literally be working to fix the language forever. The Open Group is committed to supporting these kinds of efforts; it’s the foundation for why they exist.

But is there a better, compatible approach?  I think there is.

Re-purposing ArchiMate

As a starter, let’s look at the evolution of and technology hierarchy that supports high-level programming languages. Pick your favorite language. Many of you will choose Java; I’m a C# person. (It doesn’t really matter.)

Before the advent of managed, cross-platform execution environments (like the Java VM and the .NET Runtime that provide memory management and garbage collection, advanced exception management, data protection, secure execution contexts, etc.), prior languages like C and C++ followed a simple compilation model as illustrated in Figure 1.

Figure 1. C/C++ Compilation Model

This scenario is synonymous with the current lower-level language support available in ArchiMate 3.0. There’s effectively one language level and that’s all you have.

The C# (.NET) compilation model ups the ante by introducing a cross-platform intermediate language (Microsoft Intermediate Language (MSIL)) as shown in Figure 2.  Java achieves something similar using Java bytecode.

Figure 2. C# Compilation Model: Role of the Microsoft Intermediate Language (MSIL)

Re-purposing ArchiMate as a Lower-Level Intermediate EA Language

In an approach similar to the way the .NET  Framework uses MSIL, ArchiMate can be re-purposed as the lower-level intermediate language for creating higher-level EA languages.

The article Modeling a Company and Its Locations, Markets, Employees, Investors & Roles: Proposals, Wishes & Dreams is a small but real-life, practical example of how this can be executed to create a new EA language for describing Business Organizations (as illustrated below in Figure 3).

Figure 3. Business Organization EA Language, an ArchiMate 3.0 Specialization

This approach more easily and more formally supports the concept of domain-specific languages (DSLs) for enterprise architecture.

As The Open Group moves ArchiMate forward, the published higher-level EA languages can incrementally adopt the new changes – in the same way the Java JIT compilers and Microsoft JIT compilers are updated to adopt new instruction sets from Intel or AMD.

Making It Real

The Archi modeling tool can easily be adapted to serve as the reference implementation for these new EA languages. This is relatively easy to accomplish because all of the ArchiMate relationships remain the same; and, at least initially, it’s simply a matter of extending Archi’s existing ArchiMate elements with families of new elements that address the scope of each new EA DSL.  It is a SMOP.

More food for thought… Please post your comments below.

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.