Category Archives: The Open Group

Crossing the EA Chasm: Graphitization of ArchiMate 3.0 – Iteration 2

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

First Draft: April 5, 2017

This article documents a number of parallel efforts to improve the usability, understandability, utility, and correctness of the ArchiMate 3.0 Specification. In particular, this article extends a well-received previous article Crossing the EA Chasm: Graphitization of ArchiMate 3.0 – Iteration 1 where I posed the question:

Wouldn’t it be nice to have an authoritative reference for ArchiMate 3.0, more specifically, a repository for the enterprise architecture language‘s elements and relationship matrix, that is queryable.

This article documents the current iteration of the ModelMate project, Iteration 2, whose goal is to create an improved queryable repository for a corrected version of relationship matrix (more correct relative to the Appendix B tables in the current ArchiMate 3.0 Specification).

Background

Over the past few months, I’ve written several articles commenting on the current state of the ArchiMate language for Enterprise Architecture including:

In addition, there are almost weekly postings about usability issues or errors with the Specification in the Linkedin ArchiMate group, the GitHub Archi issues log, LinkedIn Pulse, and the Google ArchiMate group; as well as other forums [1][2].

The recent effort, called the ModelMate project, is a focused effort to create a more broadly applicable, usable, useful, ArchiMate-based, extensible language environment for enterprise architecture as described in these 4 articles:

Current Scenario

The current scenario is highlighted by the following points taken from the above references:

  • “[People should be] encouraged to try to model these examples for yourself: to start learning how to “think in ArchiMate” as your second or third written language.” The way the ArchiMate language is currently designed and, more importantly, described makes this difficult.
  • In an abstract sense, the extension of the ArchiMate language is supported but, in reality, few if any broadly adopted extensions have appeared in the market. A better approach is described here: Crossing the EA Chasm: ArchiMate 3.0, fix it or re-purpose it?
  • There is no single, authoritative, machine-readable version of the ArchiMate 3.0 relationship matrix; let alone one that is easily accessible and queryable.
  • The Open Group’s insistence on using abstract terminology to name element types and relation types presents users with additional challenges.

Problem Description

At a data level, the root causes of the problems with the ArchiMate 3.0 relationship matrix in Appendix B of the ArchiMate 3.0 Specification include:

  • No machine-readable version of the tables are available for external validation for correctness
  • The tables contain errors in the approximately 11,000 relations that are represented in the tables.  Is is estimated that there are few hundred to a few thousand errors present in the current ArchiMate 3.0 tables
  • The tables contain all possible (valid) relations but do not differentiate between Core relations and Derived (non-Core) relations.

All three issues are critical for the ArchiMate 3.0 Specification and these tables to be trusted and more generally useful.

In addition, the Derived Relation Derivation Algorithm has never been published by The Open Group.  Attempts to create an alternative algorithm have highlighted that the text of the ArchiMate 3.0 Specification is neither consistent nor complete when it comes to identifying the set of Core Relations and a correct and complete Derviation Algorithm.

Lastly, when dealing with 1000+ Core Relations and several thousand Derived Relations (8000-9000 or more), it’s difficult to analyze and visualize what the ArchiMate 3.0 relationship matrix looks like in total, or when subdivided by Domain (Layer) or Aspect, or when focused on a specific element prototype (e.g. Node).

Solution Overview

The goal of this solution is to publish a very detailed, rich, unnormalized version of the latest and greatest ArchiMate 3.0 relationship matrix in multiple formats; including:

  • CSV text file
  • Microsoft Excel workbook
  • Microsoft Access database
  • Neo4j Cypher Query Language (CQL) queryable graph database file

When loaded into Microsoft Excel, the CSV and Microsoft Excel workbook format files appear as shown in Figure 1 (below).

Step 00 ModelMate Master Dataset Complete.png

Figure 1. ModelMate Master Datasets: Excel 2016 and CSV File Formats

The Microsoft Excel (and CSV) format file can also be used with the Microsoft Excel Web App (Figure 2) and the Microsoft Excel format can be used to create custom SharePoint lists (Figure 3).

step-00-modelmate-master-dataset-complete-web-excel

Figure 2. ModelMate Master Datasets: Excel 2016 format file in MIcrosoft Excel Web App

step-00-modelmate-master-dataset-complete-splist

Figure 3. ModelMate Master Datasets: Custom SharePoint List created from Imported Excel 2016 Format File

When loaded into Microsoft Access, the Microsoft Access database format files appear as shown in Figure 4 (below).

step-00-modelmate-master-dataset-complete-access

Figure 4. ModelMate Master Datasets: MS Access Database file format

To create a queryable graph database version of the ArchiMate 3.0 relationship tables (in effect, the entire ArchiMate 3.0 metamodel), the Cypher Query Language (CQL) file depicted in Figure 5. was created.

Step 00 ModelMate Master Dataset Complete-CQL.png

Figure 5. ModelMate Master Datasets: Neo4j CQL File

Figure 6 is an example of the output from a single line CQL query run against the ArchiMate 3.0 graph database (implemented using Neo4j).  If you look closely at the CQL statement at the top of this screen shot (click Figure 6. to enlarge it), you’ll see that it is selecting all of the relationships across all of the element prototypes in the Technology/Infrastructure domain of the ArchiMate 3.0 metamodel that connect to the Node element prototype.

370-parallelspace_modelmate_masterdataset_complete10-technologydomain7

Figure 6. ModelMate Master Datasets: Graph Mining Analysis Sample

File Downloads

You can download the files referred to in this article from the GitHub repository. Click here to download the ModelMate Master Datasets files.

In addition, there is a Neo4j Cypher Query Language (CQL) file available for download that will ingest all of the element prototypes and relations into a graph database using a single Neo4j shell invocation. From the Windows Powershell or Windows Command Prompt, use:

“C:\Program Files\Java\jre1.8.0_91\bin\java.exe” -classpath “C:\Program Files\Neo4j CE 3.0.6\bin\neo4j-desktop-3.0.6.jar” org.neo4j.shell.StartClient -c dump > MasterDataSet.cql

Lastly, there is Microsoft Access 2016 database version of the CSV file that is available for download if you prefer using Microsoft Access SQL queries or graphical SQL queries.

Solution Details

Below is a copy of the workflow and dataflow used to create the Parallelspace ModelMate Master Datasets.  It’s not as messy as it looks – it’s true mashup and a valuable one at that. It’s primarily the result of the truly ad-hoc collaboration between 3 enterprise architecture professionals with an interesting mix of diverse goals (Gerben Wierda, Ed Roberts and myself); each of us with our own set of preferred development technologies and goals (with Excel being the greatest common denominator (GCD)).

community-basedderivedrelationsproject7

Figure 7. ArchiMate 3.0 Relationship Matrix Resolution Process

The numbered steps in Figure 7. are explained below:

01Data Sources. There are many sources of information about the ArchiMate relationship matrix in addition to the Appendix B tables in the ArchiMate 3.0 Specification. The list in Figure 7. is a fairly complete. Key data sources include the GitHub Archi repository for the most widely used ArchiMate modeling tool for enterprise architecture and Gerben Wierda’s multiple ArchiMate resources publishing under the Mastering ArchiMate brand.

02“MA Core Set” Spreadsheet. Wierda worked to consolidate various data sources from Step 1 above to create the “MA Core Set” Mastering ArchiMate relationship matrix (plus a number of other relationship matrices that Wierda used for comparative analysis and troubleshooting purposes). The “MA Core Set” represents the “seed” or Core Set of (non-derived) ArchiMate relations. Wierda created this Core Set over several iterations reviewing the word-for-word text of the Specification, the inheritance diagrams, as well as incorporating his extensive practical knowledge and experience documenting ArchiMate in the book entitled Mastering ArchiMate – Edition II.

The “MA Core Set” tab in the AllowedRelationsArchiMate30VBA-public.xlsm Excel spreadsheet also includes additional columns that are reserved for calculating and storing an intermediate 3-column, reverse-transposed version of the relationship matrix (Step 3 below).

03CreatePrologList() Visual Basic for Applications (VBA) Macro: This macro is used to perform the actual reverse-transposition of the “MA Core Set” relationship matrix into the 3-column format which including a column for storing the relation(source,target) 3-tuple formatted data (in Prolog format). The 2-D relationship matrix is the input to the macro (along with some additional master data tables that are part of the VBA code). The 3-tuples are the essential output of the VBA macro (stored “in-place” in the first 3 columns of the spreadsheet).

04CoreSet.prolog File. To proceed through to the next step of the workflow, the Prolog format data is copied from the spreadsheet and pasted into a plain text file called CoreSet.prolog, for example (or any other filename you would like to use).

05 Derivaton.py Python Script and outfile.csv. The Derivation.py script contains is the “magic sauce”. Written by Wierda, Derivation.py reads the CoreSet.prolog file and executes a complex and detailed algorithm to expand the Core Set of ArchiMate relations read from the CoreSet.prolog file into a number of alternative output formats, including CSV and Prolog formats.

To support the ModelMate project, a version of Derivation.py was modified to output a number of additional CSV columns (outfile.csv). Columns:

  1. SourceElement
  2. TargetElement
  3. Relation
  4. RelativeStrength
  5. IsInputRelation
  6. StandardVersion
  7. ScriptVersion

06Outfile.xml File. Steps 6 and 7 are part of a sequence of activities that were used to create a relationships.xml file that is compatible with the relationship configuration requirements of the Archi modeling tool. This process, originally implemented by Ed Roberts, owner of Dallas-based Elparazim, uses Excel to load the outfile.csv save it out as an outfile.xml file.

07For Step 7, Ed Roberts wrote an XSL Transform script that when applied to the outfile.xml file creates the Archi-compatible relationship.xml that is used by the Archi model to automatically configure the element-element relations supported in a given version of Archi (e.g. Archi 4.0).

08Steps 8-10 mark an alternative data flow created to support the needs of the ModelMate Master Datasets project.

In Step 8, the contents of the ModelMate-compatible modified CSV output from Step 5 (outfile.csv) is copy-and-pasted into the Parallelspace_ModelMate_MasterDatasets_CoreAndDerivedNN.xlsx Excel workbook (where NN is a version number).

A matrix of automated Excel functions in the Complete spreadsheet merge the elements and relations master data attributes from the Elements and Relations spreadsheet with the data from the Derived spreadsheet to compute the corresponding column values in the Complete spreadsheet. Think of the Complete spreadsheet as a super-unnormalized version of the relationship matrix.  The InInputRelation column values indicate whether a specific relation (and it’s companion source and target elements) are Core relations or Derived relations.

The workbook contains 4 spreadsheets (Derived, Complete, Elements, and Relations):

  • Derived spreadsheet – copy-and-pasted version of the outfile.csv from Step 4. The “input” spreadsheet.
    Columns:

    1. SourceElement
    2. TargetElement
    3. Relation
    4. RelativeStrength
    5. IsInputRelation
    6. StandardVersion
    7. ScriptVersion
  • Complete spreadsheet – leverages the master data in the Elements and Relations tabs to expand the columns in the Derived spreadsheet to include additional metadata property columns for the source and target elements as well as the relations. The “output” spreadsheet that will be saved as a CSV file in Step. 9.
    Columns:

    1. SourceElement
    2. TargetElement
    3. Relation
    4. RelativeStrength
    5. IsInputRelation
    6. StandardVersion
    7. ScriptVersion
    8. RelationName
    9. RelationLabel
    10. RelationQualifiedLabel
    11. RelationForwardVerbLabel
    12. RelationReverseVerbLabel
    13. RelationQualifiedForwardVerbLabel
    14. RelationQualifiedReverseVerbLabel
    15. SourceName
    16. SourceLabel
    17. SourceQualifiedLabel
    18. TargetName
    19. TargetLabel
    20. TargetQualifiedLabel
    21. SourceDomainName
    22. SourceDomainLabel
    23. SourceDomainQualifiedLabel
    24. SourceAspectName
    25. SourceAspectLabel
    26. SourceAspectQualifiedLabel
    27. TargetDomainName
    28. TargetDomainLabel
    29. TargetDomainQualifiedLabel
    30. TargetAspectName
    31. TargetAspectLabel
    32. TargetAspectQualifiedLabel
  • Elements spreadsheet – master data attributes and values for each element prototype.
    Columns:

    1. ElementCode
    2. ElementLabel
    3. ElementName
    4. ElementQualifiedLabel
    5. DomainName
    6. DomainLabel
    7. DomainQualifiedLabel
    8. AspectName
    9. AspectLabel AspectQualifiedLabel
  • Relations spreadsheet – master data attributes and values for each relation prototype.
    Columns:

    1. RelationCode
    2. RelationName
    3. RelationQualifiedLabel
    4. RelationForwardVerb
    5. RelationQualifiedForwardVerb
    6. RelationReverseVerb
    7. RelationQualifiedReverseLabel

09In Step 9, columns 4-32 of the Complete spreadsheet are saved as a separate CSV format file (using the same versioned file name as the parent workbook but with a suffix of .csv).

Also considered part of Step 9, the CSV file is imported into an empty Microsoft Access database. The datatype of the InInputRelation is changed to be a Yes/No (boolean) field. The database file is given the same name as the CSV file but with a suffix of .accdb.

10Step 10 uses a series of Cypher Query Language (CQL) script files to create and populate a Neo4j graph database – to enable simple but powerful ad-hoc queries against the ArchiMate 3.0 relationship tables/metamodel.

Step 10.1. Merge all of Source and Target Element Prototypes

step-01-merge-element-prototypes

Script 1. Merge Source and Target Element Prototypes

Step 10.2. Label Elements with Element, Domain and Aspect Names

step-02-label-elements-with-element-domain-and-aspect-names

Script 2. Label Elements with Element, Domain and Aspect Names

Step 10.3 Create the Metamodel Relationships

TODO

Results

Use Cases

This section documents the results of the following use cases (queries against the Neo4j graph model):

  1. All Business domain source and target element prototypes and all related Core and Derived relationships
  2. All Core relationships where the source element prototype is from the Business domain
  3. All Core relationships where the source and target element prototypes are from the Business domain
  4. All Application domain source and target element prototypes and all related Core and Derived relationships
  5. All Core relationships where the source and target element prototypes are from the Application domain
  6. All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain
  7. All Core relationships where the source and target element prototypes are from the Technology domain
  8. All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other
  9. All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
  10. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
  11. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype
  12. All Core relationships where the source and target element prototypes belong to the Passive Structure aspect
  13. All Core relationships where the source and target element prototypes belong to the Active Structure aspect
  14. All Core relationships where the source and target element prototypes belong to the Behavior aspect

Use Case Results

Click on any of the figures to enlarge them in a separate browser tab.

Business Domain Use Case Results

Use Case 1: All Business domain source and target element prototypes and all related Core and Derived relationshipsUse Cases

Figure 8. is the result of an ad-hoc CQL query against all element prototypes in the Business domain; more specifically, where both the source and target element prototypes are in the Business domain.

100-parallelspace_modelmate_masterdataset_complete10-businessdomain

Figure 8. All Business domain source and target element prototypes and all related Core and Derived relationships

Use Case 2: All Core relationships where the source element prototype is from the Business domain

Figure 9. is the result of an ad-hoc CQL query against all Core relationships where the source element prototype is from the Business domain.

120-parallelspace_modelmate_masterdataset_complete10-businessdomain2

Figure 9. All Core relationships where the source element prototype is from the Business domain

Use Case 3: All Core relationships where the source and target element prototypes are from the Business domain

Figure 10. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Business domain.

130-parallelspace_modelmate_masterdataset_complete10-businessdomain3

Figure 10. All Core relationships where the source element prototype is from the Business domain

Application Domain Use Case Results

Use Case 4: All Application domain source and target element prototypes and all related Core and Derived relationships

Figure 11. is the result of an ad-hoc CQL query against all element prototypes in the Application domain; more specifically, where both the source and target element prototypes are in the Application domain.

200-parallelspace_modelmate_masterdataset_complete10-applicationdomain

Figure 11. All Application domain source and target element prototypes and all related Core and Derived relationships

Use Case 5: All Core relationships where the source and target element prototypes are from the Application domain

Figure 12. is the result of an ad-hoc CQL query against all Core and Derived relationships where the source element prototype is from the Application domain.

230-parallelspace_modelmate_masterdataset_complete10-applicationdomain3

Figure 12. All Core relationships where the source and target element prototypes are from the Application domain

Technology Domain Use Case Results

Use Case 6: All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain

Figure 13. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology/Infrastructure domain.

300-parallelspace_modelmate_masterdataset_complete10-technologydomain

Figure 13. All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain

Use Case 7: All Core relationships where the source and target element prototypes are from the Technology domain

Figure 14. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain.

330-parallelspace_modelmate_masterdataset_complete10-technologydomain3

Figure 14. All Core relationships where the source and target element prototypes are from the Technology domain

Use Case 8: All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other

Figure 15. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain and are identical to each other.

340-parallelspace_modelmate_masterdataset_complete10-technologydomain5

Figure 15. All Core relationships where the source and target element prototypes are from the Technology domain and identical to each other

Use Case 9: All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Figure 16. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing).

350-parallelspace_modelmate_masterdataset_complete10-technologydomain4

Figure 16. All Core relationships where the source and target element prototypes are from the Technology domain and different from each other (non-self referencing)

Use Case 10: All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Figure 17. is the result of an ad-hoc CQL query against all Core and Derived relationships where both the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing).

360-parallelspace_modelmate_masterdataset_complete10-technologydomain6

Figure 17. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Use Case 11: All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype

Figure 18. is the result of an ad-hoc CQL query against all Core and Derived relationships where both the source and target element prototypes are from the Technology domain and are connected to the Node element prototype.

370-parallelspace_modelmate_masterdataset_complete10-technologydomain7

Figure 18. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype

Aspects Use Case Results: Passive Structure, Active Structure, Behavior

Use Case 12: All Core relationships where the source and target element prototypes belong to the Passive Structure aspect

Figure 19. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Passive Structure aspect.

410-parallelspace_modelmate_masterdataset_complete10-passivestructure1

Figure 19. All Core relationships where the source and target element prototypes belong to the Passive Structure aspect

Use Case 13: All Core relationships where the source and target element prototypes belong to the Active Structure aspect

Figure 20. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Active Structure aspect.

420-parallelspace_modelmate_masterdataset_complete10-activestructure1

Figure 20. All Core relationships where the source and target element prototypes belong to the Active Structure aspect

Use Case 14: All Core relationships where the source and target element prototypes belong to the Behavior aspect

Figure 21. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Behavior aspect.

430-parallelspace_modelmate_masterdataset_complete10-behavior1

Figure 21. All Core relationships where the source and target element prototypes belong to the Behavior aspect

Feedback

Please add your comments and feedback to the end of this article.

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

*ArchiMate is a registered trademark of The Open Group.

Leave a comment

Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Definitions, Domain Specification Languages (DSL), Enterprise Architecture, Enterprise Architecture Chasm, graph database, Graphitization, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, Progressive Enterprise Architecture Map (PEAM), The Open Group

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.

cpp-compilation-model-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.

csharp-compilation-model1Figure 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).

parallelspace_modelmate_trumpworld2

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.

4 Comments

Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Domain Specification Languages (DSL), Enterprise Architecture, Enterprise Architecture Chasm, The Open Group

Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Relations as Verbs

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

[Updated: February 6, 2017]

In the article Crossing the EA Chasm: Re-visioning the ArchiMate Specification, I proposed a new architectural framework for re-visioning the current ArchiMate 3.0 Specification.

In this article, I propose using the following list of verbs to either augment or replace the existing ArchiMate relationship names in the Specification and move towards a more humane, more understandable, more usable, and more acceptable language for enterprise architecture.

modelmate-relationship-verbs-2017-02-06

Table 1. Proposed List of Verbs to Augment or Replace
the Current ArchiMate 3.0 Relationship Names

An interesting observation: Note the verbs that start with “Is*”.  They appear in either the “Source-Target” (ForwardVerb) or the “Target-Source” (ReverseVerb) columns but not both for a given relationship.  This wasn’t deliberate – this is just the way it turned out.  Does this indicate anything about which direction is the natural direction for the relationship to point to?

What do you think of this proposal?  Please post a comment below, email me, or post a reply in the LinkedIn ArchiMate group.

To learn more about the background and history of this proposal, check out:

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

2 Comments

Filed under ArchiMate, Architecture Reference Models, Business Value, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, The Open Group

Crossing the EA Chasm: Re-visioning the ArchiMate Specification

It’s not a typo.  “Re-visioning” is the right word; one part, re-envisioning, and one part, revisioning: re-visioning of the ArchiMate 3.0 Specification.

This article presents a new architectural point-of-view for describing the ArchiMate language based on a layered architecture reference model for languages.

Motivation

Frequent feedback is that ArchiMate views are too technical and not “senior management friendly”. No enterprise architect wants to take an enterprise architecture view straight from their favorite modeling tool into a meeting with their CIO (unless their CIO is a very technical person). How can ArchiMate be customized or improved to address this?

ArchiMate often does not work well across heterogeneous or mixed-platform enterprise architectures. For example, it is difficult to work across mixed technology on-premise environments as well as heterogeneous cloud-based IaaS, PaaS, and SaaS platforms supported by a diverse complement of vendors (e.g. Microsoft Azure, Amazon WWS, IBM BlueMix, Salesforce, Google Cloud Platform, SAP, Oracle, VMware, etc.).

This situation is further complicated because none of these platform vendors document their architectures using ArchiMate. Every vendor documents their platforms and architecture reference models using their own collection of concepts, symbols, and stencils.

As of November 2016, there are approximately 3600 ArchiMate certified professionals worldwide according to The Open Group ArchiMate website (approximately 2600 ArchiMate Level 2 certifications and approximately 1000 Level 1 certifications – not accounting for overlaps). By comparison, there are approximately 730,000 Project Management Professional (PMP) professionals worldwide and, according to the OMG, “several tens of thousands of developers hold the OMG Certified UML Professional (OCUP) certification (including the updated OCUP 2 certification program)”. The implication is it should be possible to increase the broader adoption of ArchiMate beyond its current levels.

Another key motivation is to provide an architectural framework that makes it easier to understand how ArchiMate can be customized; making ArchiMate visualizations of EA models more approachable, easier to understand, and accepted by a broader audience. Customization is discussed near the end of this article.

To begin looking at how ArchiMate can be improved in terms of how it is described and how it is used, let’s start by looking at the ArchiMate 3.0 Specification and how ArchiMate is currently documented; and then, look at how the Specification can be improved (or augmented with a companion architecture reference model).

Current ArchiMate 3.0 Specification

What follows is a collection of quotations from the ArchiMate 3.0 Specification.  The quotations have been annotated as follows:

  • Italics have been added for emphasis and to identify key words and phrases
  • Numbered bullets (01) have been added for reference purposes. A legend based on the ModelMate Information Architecture for ArchiMate (described below) appears in Appendix A.
  • NOTE: The numbered bullets and legend (and italicized phrases) are not part of the ArchiMate 3.0 Specification.

Annotated Excerpts from the ArchiMate® 3.0 Specification

Start of excerpts.

Introduction
1.1 Objective

This standard is the specification of the ArchiMate Enterprise Architecture modeling language 01020304, a visual language 06 with a set of default iconography 06 for describing, analyzing, and communicating many concerns of Enterprise Architectures as they change over time. The standard provides a set of entities 0103 and relationships 0203 with their corresponding iconography 06 for the representation of Architecture Descriptions 0409.

1.2 Overview

The ArchiMate Enterprise Architecture modeling language provides a uniform representation for diagrams that describe Enterprise Architectures 07. It includes concepts for specifying inter-related architectures 09, specific viewpoints 07 for selected stakeholders, and language customization mechanisms 010203060708. It offers an integrated architectural approach that describes and visualizes different architecture domain04 and their underlying relations and dependencies 01020304. Its language framework provides a structuring mechanism for architecture domains 04, layers 04, and aspects 04. It distinguishes between the model elements and their notation 0102030406, to allow for varied, stakeholder-oriented depictions of architecture information 07. The language uses service-orientation to distinguish and relate the Business, Application, and Technology Layers of Enterprise Architectures 030405, and uses realization relationships 020305 to relate concrete elements 0103 to more abstract elements across these layers 05.

Language Structure

3.1 Language Design Considerations

image002.png

Figure. 1 Top-Level Hierarchy of ArchiMate Concepts 0102030509

End of excerpts.

The italicized words and phrases are the key words and phrases which describe the key ideas that make up the ArchiMate language (e.g. modeling language, visual language, a default set of iconography, set of entities and relationships, etc.). The initial sections of the Specification’s Introduction (quoted above) provide a comprehensive overview of the ArchiMate language.

The numbered bullets relate the key words and phrases in the Specification’s Introduction to the ModelMate Information Architecture for ArchiMate (described later in this article).

The Specification’s Table of Contents illustrates how the current version of the specification is structured:

  • Preface
  • 1. Definitions
  • 2. Language Elements
  • 3. Generic Metamodel
  • 4. Relationships
  • 5-13. Layers and Domains of language concepts further organized by Aspects
  • 14. Stakeholders, Views, and Viewpoints
  • 15. Language Customization Mechanisms

The approach used to describe ArchiMate can be improved.

An Alternative, Architectural Approach for Describing ArchiMate

Is there an alternative (and perhaps a better way) to describe the ArchiMate language with the goal of encouraging broader adoption, greater support, and more innovative applications of the ArchiMate language?  I think there is. Let’s consider a generic architecture reference model for languages like ArchiMate.

ModelMate Information Architecture for Languages

What is the ModelMate Information Architecture for Languages? The ModelMate Information Architecture for Languages (MIAL) is an architecture reference model for analyzing and describing languages.  The initial use cases are from the enterprise architecture domain but their applicability is not limited to enterprise architecture.

There are 8 primary domains in the MIAL architecture reference model (from the bottom up):

  • Vocabulary
  • Semantics
  • Grammar
  • Visual Notation
  • Visualizations
  • Descriptive Information
  • Overall Structure
  • Text Notations

For the most part, these are familiar concepts for describing most languages; technical languages in particular. These concepts are illustrated below.

modelmate-information-architecure-for-languages-3-0-5-overview

Figure 2. ModelMate Information Architecture for Languages

The MIAL 8 domains have the following definitions:

  • Vocabulary lists the names of the nouns and verbs of the language (and possibly other language parts)
  • Semantics provides meanings for each of nouns and verbs
  • Grammar governs the composition of nouns and verbs into phrases or other constructs (phrases, sentences, paragraphs, chapters, and stories)
  • Separate from the Vocabulary elements themselves, a Visual Notation provides a collection of one or more graphic renderings of each individual noun and verb
  • Visualizations describes how the Grammar and Visual Notation can be used together to create graphical views consisting of multiple compositions of nouns and verbs (graphical phrases, sentences, and paragraphs)
  • Descriptive Information describes what kinds of additional descriptive information (metadata) can be used to annotate the nouns and verbs in the Vocabulary
  • Overall Structure of a document or model
  • Text Notations for serializing an ArchiMate model into XML, JSON, or native spoken language documentation, as examples

An additional list of definitions can be found in this glossary.

The MISL 8 domains are, in turn, subdivided into MIAL 10 essential elements:

  1. Vocabulary of nouns
  2. Vocabulary of verbs
  3. Semantic definitions for the nouns and verbs
  4. Grammar rules for governing the composition of nouns and verbs (grammatical structure)
  5. Grouping and organizing constructs
  6. Visual notation comprised of a set of graphical symbols for each noun and verb
  7. Normative descriptions to guide the creation of visualizations based on the grammar rules and visual notation
  8. Annotation of nouns and verbs with descriptive information (metadata)
  9. Overall structure of a document or model
  10. Other notations for representing the structure (e.g. text, XML, JSON, native spoken languages)

Let’s look at how this information architecture reference model can be applied to ArchiMate.

ModelMate Information Architecture for ArchiMate

What is the ModelMate Information Architecture for ArchiMate? The ModelMate Information Architecture for ArchiMate (MIAA) is an instance of the MIAL customized to serve as an information architecture reference model for the ArchiMate language.

NOTE: The ModelMate Information Architecture for ArchiMate is not part of the ArchiMate 3.0 Specification.

Below is the list of the MIAL 10 essential elements customized for ArchiMate:

01 Vocabulary of nouns (elements) – a vocabulary of words

02 Vocabulary of verbs (relationships) for relating one noun to another – another vocabulary of words

03 Semantic definitions for the nouns (elements) and verbs (relationships) for describing enterprise architecture models – a glossary of definitions

04 Grammar rules for governing the composition of elements and relationships into a model – a grammar

05 Collection of domains and layers for organizing the elements into several (mostly) horizontal categories (Strategy, Business, Application, Technology, Physical, Implementation & Migration) and a collection of aspects for organizing the elements across the domains into a number of vertical categories (Active Structure, Behavior, and Passive Structure) – a taxonomy

06 Visual notation comprised of a set of graphical symbols for each element and relationship – an iconography

07 Normative descriptions of views and viewpoints to guide the creation of visualizations based on the visual notation and grammar rules

08 Annotation of elements and relationships with descriptive information – metadata

09 Model structure comprised of the elements, relationships, views, and metadata enabling models of enterprise architectures to be created, analyzed and visualized – an information architecture reference model

10 Text-based notation (e.g. XML-based model exchange format) for describing an enterprise architecture model (a collection of elements, relationships, views, and metadata) – enabling the serialization of an enterprise architecture model based on the information architecture.

The annotated excerpts from the ArchiMate 3.0 Specification found earlier in this article unpack the text of the specification by mapping the numbered bullets found next to each of the specification’s key words and phrases to the 10 elements of the ModelMate Information Architecture for ArchiMate.

The ModelMate Information Architecture for ArchiMate is illustrated graphically in the following figure. Study this architecture reference model from the bottom up.

modelmate-information-architecure-for-archimate-3-0-3

Figure 3. ModelMate Information Architecture for ArchiMate

Organization-Level Customization

Given the layered structure of the ModelMate Information Architecture for ArchiMate, it is straightforward to see how ArchiMate lends itself to being customized at each level of the 8 domains:

  • Vocabulary
  • Semantics
  • Grammar
  • Visual Notation
  • Visualizations
  • Descriptive Information
  • Overall Structure
  • Text Notations

Extend, Replace/Update, or Remove?

Below is an initial version of the ModelMate Information Architecture for ArchiMate customization decision matrix.

mial-for-archimate-1-0-1

Table 1. ModelMate Information Architecture for ArchiMate: Customization Decision Matrix

The first thing to note is how the decision matrix drove forward the idea that the MIAL 8 domains can be categorized into 2 groups:

  • Core
  • Non-Core

The Core group includes the “bottom 4” domains characterized by almost no opportunity for customization.  The Non-Core group includes the “top 4” domains characterized by being almost totally customizable.

Future articles will go into more depth in terms of describing how each domain in the ModelMate Information Architecture for ArchiMate can be customized.

This article is the main course; now proceed to the next course in this series: Crossing the EA Chasm: ArchiMate “Keep Calm and Have It Your Way”.

For additional thoughts on these topics, check out Crossing the EA Chasm: Reflections on the Current State of ArchiMate.

Bon Appetit,
Michael Herman (Toronto)
Parallelspace Corporation
mwherman@parallelspace.net

Appendix A – ModelMate Information Architecture for ArchiMate Legend

The following legend is based on the ModelMate Information Architecture for ArchiMate.

NOTE: This legend is not part of the ArchiMate 3.0 Specification.

01 Vocabulary of nouns (elements)
02 Vocabulary of verbs (relationships) for relating one noun to another
03 Semantic definitions for the nouns (elements) and verbs (relationships)
04  Grammatical structure governing the composition of elements and relationships
05 Collection of domains and layers and aspects
06 Visual notation (iconography) for each element and relationship
07 Normative descriptions of views and viewpoints
08 Annotation of elements and relationships with descriptive information (metadata)
09 Information architecture (model structure) for enterprise architecture models
10 Text-based notation (XML-based model exchange format) for describing an enterprise architecture model

*ArchiMate is a registered trademark of The Open Group.

11 Comments

Filed under ArchiMate, Architecture Reference Models, Definitions, Enterprise Architecture, How do we think, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, The Open Group

Crossing the EA Chasm: ArchiMate Art

As we research new and interesting ways for visualizing enterprise architecture models, we sometimes discover the “unexpected”. Check out these visualizations of visualizations.

img_20161117_113141_processed

img_20161117_113150_processed

img_20161117_113250_processed

img_20161117_113257_processed

img_20161117_113343_processed

img_20161117_113421_processed

img_20161117_113441_processed

img_20161117_113449_processed

img_20161117_113529_processed

img_20161117_113545_processed

img_20161117_113610_processed

img_20161117_113625_processed

img_20161117_113638_processed

img_20161117_113643_processed

img_20161117_113709_processed

img_20161117_113714_processed

img_20161117_113718_processed

img_20161117_113722_processed

img_20161117_113728_processed

img_20161117_113741_processed

img_20161117_113745_processed

img_20161117_113757_processed

img_20161117_113810_processed

img_20161117_113815_processed

 

Best regards,
Michael Herman (Toronto)

*ArchiMate is a registered trademark of The Open Group

Leave a comment

Filed under ArchiMate, Crossing the EA Charm, Humor, The Open Group

Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1

If you have been following my Crossing the EA Chasm blog series (and related articles), you’ll have noticed a number of common themes:

Automating Enterprise Architecture Modeling

Automated enterprise architecture modeling (and automated application architecture analysis) are activities that belong to the Listening and Learning phase of the Continuous Transformation Framework.

Progressive EA Model 1-0-9-PEAM3-EA Chasm-Auto-Dots.png

Figure 1. Progressive Enterprise Architecture Model: Continuous Transformation Framework

Supporting the above themes, the Technology layer diagram below is automatically generated from a simple, single line query applied to an automatically created and dynamically maintained model of 500+ Windows and Linux servers (blue dots) with 550+ server network adapter configurations (yellow dots) connected to 25 network gateways (blue dots representing 25 network routers/switches). The data originates from a series of tables maintained by a configuration management database (CMDB) solution. There is no way to understand what the Technology environment looks like by simply looking at these tables.  However, in the visualization below, it is easy to see that there are at least 14 different server farms, application clusters, and data centers.

Parallelspace TEAM-DevicesA.png

Figure 2. Automatically Generated Technology Layer Model and View

In this ModelMate model, servers are represented by Nodes with 179 properties;  network adapter configurations as Devices with 69 properties each; and, network gateways as Devices with 4 properties per device.

This is just the beginning as additional information about web application, database, DNS, and directory and domain management services is used to add additional  detail to the current state Technology layer of this enterprise architecture. “More news at 11…” (click here).

This effort was made easier through the use of ModelMate and the Neo4j Community Edition free, open source graph database and the Cypher query language.

Best regards,

Michael Herman (Toronto)

Parallelspace Corporation

mwherman@parallelspace.net

3 Comments

Filed under ArchiMate, Architecture Reference Models, Automated Application Architecture Analysis, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Data Science, Enterprise Architecture, ModelMate, Progressive Enterprise Architecture Map (PEAM), The Open Group

Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases

[Updated October 20, 2016]

As I’ve worked to support open access to enterprise architecture data by creating the ModelMate project, the range and diversity of how enterprise data can be analyzed and visualized has proved to be amazing.  Here’s yet another example: the marrying of open EA data in ModelMate models with a graph database platform …in less than 1 day.

The native (schema-less) representation for a graph database mirrors the ArchiMate* metamodel one-for-one:

  • Entities that support named types (“labels”)
  • Relationships between directed pairs of entities that also support named types (“relationship types”)
  • Unlimited property sets per entity
  • Unlimited property sets per relationship

Add to this, powerful query capabilities, a small footprint, and hyper-scalability. For example, being able to find all of the ArchiMate concepts that are 1, 2, 3, or an infinite number of relationships away from each of the Application Components in a large model and have these queries run and visualize in milliseconds (see the examples below).

For ModelMate’s first graph database integration, Neo4j from Neo Technologies was used. It was simple and efficient to install and was useable within a few minutes.  After working most of the morning to learn the Cypher query language to integrate and query the ModelMate data, the afternoon was spent exploring the graph model and experimenting with a range of queries. The most recent ModelMate logical architecture looks like the following (October 19, 2016).

modelmategraphdbhighlighted

Figure 1. ModelMate Logical Architecture

Automated Application Architecture Analysis

What are some of the results?  Here’s a series of views created with simple, single-line queries against the ModelMate graph. The scenario is automated application architecture analysis to support migration of on-premise applications to the cloud.

This version of the VetContext ModelMate model used for this example included:

  • 8714 elements (nodes) – files, assemblies, modules, methods, fields, method calls, and field references represented as ArchiMate application and technology layer concepts
  • 16,210 relationships – modeled as ArchiMate relationships that linked the above elements into a ModelMate graph

TIP: If you click on each image, you can check out the single line query at the top of each screenshot.

vetcontexta

Figure 2. Application Architecture: Contains and References Relations (1 hop)

vetcontextb

Figure 3. Application Architecture: Contains, Defines, and References Relations (2 hops)

vetcontextd

Figure 4. Application Architecture: Accesses, Calls, Contains, Defines, References, References and Type For Relations (3 hops)

 

vetcontextz

Figure 5. Application Architecture: Visualize Relations between all Application Components, Artifacts, and System Software Components (any number of hops)

vetcontexte

Figure 6. VetContext ModelMate Graph: All Application Components (any number of hops)

In Figure 7 below you can see the much smaller VetContext application in the green circle in contrast with all of the public classes and methods found in the Entity Framework assembly from Microsoft (blue circle).

VetContextEFHighlighted.png

Figure 7. VetContext Application References into the Microsoft Entity Framework

Impressive for 1-day’s worth of effort (including training).

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

Mail: mwherman@parallelspace.net

p.s. What is the VetContext ModelMate model that I’m using for these blog postings?

The VetContext ModelMate model is based on the Microsoft Entity Framework sample of the same name from the book Programming Entity Framework: Code First by Julia Lerman and Rowan Miller. The ModelMate model is comprised of data from all of the .NET assemblies, modules, type definitions (including classes, enums, etc.), method definitions, field definitions, method calls and field accesses as well as the physical files that store the assemblies in the VetContext sample application. A simplified VetContext class diagram (from Visual Studio) appears below.

vetcontextclasshierarchy

Figure 8. VetContext Class Diagram

The ModelMate Scanner for .NET Application Migration reads a folder of all of the .exe and .dll files for one or more .NET applications and builds the ModelMate model. No source code is needed. The scanner reads and parses the intermediate language (MSIL) directly.

p.p.s. The original ModelMate SQL Server schema (the original data source for the ModelMate graph) looks similar to the following. This was used before ModelMate included support for graph databases.

modelmateschema-views

Figure 9. ModelMate SQL Server (non-graph database) Schema
(obsoleted by the ModelMate migration to Neo4j graph database)

 * ArchiMate is a registered trademark of The Open Group.

 

2 Comments

Filed under ArchiMate, Automated Application Architecture Analysis, Crossing the EA Charm, Data Science, Enterprise Architecture, Graphitization, Progressive Enterprise Architecture Map (PEAM), The Open Group

Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love

[Updated October 13, 2016]

Let’s face it – not everyone is in love with the traditional enterprise architecture diagrams that are based on the ArchiMate* standard. Here, more or less, is a typical ArchiMate view.

modelmateeff1

Figure 1. A Traditional ArchiMate View: VetContext ModelMate Model

What if there was a way to create literally any type of visualization you wanted – from a common, central, “single version of the truth” repository?  Something your grandmother (and CIO) will love?

The first step is to unlock your enterprise architecture data.

In the recent article Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture, I described an open data access strategy for providing easy access to EA data from virtually any open source or COTS (commercial-off-the-shelf) modeling, data visualization, machine learning, or business intelligence platform.

The ModelMate project is a realization of this open repository strategy for EA data.  ModelMate supports access to a central EA repository using the following protocols:

  • The Open Group ArchiMate Model Exchange File Format (EFF) import and export
  • OASIS OData interoperability REST web API
  • .NET API for C# and VB.NET developers
  • Direct access to the underlying SQL Server repository using T-SQL stored procedures

The latest version of the ModelMate architecture is depicted below (October 12, 2016).

modelmate-integrations-1-0-6-pbix

Figure 2. The Model Mate Project: Logical Architecture

What sorts of visualizations does an open repository strategy like ModelMate enable? Check out the following ModelMate Graph rendered as an interactive EA exploration tool using Microsoft Power BI, the free desktop edition. This is just one rendering – the number of possibilities is limitless.

ModelMateGraph1.png

Figure 3. VetContext ModelMate Graph rendered using Microsoft Power BI (desktop)

From Power BI Desktop, it takes a couple clicks to publish a live, interactive, web version of the model to the cloud – the same ModelMate model that was used to create Figure 1.

modelmategraph1web

Figure 4. VetContext ModelMate Graph rendered using Microsoft Power BI (cloud)

Click here to check it out for yourself: ModelMate Graphs running in the cloud.

The above “spaghetti” visual is just one of the dozens of custom visuals available for Power PI.  Here’s a sampling….

This slideshow requires JavaScript.

Figure 4. Microsoft Power BI Custom Visual Gallery

TIP: To use Data Science platforms like Power BI and R to get the most out of your EA data, consider looking into the Microsoft Professional Degree Program in Data Science.

Please email me if you have any questions or additional comments at mwherman@parallelspace.net.

Best regards,

Michael Herman (Toronto)

Parallelspace Corporation

p.s. Don’t forget to email a copy of the link to your grandmother (or your CIO).  Please add your feedback in the Comments section below.

p.p.s. Here’s an updated view of the same VetContext ModelMate model using the latest version of SPARX Enterprise Architect version 13 that was released earlier this week. The layout was created using the Digraph automated layout feature.  When you have a powerful and easy way to scan and ingest arbitrary sized datasets, features like automated layout and routing become critically important.

vetcontext-logical-architecture-1-0-6

Figure 5. VetContext ModelMate Model in SPARX Enterprise Architect 13

* ArchiMate is a registered trademark of The Open Group

2 Comments

Filed under Crossing the EA Charm, Enterprise Architecture, Microsoft Azure, ModelMate, Power BI, The Open Group

Using ArchiMate 2.1 to Model Product or Service Markets

In the LinkedIn ArchiMate group, Toon Wijnands posted a query asking

I’m looking for the concept of modelling ‘Market’. I’m referring to the markets a company is active at. e.g. you could have a B2C market and a B2B market, or USA market, European market, Asian market.
[Any suggestions on how to model the concept ‘Market’ in ArchiMate?]

My response was:

Michael Herman (Toronto) I recommend using a Location to represent a Market and to aggregate the concepts that are relevant to each market and to your model’s goals. This includes using Location as an abstraction for specific B2B and B2C markets – making sure to document this practice in your EA governance document.

The aggregated concepts can [be] nested within each Location as a mini-model. Each mini-model can include Stakeholders (including specific or representative, customers, government entities, other regulatory bodies, competitors, etc), as well as Constraints and Requirements imposed by the preceding Stakeholders, etc. The market-specific set of Constraints and Requirements can then be linked to a possibly smaller, more uniform set of Drivers.

Ownership and updating of the Market mini-models, singly or in total, can be given to a member of your EA team or a business client within your organization. Elaborate Market models can be licensed or sold – but I’m getting off topic.

As a follow-up, here’s a concrete example using ArchiMate 2.1 and the Archi modeling tool; including the exact steps I followed to create a Market mini-model.

Start at the top: Most Markets are defined by their Stakeholders: Customers (or their Personas), Competitors, and Government Agencies (and perhaps, other regulatory or standards bodies). Use these to drive out a selected set of Drivers and Goals for your next product release. Of course, the current state of your Market model doesn’t have to respond to every Stakeholder or Driver.  Include all of these in the model but, in the current state of the model, only include the Goals you are trying to satisfy in the next release. From the Goals, derive more specific product or service Requirements.

In addition, add a Market Research Team as a Stakeholder to document specific market analyses or Assessments as part of your mini-model; linking these to a new or existing set of Goals.

You’ll end up with something like the following. Click to enlarge.

Markets 0

Of course, the current state of your Market mini-model doesn’t have to respond to every Stakeholder or Driver.  Include all of these in the model but, in the current state of the model, only include the Goals you are trying to satisfy in the next release. From the Goals, derive more specific product or service Requirements.

TIP: Because of the way ArchiMate works, make sure each Driver, Goal, Assessment, Requirement, etc. is linking to a Stakeholder; hence, the reason for creating the Market Research Team stakeholder.

TIP: Consider creating 3 views (I call them Construction Views) to help you track your work. In my model, I called them Markets 0, Markets 1, and Markets 2.  The above view is Markets 0.

Then select all of the elements of your Market mini-model, and drag and drop them onto a Location element (named Market M in the above example) to get the second version (view) of the model.

TIP: Different ArchImate modeling tools handle this action in different ways. In my example, Archi prompts you to add Assignment relations to relate each of the 5 Stakeholders to the Market M location element. I’ll talk more about this later.

…and voila!, here is one example of a Market mini-model.  Use the same technique to create mini-models for your additional markets. Click to enlarge.

Markets 1

What’s going on behind the scene views?

To understand how ArchiMate (and Archi) chose to model this scenario, after you’ve dragged and dropped your mini-model onto the Location element and accepted the creation of the new Assignment relations, do the reverse: select all of the mini-model elements nested inside the Location and drag and drop them outside of the Market M location element.  Your (third) view should look something like the following. Click to enlarge.

Markets 2

The Market M Location element is related to each Stakeholder using the automatically created Assignment relations.  The rest of the mini-model is related to the Location element via Derivation. This is why it was important to have the Assessment, Driver, Goal, Requirements, etc. elements related to a Stakeholder.

Every language (conventional or technical) has its idiosyncracies. Use ArchiMate and make it work in a way what works best for you and your organization.

Best regards,
Michael Herman (Toronto)

p.s. Please add your feedback in the Comments section below.  How can this idea be improved?

2 Comments

Filed under ArchiMate, Architecture Reference Models, Enterprise Architecture, Product Management, The Open Group