Move beyond digitalization of the enterprise to graphitization of the enterprise. Here’s a great diagram that explains this concept. (click on the diagram to enlarge it)

Figure 1. The New Model of IT

Graphitization of not only all of your corporate information assets across all of your constituencies and stakeholders – at the data, application entity, and business object level – but also the graphitization of all of the interconnections between every business process, application system, infrastructure component, cloud service, vendor/service provider, and business role that uses, manages, or stores corporate information (Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2).

Use graphitization to make your existing corporate information more available, more usable, and more informative. Graphitization enables you to “Keep Calm and Have IT Your Way“.

What is #Graphitization?

#Graphitization is a data science and enterprise architecture-inspired 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.

Using #Graphitization

Use graphitization of your organization to help close both the Enterprise Architecture Chasm and the Operational Data Chasm. See below.

It is very interesting to read the above HBR article and then reflect on the current state of the ArchiMate language for Enterprise Architecture. Here are a few quotes from the article (as well as a few homework questions).

Best wishes for the New Year (modeled as a Principal, Driver, Goal, or Constraint? :-))

Here are 5 quotes from the HBR article:

“Perfecting and polishing a message matters less than how it’s reflected and refined by the intended audiences.”

Does ArchiMate support reflection and refinement in the minds of stakeholders? What needs to be changed/improved? What are the useful qualities needed for a language to support reflection and refinement in the minds of stakeholders (reflection and refinement by the stakeholders themselves)?

“One of the greatest obstacles in promoting more proactive, pro-user initiatives, she quickly discovered, was that her people were prisoners of their existing vocabulary. They interpreted her calls for customer obsessiveness by intensifying existing efforts rather than discussing or describing new ways to add new value.”

Is this also a description of ArchiMate’s current state? Are we stuck in a deepening “hole of hieroglyphics”? [link] Are we prisoners of ArchiMate’s existing vocabulary?

“Microsoft’s Satya Nadella, for example, has been linguistically maneuvering from a proprietary Windows/Office software legacy to cloud computing, platform, and open systems contexts. Machine learning, for example, is now as integral to Microsoft’s new value vocabulary…”

Is Machine Learning part of the ArchiMate vocabulary? …maybe …early stage at best. Does ArchiMate resemble an open technology environment for fostering innovation in enterprise architecture?

“Entrepreneurial founders, of course, have both semantic and rhetorical advantages over their successors in this regard. A company’s creator disproportionately owns and influences its vocabulary.”

This quote has 2 edges represented by each of these 2 sentences. Food for thought.

“Understanding the importance of being understood is what makes great CEOs great communicators.”

This also applies to CIOs and enterprise architects. How does ArchiMate help CIOs and enterprise architects become great communicators? …or does it hinder them? How can this situation be improved?

My apologies if you haven’t already read the preceding article. It was part of an initial draft of this article until I realized the topic of ArchiMate customization needed to stand on its own. It became the main course; leaving this article to be the dessert and, hence, much more enjoyable.

This article consists of alternate visualizations of the same underlying ModelMate enterprise architecture model and, for the most part, the same view. The only variables are the modeling scheme and zoom factor used to render each view:

Colored dots

ArchiMate iconography

Microsoft Enterprise Viso Stencil

Amazon Web Services (AWS) 2D iconography

Amazon Web Services (AWS) 3D iconography

The first figure is an animation/slide show. It depicts a succession of views – each drawn with one of the above schemes.

Zoom factor is an interesting variable. In the first 2 frames of the above animation, the transition from the large scale view using the “dots” scheme to the smaller scale view using the ArchiMate scheme is one example of how different schemes can benefit from being used together in the same view. In this example, it’s the benefit of masking the detail in large scale views while allowing the detail to be unwrapped in small scale views. The benefit is more esthetically pleasing and understandable views for each range of zoom factors.

Figure 2 renders the view using the ArchiMate scheme, primarily. In addition, the colors of the dots denote the combination of schemes that are available in this ModelMate model. The top color of each dot denotes the ArchiMate element type and the bottom color denotes the element type based on a fine-grained Microsoft enterprise schema/taxonomy. For example, the highlighted component is a SQL Server Instance (denoted by the dark gray color in the top half of the dot). The yellow-green color (aided by the icon) identify the component as an ArchiMate infrastructure service. (Click on Figure 2 to enlarge it.)

Figure 3 is a similar view to Figure 2 but the Microsoft Enterprise Visio Stencil is used as the primary scheme. The pink color of the selected component denotes that it is an IP Subnet; the dark purple, an ArchiMate Network element. (Click on Figure 3 to enlarge it.)

More nirvana? Being able to see multiple schemes, side-by-side and interconnected at the same time rendered in a single view (e.g. ArchiMate for on-premise, AWS and/or Azure schemes used for the cloud, MS SharePoint stencil for the SharePoint information architecture, etc.). “More news at 11…”.

The Aperitif

Lastly and simply for your humor, I offer the following cartoon as the aperitif.

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)

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)

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.

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

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.

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.

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.

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

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.

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.

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

Inspired by Gerben Wierda’s thoughtful discussion about how the full framework is depicted in the new ArchiMate* 3.0 specification (An AchiMate 3 Map (Layers? What Layers! — 1)), I’m going to suggest there’s another level of improvement that can be made to the specification’s “peanut butter and jelly sandwich” diagram. [Please excuse the visual metaphor but that’s what it looks like – with PB&J leaking out on all sides.]

Figure 1. ArchiMate 3 Layers and Aspects

In his posting, Gerben suggests a succession of improvements (depicted below).

This slideshow requires JavaScript.

Figure 2. Gerben Wierda’s Suggested Improvements

But they still left my question unanswered: Why were Strategy, Motivation, Implementation & Migration left as disconnected layers on opposite sides of the enterprise architecture map? [I don’t accept Motivation being classed as an Aspect but that’s a topic for another article.]

What happened to the architectural principles of simplicity and elegance?

Aren’t the following series of enterprise architecture maps more informative and more understandable? …more pragmatically useful? I refer to the version below as the Progressive Enterprise Architecture Map.