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

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

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.

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.

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

Appendix B – Amazon Leadership Principles

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-qualityproducts, 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 breedresourcefulness, 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.

MMOR (pronounced “more”) is an online, queryable version of an updated, corrected version of the ArchiMate 3.0 relationship matrix – originally described in the article The Graphitization of ArchiMate.

This article provides an overview – a teaser, actually. I’m working on a more in-depth description that I’ll publish next week. HINT: If you poke around on hyperonomy.com – digital intelligence, you’ll find the “WIP” draft.

The above app url, username and password provide you with read-only access to the MMOR graph database – you can’t hurt anything. Please go ahead and try it using some of the sample queries I’ve documented below.

CAVEAT: There are zero guarantees on my part in terms of the availability, reliability, or performance of this hosted solution. I’ll be making changes with no advance notice.

Copy & paste each query (one at a time) into the query box (next to the ‘$’ sign)

Click the “Play” icon to run the query

Figure 1. Copy & paste each query (one at a time) – then click Play (click to enlarge)

TIP: After you’ve run your first query, in the bottom-right corner of the visualization, turn Auto-Complete to the Off position by clicking on the icon.

Figure 2. TIP: Turn Auto-Complete to the Off position

Sample Query A: Node Prototype, Technology Landscape View

Return and visualize the relations in the MMOR where the source element is a Node and the (source and) target elements are members of the Technology domain, both Core as well as Derived relations are included, and the source and target elements are different (i.e. ignore self-referencing element relations).

NOTE: The black arcs are Core relations; the red arcs are Derived relations. In the current version of the MMOR, there’s approximately an order of magnitude more Derived relations vs. Core relations.

NOTE: In Figure 3, note the use the ModelMate convention for naming relations based on a specific verb taxonomy that immeasurably improves the readability, a Stakeholders’ opportunities for further reflection and refinement, and the composability of higher-level Domain-Specific Languages (DSLs) for enterprise architecture based on using ArchiMate as a lower-level intermediate language:

NOTE: It may look pretty but it’s not very useful from a functional perspective. To fix this, try grabbing the Passive Structure elements and dragging them to the left; the Active Structure elements, moving them to the right. The Behavior elements can be left in the middle. They will act as if they are connected to the Passive and Active Structure elements by elastics or springs. You can also manually position the Behavior elements similar to what you did with the Structure elements. Go ahead and try it for yourself.

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:

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:

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.

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

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.

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

SourceElement

TargetElement

Relation

RelativeStrength

IsInputRelation

StandardVersion

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:

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.

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.

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

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

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

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

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

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

Graphitizing the ArchiMate Relationship Table

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

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

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

Recreating a Rendering of Gerben’s PDF

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

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

The initial graph looked like this:

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

More importantly, I can now answer questions like:

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

Table 1. Proposed List of Verbs to Augment or Replace
the Current ArchiMate 3.0 Relationship Names

An interesting observation: Note the verbs that start with “Is*”. They appear in either the “Source-Target” (ForwardVerb) or the “Target-Source” (ReverseVerb) columns but not both for a given relationship. This wasn’t deliberate – this is just the way it turned out. Does this indicate anything about which direction is the natural direction for the relationship to point to?

What do you think of this proposal? Please post a comment below, email me, or post a reply in the LinkedIn ArchiMate group.

To learn more about the background and history of this proposal, check out:

Move beyond digitalization of the enterprise to graphitization of the enterprise. Here’s a great diagram that explains this concept. (click on the diagram to enlarge it)

Figure 1. The New Model of IT

Graphitization of not only all of your corporate information assets across all of your constituencies and stakeholders – at the data, application entity, and business object level – but also the graphitization of all of the interconnections between every business process, application system, infrastructure component, cloud service, vendor/service provider, and business role that uses, manages, or stores corporate information (Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2).

Use graphitization to make your existing corporate information more available, more usable, and more informative. Graphitization enables you to “Keep Calm and Have IT Your Way“.

What is #Graphitization?

#Graphitization is a data science and enterprise architecture-inspired framework and process model for modeling, ingesting, organizing, analyzing, and visualizing any domain of endeavor by using graphs – networks of connected objects and relationships with each object and relationship annotated with additional descriptive information (metadata).

The primary applications of #Graphitization are:

System optimization,

Systems life cycle management, and

Transformative Change in resulting in positive increases in business value for the system being studied.

A system is defined as any collection of strategies, system components, assets, architectures or processes.

Using #Graphitization

Use graphitization of your organization to help close both the Enterprise Architecture Chasm and the Operational Data Chasm. See below.

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

Iteration 2 is a small iteration that had a goal of improved key phrase-based exploration and visualization of The Principles of Ray Dalio. This iteration builds on the ModelMate model of The Principles described earlier in this series: #Graphitization of Ray Dalio’s Principles: Iteration 1 and represents a significant improvement in terms of understanding which principles are realized by specific combinations of key phases.

Iteration 2 uses the same query used in Iteration 1. This time, the Linkurious graph visualization app is used to display the subgraph of all Topics, Principles, Subprinciples, Commentary, Questions, etc. directly or indirectly related to the key phrases “radically” and “transparent”. This concept is represented by the following simple query:

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

Background

Ray Dalio is Chairman & Chief Investment Officer at Bridgewater Associates, L.P., the world’s largest hedge fund, and is well known for The Principles that he and his colleagues at Bridgewater use to govern themselves and each other. Mr. Dalio has published the 200+ Principles in a 123-page document and made the content publically available on a dedicated website: Principles by Ray Dalio (“The Principles”). Here is his description of The Principles…

“What is written here is just my understanding of what it takes: my most fundamental life principles, my approach to getting what I want, and my “management principles,” which are based on those foundations. Taken together, these principles are meant to paint a picture of a process for the systematic pursuit of truth and excellence and for the rewards that accompany this pursuit. I put them in writing for people to consider in order to help Bridgewater and the people I care about most.”

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

That is, why not try to turn The Principles into a computer model that documents each Principle, its hierarchical inter-relationships, and, via some sophisticated cloud-based text analysis services, visualize all of the important interconnections based on a set of computer-chosen key phrases?

This article documents Iteration 1 of the #Graphitization of Ray Dalio’s Principles.

Wisdom in, Wisdom out

Today, there are several easy-to-use technologies that enable developers to view web pages as sophisticated databases. The Principles website (a single web page) is no exception.

A simple query like the one below makes it is easy to exact the hierarchy of Sections, Topics, Principles, Subprinciples, Summary Paragraphs, Questions, Bullets, Figures, etc. from The Principles using a single statement.

Figure 1. The Principles Web Page Query

A sample portion of The Principles web page appears below and has the following structure:

“To Get The Culture Right…” is a Section. There are 4 Sections at the top level of the Publication.

“TRUST IN TRUTH” is a Topic and it is also a numbered Principle.

“Realize that you have nothing to fear from truth.” is a numbered Principle.

Topics, Principles, and Subprinciples are numbered sequentially; there is no hierarchical numbering scheme.

Figure 2. Web Page Sample: The Principles By Ray Dalio

In my ModelMate model for The Principles, 3 classes of key phrases are used to cross-index each Topic, Principle, Subprinciple, etc.

Key Topics – short phrases deemed to be particularly relevant and interesting across the entire document (i.e. the corpus)

Key Phrases – short phrases deemed to be of particular importance within the scope of a single title, paragraph of text, question, or bullet.

Other Phrases – additional key phrases chosen because they are particularly relevant to Bridgewater, Mr. Dalio, and The Principles.

In total, there are 2470 key phases; about 200 of these are Key Topics selected by a cloud-based text analytics service, about 300 are Other Phases. The remaining Key Phrases (with a few overlaps) were selected by a different text analytics service that was run against the text of each individual Topic, Principle, Subprinciple, etc.

A sample of the ingested The Principles web page content looks like the following (click to enlarge):

Figure 3. Ingested Web Page

Results of Iteration 1

The entire structure and content of The Principles was ingested during Iteration 1 of this project:

The sample queries below highlight The Principles that are related to 2 critically important concepts at Bridgewater: “radically” and “transparent” (including all words that have these words as reasonable root words).

The single line queries found all artifacts that were in some way related to the 2 key phases; then calculated the traceability up to through to the top (beginning) of The Principles (click to enlarge).

Figure 4. All Topics, Principles, Subprinciples, etc. with Traceability to the Key Phases “radically” and “transparent”

The large orange dot represents the top (the root of the web page). The large blue dots represent the 4 top-level Sections in The Principles:

Figure 5 (below) includes some exploration (expansion) of Principal 2. Realize that you have nothing to fear from truth.

Figure 5. Principal 2. Realize that you have nothing to fear from truth.

Conclusions

In the end, extending the ModelMate platform to support the above produced more learning than what I’ve been able to glean from subsequent exploration of the #Graphitization of The Principles. Perhaps someone with more familiarity with The Principles can contact me with some interesting use cases. I’m extremely curious to derive more value from this model

This work on this project was made infinitely easier through the use of the ModelMate platform (powered by the Neo4j graph database).

It is very interesting to read the above HBR article and then reflect on the current state of the ArchiMate language for Enterprise Architecture. Here are a few quotes from the article (as well as a few homework questions).

Best wishes for the New Year (modeled as a Principal, Driver, Goal, or Constraint? :-))

Here are 5 quotes from the HBR article:

“Perfecting and polishing a message matters less than how it’s reflected and refined by the intended audiences.”

Does ArchiMate support reflection and refinement in the minds of stakeholders? What needs to be changed/improved? What are the useful qualities needed for a language to support reflection and refinement in the minds of stakeholders (reflection and refinement by the stakeholders themselves)?

“One of the greatest obstacles in promoting more proactive, pro-user initiatives, she quickly discovered, was that her people were prisoners of their existing vocabulary. They interpreted her calls for customer obsessiveness by intensifying existing efforts rather than discussing or describing new ways to add new value.”

Is this also a description of ArchiMate’s current state? Are we stuck in a deepening “hole of hieroglyphics”? [link] Are we prisoners of ArchiMate’s existing vocabulary?

“Microsoft’s Satya Nadella, for example, has been linguistically maneuvering from a proprietary Windows/Office software legacy to cloud computing, platform, and open systems contexts. Machine learning, for example, is now as integral to Microsoft’s new value vocabulary…”

Is Machine Learning part of the ArchiMate vocabulary? …maybe …early stage at best. Does ArchiMate resemble an open technology environment for fostering innovation in enterprise architecture?

“Entrepreneurial founders, of course, have both semantic and rhetorical advantages over their successors in this regard. A company’s creator disproportionately owns and influences its vocabulary.”

This quote has 2 edges represented by each of these 2 sentences. Food for thought.

“Understanding the importance of being understood is what makes great CEOs great communicators.”

This also applies to CIOs and enterprise architects. How does ArchiMate help CIOs and enterprise architects become great communicators? …or does it hinder them? How can this situation be improved?

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.

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

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

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

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

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.

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.