Category Archives: Crossing the EA Charm

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.

13 Comments

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

Crossing the Chasm: Progressive​ Enterprise Architecture Model (PEAM)

[Updated October 5, 2016]

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

image004

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.

Progressive EA Model 1-0-2-Base-Slide

Progressive EA Model 1-0-2-Layers-Slide

Progressive EA Model 1-0-2-Aspects-Slide

Progressive EA Model 1-0-2-Both-Slide

Figure 3. Progressive Enterprise Architecture Model: Progressive Enterprise Architecture Map

Check them out for yourself and please add your feedback in the Comments section below. Click on any diagram to see a larger version.

Best regards,
Michael Herman (Toronto)

p.s. If the arrows make the enterprise architecture map too prescriptive from a pure ArchiMate specification perspective, what do you think of this version?

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

p.p.s. In October 2016, in the article Crossing the Enterprise Architecture Chasm, I extended PEAMs to include:

  • Continuous Transformations
  • Strategy Chasm
  • Enterprise Architecture Chasm

Here’s an example (click to enlarge):

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

*ArchiMate is a registered trademark of The Open Group.

6 Comments

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

What’s the difference between improving the design and operation of an aircraft engine vs. an enterprise?

Answer: Nothing

Continuous Transformation 2

Continuous Transformation 1.png

Continuous Transformation is a key principle of the Progressive Enterprise Architecture Model (PEAM); part of the practice of Total Enterprise Architecture Management (TEAM).

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

mwherman@parallelspace.net

1 Comment

Filed under Architecture Reference Models, Business Value, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, Progressive Enterprise Architecture Map (PEAM), The Open Group

How We Think About How We Work

Copyright (c) 2016-2025 Michael Herman (Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
https://creativecommons.org/licenses/by-sa/4.0/legalcode

How do we think about how we work? We rely on a few simple processes. Here is a list:

  • Progressive Improvement & Learning Process (PILP)
  • Continuous Transformation Process (CTP)
  • Deliverable Review: Initiate, Create, Review, Validate & Approve Process (ICRVA Process – “I crave a” Process)
  • Purpose: Awareness, Knowledge, Understanding, and Wisdom

Many thanks go to Alison Williams for helping me to clarify the Continuous Transformation Process (CTP).

Progressive Improvement through Continuous Transformation (and Learning)

Progressive Improvement thru Continuous Transformation 1-0-1

Progressive Improvement & Learning Process (PILP)

Progressive Improvement A 1-0-1

Progressive Improvement B 1-0-1

Continuous Transformation Process (CTP)

Parallelspace Continuous Transformation 2-0-1

Deliverable Review

Initiate, Create, Review, Validate & Approve (ICRVA) Process (“I crave a” Process)

Parallelspace ICRVA v12-0-2

Parallelspace ICRVA v12-0-2 Complete

The roles in the ICRVA process are based on the RACI matrix of responsibilities.

Content Purpose

– when writing a whitepaper or creating a new presentation. What is the aim of your deliverable?

  1. Awareness (An Overview of what is being described (Information))
  2. Knowledge (The “What” of what is being described)
  3. Understanding (The “How” of what is being described)
  4. Expertise (Deep, reliably demonstrated ability to understand, perform, and make sound judgments in a specific domain based on knowledge, skill, and experience)
  5. Wisdom (Broader judgment that applies experience, reflection, and values to choose what should be done, not just what can be done)

By wisdom a house is built, and by understanding it is established; by knowledge the rooms are filled with all precious and pleasant riches. A wise man is full of strength, and a man of knowledge enhances his might, for by wise guidance you can wage your war, and in abundance of counselors there is victory. Wisdom is too high for a fool; in the gate he does not open his mouth. (Proverbs 24:3-7)

Intended Audience Statement (Example)

The intended audience for this tutorial about Structured Credentials is a broad range of professionals interested in furthering the application of Verifiable Credentials technology for use in software apps, agents, and services. The primary audience includes software architects, application developers, and user experience (UX) specialists; as well as people involved in a broad range of standards efforts related to decentralized identity, verifiable credentials, and secure storage.

Michael Herman’s Hierarchies

  • Awareness – Knowledge – Understanding – Expertise – Wisdom
  • Dream – Desire – Want – Need
  • Sensing – Learning – Training – Experiencing
  • Keywords – (Controlled) Vocabulary – Glossary – Dictionary – Taxonomy – Ontology

Michaels Hierarchies

Product Management: 3 Prioritization Levels

  1. Need to have
  2. Nice to have
  3. *Neat* to have

Scalability Levels

hyper-scalability-1-0-1

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

5 Comments

Filed under Architecture Reference Models, continuous transformation, Crossing the EA Charm, Definitions, How do we think, Parallelspace TDM, Process, Progressive Enterprise Architecture Map (PEAM)

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

[Updated March 3, 2017]

PLEASE POST A COMMENT ABOUT WHY THIS PAGE IS IMPORTANT TO YOU.
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]

Notes

  • 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/):

image1

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.

ms-azure-stack-2017-image1

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)
mwherman@parallelspace.net

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

7 Comments

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

External IoT vs. Internal IoT: Beware of the Hype Cycle

Subtitle: Fusing Enterprise IoT and Traditional Enterprise Architecture

Context

External IoT – External world of devices, events, connections, storage, and analysis; the “traditional” Internet of Things; the world of devices outside the enterprise.

Internal IoT – Internal world within the enterprise consisting of business processes, business objects, actors and roles; application components, application services, application functionality, and data objects; and lastly, infrastructure consisting of servers, networks, data stores, foundation services, and foundational functionality. The “hum” within an Enterprise.

Enterprise IoT – The confluence or integration of External IoT and Internal IoT landscapes centered around a particular enterprise organization. Often represented and accessed as an enterprise graph.

Ecosystem IoT – The confluence or integration of 2 or more separate Enterprise IoT landscapes (complete or partial) centered around a specific ecosystem or community. Supporting Federated Enterprise Architecture.

Discussion

Do some of these latter terms sound familiar?  If so, you likely have some exposure, background, and experience with the practice of Enterprise Architecture Management (EAM).  Having lived on both sides of the IoT divide for more than a decade, it’s interesting to watch how the current rage around IoT is almost exclusively focused on External IoT and it’s coupling to Business Intelligence and Analysis.

What about what’s happening inside the business, information, application and infrastructure architecture of our own enterprises? …regardless of whether the “things” are internal to your organization, external to your organization, or, possibly, part of someone else’s organization (e.g. owned by a client, customer, partner, …), it’s all part of the Enterprise IoT landscape.

A good name for the combination of External IoT and Internal IoT is the “Enterprise of Things” …but another organization is already using this term.

Ultimately, this is all about the Internet of Things merged and being combined with Enterprise Architecture Management: Enterprise IoT.

“More news at 11…”

Michael Herman (Toronto)

4 Comments

Filed under Crossing the EA Charm, Definitions, Enterprise Architecture, Graphitization, IoT, Progressive Enterprise Architecture Map (PEAM)