Tag Archives: Architecture Reference Models

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 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 , , , , , ,

October 28, 2016 · 12:02 am

ModelMate Architecture Reference Model

[Updated October 28, 2016]

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

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

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

ModelMate

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

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

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

Figure 1. Progressive Enterprise Architecture Model

Continuous Transformation Framework

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

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

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

peam-continuous-transformation

Figure 2. Continuous Transformation Framework

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

ModelMate Architecture Reference Model

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

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

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

marm-modelmate-open-hybrid-repository-app-categories

Figure 3. ModelMate Architecture Reference Model: 3 Layers

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

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

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

marm-modelmate-open-hybrid-repository-apps

Figure 4. ModelMate Architecture Reference Model: Apps

Ingestion

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

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

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

Pure Modeling and Layout Apps

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

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

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

Modeling, Layout & Visualization Apps

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

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

Data Science Apps

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

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

Custom Mobile and Web Apps

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

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

Program & Project Management Apps

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

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

Operations and Change Management Apps

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

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

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

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

*ArchiMate is a registered trademark of The Open Group.

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

4 Comments

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

Tagged as , , , , , ,

June 15, 2016 · 4:32 pm

ARM Models for Model-Driven LOB apps: SharePoint 2013/SharePoint 2016 [Oct. 24, 2016]

[April 12, 2017 Update: changed “metadata-driven” to “model-driven (metadata-driven)”]

[October 24, 2016 Update:

  • Technology Building Block for Microsoft SQL Server added
  • Building Blocks RACI Roles added
  • Existing relationships updated for conformance with ArchiMate specification
  • Typos and grammar corrected
  • ARM for SharePoint 2013/2016 image replaced in this blog posting

This is now a “version 2” (make it work better) model.]

It’s an interesting exercise to try and create an Architecture Reference Model (ARM) in ArchiMate for large, model-driven (metadata-driven) LOB applications like Microsoft SharePoint, Salesforce, Microsoft Dynamics CRM, SAP, Oracle Financials, a SQL Server fault-tolerant cluster, the Microsoft Azure platform, etc.

Even though some applications (platforms) are architecturally quite different from one and another (e.g. SharePoint configurability vs. SAP modularity), the fact that metadata drives the configuration and reconfiguration these applications is the most interesting aspect from an architectural point-of-view (vs. manually or semi-automatically configuring a collection of software components or modules).

For the next while, I’m focused on creating Architecture Reference Models that in turn can be used as templates for creating logical and physical enterprise architecture models for these platforms.

Here’s version 1 (“make it work”) of the Parallelspace ARM for SharePoint 2013/2016. It’s based on my 15+ years experience as a SharePoint architect – working first for the SharePoint product group and then a number of Microsoft solution partners (including my own company Parallelspace Corporation).

Note: This is now a “version 2” (make it work better) model.

Please email me your feedback (mwherman@parallelspace.net) or add it to the comments below.

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

p.s The model below was created using ArchiMate 2.1 and the Archi EA modeling tool.

Click to enlarge.

Parallelspace ARM-SharePoint 2013-2016 v1-0-12.png

p.p.s. The above view is what I refer to as a Construction view.  This isn’t a formal view in the ArchiMate specification but it is a view I use when I am building or constructing or updating a model.  It’s an “all in” view of the model who’s only stakeholder audience is the Enterprise Architect responsible for maintaining the ARM (architecture reference model). One downside of this view is that it has too many overlapping lines – but that’s OK. Appropriate stakeholder views should then be derived from the elements and relationships in this “all in” ARM.

5 Comments

Filed under ArchiMate, Architecture Reference Models, Enterprise Architecture, SharePoint

Tagged as , , , ,