Category Archives: ModelMate Information Architecture for Languages

May 18, 2017 · 7:57 am

Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor

Michael Herman is an expert when it comes to the mathematical modeling, analysis, and visualization of almost everything:

Large enterprise organizations,
Commercial, global-scale, cloud services platforms,
Organization principles and belief systems,
Human platforms,
Aircraft engines, and
Muscle cars.

Michael is the inventor of the #Graphitization Continous Transformation Model – a closed-closed loop feedback process for the ingestion, modeling, analysis, visualization, systems optimization, and life cycle management of any type of strategy, system, asset, architecture, or process.

Figure 1. #Graphitization Continuous Transformation Model

A key concept of #Graphitization is the implementation of Transformative Changes that result in positive increases in business value in the system being modeled.

#Graphitization

What is #Graphitization?

#Graphitization is a data science and enterprise architecture framework and process model for modeling, ingesting, organizing, analyzing, and visualizing any domain of endeavor by using graphs – networks of connected objects and relationships with each object and relationship annotated with additional descriptive information (metadata).

The primary applications of #Graphitization are:

System optimization,
Systems life cycle management, and
Transformative Change in resulting in positive increases in business value for the system being studied.

A system is defined as any collection of strategies, system components, assets, architectures or processes.

References

#Graphitization Continuous Transformation Model

The #Graphitization general model is described in Figure 2. as it applies to the design and optimization of large enterprise organizations.

Figure 2. #Graphization Continuous Transformation Model: Large Enterprise Organizations

The same model can also be used to improve the design and operation of many different types of systems:

Large scale enterprise organizations (public and private sector)
Aircraft engines, muscle cars, and other high-performance engine systems
Commercial, global-scale, cloud services platforms
Automated service composition of cloud services-based data systems
Large collaborative ecosystems: employee groups, business partners, social networks
Large ecosystems of competing or competitive business organizations
Organization principles and belief systems
Conventions software applications and architectures: desktop, server, and web apps
International standards for visual modeling languages
Parallelspace ModelMate
Enterprise Data Management
Internet of Things (IoT)
Architecture Reference Models

Standards

NEO Enhancement Proposal (NEP) Standards Author

Principal author: NEP-10 Composite Smart Contracts
“This NEP proposes a solution to the scenarios where a smart contract supports extensions to an existing standard. Conforming to this NEP involves implementing a single required, constant-valued operation and method `supportedStandards`, and possibly creating one or more new NEPs to define any new, required set(s) of required operations and methods.”
Reference: https://github.com/neo-project/proposals/blob/master/nep-10.mediawiki

Projects and Publications

0. SerentityData Graph

Model-based off-chain and on-chain (blockchain) graph data creation, migration, visualization, and analysis

Abstract

SerentityData Graph is an entity-relationship modeling, serialization, and graph analysis solution that supports development of traditional full-stack and blockchain smart contract applications. SerentityData features tight Neo4j integration for on-chain & off-chain graph data visualization and analysis.

Description

SerentityData Graph is an open source, entity-relationship modeling, serialization, and graph data visualization and analysis solution that supports the development of traditional full-stack, blockchain-based smart contract, and Neo4j graph database applications.

Starting from a single data model, SerentityData supports the automatic code generation of entities and relationships that support symmetric development of: (a) off-chain data in traditional multi-tier full-stack applications, (b) on-chain data management for blockchain-based distributed ledger technology apps (dApps), and (c) Neo4j enterprise graph applications.

SerentityData features complete life-cycle integration with Neo4j for on-chain and off-chain graph data creation, migration, visualization, and analysis. Live code walk-throughs and demonstrations will enable you to begin using SerenityData and Neo4j immediately. Github: https://github.com/mwherman2000/serentitydata-compiler

Resources

My blog: https://hyperonomy.com/

Related blog posts

Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor https://hyperonomy.com/2017/05/18/michael-herman-inventor-of-graphitization/
#Graphitization of the Enterprise https://hyperonomy.com/2017/01/02/graphitization-of-the-enterprise/
Tokenize Every Little Thing (ELT) https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/
#Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases https://hyperonomy.com/2016/10/19/crossing-the-ea-chasm-marrying-open-ea-data-with-graph-databases/
#Graphitization of Ray Dalio’s Principles: Iteration 1 https://hyperonomy.com/2016/12/29/graphitization-of-ray-dalios-principles/
#Graphitization of Ray Dalio’s Principles: Iteration 2 https://hyperonomy.com/2016/12/30/graphitization-of-ray-dalios-principles-iteration-2/
Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1 https://hyperonomy.com/2017/01/17/crossing-the-ea-chasm-graphitization-of-archimate-3-0/
Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 2 https://hyperonomy.com/2017/02/08/crossing-the-ea-chasm-graphitization-of-archimate-3-0-iteration-2/
Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1 https://hyperonomy.com/2016/10/22/crossing-the-ea-chasm-automating-enterprise-architecture-modeling/
Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2 https://hyperonomy.com/2016/11/04/crossing-the-ea-chasm-automating-enterprise-architecture-modeling-2/
Crossing the EA Chasm: ArchiMate “Keep Calm and Have IT Your Way” https://hyperonomy.com/2016/11/17/crossing-the-ea-chasm-archimate-have-it-your-way/
Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture https://hyperonomy.com/2016/10/04/the-ea-chasm-open-repository-strategies-for-enterprise-architecture/
Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love https://hyperonomy.com/2016/10/13/archimate-diagrams-your-grandmother-and-cio-will-love/
#Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository https://hyperonomy.com/2017/02/10/crossing-the-ea-chasm-how-to-use-the-modelmate-online-repository-mmor/
#Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1 https://hyperonomy.com/2017/05/08/amazons-principles/
What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale? https://hyperonomy.com/2017/04/10/whats-the-difference-between-improving-the-design-and-operation-of-an-aircraft-engine-a-muscle-car-a-large-enterprise-and-a-commercial-global-cloud-services-platform/

Live Neo4j Models

http://hobby-icgaeohcoeaggbkeabhldpol.dbs.graphenedb.com:24789/browser/ Userid: ModelMate_Master_Datasets10 Password: YqeZAH4ODEJqglkEsK5p

YouTube Channel: https://www.youtube.com/playlist?list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5

12. NEO Persistable Classes (NPC) Platform 2.1: Preview https://www.youtube.com/watch?v=N-jiJOZwiFg&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=5
NEO Persistable Classes (NPC) Platform 2.0: Deep Dive https://www.youtube.com/watch?v=Nj4-m2o94VE&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=6
NEO Persistable Classes 1.0: Deep Dive (Video 2 of 3) [Update 1] https://www.youtube.com/watch?v=qwteL1BiCjM&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=7
NEO Persistable Classes Platform 2.2: Structured Storage & Reusable, Indexed, Non-Fungible Entities https://www.youtube.com/watch?v=vnAxyCAZ1ec&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=10

Related Github Projects

SerentityData Entity Compiler (serentitydata-compiler) https://github.com/mwherman2000/serentitydata-compiler/blob/master/README.md
NEO Persistable Classes (NPC) Compiler 2.1 (npcc) – Compiler for the NEO Persistable Classes (NPC) Platform 2.1 https://github.com/mwherman2000/neo-npcc2
NEO Persistable Classes V1.0 – An Efficient Object-Oriented Framework for C#.NEO Smart Contract Development (ORIGINAL) – https://github.com/mwherman2000/neo-persistibleclasses

Recognition

NeoDraw – NEO Persistable Classes Platform 2.0: NEO-Microsoft dApp Competition (4th place prize – USD$15,000) – https://neo.org/blog/details/3074 and https://neo.org/awards.html

Keywords

blockchain on-chain data modeling symmetric programming data management .NET C# NEO Stratis Ethereum Technical Case Study Developer Best Practices

1. Large scale enterprise organizations (public and private sector)

The first applications of #Graphitization were in the field of traditional enterprise architecture modeling and analysis:

Business Architecture
Application Architecture
Technology/Infrastructure Architecture

References

2. Aircraft engines, muscle cars, and other high-performance engine systems

It turns out that the modeling and analysis of any complex system is an ideal candidate for #Graphitization.

References

What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

3. Commercial, global-scale, cloud services platforms

One particularly important application is the modeling and analysis of very large, commercial, global-scale, cloud services platforms.

References

What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

4. Automated service composition of cloud services-based data systems

Call the solution “Expedia for Microsoft Azure/AWS/SFDC/…” or whatever you prefer, today’s commercial cloud services platforms are still a pain in the ass to use for creating non-trivial applications. Left, right, and center you have to hand-code a myriad of worker processes simply to reformat and pass data around.

#Graphitization is an optimal approach for modeling the underlying cloud services platform services catalog.

References

5. Large collaborative ecosystems: employee groups, business partners, social networks

Project “Boston” is named after some potential business partners and the embryo for the idea coming from my months as a founding Groove Networks business partner (including many of my most important relationships that I still maintain today).

6. Large ecosystems of competing or competitive business organizations

Modeling of large ecosystems of competing/competitive business organizations is a straightforward #Graphitization use case.

7. Organization principles and belief systems

On the surface, the #Graphitization of principle and belief-based frameworks is pretty straightforward but this is because the basic #Graphitization serves as the substrate for many advanced data ingestion, analysis, and visualization projects.

Below are the results of the #Graphitization of two principle and belief-based frameworks:

Bridgewater Associates: Ray Dalio’s Principles
Amazon: Jeff Bezos’ Amazon Leadership Principles

References

8. Conventional software applications and architectures: desktop, server, and web apps

Modeling of complex, multi-language, multiple runtime software environments is a use case that is an ideal application of #Graphitization.

References

9. International standards for visual modeling languages

A significant investment has been made in applying #Graphitization to language modeling; specifically, languages for enterprise architecture like ArchiMate.

ArchiMate References

10. Enterprise Data Management

Modeling and analyzing enterprise data structures and stores is a common application of #Graphitization; including the modeling of taxonomies and master data.

References

RE: Managing Master Data With ArchiMate

11. Parallelspace ModelMate

Parallelspace ModelMate is an approach (platform and language framework) for creating domain specific languages (DSLs) for enterprise architecture. It is realized using #Graphitization and the ArchiMate enterprise architecture modeling language.

References

12. Internet of Things (IoT)

IoT is an interesting beast. It is a reference to an application service for processing raw events from a device or dynamically generated events from a software system. IoT also defines a conceptual software and data flow architecture that can also be used for the dynamic creating and maintenance of complex systems such as large enterprise architectures.

References

13. Architecture Reference Models (ARMs)

An ARM is easily modeled (and analyzed) using #Graphitization. SharePoint and Azure Stack are two good examples.

References

General References

Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
To dig deeper, check out Graphitization of the Enterprise (click here)
[Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)
Crossing the EA Chasm: The Surveyor

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

ArchiMate is registered trademark of The Open Group.

1 Comment

Filed under ArchiMate, Architecture Reference Models, Automated Application Architecture Analysis, Automated Enterprise Architecture Modeling, Graphitization, How do we think, Microsoft Azure, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

February 28, 2017 · 11:25 am

Michael Herman: Award-winning Author, Invited Speaker, Illustrator, and Trainer

Feel free to contact me at:

Michael Herman
mwherman@parallelspace.net
(416) 524-7702

PARTIAL PORTFOLIO

All of the publications below are full-length white papers or technical notes – unless noted otherwise (e.g. presentations, training materials, online product help).

Tzunami K-Wise Deployer

Client: Tzunami

Tzunami Inc. Evaluation Guide: Using K-Wise Deployer™ for Rapid Content Migration into Microsoft SharePoint Products and Technologies (50 pages)

#Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository

MMOR (pronounced “more”) is an online, queryable version of an updated, corrected version of the ArchiMate 3.0 relationship matrix – originally described in the article The Graphitization of ArchiMate.

The source data for MMOR is based on Gerben Wierda‘s recent (February 2017) blog article The ArchiMate 3.0 Relations Table….

This article provides an overview – a teaser, actually. I’m working on a more in-depth description that I’ll publish next week. HINT: If you poke around on hyperonomy.com – digital intelligence, you’ll find the “WIP” draft.

Logging into MMOR (pronounced “more”)

MMOR Url: http://hobby-icgaeohcoeaggbkeabhldpol.dbs.graphenedb.com:24789/browser/
MMOR Username: ModelMate_Master_Datasets10
MMOR Password: YqeZAH4ODEJqglkEsK5p

The above app url, username and password provide you with read-only access to the MMOR graph database – you can’t hurt anything. Please go ahead and try it using some of the sample queries I’ve documented below.

CAVEAT: There are zero guarantees on my part in terms of the availability, reliability, or performance of this hosted solution. I’ll be making changes with no advance notice.

Running Queries

To run a query, follow these steps:

Connect to the MMOR app and login (see above)
Copy & paste each query (one at a time) into the query box (next to the ‘$’ sign)
Click the “Play” icon to run the query

Figure 1. Copy & paste each query (one at a time) – then click Play (click to enlarge)

TIP: After you’ve run your first query, in the bottom-right corner of the visualization, turn Auto-Complete to the Off position by clicking on the icon.

Figure 2. TIP: Turn Auto-Complete to the Off position

Sample Query A: Node Prototype, Technology Landscape View

Return and visualize the relations in the MMOR where the source element is a Node and the (source and) target elements are members of the Technology domain, both Core as well as Derived relations are included, and the source and target elements are different (i.e. ignore self-referencing element relations).

MATCH path = (source:ElementProtoype_ArchiMate30_TheOpenGroup) 
            -[relation]->
             (target:ElementProtoype_ArchiMate30_TheOpenGroup)
WHERE source.DomainQualifiedLabel IN ["TechnologyDomain_ArchiMate30_TheOpenGroup"]
AND   target.DomainQualifiedLabel IN ["TechnologyDomain_ArchiMate30_TheOpenGroup"]
AND   type(relation) IN ["CoreRelation_ModelMate30_Parallelspace",
                         "DerivedRelation_ModelMate30_Parallelspace"]
AND   source.QualifiedName <> target.QualifiedName
AND   source.QualifiedName = "Node_ArchiMate30_TheOpenGroup"
RETURN path

NOTE: In the above Cypher Query Language (CQL) query, note the use of the following ModelMate Namespace Naming Standard used for:

Element prototype types on the source and target elements (e.g. ElementPrototype_ArchiMate30_TheOpenGroup, Node_ArchiMate30_TheOpenGroup)
Each element’s domain (e.g. TechnologyDomain_ArchiMate30_TheOpenGroup)
Categorizing relations (e.g. CoreRelation_ModelMate30_Parallelspace, DerivedRelation_ModelMate30_Parallelspace)

The general format used for the ModelMate Namespace Naming Standard is:

[typeclassname]_[typeclasscategory]_[typeclassoriginatingbody]

e.g. ApplicationComponent_ArchiMate30_TheOpenGroup

Figure 3. Sample Query A: Results (click to enlarge)

NOTE: The black arcs are Core relations; the red arcs are Derived relations. In the current version of the MMOR, there’s approximately an order of magnitude more Derived relations vs. Core relations.

NOTE: In Figure 3, note the use the ModelMate convention for naming relations based on a specific verb taxonomy that immeasurably improves the readability, a Stakeholders’ opportunities for further reflection and refinement, and the composability of higher-level Domain-Specific Languages (DSLs) for enterprise architecture based on using ArchiMate as a lower-level intermediate language:

Sample Query B: Core Relations, All Domains Landscape View

Return and visualize all of the Core relations in the MMOR.

MATCH path = (source) 
            -[relation:CoreRelation_ModelMate30_Parallelspace]-> 
             (target)
WHERE id(source) <> id(target) 
RETURN path

Figure 4. Sample Query B: Results (click to enlarge)

NOTE: It may look pretty but it’s not very useful from a functional perspective. To fix this, try grabbing the Passive Structure elements and dragging them to the left; the Active Structure elements, moving them to the right. The Behavior elements can be left in the middle. They will act as if they are connected to the Passive and Active Structure elements by elastics or springs. You can also manually position the Behavior elements similar to what you did with the Structure elements. Go ahead and try it for yourself.

There are several additional visualization tools in the market that work substantially better than the default browser app that ships with the Neo4j graph database. Check out this page: Graph Visualization for Neo4j. Linkurious is one of my favorite graph visualization apps.

Sample Query C: All Elements Prototypes, Statistical Matrix

Return and display a statistical matrix describing the element prototypes in the MMOR.

MATCH (source), (target)
WHERE id(source) <> id(target)
RETURN DISTINCT labels(source), count(*) AS Count,
avg(size(keys(source))) as AvgPropertyCount,
min(size(keys(source))) as MinPropertyCount,
max(size(keys(source))) as MaxPropertyCount,
avg(size((source)-[]->(target))) as AvgRelationsCount,
min(size((source)-[]->(target))) as MinRelationsCount,
max(size((source)-[]->(target))) as MaxRelationsCount

Figure 5. Sample Query C: Results (click to enlarge)

NOTE: The use of multiple Cypher Query Language (CQL) labels to support multiple-inheritance at the element prototype level. For example, using the first row of data in Figure 5:

the generic element prototype (i.e. Element_ArchiMate30_TheOpenGroup),
ArchiMate domain (layer) type (e.g. MotivationDomain_ArchiMate30_TheOpenGroup), and
ArchiMate aspect type (e.g. MeaningAndValueAspect_ArchiMate30_TheOpenGroup);
in addition to the element’s specific ArchiMate prototype (e.g. Value_ArchiMate30_TheOpenGroup).

Downloadable Files

You can also download file-based versions of the MMOR Master Datasets from GitHub in the following file formats:

CSV text file
Microsoft Excel workbook
Microsoft Access database
Neo4j Cypher Query Language (CQL) file.

In addition, there is a ZIP file containing all 4 file formats.

https://github.com/mwherman2000/ModelMate30_Parallelspace/tree/master/Parallelspace_ModelMate_MasterDataset_Complete10

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

*ArchiMate is a registered trademark of The Open Group.

2 Comments

Filed under ArchiMate, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, Master Data Management, Master Metadata Management, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, The Open Group

Tagged as ArchiMate, cypher, MMOR, ModelMate Master Online Repository, Neo4j

February 8, 2017 · 4:44 pm

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

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).

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).

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

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).

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.

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.

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)).

Figure 7. ArchiMate 3.0 Relationship Matrix Resolution Process

The numbered steps in Figure 7. are explained below:

Data 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.

“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).

CreatePrologList() 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).

CoreSet.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).

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:

SourceElement
TargetElement
Relation
RelativeStrength
IsInputRelation
StandardVersion
ScriptVersion

Outfile.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.

For 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).

Steps 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

In 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.

Step 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

Script 1. Merge Source and Target Element Prototypes

Step 10.2. 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):

All Business domain source and target element prototypes and all related Core and Derived relationships
All Core relationships where the source element prototype is from the Business domain
All Core relationships where the source and target element prototypes are from the Business domain
All Application domain source and target element prototypes and all related Core and Derived relationships
All Core relationships where the source and target element prototypes are from the Application domain
All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain
All Core relationships where the source and target element prototypes are from the Technology domain
All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other
All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
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)
All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype
All Core relationships where the source and target element prototypes belong to the Passive Structure aspect
All Core relationships where the source and target element prototypes belong to the Active Structure aspect
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.

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.

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.

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.

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.

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.

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.

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.

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).

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).

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.

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.

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.

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.

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.

1 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

Tagged as Archi, ArchiMate, Graphitization

January 17, 2017 · 11:44 am

Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1

While working on a new series of projects and articles on #graphitization I pondered the following 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.

Queryable being the keyword. This article describes the ArchiMate Graphitization Project.

Background

“The nice thing about standards is that you have so many to choose from.”
[Andrew S. Tanenbaum]

Today, there are at least 4 authoritative, semi-authoritative, or at least machine-readable, versions of the ArchiMate 3.0 relationship matrix:

The 4 “Appendix B Tables” in Appendix B of the ArchiMate 3.0 Specification
The “relationships.xml” file in the Archi [4.0] github repository (which also includes Issue #164 that is being used to track problems in the relationships.xml file as well as the Appendix B Tables)
Gerben Wierda‘s “ArchiMate 3.0 metamodel PDF“
ARKWRT, Colin Coate‘s “CLI (command-line interface) tool that provides a partial implementation of the ArchiMate 2.1 [and 3.0] Specification”

The first step in the ArchiMate Graphitization Project was to consolidate and make consistent these 4 data sources; or rather, attempt to consolidate and make them consistent. The Appendix B Tables are not very usable (i.e. not machine-readable in their current form) and hence, can only be used as a secondary, passive reference. These tables are also known to have some bugs which are expected to be fixed in the next release of the ArchiMate Specification.

The most reliable, most usable, and most complete data source is the Archi 4.0 project’s relationships.xml file; defining 11,000+ relationships. This file’s only drawback is that it includes all relationships – both Derived as well as the Core Subset – and does not have any tags or other markings to identify the Core relations; regardless, this file proved to be exceedingly valuable. The Appendix B Tables suffer from this same problem: no tagging to help identify the Core relationships.

Gerben Wierda’s ArchiMate 3.0 metamodel PDF is the best and internationally renown reference for the most commonly used ArchiMate relationships (what I think of as the ArciMate Core Subset). Gerben has done an excellent job of documenting these for ArchiMate 2.1, and now, ArchiMate 3.0. Using his PDF data, we were able to troubleshoot a number of missing as well as extra relationships across all 4 data sources [Thank you Gerben].

Colin Coate’s ARKWRT is also an excellent tool. I learned about Colin’s tool too late into my project cycle to use it; regardless, Colin has also been very helpful based on his deep knowledge of the ArchiMate specifications.

For this iteration of the ArchiMate Graphitization Project, I combined the relationship.xml data with Gerben’s PDF data. I was careful to tag each element and relation with its data source(s). The Appendix B Tables were used as a secondary reference for verification purposes.

Graphitizing the ArchiMate Relationship Table

I won’t go into detail about all the steps but I do want to emphasize that this was a very straightforward process once I had some good data – as in any Data Science project. The relationships.xml file is well formed and opened nicely in Excel 2016 (as well as earlier versions of Excel no doubt). It was simple to save it out as a CSV file (after some preformatting to create namespaces for the AchiMate element and relationship names). Here’s a sample that resembles what the final CSV file looked like before ingesting it into Neo4j graph database (click the figure below to enlarge it).

The relationship naming scheme is based on the ModelMate Verbs notation described in the article Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Relations as Verbs.

Ingesting the CSV file, creating the graph nodes, labeling them based on ArchiMate element type (i.e. ModelMate Verb), and finally, creating the relationships were also pretty easy to accomplish using the Cypher language. Here’s the actual query:

There were a couple of additional steps such as assigning weights (strengths) to each of the relationships based on the relationship type, tagging relations with a data source code, etc. that were part of the overall process.

Recreating a Rendering of Gerben’s PDF

The biggest challenge for the project was to see how easy it would be to recreate something that looked similar to Gerben’s ArchiMate 3.0 metamodel PDF. Here’s a copy of the actual Cypher query. It’s not optimized but only takes a few seconds to run.

The highlighted clauses encode the margin notes on page 1 of Gerben’s PDF. The unhighlighted clauses at the bottom (that refer to Strength) reduce the multiple relations-per-element-pair returned by the first half of the query to a single relation per distinct element-pair (based on the relative weight or strength of the relationships for each pair of elements).

The initial graph looked like this:

Because all of the elements are connected together with relations that act like springs, it took only a couple minutes to manually produce this layout (very similar to page 1 of Gerben’s PDF):

More importantly, I can now answer questions like:

Show me how Nodes are connected to Products 
using only Core Subset relationships
using 2 hops
in the ArchiMate 3.0 metamodel

Please post your feedback, questions, and comments below.

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

*ArchiMate is a registered trademark of The Open Group.

3 Comments

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Data Science, graph database, Graphitization, Master Metadata Management, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

Tagged as ArchiMate, Graphitization

January 13, 2017 · 3:12 pm

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

[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.

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.

3 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

Tagged as ArchiMate, Architecture Reference Models, Crossing EA Chasm, ModelMate, Relations, relationships, Verbs

November 17, 2016 · 7:43 pm

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 () 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.

1 Introduction

1.1 Objective

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

1.2 Overview

…

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

…

3 Language Structure

…

3.1 Language Design Considerations

…

Figure. 1 Top-Level Hierarchy of ArchiMate Concepts

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.

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:

Vocabulary of nouns
Vocabulary of verbs
Semantic definitions for the nouns and verbs
Grammar rules for governing the composition of nouns and verbs (grammatical structure)
Grouping and organizing constructs
Visual notation comprised of a set of graphical symbols for each noun and verb
Normative descriptions to guide the creation of visualizations based on the grammar rules and visual notation
Annotation of nouns and verbs with descriptive information (metadata)
Overall structure of a document or model
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:

Vocabulary of nouns (elements) – a vocabulary of words

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

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

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

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

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

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

Annotation of elements and relationships with descriptive information – metadata

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

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.

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.

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.

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

*ArchiMate is a registered trademark of The Open Group.

12 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

Tagged as customization, grammar, information architecture, semantics, visual notation, visualization, vocabulary

	[OLD] Web 7.0 DIDCom… on Web 7.0 DIDComm Agent Architec…
	Welcome to Web 7.0!… on Web 7.0 DIDComm Agent Architec…
	Web 7.0 DIDComm Agen… on Web 7.0 DIDComm Agent Architec…
	Web 7.0 DIDComm Agen… on [OLD] Web 7.0 DIDComm Agent Ar…
	Web 7.0 DIDComm Agen… on Welcome to Web 7.0! (over…

	[OLD] Web 7.0 DIDCom… on Web 7.0 DIDComm Agent Architec…
	Welcome to Web 7.0!… on Web 7.0 DIDComm Agent Architec…
	Web 7.0 DIDComm Agen… on Web 7.0 DIDComm Agent Architec…
	Web 7.0 DIDComm Agen… on [OLD] Web 7.0 DIDComm Agent Ar…
	Web 7.0 DIDComm Agen… on Welcome to Web 7.0! (over…

Category Archives: ModelMate Information Architecture for Languages

Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor

#Graphitization

What is #Graphitization?

References

#Graphitization Continuous Transformation Model

Standards

NEO Enhancement Proposal (NEP) Standards Author

Projects and Publications

0. SerentityData Graph

Abstract

Description

Resources

Recognition

Keywords

1. Large scale enterprise organizations (public and private sector)

References

2. Aircraft engines, muscle cars, and other high-performance engine systems

References

3. Commercial, global-scale, cloud services platforms

References

4. Automated service composition of cloud services-based data systems

References

5. Large collaborative ecosystems: employee groups, business partners, social networks

6. Large ecosystems of competing or competitive business organizations

7. Organization principles and belief systems

References

8. Conventional software applications and architectures: desktop, server, and web apps

References

9. International standards for visual modeling languages

ArchiMate References

10. Enterprise Data Management

References

11. Parallelspace ModelMate

References

12. Internet of Things (IoT)

References

13. Architecture Reference Models (ARMs)

References

General References

Share this:

Michael Herman: Award-winning Author, Invited Speaker, Illustrator, and Trainer

PARTIAL PORTFOLIO

Microsoft Live Communications Server

Microsoft SharePoint Products and Technologies

Microsoft Exchange Server

Metalogix Replicator for SharePoint

Microsoft “Alchemy”

Parallelspace Vulture

Tzunami K-Wise Deployer

Share this:

#Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository

Share this:

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

Share this:

Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1

Share this:

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

Share this:

Crossing the EA Chasm: Re-visioning the ArchiMate Specification

1 Introduction

1.1 Objective

1.2 Overview

3 Language Structure

3.1 Language Design Considerations

Share this:

Recent Posts

Categories

Meta

Archives

Recent Comments