Category Archives: Architecture Reference Models

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

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

[Updated: February 6, 2017]

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

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

modelmate-relationship-verbs-2017-02-06

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

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

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

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

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

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

Crossing the EA Chasm: Re-visioning the ArchiMate Specification

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

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

Motivation

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

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

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

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

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

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

Current ArchiMate 3.0 Specification

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

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

Annotated Excerpts from the ArchiMate® 3.0 Specification

Start of excerpts.

Introduction
1.1 Objective

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

1.2 Overview

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

Language Structure

3.1 Language Design Considerations

image002.png

Figure. 1 Top-Level Hierarchy of ArchiMate Concepts 0102030509

End of excerpts.

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

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

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

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

The approach used to describe ArchiMate can be improved.

An Alternative, Architectural Approach for Describing ArchiMate

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

ModelMate Information Architecture for Languages

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

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

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

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

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

Figure 2. ModelMate Information Architecture for Languages

The MIAL 8 domains have the following definitions:

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

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

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

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

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

ModelMate Information Architecture for ArchiMate

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

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

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

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

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

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

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

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

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

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

08 Annotation of elements and relationships with descriptive information – metadata

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

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

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

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

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

Figure 3. ModelMate Information Architecture for ArchiMate

Organization-Level Customization

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

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

Extend, Replace/Update, or Remove?

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

mial-for-archimate-1-0-1

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

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

  • Core
  • Non-Core

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

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

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

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

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

Appendix A – ModelMate Information Architecture for ArchiMate Legend

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

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

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

*ArchiMate is a registered trademark of The Open Group.

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

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)

parallelspace-modelmate-web-database-server-farm1

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

mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

3 Comments

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

Crossing the EA Chasm: Annotating Your EA Models with RACI Roles

In the LinkedIn ArchiMate posting Difference between business/application/technology process?, Anna Aaltonen asked:

“Does someone have good examples how elements Technology process and Application process differ? Maybe comparing also to element Business process. Basically, processes are the same, no matter how those are executed. Basically moving from higher level models to detailed models is just playing with hierarchy, not changing layer. I am looking for a practical example (preferably an example using all those) as well as some hints how to guide modelers (in practice), when they ask whether they should use this or that.”

One tip I use to help clarify these type of questions is to think about the constituencies served by each layer in a traditional enterprise architecture model and add the specific list of roles beside (to the right side of) each layer. Below is an example taken from the article ARMs for Metadata-Driven LOB apps: SharePoint 2013/SharePoint 2016.

parallelspace-arm-sharepoint-2013-2016-v1-0-12-roles4

Figure 1. Enterprise Architecture Layers: Constituencies

 

For each of the layers, the list of pertinent roles is listed.  I choose to further organize the roles based on  RACI categories (also check out this related article):

  • Responsible (Deliverables)
  • Accountable (Approvers)
  • Consulted (Contributors)
  • Informed

Linking back to Anna’s question, this approach helps to focus everything that exists in a particular layer relative its constituency. Business Processes serve the needs to the Business architecture layer constituency; Application Processes, the needs of the Application layer constituency layer; Technology Processes, the needs of the Technology layer constituency.

Application Processes include development, testing and maintenance. For Technology Processes, deployment, operations and upgrading are simple examples.

Best regards,

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

 

1 Comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture

Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1

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

Automating Enterprise Architecture Modeling

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

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

Figure 1. Progressive Enterprise Architecture Model: Continuous Transformation Framework

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

Parallelspace TEAM-DevicesA.png

Figure 2. Automatically Generated Technology Layer Model and View

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

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

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

Best regards,

Michael Herman (Toronto)

Parallelspace Corporation

mwherman@parallelspace.net

4 Comments

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

Crossing the EA Chasm: “Where does IoT [Internet of Things] fit in?”

In the article The EA Chasm: Open Repository Strategies for Enterprise Architecture, Vijay Sharma asked the question: “Where does IoT [Internet of Things] fit in?”. Vijay, you couldn’t have chosen a more perfect example or a better question.

The one-word answer is “everywhere” – no sarcasm intended.

The “1000 word” answer can be found in the following diagram based on the Progressive Enterprise Architect Map (PEAM) model (click to enlarge):

Progressive EA Model 1-0-7-PEAMS-Chasms-IoT.png

The first thing that strikes me about this diagram is: with the need to complete 15+ major, cross-functional, interdependent activities, it is completely understandable why major digital business initiatives fail or, otherwise, “wither and die on the vine” before they’re completed.  This applies to all digital business initiatives – not just IoT.

Second, what happens when an IoT (or any other enterprise) initiative starts off as a “skunkworks” project?  Placing the question in the context of the above diagram, what if IoT starts off on the far, far right (activities 12-15) as unplanned, uncoordinated activities by a group without any defined business drivers, linkage to the business strategy, or connection to the enterprise architecture?

Food for thought (and time for breakfast).

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

p.s. Why was activity 16 (IoT Platforms and Tools) placed inside the Enterprise Architecture Chasm?

It’s mostly unrelated to the above discussion but it hints at the idea that IoT approaches can also be used in a non-traditional way to Listen to signals in the  Enterprise Assets, Systems, and Processes (performance data, usage information, planned and unplanned changes in the operational processes and systems, etc.), and then use this data to annotate the Core Enterprise Architecture. BI techniques can be used to analyse and visualize the annotated EA model to create new Designs.  The coordination of the building and  deployment of the new Designs hopefully results in Transformative Changes being applied to the Enterprise’s Strategies, Systems, Assets, and Processes to produce additional, meaningful business value.

IoT Platforms and Tools are enablers for listening and responding to the “hum” of an organization’s systems, assets and processes, and, when fully realized, can also be used to distribute Transformative Changes in a software-defined enterprise.

To read more about using IoT to create, maintain and manage an enterprise architecture, check out External IoT vs. Internal IoT: Beware of the Hype Cycle.

1 Comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture, ModelMate, Progressive Enterprise Architecture Map (PEAM)

Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture

[Updated October 27, 2016]

In a recent posting (Crossing the Enterprise Architecture Chasm), I offered a definition for the term Enterprise Architecture Chasm, the practical gap that will always exist between enterprise architecture and an organization’s systems, strategies, assets, and processes (and the companion Strategy Chasm that exists between an organization’s motivation and strategy and its enterprise architecture).

progressive-ea-model-1-0-6-peam3-chasms

Figure 1. Progressive Enterprise Architecture Map

In this posting, I describe the “ModelMate” project – the creation of an open EA repository software solution that assists in crossing the EA Chasm. “ModelMate” is a codename for this project (also read the p.s. at the bottom of this posting). Caveat: This posting will be somewhat technical but regardless of who you  are, you’ll find the example use cases to be insightful.

Definition

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.

Architecture

The ModelMate schema is modeled more or less after The Open Group ArchiMate Model File Exchange File Format (EFF) with several extensions; including support for multi-tenancy, 2D and 3D entities, 3D views of 2D and 3D entities, processing history, versioning, annotations (including usage and performance data), automated heat maps, replication and synchronization. Read/write access to the repository is supported using an entity-based .NET API.  Importing and exporting of EFF files is fully supported. The physical repository is a highly normalized SQL Server database. Here is what the high-level ModelMate architecture looks like.

ModeMate-HL-Architecture.png

Figure 2. Use Case 1. Cloud migration of custom .NET desktop apps, services, and web applications

ModelMate can run anywhere: on your laptop, Windows server, virtual server, data center, or in the cloud; anywhere you can use SQL Server Express, SQL Server, or Azure SQL Server.

Use Case 1: Cloud migration of custom .NET desktop apps, services, and web applications

In this scenario, a .NET Entity Discovery component scans the compiled .NET executables (.EXE files) and library assemblies (.DLL files); calling the ModelMate API to create a model in the ModelMate repository.  A separate component uses the EFF Exporter capability to read the ModelMate model and create an EFF file containing the model data.  In this specific scenario, Archi was used to read the ModelMate model and support real-time exploration of the .NET application’s architecture. At this point in the project, views are being created manually but highly facilitated by the design of the model and Archi’s Visualizer and Navigation features.  Here’s a sample of a view created from the resulting ModelMate model as well as a screenshot of what the actual dual-screen user experience looks like.

This slideshow requires JavaScript.

Figure 3. VetContext ModelMate Model imported into Archi

The broader use case is system analysis and assessment to support migration of on-premise custom .NET desktop, service and web applications to the cloud.

The above model is large; containing:

  • 190,000 properties and values
  • 25,000 labels
  • 16,000 relationships
  • 8,700 elements

The EFF file is 52MB in size;. the resulting Archi .archimate file, 34MB in size.

Because ModelMate models are based on the EFF file format, any EFF compatible modeler such as BiZZdesign Enterprise Studio or SPARX Enterprise Architect can also be used.

This slideshow requires JavaScript.

Figure 4. VetContext ModelMate Model imported into SPARX Enterprise Architect

SPARX EA’s automated layout and routing capabilities proved to be quite valuable – especially when the burden of importing extremely large numbers of elements and relationships into any of these tools is reduced to a few mouse clicks.

Use Case 2: Support for COTS (commercial-off-the-shelf) Business Intelligence tools

Because the ModelMate Repository schema is based on the EFF format (with extensions) and is realized as a SQL Server database, it is easy to produce any myriad of visualizations and perform analysis using easily-available COTS and open source tools such as Microsoft Power BI interactive data visualization tools, and the R language for statistical computing. Detailed examples with be added to this article over the next few weeks.

modelmate-integrations

Figure 5. ModelMate Logical Architecture

Given the enormous user communities and large libraries of user-contributed data analysis, machine learning, and visualization components available for each of these platforms (as well as Power BI’s support for R), there are no limits to what you can do with a ModelMate model.

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

p.s. At this point, there are no specific plans to commercialize the ModelMate project but if you think ModelMate can help make what you’re trying to accomplish a bit easier to realize, please email me at mwherman@parallelspace.net.

* ArchiMate is a registered trademark of The Open Group

10 Comments

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Definitions, Enterprise Architecture, ModelMate

Crossing the Enterprise Architecture Chasm

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.

progressive-ea-model-1-0-9-peam3-ea-chasm-dots

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

progressive-ea-model-1-0-6-peam3-chasms

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.

12 Comments

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?

3 Comments

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

Progressive​ Enterprise Architecture Maps – Update 2

Pavel Harbe asked an interesting question with respect to the original version of the Progressive Enterprise Architecture Map: “Why … is Strategy first and then Motivation and not in opposite order (or in many iterations)?” and goes on to explain that, yes, in fact Motivation should precede Strategy (at least initially, and then followed by possibly several iterations).  Of course, Pavel is correct …but so is the diagram (see below). However, Pavel’s comments do indicate a need to clarify these points – here in text as well as in a new version of the Progressive Enterprise Architecture Map.

Progressive EA Model 1-0-3-NoArrows-Slide

*Original discussion: Progressive Enterprise Architecture Maps

To respond directly to Pavel’s question, the subtlety in the original diagram can be found in text beneath the caption of each layer (emphasis added for this explanation):

  • Strategy refers to the “Strategy of the *Enterprise*”, the organizational strategy.
  • Motivation refers to the “Intentions of the *Architecture*”, a phrase borrowed from Gerben Wierda’s original discussion (An ArchiMate 3 Map (Layers? What Layers!))

The original diagram referred to the strategy of the organization driving the motivations [intentions] for the companion enterprise architecture.

Given pragmatic usefulness is one of my goals for the Progressive Enterprise Architecture Map (while at the same time preserving architectural simplicity), the following elaboration is warranted: adding 2 more layers to clarify the levels at which Strategy and Motivation are used to drive continuous transformation of the organization and its enterprise architecture.  Here is version 2 of Progressive Enterprise Architecture Map.

Progressive EA Model 1-0-3-PEAM2-Slide

On the left side of the diagram, there is a distinct pair of Motivation and Strategy layers for enterprise-level strategy planning.  In addition, there is a distinct pair of these 2 layers which transform the enterprise-level drivers, goals, and strategies into drivers, goals, and strategies for the enterprise architecture. You can argue these should be the same but due to many reasons such as timing and resources, they are not always the same.

Progressive Enterprise Architecture Maps, Continuous Transformation, and Total Enterprise Architecture Managment

Given this elaboration, I decided to “take it all the way” and link Progressive Enterprise Architecture Maps to Continuous Transformation and Total Enterprise Architecture Managment – topics I’ve discussed and modeled in the article [Enterprise Architecture] Tools and Methods Don’t Create Business Value.  The model for Continuous Transformation and Total Enterprise Architecture Managment looks like the following:

Parallelspace-Business Value from Transformative Change4

Here’s version 3 of the Progressive Enterprise Architecture Map (linked to Continuous Transformation and Total Enterprise Architecture Management).

Progressive EA Model 1-0-3-PEAM3-Slide

Best regards,
Michael Herman (Toronto)

1 Comment

Filed under ArchiMate, Architecture Reference Models, Enterprise Architecture, Progressive Enterprise Architecture Map (PEAM)