Monthly Archives: January 2017

January 27, 2017 · 2:58 pm

Crossing the EA Chasm: ArchiMate 3.0, fix it or re-purpose it?

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

It is the end of January 2017 and, recently, there has been a lot of discussion in the LinkedIn ArchiMate group about the ArchiMate language for enterprise architecture (EA), its “idioms”, usability, adoption, etc.

In addition, in the article Crossing the EA Chasm: Reflections on the Current State of ArchiMate, I asked some questions related to ArchiMate’s purpose and whether it is adequately addressing all of enterprise architecture’s stakeholders’ needs. Crossing the EA Chasm: Re-visioning the ArchiMate Specification is a related article.

These discussions led to this short-form question, the key topic for today:

ArchiMate 3.0, fix it or re-purpose it?

Fixing ArchiMate

On the “fix it” side of the discussion, people will literally be working to fix the language forever. The Open Group is committed to supporting these kinds of efforts; it’s the foundation for why they exist.

But is there a better, compatible approach?  I think there is.

Re-purposing ArchiMate

As a starter, let’s look at the evolution of and technology hierarchy that supports high-level programming languages. Pick your favorite language. Many of you will choose Java; I’m a C# person. (It doesn’t really matter.)

Before the advent of managed, cross-platform execution environments (like the Java VM and the .NET Runtime that provide memory management and garbage collection, advanced exception management, data protection, secure execution contexts, etc.), prior languages like C and C++ followed a simple compilation model as illustrated in Figure 1.

cpp-compilation-model-1

Figure 1. C/C++ Compilation Model

This scenario is synonymous with the current lower-level language support available in ArchiMate 3.0. There’s effectively one language level and that’s all you have.

The C# (.NET) compilation model ups the ante by introducing a cross-platform intermediate language (Microsoft Intermediate Language (MSIL)) as shown in Figure 2.  Java achieves something similar using Java bytecode.

csharp-compilation-model1Figure 2. C# Compilation Model: Role of the Microsoft Intermediate Language (MSIL)

Re-purposing ArchiMate as a Lower-Level Intermediate EA Language

In an approach similar to the way the .NET  Framework uses MSIL, ArchiMate can be re-purposed as the lower-level intermediate language for creating higher-level EA languages.

The article Modeling a Company and Its Locations, Markets, Employees, Investors & Roles: Proposals, Wishes & Dreams is a small but real-life, practical example of how this can be executed to create a new EA language for describing Business Organizations (as illustrated below in Figure 3).

parallelspace_modelmate_trumpworld2

Figure 3. Business Organization EA Language, an ArchiMate 3.0 Specialization

This approach more easily and more formally supports the concept of domain-specific languages (DSLs) for enterprise architecture.

As The Open Group moves ArchiMate forward, the published higher-level EA languages can incrementally adopt the new changes – in the same way the Java JIT compilers and Microsoft JIT compilers are updated to adopt new instruction sets from Intel or AMD.

Making It Real

The Archi modeling tool can easily be adapted to serve as the reference implementation for these new EA languages. This is relatively easy to accomplish because all of the ArchiMate relationships remain the same; and, at least initially, it’s simply a matter of extending Archi’s existing ArchiMate elements with families of new elements that address the scope of each new EA DSL.  It is a SMOP.

More food for thought… Please post your comments below.

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

*ArchiMate is a registered trademark of The Open Group.

4 Comments

Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Domain Specification Languages (DSL), Enterprise Architecture, Enterprise Architecture Chasm, The Open Group

Tagged as , , , , ,

January 25, 2017 · 4:39 pm

Modeling a Company and Its Locations, Markets, Employees, Investors & Roles: Proposals, Wishes & Dreams

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

This article presents some new approaches for modeling answers to the following frequently asked question:

How do I model X in ArchiMate?

NOTE: You are encouraged to try to model these examples for yourself: to start learning how to “think in ArchiMate” as your second or third written language. Archi is a great free tool for learning the ArchiMate language. You can download the Archi .archimate file containing the model used for this article from here. You can download the latest version of the Archi 4.0 modeling tool from here (which includes full support for the ArchiMate 3.0 language).

ArchiMate 3.0 is used as the baseline enterprise architecture modeling language for this discussion; especially the new Grouping element.

The Proposals

There are 2 new proposals described in this article: one more generic and one more specific.

  1. Proposal 1: A new (general) approach for visually presenting answers to the question “How do I model X in ArchiMate?” using a metamodel-level reference model modeling strategy
  2. Proposal 2: A specific approach (reference model) for modeling a Company and its Locations, Markets, Employees, Investors, etc. and their Roles.

The second proposal is an example or use case for the former.

Proposal 1: Modeling of Best Practice Modeling Patterns

Proposal 1 is illustrated in Figure 1 and Figure 2. These figures illustrate a general approach for modeling and visually presenting answers to the question “How do I model X in ArchiMate?”.

Rather than provide simple, less-informative, textual answers such as “use Business Collaborations to model Companies” or in ArchiMate 3.0, “use Groupings to model Companies”, why not:

  • Leverage Specialization relationships to model, name, and visually illustrate, in these examples, alternative representations of a Company element
  • From a presentation perspective, place the new best practices modeling pattern on the left – side-by-side – with the portion of the applicable elements of the base-level ArchiMate metamodel on the right

as illustrated in Figure 1 and Figure 2.

NOTE: Proposal 1 is illustrated with 2 examples. The merits of the individual examples are discussed below in Proposal 2. The comparison of these 2 examples is not part of Proposal 1.

parallelspace_modelmate_trumpworld1

Figure 1. Metamodel-level Reference Model for a Company using Business Collaboration

parallelspace_modelmate_trumpworld2

Figure 2. Metamodel-level Reference Model for a Company using Grouping

Proposal 2: Specific approach (reference model) for modeling a Company

Proposal 2 asks the question: Of the 2 options presented above (or any additional alternative options), which option represents a best practice reference model for modeling a Company and its Locations, Markets, Employees, Investors, etc. and their Roles.

The only tangible difference between the modeling strategy in Figure 1 vs. Figure 2 is:

  • Figure 1 derives Business Organization from Business Collaboration
  • Figure 2 derives Business Organization from Grouping (a new element introduced in ArchiMate 3.0)

These choices, in turn, have a secondary effect in terms of the valid set of relationships that can be used to compose or aggregate the elements that comprise a Business Organization.

To aid your consideration, Figure 3 provides a more concrete example using the second option: using Groupings to represent Companies (my current preferred solution).

NOTE: The goal of these models is to model the active structure of a Business Organization which excludes concepts like Business Processes and Business Services.

parallelspace_modelmate_bridgewater1

Figure 3. Proposal 2 Example: Bridgewater Associates

What do you think?

Please add your comments, thoughts, and questions below.

Best regards,

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

*ArchiMate is a registered trademark of The Open Group.

8 Comments

Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Definitions, Enterprise Architecture, Enterprise Architecture Chasm, Graphitization, ModelMate Information Architecture for ArchiMate

Tagged as , , , , ,

January 22, 2017 · 11:55 am

RE: Managing Master Data With ArchiMate

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

In the Linkedin ArchiMate group, Gunther BONNARD recently asked the following question (January 20, 2017 Inauguration Day):

Managing Master Data With ArchiMate

I am looking for an easy way to manage Master Data (Business Objects) with ArchiMate. I was wondering which association to use to link MD with the business capabilities in charge (“accountable”) of the MD and the same problem to link data object that realize the MD with the application (that create the MD). …any ideas?

…with the following additional clarifications:

How can I model that a business object “belongs” to a capability or a data object is under the responsibility of an application component? I have this issue because I need to manage what is the “master” of the data (without using functions) …

For example, I would like to model that:
– the business object Client belong to the business capabilities CRM
– the application SalesForce is the master of the data object Client …

What follows is more of an approach than a definitive answer.  Please add your feedback, questions, and comments at the bottom of this article.

  • Start by exploring the context of the question …a simple business analysis task. What is the scope of what Gunther is talking about? …key concepts or objects, important relationships, etc.
  • Ask clarifying questions.
  • Start sketching the context in ArchiMate. “Learn to think in the ArchiMate language” …like learning to think in a second or third language.  (Archi makes this easy to do or use a commercial modeling tool.)
  • Go beyond the boundaries of the immediate problem to help ensure you understand the broader context.  It will make your eventual answer more correct and increase its longevity and utility.
    • Are you answering the right question?
    • Think of physical or real-life examples.  Then create higher-level abstractions.
  • Your sketch doesn’t have to be perfect or “correct”. It needs to be what you need it to be to help you think about and answer your question.
  • It is the “thought process” that is forced to take place while you are creating your sketch that is the most important activity of the overall process (like whenever you’re forced to write something down on paper or on your device).

Here’s the ArchiMate 2.1 sketch I came up with:

modelmate-master-data-management-parallelspace4

Figure 1. Master Data Management: Ownership and Responsibilities (Sketch 1)

Don’t work on your sketch for “days”; at most an hour or a couple hours.  That’s why it’s called a sketch.

My Thought Process

These are the questions and notes that came to mind while I worked on the above sketch:

  • Need to maintain clarity between the concepts of Master Data and Master Data Definitions (aka Master Data Management and Master Metadata Management, respectively). Gunther is asking about Master Data in his posting – not Master Data Definitions (even though they are closely related).  I should have asked a clarifying question about this to get confirmation.
  • Typically, Salesforce applications are not traditional applications built by traditional application and technology roles BUT for this example, we’ll assume they are.
  • Salesforce applications are not Software Components. They are configuration artifacts stored in and processed by the Salesforce platform to realize Application Functions (and Application Services) and custom Data Objects.
  • Salesforce has a strong underlying concept of Master Metadata Management (even if they don’t use this term). It’s the core of the platform (IMHO).
  • Customer is one class of Master Data data.  “Customer 123” is a Master Data data instance.  Create this sketch using classes of Master Data data – not instances (unless you’re creating a secondary view to show an example of Customer Master Data data instance).
  • Business Roles are associated with Business Capabilities
    • which in turn aggregate Business Processes
    • that access Business Objects
    • “ArchiMate 101”
  • Revisit the question while you’re creating the sketch: Should Business Capabilities own Master Data?  My answer to this question was: No. I think Business Capabilities can be associated with classes of Master Data.
    I believe Business Roles (and Business Actors assigned to these roles) should own Master Data.  Master Data is created and managed by Business Processes but it is not owned by these Business Processes.  I believe this contradicts the definition of (or purpose for) having Master Data.
  • Classes of Master Data are defined by Master Data Definitions. Sketch these as Technology Artifacts UNLESS you are trying to model a Master Data Management/Master Metadata Management application.  If you’re doing the latter, no problem but I don’t think that this is directly related to Gunter’s original question.
  • Modeling a Salesforce “Org” as a Software Component is a bit of a stretch but it’s the best choice I could come up with.  Salesforce Org’s aren’t software.
  • The Business Capabilities and Business Roles you choose (and classes of Master Data) and their interrelationships will be specific to a particular company.

Once you’re happy with your detailed sketch, then you can use ArchiMate derivation to work backwards to create more focused (smaller) views that more specifically illustrate the answer(s) to your question.

If you want to do a full RACI treatment, then consider an approach like the one illustrated in this article: ARMs for Metadata-Driven LOB apps: SharePoint 2013/SharePoint 2016.

Homework: Data Lakes

  1. What if Customer was an aggregated, virtual Master Data class drawn from multiple applications and data sources both inside and outside your organization? …rather than a single data source or application? How would you represent this in your ArchiMate sketch?

That’s my 2 cents (Canadian). 🙂

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

*ArchiMate is a registered trademark of The Open Group.

2 Comments

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture, Master Data Management, Master Metadata Management, Salesforce

Tagged as , , , , ,

January 20, 2017 · 7:37 am

Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Elements as Adjectives [WIP]

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

[NOTE: This is a work-in-progress (WIP) placeholder for an article I plan to write …likely sooner rather than later …but there’s no specific schedule.]

Basic Concepts: Nouns and Adjectives

Referring to Figure 1 below, imagine that there are only a small number of concrete concepts in the ArchiMate language:

  • Model,
  • Concept

…and the remaining concepts are simply derivations of the one of these two Nouns: Model or Concept.

figure-1-top-level-hierarchy-of-archimate-concepts

Figure 1. Top-Level Hierarchy of ArchiMate Concepts (The Open Group)

Model and Concept become new Nouns in the next to-be-updated version of the ModelMate Information Architecture for ArchiMate.

The remaining concepts in Figure 1 and Figure 2 become Adjectives (i.e. abstract or virtual concepts) that modify or specialize the behavior of the target concept. The purpose of an Adjective (and more often a collection of Adjectives) is to support specialization of a Noun.

For example, in Figure 2 below, the box entitled “Capability” is a Concept which inherits the following Adjectives (specializations):

  • Element_ModelMate30_Parallelspace
  • BehaviorElement_ModelMate30_Parallelspace

figure-4-hierarchy-of-behavior-and-structure-elements

Figure 2. Hierarchy of Behavior and Structure Elements (The Open Group)

For a more elaborate example (see Figure 3 below), Business Role, Business Actor, and Business Collaboration are Nouns which inherit the following Adjectives:

  • Element_ModelMate30_Parallelspace
  • BusinessElement_ModelMate30_Parallelspace
  • InternalActiveStructureElement_ModelMate30_Parallelspace

figure-50-business-internal-active-structure-elements

Figure 3. Business Internal Active Structure Elements (The Open Group)

Windows Server Windows Service Example

TODO

1 Comment

Filed under Uncategorized

January 17, 2017 · 11:44 am

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

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

While working on a new series of projects and articles on #graphitization I pondered the following question:

Wouldn’t it be nice to have an authoritative reference for ArchiMate 3.0, more specifically, a repository for the enterprise architecture language‘s elements and relationship matrix, that is queryable.

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

Background

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

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

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

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

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

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

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

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

Graphitizing the ArchiMate Relationship Table

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

graphitization-of-gerben-wierdas-archimate-3-0-metamodel-d

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

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

graphitization-of-gerben-wierdas-archimate-3-0-metamodel-f

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

Recreating a Rendering of Gerben’s PDF

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

graphitization-of-gerben-wierdas-archimate-3-0-metamodel-e

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

The initial graph looked like this:

Graphitization of Gerben Wierda's ArchiMate 3.0 Metamodel g.png

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

graphitization-of-gerben-wierdas-archimate-3-0-metamodel-b

More importantly, I can now answer questions like:

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

Graphitization of Gerben Wierda's ArchiMate 3.0 Metamodel h.png

Please post your feedback, questions, and comments below.

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

*ArchiMate is a registered trademark of The Open Group.

3 Comments

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

Tagged as ,

January 13, 2017 · 3:12 pm

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

Tagged as , , , , , ,

January 2, 2017 · 2:25 pm

#Graphitization of the Enterprise

COPYRIGHT © 2016-2017 by Michael Herman, Toronto Canada. All rights reserved. [Updated June 16, 2018]

This article is the first in a series on #Graphitization. Click here to explore the other articles in this series.

Reprinted from #Graphitization of the Enterprise on LinkedIn.

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)

graphitization-new-world-of-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.

progressive-ea-model-1-0-11-peam4-operational-data-chasm
Figure 2. Continuous Transformation Framework: Enterprise Architecture Chasm and Operational Data Chasm

progressive-ea-model-1-0-11-peam5-1010
Figure 3. Continuous Transformation Framework: Process Groups and Activities

To learn more about other applications of graphitization, check out the following articles:

Best regards and best wishes for the New Year,

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

6 Comments

Filed under continuous transformation, Crossing the EA Charm, Data Science, Digital Transformation, Enterprise Architecture, Enterprise Architecture Chasm, Graphitization, ModelMate, Operational Data Chasm, Progressive Enterprise Architecture Map (PEAM)

Tagged as , , , ,