Category Archives: Definitions

May 8, 2017 · 1:37 pm

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

PLEASE POST A COMMENT ABOUT WHY THIS PAGE IS IMPORTANT TO YOU.
This particular page is 1 of my top 5 most viewed pages (ever) and I’d like to understand why. Thank you!

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

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

Make the Amazon Leadership Principles visually more understandable and more memorable
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
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,

The latest version of the Archi .archimate model file created for this article be downloaded from here.
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

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

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

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.

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.

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

Continuous Transformation and Transformative Change are key principles of the Total Enterprise Architecture Model (TEAM) (click here)
To dig deeper, check out Graphitization of the Enterprise (click here)
[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.

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

3 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

Tagged as Amazon, Core Entities, Entities, graph database, Leadership, Map, maps, Neo4j, Principles, relationships, Subprinciples

February 8, 2017 · 4:44 pm

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

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

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

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

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

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.

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.

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

Figure 7. ArchiMate 3.0 Relationship Matrix Resolution Process

The numbered steps in Figure 7. are explained below:

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

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

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

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

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:

SourceElement
TargetElement
Relation
RelativeStrength
IsInputRelation
StandardVersion
ScriptVersion

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

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

Steps 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

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

Step 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

Script 1. Merge Source and Target Element Prototypes

Step 10.2. 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):

All Business domain source and target element prototypes and all related Core and Derived relationships
All Core relationships where the source element prototype is from the Business domain
All Core relationships where the source and target element prototypes are from the Business domain
All Application domain source and target element prototypes and all related Core and Derived relationships
All Core relationships where the source and target element prototypes are from the Application domain
All Core and Derived relationships where the source and target element prototypes are from the Technology/Infrastructure domain
All Core relationships where the source and target element prototypes are from the Technology domain
All Core relationships where the source and target element prototypes are from the Technology domain and are identical to each other
All Core relationships where the source and target element prototypes are from the Technology domain and are different from each other (non-self referencing)
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)
All Core and Derived relationships where the source and target element prototypes are from the Technology domain and connected to the Node element prototype
All Core relationships where the source and target element prototypes belong to the Passive Structure aspect
All Core relationships where the source and target element prototypes belong to the Active Structure aspect
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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

Tagged as Archi, ArchiMate, Graphitization

January 25, 2017 · 4:39 pm

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

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.

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

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

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.

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 ArchiMate, Architecture Reference Models, Grouping, ModelMate, proposal, specialization

November 17, 2016 · 7:43 pm

Crossing the EA Chasm: Re-visioning the ArchiMate Specification

It’s not a typo. “Re-visioning” is the right word; one part, re-envisioning, and one part, revisioning: re-visioning of the ArchiMate 3.0 Specification.

This article presents a new architectural point-of-view for describing the ArchiMate language based on a layered architecture reference model for languages.

Motivation

Frequent feedback is that ArchiMate views are too technical and not “senior management friendly”. No enterprise architect wants to take an enterprise architecture view straight from their favorite modeling tool into a meeting with their CIO (unless their CIO is a very technical person). How can ArchiMate be customized or improved to address this?

ArchiMate often does not work well across heterogeneous or mixed-platform enterprise architectures. For example, it is difficult to work across mixed technology on-premise environments as well as heterogeneous cloud-based IaaS, PaaS, and SaaS platforms supported by a diverse complement of vendors (e.g. Microsoft Azure, Amazon WWS, IBM BlueMix, Salesforce, Google Cloud Platform, SAP, Oracle, VMware, etc.).

This situation is further complicated because none of these platform vendors document their architectures using ArchiMate. Every vendor documents their platforms and architecture reference models using their own collection of concepts, symbols, and stencils.

As of November 2016, there are approximately 3600 ArchiMate certified professionals worldwide according to The Open Group ArchiMate website (approximately 2600 ArchiMate Level 2 certifications and approximately 1000 Level 1 certifications – not accounting for overlaps). By comparison, there are approximately 730,000 Project Management Professional (PMP) professionals worldwide and, according to the OMG, “several tens of thousands of developers hold the OMG Certified UML Professional (OCUP) certification (including the updated OCUP 2 certification program)”. The implication is it should be possible to increase the broader adoption of ArchiMate beyond its current levels.

Another key motivation is to provide an architectural framework that makes it easier to understand how ArchiMate can be customized; making ArchiMate visualizations of EA models more approachable, easier to understand, and accepted by a broader audience. Customization is discussed near the end of this article.

To begin looking at how ArchiMate can be improved in terms of how it is described and how it is used, let’s start by looking at the ArchiMate 3.0 Specification and how ArchiMate is currently documented; and then, look at how the Specification can be improved (or augmented with a companion architecture reference model).

Current ArchiMate 3.0 Specification

What follows is a collection of quotations from the ArchiMate 3.0 Specification. The quotations have been annotated as follows:

Italics have been added for emphasis and to identify key words and phrases
Numbered bullets () have been added for reference purposes. A legend based on the ModelMate Information Architecture for ArchiMate (described below) appears in Appendix A.
NOTE: The numbered bullets and legend (and italicized phrases) are not part of the ArchiMate 3.0 Specification.

Annotated Excerpts from the ArchiMate® 3.0 Specification

Start of excerpts.

1 Introduction

1.1 Objective

This standard is the specification of the ArchiMate Enterprise Architecture modeling language , a visual language with a set of default iconography for describing, analyzing, and communicating many concerns of Enterprise Architectures as they change over time. The standard provides a set of entities and relationships with their corresponding iconography for the representation of Architecture Descriptions .

1.2 Overview

…

The ArchiMate Enterprise Architecture modeling language provides a uniform representation for diagrams that describe Enterprise Architectures . It includes concepts for specifying inter-related architectures , specific viewpoints for selected stakeholders, and language customization mechanisms . It offers an integrated architectural approach that describes and visualizes different architecture domains and their underlying relations and dependencies . Its language framework provides a structuring mechanism for architecture domains , layers , and aspects . It distinguishes between the model elements and their notation , to allow for varied, stakeholder-oriented depictions of architecture information . The language uses service-orientation to distinguish and relate the Business, Application, and Technology Layers of Enterprise Architectures , and uses realization relationships to relate concrete elements to more abstract elements across these layers .

…

3 Language Structure

…

3.1 Language Design Considerations

…

Figure. 1 Top-Level Hierarchy of ArchiMate Concepts

End of excerpts.

The italicized words and phrases are the key words and phrases which describe the key ideas that make up the ArchiMate language (e.g. modeling language, visual language, a default set of iconography, set of entities and relationships, etc.). The initial sections of the Specification’s Introduction (quoted above) provide a comprehensive overview of the ArchiMate language.

The numbered bullets relate the key words and phrases in the Specification’s Introduction to the ModelMate Information Architecture for ArchiMate (described later in this article).

The Specification’s Table of Contents illustrates how the current version of the specification is structured:

Preface
1. Definitions
2. Language Elements
3. Generic Metamodel
4. Relationships
5-13. Layers and Domains of language concepts further organized by Aspects
14. Stakeholders, Views, and Viewpoints
15. Language Customization Mechanisms

The approach used to describe ArchiMate can be improved.

An Alternative, Architectural Approach for Describing ArchiMate

Is there an alternative (and perhaps a better way) to describe the ArchiMate language with the goal of encouraging broader adoption, greater support, and more innovative applications of the ArchiMate language? I think there is. Let’s consider a generic architecture reference model for languages like ArchiMate.

ModelMate Information Architecture for Languages

What is the ModelMate Information Architecture for Languages? The ModelMate Information Architecture for Languages (MIAL) is an architecture reference model for analyzing and describing languages. The initial use cases are from the enterprise architecture domain but their applicability is not limited to enterprise architecture.

There are 8 primary domains in the MIAL architecture reference model (from the bottom up):

Vocabulary
Semantics
Grammar
Visual Notation
Visualizations
Descriptive Information
Overall Structure
Text Notations

For the most part, these are familiar concepts for describing most languages; technical languages in particular. These concepts are illustrated below.

Figure 2. ModelMate Information Architecture for Languages

The MIAL 8 domains have the following definitions:

Vocabulary lists the names of the nouns and verbs of the language (and possibly other language parts)
Semantics provides meanings for each of nouns and verbs
Grammar governs the composition of nouns and verbs into phrases or other constructs (phrases, sentences, paragraphs, chapters, and stories)
Separate from the Vocabulary elements themselves, a Visual Notation provides a collection of one or more graphic renderings of each individual noun and verb
Visualizations describes how the Grammar and Visual Notation can be used together to create graphical views consisting of multiple compositions of nouns and verbs (graphical phrases, sentences, and paragraphs)
Descriptive Information describes what kinds of additional descriptive information (metadata) can be used to annotate the nouns and verbs in the Vocabulary
Overall Structure of a document or model
Text Notations for serializing an ArchiMate model into XML, JSON, or native spoken language documentation, as examples

An additional list of definitions can be found in this glossary.

The MISL 8 domains are, in turn, subdivided into MIAL 10 essential elements:

Vocabulary of nouns
Vocabulary of verbs
Semantic definitions for the nouns and verbs
Grammar rules for governing the composition of nouns and verbs (grammatical structure)
Grouping and organizing constructs
Visual notation comprised of a set of graphical symbols for each noun and verb
Normative descriptions to guide the creation of visualizations based on the grammar rules and visual notation
Annotation of nouns and verbs with descriptive information (metadata)
Overall structure of a document or model
Other notations for representing the structure (e.g. text, XML, JSON, native spoken languages)

Let’s look at how this information architecture reference model can be applied to ArchiMate.

ModelMate Information Architecture for ArchiMate

What is the ModelMate Information Architecture for ArchiMate? The ModelMate Information Architecture for ArchiMate (MIAA) is an instance of the MIAL customized to serve as an information architecture reference model for the ArchiMate language.

NOTE: The ModelMate Information Architecture for ArchiMate is not part of the ArchiMate 3.0 Specification.

Below is the list of the MIAL 10 essential elements customized for ArchiMate:

Vocabulary of nouns (elements) – a vocabulary of words

Vocabulary of verbs (relationships) for relating one noun to another – another vocabulary of words

Semantic definitions for the nouns (elements) and verbs (relationships) for describing enterprise architecture models – a glossary of definitions

Grammar rules for governing the composition of elements and relationships into a model – a grammar

Collection of domains and layers for organizing the elements into several (mostly) horizontal categories (Strategy, Business, Application, Technology, Physical, Implementation & Migration) and a collection of aspects for organizing the elements across the domains into a number of vertical categories (Active Structure, Behavior, and Passive Structure) – a taxonomy

Visual notation comprised of a set of graphical symbols for each element and relationship – an iconography

Normative descriptions of views and viewpoints to guide the creation of visualizations based on the visual notation and grammar rules

Annotation of elements and relationships with descriptive information – metadata

Model structure comprised of the elements, relationships, views, and metadata enabling models of enterprise architectures to be created, analyzed and visualized – an information architecture reference model

Text-based notation (e.g. XML-based model exchange format) for describing an enterprise architecture model (a collection of elements, relationships, views, and metadata) – enabling the serialization of an enterprise architecture model based on the information architecture.

The annotated excerpts from the ArchiMate 3.0 Specification found earlier in this article unpack the text of the specification by mapping the numbered bullets found next to each of the specification’s key words and phrases to the 10 elements of the ModelMate Information Architecture for ArchiMate.

The ModelMate Information Architecture for ArchiMate is illustrated graphically in the following figure. Study this architecture reference model from the bottom up.

Figure 3. ModelMate Information Architecture for ArchiMate

Organization-Level Customization

Given the layered structure of the ModelMate Information Architecture for ArchiMate, it is straightforward to see how ArchiMate lends itself to being customized at each level of the 8 domains:

Vocabulary
Semantics
Grammar
Visual Notation
Visualizations
Descriptive Information
Overall Structure
Text Notations

Extend, Replace/Update, or Remove?

Below is an initial version of the ModelMate Information Architecture for ArchiMate customization decision matrix.

Table 1. ModelMate Information Architecture for ArchiMate: Customization Decision Matrix

The first thing to note is how the decision matrix drove forward the idea that the MIAL 8 domains can be categorized into 2 groups:

Core
Non-Core

The Core group includes the “bottom 4” domains characterized by almost no opportunity for customization. The Non-Core group includes the “top 4” domains characterized by being almost totally customizable.

Future articles will go into more depth in terms of describing how each domain in the ModelMate Information Architecture for ArchiMate can be customized.

This article is the main course; now proceed to the next course in this series: Crossing the EA Chasm: ArchiMate “Keep Calm and Have It Your Way”.

For additional thoughts on these topics, check out Crossing the EA Chasm: Reflections on the Current State of ArchiMate.

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

Appendix A – ModelMate Information Architecture for ArchiMate Legend

The following legend is based on the ModelMate Information Architecture for ArchiMate.

NOTE: This legend is not part of the ArchiMate 3.0 Specification.

Vocabulary of nouns (elements)
Vocabulary of verbs (relationships) for relating one noun to another
Semantic definitions for the nouns (elements) and verbs (relationships)
Grammatical structure governing the composition of elements and relationships
Collection of domains and layers and aspects
Visual notation (iconography) for each element and relationship
Normative descriptions of views and viewpoints
Annotation of elements and relationships with descriptive information (metadata)
Information architecture (model structure) for enterprise architecture models
Text-based notation (XML-based model exchange format) for describing an enterprise architecture model

*ArchiMate is a registered trademark of The Open Group.

12 Comments

Filed under ArchiMate, Architecture Reference Models, Definitions, Enterprise Architecture, How do we think, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, The Open Group

Tagged as customization, grammar, information architecture, semantics, visual notation, visualization, vocabulary

October 4, 2016 · 8:56 pm

Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture

[Updated October 27, 2016]

In a recent posting (Crossing the Enterprise Architecture Chasm), I offered a definition for the term Enterprise Architecture Chasm, the practical gap that will always exist between enterprise architecture and an organization’s systems, strategies, assets, and processes (and the companion Strategy Chasm that exists between an organization’s motivation and strategy and its enterprise architecture).

Figure 1. Progressive Enterprise Architecture Map

In this posting, I describe the “ModelMate” project – the creation of an open EA repository software solution that assists in crossing the EA Chasm. “ModelMate” is a codename for this project (also read the p.s. at the bottom of this posting). Caveat: This posting will be somewhat technical but regardless of who you are, you’ll find the example use cases to be insightful.

Definition

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

Architecture

The ModelMate schema is modeled more or less after The Open Group ArchiMate Model File Exchange File Format (EFF) with several extensions; including support for multi-tenancy, 2D and 3D entities, 3D views of 2D and 3D entities, processing history, versioning, annotations (including usage and performance data), automated heat maps, replication and synchronization. Read/write access to the repository is supported using an entity-based .NET API. Importing and exporting of EFF files is fully supported. The physical repository is a highly normalized SQL Server database. Here is what the high-level ModelMate architecture looks like.

Figure 2. Use Case 1. Cloud migration of custom .NET desktop apps, services, and web applications

ModelMate can run anywhere: on your laptop, Windows server, virtual server, data center, or in the cloud; anywhere you can use SQL Server Express, SQL Server, or Azure SQL Server.

Use Case 1: Cloud migration of custom .NET desktop apps, services, and web applications

In this scenario, a .NET Entity Discovery component scans the compiled .NET executables (.EXE files) and library assemblies (.DLL files); calling the ModelMate API to create a model in the ModelMate repository. A separate component uses the EFF Exporter capability to read the ModelMate model and create an EFF file containing the model data. In this specific scenario, Archi was used to read the ModelMate model and support real-time exploration of the .NET application’s architecture. At this point in the project, views are being created manually but highly facilitated by the design of the model and Archi’s Visualizer and Navigation features. Here’s a sample of a view created from the resulting ModelMate model as well as a screenshot of what the actual dual-screen user experience looks like.

This slideshow requires JavaScript.

Figure 3. VetContext ModelMate Model imported into Archi

The broader use case is system analysis and assessment to support migration of on-premise custom .NET desktop, service and web applications to the cloud.

The above model is large; containing:

190,000 properties and values
25,000 labels
16,000 relationships
8,700 elements

The EFF file is 52MB in size;. the resulting Archi .archimate file, 34MB in size.

Because ModelMate models are based on the EFF file format, any EFF compatible modeler such as BiZZdesign Enterprise Studio or SPARX Enterprise Architect can also be used.

This slideshow requires JavaScript.

Figure 4. VetContext ModelMate Model imported into SPARX Enterprise Architect

SPARX EA’s automated layout and routing capabilities proved to be quite valuable – especially when the burden of importing extremely large numbers of elements and relationships into any of these tools is reduced to a few mouse clicks.

Use Case 2: Support for COTS (commercial-off-the-shelf) Business Intelligence tools

Because the ModelMate Repository schema is based on the EFF format (with extensions) and is realized as a SQL Server database, it is easy to produce any myriad of visualizations and perform analysis using easily-available COTS and open source tools such as Microsoft Power BI interactive data visualization tools, and the R language for statistical computing. Detailed examples with be added to this article over the next few weeks.

Figure 5. ModelMate Logical Architecture

Given the enormous user communities and large libraries of user-contributed data analysis, machine learning, and visualization components available for each of these platforms (as well as Power BI’s support for R), there are no limits to what you can do with a ModelMate model.

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

p.s. At this point, there are no specific plans to commercialize the ModelMate project but if you think ModelMate can help make what you’re trying to accomplish a bit easier to realize, please email me at mwherman@parallelspace.net.

* ArchiMate is a registered trademark of The Open Group

10 Comments

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Definitions, Enterprise Architecture, ModelMate

Tagged as chasm, Enterprise Architecture Chasm, entity, Exchange File Format, Repository, Strategy Chasm

May 9, 2016 · 3:00 pm

How We Think About How We Work

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

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

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

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

Progressive Improvement through Continuous Transformation (and Learning)

Progressive Improvement & Learning Process (PILP)

Continuous Transformation Process (CTP)

Deliverable Review

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

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

Content Purpose

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

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

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

Intended Audience Statement (Example)

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

Michael Herman’s Hierarchies

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

Product Management: 3 Prioritization Levels

Need to have
Nice to have
*Neat* to have

Scalability Levels

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

5 Comments

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

Tagged as continuous transformation, icrva, Process, progressive, progressive improvement, RACI, transformation

April 12, 2016 · 1:34 pm

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

Subtitle: Fusing Enterprise IoT and Traditional Enterprise Architecture

Context

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

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

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

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

Discussion

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

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

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

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

“More news at 11…”

Michael Herman (Toronto)

4 Comments

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

Tagged as Ecosystem IoT, enterprise graph, Enterprise IoT, External IoT, Internal IoT, IoT, IoT Landscape

April 6, 2016 · 10:13 pm

Glossary Glossary: Controlled Vocabulary, Dictionary, Glossary, Grammar, Taxonomy, Folksonomy, Ontology, Semantic Network, Knowledge Graph

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

Glossary Glossary

Controlled Vocabulary (Vocabulary) – list of distinct, selected terms or keywords

Dictionary or Glossary – a vocabulary with definition(s)

Grammar – a set of structural rules governing the composition of clauses, phrases, and words in any given language

Taxonomy – terms from a vocabulary, dictionary or glossary that are structured or organized by a classification system that is most often hierarchical in nature (but this is not a requirement).

Folksonomy – terms from a vocabulary, dictionary or glossary are categorized by a set of users’ tags or keywords.

Ontology, Semantic Network, Knowledge Graphs – superset of capabilities relative to a taxonomy that includes properties (with or without data types) as well as potentially arbitrary interrelationships; a set of types, properties, and relationships.

Good (complete) references:

5 Comments

Filed under Definitions

Tagged as classification, Controlled Vocabulary, Dictionary, Folksonomy, Glossary, grammar, Knowledge Graphs, Ontology, relationships, Semantic Network, taxonomy

	Microsoft Windows… on “Truly Collaborative Bus…
	Web 7.0 AgenticOS™:… on Microsoft Windows “Longh…
	Web 7.0 Agentic OS:… on The AUSOM Application Design…
	Web 7.0 Agentic OS:… on “Truly Collaborative Bus…
	Web 7.0 Agentic OS:… on Windows 1.0 SDK Samples: …

	Microsoft Windows… on “Truly Collaborative Bus…
	Web 7.0 AgenticOS™:… on Microsoft Windows “Longh…
	Web 7.0 Agentic OS:… on The AUSOM Application Design…
	Web 7.0 Agentic OS:… on “Truly Collaborative Bus…
	Web 7.0 Agentic OS:… on Windows 1.0 SDK Samples: …

Category Archives: Definitions

Amazon Leadership Principles, Core Entities, and Relationships

Personal Leadership Principle Maps

Next Steps for Iteration 2

References

Appendix A – Amazon Leadership Principles (and Subprinciples)

Appendix B – Amazon Leadership Principles

Leadership Principles

Customer Obsession (1)

Ownership (2)

Invent and Simplify (3)

Are Right, A Lot (4)

Learn and Be Curious (5)

Hire and Develop the Best (6)

Insist on the Highest Standards (7)

Think Big (8)

Bias for Action (9)

Frugality (10)

Earn Trust (11)

Dive Deep (12)

Have Backbone; Disagree and Commit (13)

Deliver Results (14)

Share this:

Share this:

Share this:

1 Introduction

1.1 Objective

1.2 Overview

3 Language Structure

3.1 Language Design Considerations

Share this:

Share this:

Progressive Improvement through Continuous Transformation (and Learning)

Progressive Improvement & Learning Process (PILP)

Continuous Transformation Process (CTP)

Deliverable Review

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

Content Purpose

Intended Audience Statement (Example)

Michael Herman’s Hierarchies

Product Management: 3 Prioritization Levels

Scalability Levels

Share this:

Share this:

Glossary Glossary

Share this:

Recent Posts

Categories

Meta

Archives

Recent Comments