Michael Herman, Enterprise Architect and Data Scientist: #Graphitization Inventor

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

Michael Herman is an expert when it comes to the mathematical modeling, analysis, and visualization of almost everything:

  • Large enterprise organizations,
  • Commercial, global-scale, cloud services platforms,
  • Organization principles and belief systems,
  • Human platforms,
  • Aircraft engines, and
  • Muscle cars.

Michael is the inventor of the #Graphitization Continous Transformation Model – a closed-closed loop feedback process for the ingestion, modeling, analysis, visualization, systems optimization, and life cycle management of any type of strategy, system, asset, architecture, or process.

progressive-ea-model-1-0-11-peam4-operational-data-chasm

Figure 1. #Graphization Continuous Transformation Model

A key concept of #Graphitization is the implementation of Transformative Changes that result in positive increases in business value in the system being modeled.

#Graphitization

What is #Graphitization?

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

References

#Graphitization Continuous Transformation Model

The #Graphitization general model is described in Figure 2. as it applies to the design and optimization of large enterprise organizations.

progressive-ea-model-1-0-11-peam4-operational-data-chasm

Figure 2. #Graphization Continuous Transformation Model: Large Enterprise Organizations

The same model can also be used to improve the design and operation of many different types of systems:

  1. Large scale enterprise organizations (public and private sector)
  2. Aircraft engines, muscle cars, and other high-performance engine systems
  3. Commercial, global-scale, cloud services platforms
  4. Automated service composition of cloud services-based data systems
  5. Large collaborative ecosystems: employee groups, business partners, social networks
  6. Large ecosystems of competing or competitive business organizations
  7. Organization principles and belief systems
  8. Conventions software applications and architectures: desktop, server, and web apps
  9. International standards for visual modeling languages
  10. Parallelspace ModelMate
  11. Enterprise Data Management
  12. Internet of Things (IoT)
  13. Architecture Reference Models

Publications and Research Projects

1. Large scale enterprise organizations (public and private sector)

The first applications of #Graphitization were in the field of traditional enterprise architecture modeling and analysis:

  • Business Architecture
  • Application Architecture
  • Technology/Infrastructure Architecture

References

  1. #Graphitization of the Enterprise
  2. Crossing the Chasm: Progressive Enterprise Architecture Model (PEAM)
  3. Progressive Enterprise Architecture Maps – Update 2
  4. Using ArchiMate 2.1 to Model Product or Service Markets
  5. ArchiMate 3.0: What is the preferred way to model a Server Farm?
  6. Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love
  7. Crossing the EA Chasm: Annotating Your EA Models with RACI Roles
  8. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1
  9. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2
  10. Crossing the Enterprise Architecture Chasm
  11. ModelMate Architecture Reference Model
  12. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?
  13. Modeling a Company and Its Locations, Markets, Employees, Investors & Roles: Proposals, Wishes & Dreams

2. Aircraft engines, muscle cars, and other high-performance engine systems

It turns out that the modeling and analysis of any complex system is an ideal candidate for #Graphitization.

References

  1. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

3. Commercial, global-scale, cloud services platforms

One particularly important application is the modeling and analysis of very large, commercial, global-scale, cloud services platforms.

References

  1. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

4. Automated service composition of cloud services-based data systems

Call the solution “Expedia for Microsoft Azure/AWS/SFDC/…” or whatever you prefer, today’s commercial cloud services platforms are still a pain in the ass to use for creating non-trivial applications.  Left, right, and center you have to hand-code a myriad of worker processes simply to reformat and pass data around.

#Graphitization is an optimal approach for modeling the underlying cloud services platform services catalog.

References

  1. MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts.
  2. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?
  3. Microsoft Azure Stack POC Architecture Reference Model (ARM): ArchiMate Model – version 1-0-7 – April 30, 2016

5. Large collaborative ecosystems: employee groups, business partners, social networks

Project “Boston” is named after some potential business partners and the embryo for the idea coming from my months as a founding Groove Networks business partner (including many of my most important relationships that I still maintain today).

6. Large ecosystems of competing or competitive business organizations

Modeling of large ecosystems of competing/competitive business organizations is a straightforward #Graphitization use case.

7. Organization principles and belief systems

On the surface, the #Graphitization of principle and belief-based frameworks is pretty straightforward but this is because the basic #Graphitization serves as the substrate for many advanced data ingestion, analysis, and visualization projects.

Below are the results of the  #Graphitization of two principle and belief-based frameworks:

  • Bridgewater Associates: Ray Dalio’s Principles
  • Amazon: Jeff Bezos’ Amazon Leadership Principles

References

  1. #Graphitization of Ray Dalio’s Principles: Iteration 1
  2. #Graphitization of Ray Dalio’s Principles: Iteration 2
  3. #Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1

8. Conventional software applications and architectures: desktop, server, and web apps

Modeling of complex, multi-language, multiple runtime software environments is a use case that is an ideal application of #Graphitization.

References

  1. #Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases
  2. Pinc-A Tool For Maintaining Configurable Software in Pascal1
  3. Pinc-A Tool For Maintaining Configurable Software in Pascal2
  4. Pinc-A Tool For Maintaining Configurable Software in Pascal3
  5. Pinc-A Tool For Maintaining Configurable Software in Pascal4
  6. Pinc-A Tool For Maintaining Configurable Software in Pascal5

9. International standards for visual modeling languages

A significant investment has been made in applying #Graphitization to language modeling; specifically, languages for enterprise architecture like ArchiMate.

ArchiMate References

  1. Using ArchiMate 2.1 to Model Product or Service Markets
  2. ArchiMate 3.0: What is the preferred way to model a Server Farm?
  3. How do I model “X” using ArchiMate?
  4. Crossing the EA Chasm: ArchiMate “Keep Calm and Have IT Your Way”
  5. Crossing the EA Chasm: ArchiMate Art
  6. Crossing the EA Chasm: Re-visioning the ArchiMate Specification
  7. Crossing the EA Chasm: Reflections on the Current State of ArchiMate
  8. Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Relations as Verbs
  9. Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Elements as Adjectives [WIP]
  10. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1
  11. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 2 (long but meaty)
  12. #Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository

10. Enterprise Data Management

Modeling and analyzing enterprise data structures and stores is a common application of #Graphitization; including the modeling of taxonomies and master data.

References

  1. RE: Managing Master Data With ArchiMate

11. Parallelspace ModelMate

Parallelspace ModelMate is an approach (platform and language framework) for creating domain specific languages (DSLs) for enterprise architecture.  It is realized using #Graphitization and the ArchiMate enterprise architecture modeling language.

References

  1. Crossing the Enterprise Architecture Chasm
  2. Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture
  3. ModelMate Architecture Reference Model

12. Internet of Things (IoT)

IoT is an interesting beast.  It is a reference to an application service for processing raw events from a device or dynamically generated events from a software system.  IoT also defines a conceptual software and data flow architecture that can also be used for the dynamic creating and maintenance of complex systems such as large enterprise architectures.

References

  1. Subject: MS Azure Services: Is there an overarching architectural vision?
  2. MS Azure is a bit of a bucket of bolts …very good bolts …but relative to the other IoT vendors, a bucket of bolts.
  3. Crossing the EA Chasm: “Where does IoT [Internet of Things] fit in?”

13. Architecture Reference Models (ARMs)

An ARM is easily modeled (and analyzed) using #Graphitization.  SharePoint and Azure Stack are two good examples.

References

  1. ARMs for Model-Driven LOB apps: SharePoint 2013/SharePoint 2016 [Oct. 24, 2016]
  2. Microsoft Azure Stack POC Architecture Reference Model (ARM): ArchiMate Model – version 1-0-7 – April 30, 2016

General References

  1. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  2. To dig deeper, check out Graphitization of the Enterprise (click here)
  3. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)
  4. Crossing the EA Chasm: The Surveyor

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

  • ArchiMate is registered trademark of The Open Group.

Leave a comment

Filed under Uncategorized

#Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1

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

[Click on any figure to enlarge it to its full, original size.]

The motivation and goals for Iteration 1 of this project are simple:

  1. Make the Amazon Leadership Principles visually more understandable and more memorable
  2. Introduce the concept of a Personal Leadership Principles Map where one’s personal career and personal belief system is mapped to each of the Amazon Leadership Principles
  3. Promulgate the use and application of #Graphitization beyond its traditional roots in Enterprise Architecture.

This article is structured as follows:

  • Appendix B – Amazon Leadership Principles is copy of the original text (non-graphitized) version of the Amazon Leadership Principles from the Amazon Jobs website.
  • Appendix A – Amazon Leadership Principles (and Subprinciples) contains an ArchiMate enterprise architecture model that depicts the (and then decomposes) the 14 Amazon Leadership Principles into multiple levels of subprinciples. Scroll down to the bottom of this article to check it out.
    NOTE: The underlining in Appendix A attempts to highlight the individual Subprinciples and Relationships found in the text description of each of the 14 Principles.
  • The first real section Amazon Leadership Principles, Core Entities, and Relationships presents a new innovative way to learn, remember, understand, and apply the Amazon Leadership Principles as highly visual web (or mesh or graph) of principles, concrete entities, abstract entities, and relationships.
  • The last section (just before Appendix A), entitled Personal Leadership Principle Maps, depicts how the experiences and accomplishments of one person’s career (mine) can be (formally) mapped the Amazon Leadership Principles.

Let’s start the journey. If you’re not familiar with the Principles, start by reading:

  • Appendix B – Amazon Leadership Principles; then
  • Appendix A – Amazon Leadership Principles (and Subprinciples)

All of the figures in this article represent different graphitized views of the Amazon Leadership Principles (click here) …all built from a single underlying graph model (which, in total, is referred to as the #Graphitization of the Amazon Leadership Principles).

Visually, the model is expressed using the ArchiMate 3.0 visual language standard for enterprise architecture. The model was built with the latest version of Archi 4.0, the open-source, free enterprise architecture modeling platform.

If you would like to work directly with the ArchiMate model for the Amazon Leadership Principles,

This article concludes with a list of possible Next Steps for Iteration 2.

Enjoy.

Amazon Leadership Principles, Core Entities, and Relationships

The text of the Amazon Leadership Principles references specific:

  • Roles
  • Concrete entities,
  • Abstract Entities, as well as, more importantly,
  • Relationships between these entities

These are collectively referred to as the Core Entities. Roles include:

  • Leader
  • Owner
  • Customer
  • Competitor
  • Partner
  • etc.

Concrete Entities include:

  • The Amazon Organization (presented by an employee directory or org chart)
  • Employee Team (same including virtual teams documented in project documents)
  • Standards (assuming they are written down or, in other words, documented)
  • Products
  • Services
  • Processes
  • etc.

Abstract Entities include:

  • Speed
  • Calculated Risks
  • Decisions
  • Actions
  • Inputs
  • Results
  • Bold Directions
  • Capabilities
  • etc.

Relationships include:

  • Leaders obsess over Customers
  • Leaders pay attention to Competitors
  • Leaders earn and keep Customer Trust
  • Constraints breed Resourcefulness
  • Constraints breed Self-Sufficiency
  • Constraints breed Invention
  • etc.

All of the entities and relationships are depicted in Figure 1 below (assuming none or only a few have been overlooked). (Click the figure to enlarge it.)

The entities and relationships were deduced by inspection and analysis of each of the 14 Amazon Leadership Principles (classic business analysis, more or less).

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P00-Core Entities v1.30

Figure 1. Amazon’s Principles, Core Entities, and Relationships: The Core Model

The existence, enablement, creation and/or execution of each group of relationships gives rise to (or realizes) one or more of the 14 Principles (and/or their Subprinciples). When these realization relationships are added to the Core Entities depicted in Figure 1,  Figure 2., the “Complete Model”, is the result. (Click to enlarge.)

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P00-All v1.30

Figure 2. Amazon’s Principles, Core Entities, and Relationships: The Complete Model

To simplify the understanding of the model, 14 new views were created – one for each of the 14 Principles – each overlayed on the original Core Model (Figure 1). Figure 3 is an example drawn from one of these 14 views: Principle 1. Customer Obsession.

Parallelspace-Amazon Leadership Principles, Roles, and Relationships-P01 v1.30

Figure 3. Amazon’s Principles, Core Entities, and Relationships: Principle 1. Customer Obsession

Located in the lower-left side of Figure 3, the Customer Obsession Principle is realized by:

  • a) a Leader’s focus or “obsession over Customers”, and
  • b) a Leader’s “attention to the Competition”.

Figure 4. below is an animation of the Complete Model overlayed, principle-by-principle, against the Core Model.

This slideshow requires JavaScript.

Figure 4. Amazon’s Principles, Core Entities, and Relationships: Principle-by-Principle Animation overlayed against the Core Model

The individual views of the 14 Amazon Leadership Principles can be downloaded from here: https://www.facebook.com/mwherman/media_set?set=a.10155018158800932.1073741988.635655931&type=3.

So far, we’ve addressed the “what” of the Amazon Leadership Principles depicted as a #Graphitization model projected as a number of different views.

In the next section, the Amazon Leadership Principles are used as a framework for cataloging one’s lifetime experiences and accomplishments. Personal Leadership Principle Maps is an Amazon Leadership Principles application – it’s the Amazon Leadership Principles put into action.

Personal Leadership Principle Maps

Have you been living an Amazon Leadership Principled career/faith/life?

Figure 5. is a copy of my Personal Leadership Principle Map (PLPM).

  • ArchiMate Assessment entities are used to model specific experiences and accomplishments.
  • ArchiMate Outcome entities are used to model specific evidence, learnings, or proof that one has been able to apply the specific principle in their career, faith and/or life.

Parallelspace-Amazon Leadership Principles-Personal Leadership Principle Map-Michael Herman v1.30

Figure 5. Amazon’s Principles: Michael’s Experiences and Accomplishments

In my case, for Principle 7. Insist on the Highest Standards, I have specific experiences related to the recent Toronto Salesforce 2017 Tour, working at Parallelspace Corporation, the IBM Canada Toronto Software Lab, and at Microsoft.

Specific evidence includes:

  • Parallelspace trust framework (Relationships-Reputation-Trust)
  • Working as an ISO-9000 Quality Analyst and a certified Quality Assurance Auditor
  • A concept I call focusing on the success of an Individual Individual
  • Various and diverse experiences working for Microsoft as a full-time employee (blue badge) and as a Microsoft partner

Next Steps for Iteration 2

Possible next steps include:

  • Federation of Personal Leadership Principle Maps – at the Employee Team, business unit, or Organization level to discover the aggregates collective experiences and accomplishments for the purpose of rebalancing hiring objectives (Principle Gap Analysis), accumulating customer as well as competitive intelligence, etc. to support Customer Obsession, Ownership, Invent and Simplify, etc. goals and objectives. Identifying the best sources of experiences and accomplishments for specific Principles based on a Team’s or Organization’s previous roles, education, or training.
  • Use of both the Core Model and the Complete Model as well as the Federate Personal Leadership Principle Maps to create a graph database repository to real-time query analysis and visualization (e.g. using the Neo4j graph database).
  • To support Amazon’s operational data analysis needs (e.g. Amazon Marketplace 3rd Party Retail Data).
  • Apply the Parallelspace principles

References

  1. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  2. To dig deeper, check out Graphitization of the Enterprise (click here)
  3. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)

Appendix A – Amazon Leadership Principles (and Subprinciples)

Below is an ArchiMate enterprise architecture model that depicts (and then decomposes) the 14 Amazon Leadership Principles into multiple levels of subprinciples (as appropriate/as required).

These are based on the text-based defintions of the 14 Principles found in Appendix B – Amazon Leadershp Principles.

Parallelspace-Amazon Leadership Principles (and Subprinciples) v1.30

Figure 6. Amazon’s Principles (and Subprinciples)

Appendix B – Amazon Leadership Principles

The following Leadership Principles are taken directly from the Amazon Jobs website.

  • The sequential numbering (in parenthesis) was added by me.
  • The underlining attempts to highlight the individual Subprinciples and Relationships found in the text description of each of the 14 Principles.

Leadership Principles

Our Leadership Principles aren’t just a pretty inspirational wall hanging. These Principles work hard, just like we do. Amazonians use them, every day, whether they’re discussing ideas for new projects, deciding on the best solution for a customer’s problem, or interviewing candidates. It’s just one of the things that make Amazon peculiar.

Customer Obsession (1)

Leaders start with the customer and work backward. They work vigorously to earn and keep customer trust. Although leaders pay attention to competitors, they obsess over customers.

Ownership (2)

Leaders are owners. They think long term and don’t sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team. They never say “that’s not my job”.

Invent and Simplify (3)

Leaders expect and require innovation and invention from their teams and always find ways to simplify. They are externally aware, look for new ideas from everywhere, and are not limited by “not invented here”. As we do new things, we accept that we may be misunderstood for long periods of time.

Are Right, A Lot (4)

Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

Learn and Be Curious (5)

Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Hire and Develop the Best (6)

Leaders raise the performance bar with every hire and promotion. They recognize exceptional talent and willingly move them throughout the organization. Leaders develop leaders and take seriously their role in coaching others. We work on behalf of our people to invent mechanisms for development like Career Choice.

Insist on the Highest Standards (7)

Leaders have relentlessly high standards – many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high-quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

Think Big (8)

Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

Bias for Action (9)

Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Frugality (10)

Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size or fixed expense.

Earn Trust (11)

Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

Dive Deep (12)

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.

Have Backbone; Disagree and Commit (13)

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

Deliver Results (14)

Leaders focus on the key inputs for their business and deliver them with the right quality and in a timely fashion. Despite setbacks, they rise to the occasion and never settle.

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

2 Comments

Filed under ArchiMate, Architecture Reference Models, Business Value, continuous transformation, Definitions, Enterprise Architecture, graph database, Graphitization, How do we think, ModelMate, Process, Product Management, Uncategorized

Why Would You Prefer to Work for Amazon (or Facebook) over Microsoft (or Salesforce)? [WIP]

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

This article is a work-in-progress [WIP] placeholder.

Why would you prefer to work for Amazon (or Facebook) over Microsoft (or Salesforce)?

Scenario 1: These are organizations with an unrelenting, unbelievable, and successful focus on happy customers. …a true, genuine, deliberate focus on building and maintaining positive relationships with their customer and partners? Would you choose to work for a Scenario 1 organization? …maybe.

Scenario 2: These are the other companies that really need your help and are willing to hire you to help make the important changes necessary to develop the same sort of unrelenting focus on building and maintaining positive customer and partner relationships Would you choose to work for a Scenario 1 organization? …maybe.

I have the option (luxury) to consider all 4 types of opportunities and in each case, work with some brilliant people. Which organization(s) would you pick?

With a Scenario 2 company, you’re starting work working for an organization in a net deficit position with respect to customer happiness, respect, and trust. Job one is to move the organization from a net negative position to a net neutral or, hopefully, positive position in the marketplace; then build of there. If you know or deeply understand the Scenario 2 company, you’re likely being asked “to return and to help” as a trusted soldier. You likely know and understand the root causes that have landed the organization at the bottom of the ladder of customer satisfaction.

With a Scenario 1 company, you’re starting work working for an organization in a net positive position with respect to customer happiness, respect, and trust. There is no Job one because the organization already has a great positive report with its customer and partners – not just its largest revenue-generating customers but all customers; from

  • Individual individuals

up through

  • Single-person corporations,
  • Two-person partnerships,
  • Small businesses/enterprises,
  • Medium size businesses/enterprises,
  • Large businesses/enterprises, and
  • Extra large businesses/enterprises.

Scenario 1 organizations are already at or near the top of the customer satisfaction mountain and are only striving to be even better. They and yourself are not starting work each day working in a negative hole. Thriving is thriving …thriving to be your best from a positive starting position of customer and partner happiness, respect, and trust.

Scenario 2 organizations start work each day in a negative hole. Yes, there may be places where, on some days, you can stand on something to see over the top of the hole and things don’t look so dreary …but it’s not guaranteed …and it’s neither fun nor enjoyable to work there every day. Thriving is equivalent to surviving.  #NotFun

Amazon

TODO

#Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1
https://hyperonomy.com/2017/05/08/amazons-principles/

TODO

Facebook

TODO

Microsoft

TODO

Salesforce

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

Leave a comment

Filed under Uncategorized

High-Velocity Service Packages and Envelopes [WIP]

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

This article is a work-in-progress [WIP] placeholder.

TODO

Introduction

TODO

Scenario

TODO

Problem

TODO

Analysis

TODO

Options

TODO

Solution

TODO

High-Velocity Service Envelopes (HVSE)

TODO

High-Velocity Service Packages (HVSP)

TODO

Results

TODO

Next Steps

TODO

Conclusions

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

Leave a comment

Filed under Uncategorized

Isomorphic Weighted Graph Databases and Graph Algorithm Non-Collinearity [WIP]

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

This article is a work-in-progress.

Introduction

TODO

Isomorphic Weighted Graphs

TODO

Definitions

TODO

isomorphic

TODO

Weighted Graph Database Scenarios

TODO

  1. Project “Matt-itrage”: Real-time, Multiple Provider, Foreign Currency Arbitrage
  2. “Expedia for Azure, AWS, and/or Salesforce”: Automated Cloud Services Composition
  3. Project “Boston”: Personal, Hyper-scalable Homeland Security Databases – Federation Optional
  4. TEAM: Large Scale, Automated Total Enterprise Architecture Management
  5. TEBD: Large Scale, Automated Total Enterprise Big Data Routing and Streaming

TODO

1. Project “Matt-itrage”: Real-time, Multiple Provider, Foreign Currency Arbitrage

TODO

Currency Arbitrage

TODO

2. “Expedia for Azure, AWS, and/or Salesforce”: Automated Cloud Services Composition

TODO

3. Project “Boston”: Personal, Hyper-scalable Homeland Security Databases (Federation Optional)

TODO

4. TEAM: Large Scale, Automated Total Enterprise Architecture Management

TODO

5. TEBD: Large Scale, Automated Total Enterprise Big Data Routing and Streaming

TODO

Graph Algorithm Non-Collinearity

TODO

Definitions

TODO

collinear

TODO

collinearity

TODO

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

1 Comment

Filed under Uncategorized

What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale?

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

Question: What are the differences between improving the design (and operation) of:

  • an aircraft engine,
  • a muscle car,
  • a large enterprise, and/or
  • an integrated commercial global cloud services platform
  • …all running at hyperscale?

Answer: None.

Scroll down to see the use cases; then the list of resources at the bottom of this article.

Use Case 1: Aircraft engine, and
Use Case 2: 
Muscle car

Continuous Transformation 2

Use Case 3: Large enterprise operating at hyperscale, and
Use Case 4: 
Integrated commercial global cloud services platform operating at hyperscale

Continuous Transformation 1.png

References

  1. Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
  2. To dig deeper, check out Graphitization of the Enterprise (click here)
  3. [Enterprise Architecture, Big Data, CRM, ERP, …] Tools and Methods Don’t Generate Business Value (click here)

Best regards,

Michael Herman
Enterprise Architect and Data Scientist
Parallelspace Corporation
M: 416 524-7702
E: mwherman@parallelspace.net
B: http://hyperonomy.com
L: https://www.linkedin.com/in/mwherman/recent-activity/posts/
Skype: mwherman2000

Living at the intersection of Enterprise Architecture, Enterprise Knowledge, and Data Science

1 Comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Data Science, Enterprise Architecture, Graphitization, How do we think, IoT, Space Flight

Structuring Small Powerful Documents

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

For the past couple weeks now, I’ve been on the left coast visit with friends and colleagues and having an extraordinary time. Often, the conversation returns to what is the best way to convince someone or some group to do this or that.  Here’s some ideas and templates to consider based on my past experiences:

  • Notes from the Field
  • Product Planning Cycles
  • Project Business Charter
  • Preliminary Vision and Scope Document
  • Jeff Bezzo’s Amazon 6-Pager

Notes from the Field

Parts

  • Introduction
  • Scenario
  • Problem
  • Analysis
  • Options
  • Solution
  • [Preliminary] Results
  • Summary

Sample Templates

Product Planning Circles

Sample Templates

Project Business Charter

Parts

  • Business Project Description
  • Deliverables
  • Project Scope / Boundaries / Assumptions
  • Project Accountability
  • Stakeholders
  • Project Execution Risks Summary and Mitigation Options
  • Project Cost Estimate
  • Links to Supporting Documentation

Sample Templates

Preliminary Vision and Scope Document

Also known as an Engagement Transition Document

Parts

  • OVERVIEW
  • PROBLEM STATEMENT
  • BUSINESS OBJECTIVES
  • EXISTING ENVIRONMENT
  • USER PROFILES
  • SOLUTION VISION
  • PROJECT SCOPE
  • CRITICAL SUCCESS FACTORS
  • IMPORTANT DATES
  • OTHER ASSUMPTIONS AND CONSTRAINTS

Sample Templates

Jeff Bezo’s Amazon 6-Pager

Parts

[The six-page narratives are structured] like a dissertation defense:

  1. The context or question.
  2. Approaches to answer the question – by whom, by which method, and their conclusions
  3. How is your attempt at answering the question different or the same from previous approaches
  4. Now what? – that is, what’s in it for the customer, the company, and how does the answer to the question enable innovation on behalf of the customer?

(via Amazon: How are the 6 page “narratives” structured in Jeff Bezos S-Team meetings? – Quora)

Sample Templates

  • None available (yet)

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

Leave a comment

Filed under Uncategorized

Michael Herman: Award-winning Author, Invited Speaker, Illustrator, and Trainer

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

Feel free to contact me at:

PARTIAL PORTFOLIO

All of the publications below are full-length white papers or technical notes – unless noted otherwise (e.g. presentations, training materials, online product help).

Microsoft Live Communications Server

Client: Microsoft Corporation Live Communications Server Product Group / Microsoft IT Showcase

Microsoft SharePoint Products and Technologies

Client: Microsoft Corporation SharePoint Product Group / Microsoft IT Showcase

Microsoft Exchange Server

Client: Microsoft Corporation Exchange Server Product Group / Microsoft IT Showcase

Metalogix Replicator for SharePoint

Client: Metalogix, market leading provider of solutions to move, manage and protect content within enterprise collaboration platforms in the cloud and on-premises.

Microsoft “Alchemy”

Client: Microsoft Web Services Product Group / Microsoft IT Showcase

Parallelspace Vulture

Client: Parallelspace Corporation

Tzunami K-Wise Deployer

Client: Tzunami

Leave a comment

Filed under Uncategorized

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

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

First Draft: April 5, 2017

This article documents a number of parallel efforts to improve the usability, understandability, utility, and correctness of the ArchiMate 3.0 Specification. In particular, this article extends a well-received previous article Crossing the EA Chasm: Graphitization of ArchiMate 3.0 – Iteration 1 where I posed the 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.

This article documents the current iteration of the ModelMate project, Iteration 2, whose goal is to create an improved queryable repository for a corrected version of relationship matrix (more correct relative to the Appendix B tables in the current ArchiMate 3.0 Specification).

Background

Over the past few months, I’ve written several articles commenting on the current state of the ArchiMate language for Enterprise Architecture including:

In addition, there are almost weekly postings about usability issues or errors with the Specification in the Linkedin ArchiMate group, the GitHub Archi issues log, LinkedIn Pulse, and the Google ArchiMate group; as well as other forums [1][2].

The recent effort, called the ModelMate project, is a focused effort to create a more broadly applicable, usable, useful, ArchiMate-based, extensible language environment for enterprise architecture as described in these 4 articles:

Current Scenario

The current scenario is highlighted by the following points taken from the above references:

  • “[People should be] encouraged to try to model these examples for yourself: to start learning how to “think in ArchiMate” as your second or third written language.” The way the ArchiMate language is currently designed and, more importantly, described makes this difficult.
  • In an abstract sense, the extension of the ArchiMate language is supported but, in reality, few if any broadly adopted extensions have appeared in the market. A better approach is described here: Crossing the EA Chasm: ArchiMate 3.0, fix it or re-purpose it?
  • There is no single, authoritative, machine-readable version of the ArchiMate 3.0 relationship matrix; let alone one that is easily accessible and queryable.
  • The Open Group’s insistence on using abstract terminology to name element types and relation types presents users with additional challenges.

Problem Description

At a data level, the root causes of the problems with the ArchiMate 3.0 relationship matrix in Appendix B of the ArchiMate 3.0 Specification include:

  • No machine-readable version of the tables are available for external validation for correctness
  • The tables contain errors in the approximately 11,000 relations that are represented in the tables.  Is is estimated that there are few hundred to a few thousand errors present in the current ArchiMate 3.0 tables
  • The tables contain all possible (valid) relations but do not differentiate between Core relations and Derived (non-Core) relations.

All three issues are critical for the ArchiMate 3.0 Specification and these tables to be trusted and more generally useful.

In addition, the Derived Relation Derivation Algorithm has never been published by The Open Group.  Attempts to create an alternative algorithm have highlighted that the text of the ArchiMate 3.0 Specification is neither consistent nor complete when it comes to identifying the set of Core Relations and a correct and complete Derviation Algorithm.

Lastly, when dealing with 1000+ Core Relations and several thousand Derived Relations (8000-9000 or more), it’s difficult to analyze and visualize what the ArchiMate 3.0 relationship matrix looks like in total, or when subdivided by Domain (Layer) or Aspect, or when focused on a specific element prototype (e.g. Node).

Solution Overview

The goal of this solution is to publish a very detailed, rich, unnormalized version of the latest and greatest ArchiMate 3.0 relationship matrix in multiple formats; including:

  • CSV text file
  • Microsoft Excel workbook
  • Microsoft Access database
  • Neo4j Cypher Query Language (CQL) queryable graph database file

When loaded into Microsoft Excel, the CSV and Microsoft Excel workbook format files appear as shown in Figure 1 (below).

Step 00 ModelMate Master Dataset Complete.png

Figure 1. ModelMate Master Datasets: Excel 2016 and CSV File Formats

The Microsoft Excel (and CSV) format file can also be used with the Microsoft Excel Web App (Figure 2) and the Microsoft Excel format can be used to create custom SharePoint lists (Figure 3).

step-00-modelmate-master-dataset-complete-web-excel

Figure 2. ModelMate Master Datasets: Excel 2016 format file in MIcrosoft Excel Web App

step-00-modelmate-master-dataset-complete-splist

Figure 3. ModelMate Master Datasets: Custom SharePoint List created from Imported Excel 2016 Format File

When loaded into Microsoft Access, the Microsoft Access database format files appear as shown in Figure 4 (below).

step-00-modelmate-master-dataset-complete-access

Figure 4. ModelMate Master Datasets: MS Access Database file format

To create a queryable graph database version of the ArchiMate 3.0 relationship tables (in effect, the entire ArchiMate 3.0 metamodel), the Cypher Query Language (CQL) file depicted in Figure 5. was created.

Step 00 ModelMate Master Dataset Complete-CQL.png

Figure 5. ModelMate Master Datasets: Neo4j CQL File

Figure 6 is an example of the output from a single line CQL query run against the ArchiMate 3.0 graph database (implemented using Neo4j).  If you look closely at the CQL statement at the top of this screen shot (click Figure 6. to enlarge it), you’ll see that it is selecting all of the relationships across all of the element prototypes in the Technology/Infrastructure domain of the ArchiMate 3.0 metamodel that connect to the Node element prototype.

370-parallelspace_modelmate_masterdataset_complete10-technologydomain7

Figure 6. ModelMate Master Datasets: Graph Mining Analysis Sample

File Downloads

You can download the files referred to in this article from the GitHub repository. Click here to download the ModelMate Master Datasets files.

In addition, there is a Neo4j Cypher Query Language (CQL) file available for download that will ingest all of the element prototypes and relations into a graph database using a single Neo4j shell invocation. From the Windows Powershell or Windows Command Prompt, use:

“C:\Program Files\Java\jre1.8.0_91\bin\java.exe” -classpath “C:\Program Files\Neo4j CE 3.0.6\bin\neo4j-desktop-3.0.6.jar” org.neo4j.shell.StartClient -c dump > MasterDataSet.cql

Lastly, there is Microsoft Access 2016 database version of the CSV file that is available for download if you prefer using Microsoft Access SQL queries or graphical SQL queries.

Solution Details

Below is a copy of the workflow and dataflow used to create the Parallelspace ModelMate Master Datasets.  It’s not as messy as it looks – it’s true mashup and a valuable one at that. It’s primarily the result of the truly ad-hoc collaboration between 3 enterprise architecture professionals with an interesting mix of diverse goals (Gerben Wierda, Ed Roberts and myself); each of us with our own set of preferred development technologies and goals (with Excel being the greatest common denominator (GCD)).

community-basedderivedrelationsproject7

Figure 7. ArchiMate 3.0 Relationship Matrix Resolution Process

The numbered steps in Figure 7. are explained below:

01Data Sources. There are many sources of information about the ArchiMate relationship matrix in addition to the Appendix B tables in the ArchiMate 3.0 Specification. The list in Figure 7. is a fairly complete. Key data sources include the GitHub Archi repository for the most widely used ArchiMate modeling tool for enterprise architecture and Gerben Wierda’s multiple ArchiMate resources publishing under the Mastering ArchiMate brand.

02“MA Core Set” Spreadsheet. Wierda worked to consolidate various data sources from Step 1 above to create the “MA Core Set” Mastering ArchiMate relationship matrix (plus a number of other relationship matrices that Wierda used for comparative analysis and troubleshooting purposes). The “MA Core Set” represents the “seed” or Core Set of (non-derived) ArchiMate relations. Wierda created this Core Set over several iterations reviewing the word-for-word text of the Specification, the inheritance diagrams, as well as incorporating his extensive practical knowledge and experience documenting ArchiMate in the book entitled Mastering ArchiMate – Edition II.

The “MA Core Set” tab in the AllowedRelationsArchiMate30VBA-public.xlsm Excel spreadsheet also includes additional columns that are reserved for calculating and storing an intermediate 3-column, reverse-transposed version of the relationship matrix (Step 3 below).

03CreatePrologList() Visual Basic for Applications (VBA) Macro: This macro is used to perform the actual reverse-transposition of the “MA Core Set” relationship matrix into the 3-column format which including a column for storing the relation(source,target) 3-tuple formatted data (in Prolog format). The 2-D relationship matrix is the input to the macro (along with some additional master data tables that are part of the VBA code). The 3-tuples are the essential output of the VBA macro (stored “in-place” in the first 3 columns of the spreadsheet).

04CoreSet.prolog File. To proceed through to the next step of the workflow, the Prolog format data is copied from the spreadsheet and pasted into a plain text file called CoreSet.prolog, for example (or any other filename you would like to use).

05 Derivaton.py Python Script and outfile.csv. The Derivation.py script contains is the “magic sauce”. Written by Wierda, Derivation.py reads the CoreSet.prolog file and executes a complex and detailed algorithm to expand the Core Set of ArchiMate relations read from the CoreSet.prolog file into a number of alternative output formats, including CSV and Prolog formats.

To support the ModelMate project, a version of Derivation.py was modified to output a number of additional CSV columns (outfile.csv). Columns:

  1. SourceElement
  2. TargetElement
  3. Relation
  4. RelativeStrength
  5. IsInputRelation
  6. StandardVersion
  7. ScriptVersion

06Outfile.xml File. Steps 6 and 7 are part of a sequence of activities that were used to create a relationships.xml file that is compatible with the relationship configuration requirements of the Archi modeling tool. This process, originally implemented by Ed Roberts, owner of Dallas-based Elparazim, uses Excel to load the outfile.csv save it out as an outfile.xml file.

07For Step 7, Ed Roberts wrote an XSL Transform script that when applied to the outfile.xml file creates the Archi-compatible relationship.xml that is used by the Archi model to automatically configure the element-element relations supported in a given version of Archi (e.g. Archi 4.0).

08Steps 8-10 mark an alternative data flow created to support the needs of the ModelMate Master Datasets project.

In Step 8, the contents of the ModelMate-compatible modified CSV output from Step 5 (outfile.csv) is copy-and-pasted into the Parallelspace_ModelMate_MasterDatasets_CoreAndDerivedNN.xlsx Excel workbook (where NN is a version number).

A matrix of automated Excel functions in the Complete spreadsheet merge the elements and relations master data attributes from the Elements and Relations spreadsheet with the data from the Derived spreadsheet to compute the corresponding column values in the Complete spreadsheet. Think of the Complete spreadsheet as a super-unnormalized version of the relationship matrix.  The InInputRelation column values indicate whether a specific relation (and it’s companion source and target elements) are Core relations or Derived relations.

The workbook contains 4 spreadsheets (Derived, Complete, Elements, and Relations):

  • Derived spreadsheet – copy-and-pasted version of the outfile.csv from Step 4. The “input” spreadsheet.
    Columns:

    1. SourceElement
    2. TargetElement
    3. Relation
    4. RelativeStrength
    5. IsInputRelation
    6. StandardVersion
    7. ScriptVersion
  • Complete spreadsheet – leverages the master data in the Elements and Relations tabs to expand the columns in the Derived spreadsheet to include additional metadata property columns for the source and target elements as well as the relations. The “output” spreadsheet that will be saved as a CSV file in Step. 9.
    Columns:

    1. SourceElement
    2. TargetElement
    3. Relation
    4. RelativeStrength
    5. IsInputRelation
    6. StandardVersion
    7. ScriptVersion
    8. RelationName
    9. RelationLabel
    10. RelationQualifiedLabel
    11. RelationForwardVerbLabel
    12. RelationReverseVerbLabel
    13. RelationQualifiedForwardVerbLabel
    14. RelationQualifiedReverseVerbLabel
    15. SourceName
    16. SourceLabel
    17. SourceQualifiedLabel
    18. TargetName
    19. TargetLabel
    20. TargetQualifiedLabel
    21. SourceDomainName
    22. SourceDomainLabel
    23. SourceDomainQualifiedLabel
    24. SourceAspectName
    25. SourceAspectLabel
    26. SourceAspectQualifiedLabel
    27. TargetDomainName
    28. TargetDomainLabel
    29. TargetDomainQualifiedLabel
    30. TargetAspectName
    31. TargetAspectLabel
    32. TargetAspectQualifiedLabel
  • Elements spreadsheet – master data attributes and values for each element prototype.
    Columns:

    1. ElementCode
    2. ElementLabel
    3. ElementName
    4. ElementQualifiedLabel
    5. DomainName
    6. DomainLabel
    7. DomainQualifiedLabel
    8. AspectName
    9. AspectLabel AspectQualifiedLabel
  • Relations spreadsheet – master data attributes and values for each relation prototype.
    Columns:

    1. RelationCode
    2. RelationName
    3. RelationQualifiedLabel
    4. RelationForwardVerb
    5. RelationQualifiedForwardVerb
    6. RelationReverseVerb
    7. RelationQualifiedReverseLabel

09In Step 9, columns 4-32 of the Complete spreadsheet are saved as a separate CSV format file (using the same versioned file name as the parent workbook but with a suffix of .csv).

Also considered part of Step 9, the CSV file is imported into an empty Microsoft Access database. The datatype of the InInputRelation is changed to be a Yes/No (boolean) field. The database file is given the same name as the CSV file but with a suffix of .accdb.

10Step 10 uses a series of Cypher Query Language (CQL) script files to create and populate a Neo4j graph database – to enable simple but powerful ad-hoc queries against the ArchiMate 3.0 relationship tables/metamodel.

Step 10.1. Merge all of Source and Target Element Prototypes

step-01-merge-element-prototypes

Script 1. Merge Source and Target Element Prototypes

Step 10.2. Label Elements with Element, Domain and Aspect Names

step-02-label-elements-with-element-domain-and-aspect-names

Script 2. Label Elements with Element, Domain and Aspect Names

Step 10.3 Create the Metamodel Relationships

TODO

Results

Use Cases

This section documents the results of the following use cases (queries against the Neo4j graph model):

  1. All Business domain source and target element prototypes and all related Core and Derived relationships
  2. All Core relationships where the source element prototype is from the Business domain
  3. All Core relationships where the source and target element prototypes are from the Business domain
  4. All Application domain source and target element prototypes and all related Core and Derived relationships
  5. All Core relationships where the source and target element prototypes are from the Application domain
  6. All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain
  7. All Core relationships where the source and target element prototypes are from the Technology domain
  8. All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other
  9. All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
  10. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
  11. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype
  12. All Core relationships where the source and target element prototypes belong to the Passive Structure aspect
  13. All Core relationships where the source and target element prototypes belong to the Active Structure aspect
  14. All Core relationships where the source and target element prototypes belong to the Behavior aspect

Use Case Results

Click on any of the figures to enlarge them in a separate browser tab.

Business Domain Use Case Results

Use Case 1: All Business domain source and target element prototypes and all related Core and Derived relationshipsUse Cases

Figure 8. is the result of an ad-hoc CQL query against all element prototypes in the Business domain; more specifically, where both the source and target element prototypes are in the Business domain.

100-parallelspace_modelmate_masterdataset_complete10-businessdomain

Figure 8. All Business domain source and target element prototypes and all related Core and Derived relationships

Use Case 2: All Core relationships where the source element prototype is from the Business domain

Figure 9. is the result of an ad-hoc CQL query against all Core relationships where the source element prototype is from the Business domain.

120-parallelspace_modelmate_masterdataset_complete10-businessdomain2

Figure 9. All Core relationships where the source element prototype is from the Business domain

Use Case 3: All Core relationships where the source and target element prototypes are from the Business domain

Figure 10. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Business domain.

130-parallelspace_modelmate_masterdataset_complete10-businessdomain3

Figure 10. All Core relationships where the source element prototype is from the Business domain

Application Domain Use Case Results

Use Case 4: All Application domain source and target element prototypes and all related Core and Derived relationships

Figure 11. is the result of an ad-hoc CQL query against all element prototypes in the Application domain; more specifically, where both the source and target element prototypes are in the Application domain.

200-parallelspace_modelmate_masterdataset_complete10-applicationdomain

Figure 11. All Application domain source and target element prototypes and all related Core and Derived relationships

Use Case 5: All Core relationships where the source and target element prototypes are from the Application domain

Figure 12. is the result of an ad-hoc CQL query against all Core and Derived relationships where the source element prototype is from the Application domain.

230-parallelspace_modelmate_masterdataset_complete10-applicationdomain3

Figure 12. All Core relationships where the source and target element prototypes are from the Application domain

Technology Domain Use Case Results

Use Case 6: All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain

Figure 13. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology/Infrastructure domain.

300-parallelspace_modelmate_masterdataset_complete10-technologydomain

Figure 13. All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain

Use Case 7: All Core relationships where the source and target element prototypes are from the Technology domain

Figure 14. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain.

330-parallelspace_modelmate_masterdataset_complete10-technologydomain3

Figure 14. All Core relationships where the source and target element prototypes are from the Technology domain

Use Case 8: All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other

Figure 15. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain and are identical to each other.

340-parallelspace_modelmate_masterdataset_complete10-technologydomain5

Figure 15. All Core relationships where the source and target element prototypes are from the Technology domain and identical to each other

Use Case 9: All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Figure 16. is the result of an ad-hoc CQL query against all Core relationships where both the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing).

350-parallelspace_modelmate_masterdataset_complete10-technologydomain4

Figure 16. All Core relationships where the source and target element prototypes are from the Technology domain and different from each other (non-self referencing)

Use Case 10: All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Figure 17. is the result of an ad-hoc CQL query against all Core and Derived relationships where both the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing).

360-parallelspace_modelmate_masterdataset_complete10-technologydomain6

Figure 17. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)

Use Case 11: All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype

Figure 18. is the result of an ad-hoc CQL query against all Core and Derived relationships where both the source and target element prototypes are from the Technology domain and are connected to the Node element prototype.

370-parallelspace_modelmate_masterdataset_complete10-technologydomain7

Figure 18. All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype

Aspects Use Case Results: Passive Structure, Active Structure, Behavior

Use Case 12: All Core relationships where the source and target element prototypes belong to the Passive Structure aspect

Figure 19. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Passive Structure aspect.

410-parallelspace_modelmate_masterdataset_complete10-passivestructure1

Figure 19. All Core relationships where the source and target element prototypes belong to the Passive Structure aspect

Use Case 13: All Core relationships where the source and target element prototypes belong to the Active Structure aspect

Figure 20. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Active Structure aspect.

420-parallelspace_modelmate_masterdataset_complete10-activestructure1

Figure 20. All Core relationships where the source and target element prototypes belong to the Active Structure aspect

Use Case 14: All Core relationships where the source and target element prototypes belong to the Behavior aspect

Figure 21. is the result of an ad-hoc CQL query against all Core relationships where the source and target element prototypes belong to the Behavior aspect.

430-parallelspace_modelmate_masterdataset_complete10-behavior1

Figure 21. All Core relationships where the source and target element prototypes belong to the Behavior aspect

Feedback

Please add your comments and feedback to the end of this article.

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

*ArchiMate is a registered trademark of The Open Group.

1 Comment

Filed under ArchiMate, Architecture Reference Models, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Definitions, Domain Specification Languages (DSL), Enterprise Architecture, Enterprise Architecture Chasm, graph database, Graphitization, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, Progressive Enterprise Architecture Map (PEAM), The Open Group