Tag Archives: ArchiMate

Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2

[Updated November 6, 2016: Added Database/Web Services Farm Example #2]

In the previous article Crossing the EA Chasm: Automating Enterprise Architecture Modeling, I included a simple example of how a current state enterprise architecture model can be created and maintained automatically.

The same ModelMate enterprise architecture model has now been extended to include a total of 832,789 ArchiMate entities connected by 828,859 relationships (with several million property values) and was created automatically from scratch in about 15 minutes.

Database/Web Services Farm Example #1 (Single Subnet)

Below is a simple example of an automatically generated view depicting the database services and web services configured on the 38 servers connected to a particular IP subnet.  There’s a total of 355 nodes in this accurate and up-to-date current state view. (Click the image to enlarge it)


Figure 1. Database/Web Services Farm Example #1 (Single Subnet)

Pretty cool. The green dots are database services (SQL Server instances to be exact – almost every possibly product edition can be found in this subnet: SQL Server Express, Developer, Enterprise, Datacenter, etc.) modeled as Infrastructure Services; the blue dots, servers (Windows physical and virtual servers) modeled as Infrastructure Nodes; and, the purple dots, web servers (IIS virtual directory applications to be exact) modeled as Infrastructure Functions.

The small orange dots represent the network adapter configurations of the network adapters configured into each server.  The most central dot is the IP gateway (network router) for this subnet.

Database/Web Services Farm Example #2 (All Subnets/All Farms)

Parallelspace ModelMate-Web-Database Server Farms2.png

Figure 2. Database/Web Services Farm Example #2 (All Subnets/All Farms)

The red dots are IP subnets (32 in this ModelMate view) connecting 208 server Nodes that host either a SQL Server Instance (376 Infrastructure Service elements) and/or an IIS Virtual Directory Application (1597 Infrastructure Function elements).  The small orange dots are network adapter configurations. (Click the image to enlarge it)

Microsoft Exchange Server Farm Example

Here’s one more example of an auto-generated view from the same ModelMate model: a Microsoft Exchange email, collaboration, and unified communications services farm. In this view, the blue dots are the Windows Services running on each of these 3 Windows Servers in this view (out of a total of 5 servers in the complete farm). The orange dot highlighted in gray near the top of the server on the right side, for example, is an IIS virtual directory application that is hosting an Outlook Web Access (OWA) web service. (Click the image to enlarge it)

Parallelspace ModelMate-Exchange Server Farm.png

Figure 3. Microsoft Exchange Server Farm Example

The larger red entity contains all of the descriptive information (metadata) for each server’s processor; the smaller red dot, the memory configuration for the server.

The Neo4j  graph database from Neo Technologies was used as a key component of the ModelMate platform. A special ModelMate tool was created for automatically uploading any SQL Server database into a graph database (including all tables, columns, primary keys, primary key constraints, composite keys, foreign keys, foreign key relationships, implied entity relationships, NULL value processing, DateTime data type handling, etc.).

Have a great weekend,

Michael Herman (Toronto)

Parallelspace Corporation


*ArchiMate is a registered trademark of The Open Group.


Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Data Science, Enterprise Architecture, ModelMate

ModelMate Architecture Reference Model

[Updated October 28, 2016]

This article describes the architecture reference model for deploying a comprehensive, integrated enterprise architecture modeling and data science platform based on ModelMate.

The audience for this article is IT professionals including enterprise architects, solution architects, and security architects who want increased visibility into the deployment of their custom applications, entire data center environments, business process definitions, and LOB applications such as SAP, Oracle Financials, Salesforce, Microsoft SharePoint, and Microsoft Dynamics CRM.

A primary use case is organizations with a requirement to move one or more on-premise applications or capabilities to the cloud or need a better understanding of how their hybrid on-premise/cloud environments (e.g. Salesforce cloud applications and on-premise or third-party customer loyalty solutions).


Quoting from Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture, “ModelMate is a working implementation of a Microsoft SQL Server and Neo4j graph database-based repository for managing arbitrarily large collections of arbitrary entities, properties, relationships, views, etc.to enable analysis, visualization, and understanding using easily-available open source and COTS (commercial off the shelf) business intelligence (BI), data visualization, and machine learning (ML) platforms, tools and cloud services.”

The primary goal of ModelMate is to provide automated support for the Continuous Transformation Framework of the Progressive Enterprise Architecture Model (PEAM) depicted in Figure 1.


Figure 1. Progressive Enterprise Architecture Model

Continuous Transformation Framework

The Continuous Transformation Framework is a Deming Cycle based on the following 4 phases:

  1. Listening & Learning
  2. Knowledge > New Designs
  3. Plan & Act
  4. Transformative Change > New Outcomes

The Framework is depicted as a continuous cycle as shown in Figure 1 above. The Framework can also be flattened and presented as a (repeating) sequence of 4 processes (Figure 2).


Figure 2. Continuous Transformation Framework

Why all of this discussion about PEAM and the Continuous Transformation Framework? It is because to be able to understand and value the ModelMate Architecture Reference Model, it’s important to understand the class of problems it is trying to solve. Automated support for Continuous Transformation is the pain; ModelMate is the pain killer.

ModelMate Architecture Reference Model

There are 3 high-level layers in the ModelMate Architecture Reference Model:

  • Apps that use the ModelMate repository
  • Continuous Transformation Framework
  • ModelMate Open Hybrid Repository (MOHR)

These 3 layers (and 4 categories of apps) are illustrated in Figure 3.  Each app category corresponds to one phase in the Continuous Transformation Framework.


Figure 3. ModelMate Architecture Reference Model: 3 Layers

The choice of apps that your organization selects for each category depends on the medium-term and long-term drivers and goals for your enterprise architecture program. The app groups map to specific phases of the Framework:

  1. Listen & Learn phase
    • Ingestion
  2. Knowledge > New Designs phase
    • Pure Modeling and Layout apps
    • Modeling, Layout & Visualization apps
    • Data Science apps
    • Custom Mobile and Web apps
  3. Plan & Act phase
    • Program & Project Management apps
  4. Transformative Change > New Outcomes phase
    • Operations and Change Management apps

Figure 4 lists a sample or representative list of applications that can fulfill the needs of each app category (each phase of the Continuous Transformation Framework).


Figure 4. ModelMate Architecture Reference Model: Apps


Ingestion apps are responsible for scanning the enterprise’s operational environment: systems, assets, and processes. Information captured about each entity includes its structure, metadata, performance and usage data.  Operational business data is usually not needed and not captured.

Sources of data include business process logs, configuration management databases, LOB application configurations (SAP, SharePoint, Salesforce, Microsoft Dynamics CRM, Oracle Financials, etc.), operations management systems (Azure OMS, Microsoft System Center, etc.), Microsoft MAP Toolkit, performance monitoring logs, usage and audit logs, etc.

These are inbound data sources used to automatically update and maintain the EA models stored in ModelMate. Ingestion apps are the primary data sources for the Listen & Learn phase of the Continuous Transformation Framework.

Pure Modeling and Layout Apps

There are several types of apps that comprise the Knowledge > New Designs phase of the Framework.  Pure Modeling and Layout Apps are applications that support the manual modeling of entities, relationships, and metadata as well as the manual layout of stakeholder specific views.

The apps in the group do not support any built-in analysis and visualization capabilities beyond manually-created basic views. In addition, pure modeling and layout apps do not include an end-user scripting capability for performing automated, user-defined custom analysis or visualization.

Archi is an example of a pure modeling and layout app.

Modeling, Layout & Visualization Apps

These types of apps support manual modeling of entities, relationships and metadata and the manual layout of stakeholder specific views but also include basic, advanced, and/or custom analysis and visualization capabilities.

BiZZdesign Enterprise Studio and other advanced EA modelers are examples of apps that belong to the Modeling, Layout & Visual Apps group – supporting the needs of the Knowledge > New Designs phase of the Framework.

Data Science Apps

Data Science Apps include non-traditional “enterprise architecture” modeling and analysis apps. This group includes both open sources as well as COTS (commercial off the shelf) data science tools and platforms. Data Science apps provide advanced analysis, machine learning and visualization capabilities enabled through open access to enterprise architecture data via standard protocols and APIs (e.g.ArchiMate Exchange File Format, OData, SQL Server stored procedures, entity models, and advanced query and analysis languages such as R, Cypher, and T-SQL).

Examples of Data Science apps include: R Studio, Microsoft Power BI, Tableau, Domo, Linkurious, Microsoft Excel and the Neo4j graph browser.

Custom Mobile and Web Apps

This is the last group of apps that support the Knowledge > New Designs phase of the Framework and includes both no-code and code platforms for creating custom reporting, analysis, visualization apps.

No-code custom apps designed with Microsoft PowerApps (and Microsoft PowerFlow) are examples of the former; traditional C#/VB.Net, Java, and Node.js/JavaScript apps are examples of the latter.

Program & Project Management Apps

Program & Project Management Apps support the Plan & Act phase of the Framework.

Traditional portfolio, program, and project managements apps are examples of applications in this group. Collaboration tools such as Microsoft SharePoint, Confluence, and Jira can also belong in this group. Collaboration tools can also be considered as “horizontal” solutions that can be used across all phases of the Framework.

Operations and Change Management Apps

All of the effort to create and manage a functioning enterprise architecture solution only realizes direct business value when it leads to Transformative Changes being made in the enterprise’s strategies, systems, assets, and processes; and measurable, positive New Outcomes result from the changes.

Examples of apps in this category include change management applications that support IT Service Management (ITSM) disciplines such as ITIL. ServiceNow is an example of an ITSM app.

Please provide your feedback in the Comments section below or feel free to email me directly.

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

*ArchiMate is a registered trademark of The Open Group.

All other trademarks, servicemarks, registered trademarks, and registered servicemarks are the property of their respective owners.


Filed under ArchiMate, Automated Application Architecture Analysis, Automated Enterprise Architecture Modeling, Business Value, continuous transformation, Crossing the EA Charm, Data Science, ModelMate, Power BI, Progressive Enterprise Architecture Map (PEAM), Salesforce, SharePoint

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


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.


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


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


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


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


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


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.


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.


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.


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 Enterprise Architecture Chasm


Enterprise Architecture Chasm

What is the Enterprise Architecture Chasm?  First, a quick Google search didn’t find any previous references to the term Enterprise Architecture Chasm, at least not in the context I’m using it.  So what am I talking about?  We need to recognize the difference, the practical gap, that will always exist between EA models, plans, and other artifacts and an enterprise’s actual strategies, systems, assets, and processes. There will always be a gap because of several factors:

  • Time to design
  • Time to plan
  • Time to act
  • Time to operate
  • Time to measure new outcomes

and, lastly, the completeness and faithfulness of transformative changes that are actually implemented relative what’s documented in the enterprise architecture.  Here’s a picture highlighting this gap, the Enterprise Architecture Chasm.


Figure 1. Total Enterprise Architecture Model (TEAM): Enterprise Architecture Chasm

This iterative 4-step management cycle is called the Continuous Transformation Framework. At a given time, there isn’t just 1 Continuous Transformation cycle at work in an organization but there can be several, even hundreds, dependent on the size and complexity of your enterprise.

Homework Question: Which dimensions or metrics can be used to characterize or benchmark the size of the Enterprise Chasm in an organization?

Strategy Chasm

Is the EA Chasm the only chasm?  No.  In most organizations, there is most likely a Strategy Chasm as well – the gap between the organization’s motivations and strategies and what is represented and planned for in the enterprise architecture.  Same set of issues.  They just occur earlier in the process.  Here’s an example of the Strategy Chasm. (Click to enlarge this diagram.)


Figure 2. Team Enterprise Architecture Model (TEAM): Strategy Chasm and Enterprise Architecture Chasm

In the Fall of 2016, two webinars were presented that looked how to extend traditional enterprise architecture methods (e.g. TOGAF) to be more complete/fill in some gaps.  The first talk, 7 Reasons Why IT4IT™ is Good for Architects presented by Dan Warfield and Sven van Dijk, looked to The Open Group’s IT4IT for answers on how to cross the enterprise architecture chasm. The second talk, BIZBOK® Guide and TOGAF® Standard: Business Architecture Value Proposition presented by Chris Armstrong  and Wally McLaughlin, looked at a related set of problems from a Business Architecture and BIZBOK perspective.

To what extent are your EA methods, repositories, and tools helping your organization cross the Strategy Chasm and the EA Chasm?

Will IT4IT and BIZBOK and other methods (e.g. ITIL) help cross or close the gap?

“Time will tell…”

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

p.s. These diagrams on based on the Progressive Enterprise Architecture Model described here.


Filed under ArchiMate, Architecture Reference Models, continuous transformation, Crossing the EA Charm, Digital Transformation, Enterprise Architecture, Enterprise Architecture Chasm, IoT, ModelMate

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?


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

Parallelspace PowerPoint Template for ArchiMate 2.1

[Scroll down to see an experimental version of the PowerPoint template for modeling Conceptual, Logical and Physical architectures using ArchiMate symbols.]

Standard PowerPoint Template

Click here to open or download a copy of my Parallelspace PowerPoint Template for ArchiMate 2.1 version 1.1 (file version 1-0-12).  For Microsoft Office, there are Visio templates for ArchiMate but I’m not aware of there being any PowerPoint templates. See below for an example.

Please post your feedback in the comments …good or otherwise.  Please let me know what you think and, more importantly, how are these helping you and what you would like to see next?


This slideshow requires JavaScript.

Here’s a simple PPT use case/example:

Parallelspace ArchiMate Concepts 1-0-12-Example

Experimental PowerPoint Template (Conceptual, Logical and Physical Architecture Modeling)

Click here to open or download a copy of an experimental version of my Parallelspace PowerPoint Template for ArchiMate 2.1 version 2.0 (file version 1-0-14) containing experimental conceptual, logical and physical renderings of the ArchiMate Business Architecture, Application Architecture and Physical Architecture concepts.

This slideshow requires JavaScript.

Best regards,
Michael Herman (Toronto)

*ArchiMate is a registered trademark of The Open Group.

1 Comment

Filed under ArchiMate, Enterprise Architecture, The Open Group

Microsoft Azure Stack POC Architecture Reference Model (ARM): ArchiMate Model – version 1-0-7 – April 30, 2016

[Updated March 3, 2017]

This particular page is 1 of my top 5 most viewed pages (ever) and I’d like to understand why. Thank you!

MS Azure Stack POC 1-0-7

Figure 1. Parallelspace Logical/Physical Architecture View: Microsoft Azure Stack POC (April 2016)

[Click here for a larger version of the ArchiMate model]


  • The actual drive letters will vary from system to system. Don’t fret these details.
  • I’ll keep adding more detail to the model as I work through the full deployment of the Microsoft Azure Stack POC.

The above ArchiMate enterprise architecture model was created with Archi 3.2 – The Free ArchiMate Modeling Tool.  Download the latest version of Archi from here.

Here’s what the original Microsoft drawing (a Visio sketch – not a model) looks like in April 2016 (from https://azure.microsoft.com/en-us/documentation/articles/azure-stack-architecture/):


Figure 2. Microsoft Azure Conceptual Architecture View: Microsoft Azure Stack POC (April 2016)

[Click here for a larger version of the Microsoft drawing.]  It’s mostly useless but typical of what you’d expect in a Microsoft marketecture diagram.

Microsoft has subsequently updated their conceptual architecture diagram (March 1, 2017). It now looks like this (at the same URL noted above).  The new diagram is an improvement and I can’t help but imagine it was influenced by my ArchiMate model.


Figure 3. Microsoft Azure Architecture View: Microsoft Azure Stack POC (March 2017)

For a topic that in theory has a relatively narrow audience, this article has had an extraordinary number of views over the past year.

Best regards,
Michael Herman (Toronto)

p.s. I can only assume it is Microsofties trying to learn a little bit more about enterprise architecture.  You can see the (good) results in Figure 3 (above).


Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture, Graphitization, IoT, Microsoft Azure, Parallelspace TDM