January 25, 2017 · 4:39 pm

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

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

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

How do I model X in ArchiMate?

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

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

The Proposals

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

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

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

Proposal 1: Modeling of Best Practice Modeling Patterns

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

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

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

as illustrated in Figure 1 and Figure 2.

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

parallelspace_modelmate_trumpworld1

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

parallelspace_modelmate_trumpworld2

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

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

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

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

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

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

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

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

parallelspace_modelmate_bridgewater1

Figure 3. Proposal 2 Example: Bridgewater Associates

What do you think?

Please add your comments, thoughts, and questions below.

Best regards,

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

*ArchiMate is a registered trademark of The Open Group.

8 Comments

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

Tagged as , , , , ,

January 22, 2017 · 11:55 am

RE: Managing Master Data With ArchiMate

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

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

Managing Master Data With ArchiMate

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

…with the following additional clarifications:

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

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

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

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

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

modelmate-master-data-management-parallelspace4

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

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

My Thought Process

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

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

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

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

Homework: Data Lakes

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

That’s my 2 cents (Canadian). 🙂

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

*ArchiMate is a registered trademark of The Open Group.

2 Comments

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

Tagged as , , , , ,

January 20, 2017 · 7:37 am

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

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

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

Basic Concepts: Nouns and Adjectives

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

  • Model,
  • Concept

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

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

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

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

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

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

  • Element_ModelMate30_Parallelspace
  • BehaviorElement_ModelMate30_Parallelspace

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

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

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

  • Element_ModelMate30_Parallelspace
  • BusinessElement_ModelMate30_Parallelspace
  • InternalActiveStructureElement_ModelMate30_Parallelspace

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

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

Windows Server Windows Service Example

TODO

1 Comment

Filed under Uncategorized

January 17, 2017 · 11:44 am

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

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

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

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

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

Background

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

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

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

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

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

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

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

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

Graphitizing the ArchiMate Relationship Table

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

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

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

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

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

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

Recreating a Rendering of Gerben’s PDF

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

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

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

The initial graph looked like this:

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

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

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

More importantly, I can now answer questions like:

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

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

Please post your feedback, questions, and comments below.

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

*ArchiMate is a registered trademark of The Open Group.

3 Comments

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

Tagged as ,

January 13, 2017 · 3:12 pm

Crossing the EA Chasm: Re-visioning ArchiMate 3.0 Relations as Verbs

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

[Updated: February 6, 2017]

In the article Crossing the EA Chasm: Re-visioning the ArchiMate Specification, I proposed a new architectural framework for re-visioning the current ArchiMate 3.0 Specification.

In this article, I propose using the following list of verbs to either augment or replace the existing ArchiMate relationship names in the Specification and move towards a more humane, more understandable, more usable, and more acceptable language for enterprise architecture.

modelmate-relationship-verbs-2017-02-06

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

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

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

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

Best regards,
Michael Herman (Toronto)
Parallelspace Corporation

mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

3 Comments

Filed under ArchiMate, Architecture Reference Models, Business Value, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, ModelMate, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages, The Open Group

Tagged as , , , , , ,

January 2, 2017 · 2:25 pm

Using #Graphitization to Create Your Organization’s Digital Twin

Original title: #Graphitization of the Enterprise

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

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

Reprinted from #Graphitization of the Enterprise on LinkedIn.

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

graphitization-new-world-of-it
Figure 1. Digital Twin Model of IT

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

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

What is #Graphitization?

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

The primary applications of #Graphitization are:

  • System optimization,
  • Systems life cycle management, and
  • Transformative Change in resulting in positive increases in business value for the system being studied.

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

Using #Graphitization

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

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

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

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

Michael Herman (Calgary)
mwherman@parallelspace.net

7 Comments

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

Tagged as , , , ,

December 30, 2016 · 10:10 am

#Graphitization of Ray Dalio’s Principles: Iteration 2

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

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:

MATCH path =
 (pub:Publication_Principles_RayDalio_ModelMate)-[*]->(principle)
 -[r:HAS_KEYPHRASE]->(phrase:KeyPhase_Principles_RayDalio_ModelMate)
 WHERE phrase.Phrase CONTAINS "radical"
 OR phrase.Phrase CONTAINS "transparen"
 RETURN path;

The Principles subgraph containing all elements that are directly or indirectly related to the key phrases “radically” and “transparent” is shown below (click to enlarge).

ModelMate-Ray-Dalio-Radically Transparent.png

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

The underlying graph is implemented using the ModelMate framework and implemented using the Neo4j graph database.

Best regards,

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

7 Comments

Filed under Automated Enterprise Architecture Modeling, continuous transformation, Data Science, Graphitization, How do we think, ModelMate, Progressive Enterprise Architecture Map (PEAM)

Tagged as , , , , , , , ,

December 29, 2016 · 5:19 pm

#Graphitization of Ray Dalio’s Principles: Iteration 1

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

[If you “only want to see the pictures”, scroll down to Figure 4.]

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

Background

ray-dalioRay 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.”

I encourage you to read more of his Introduction here.

What is #Graphitization?

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

The primary applications of #Graphitization are:

  • System optimization,
  • Systems life cycle management, and
  • Transformative Change in resulting in positive increases in business value for the system being studied.

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

In the article #Graphitization of the Enterprise, I’ve provided a number of illustrations of how one field of endeavor, the continuous transformation of large enterprise organizations, can benefit from #Graphitization. My blog contains several additional examples of #Graphitization applied to traditional enterprise architecture; for example, Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2.

Why not try applying #Graphitization to something completely different?

#Graphitization of Ray Dalio’s Principles

A few weeks ago (December 22, 2016), the Wall Street Journal published an article (The World’s Largest Hedge Fund Is Building an Algorithmic Model From its Employees’ Brains) which describes Mr. Dalio’s vision for creating “The Book of the Future.”

“One employee familiar with the project described it as “like trying to make Ray’s brain into a computer.””

2 + 2 = ?  You guessed it. Why not try to graphitize part of Mr. Dalio’s brain?

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.

modelmate-ray-dalio-html-query

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.
  • Principles can contain numbered Subprinciples.
  • Topics, Principles, and Subprinciples can have (unnumbered) Summary Paragraphs, Questions, Bullets, Figures, etc.

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

Ray-Dalio-Principles-radically-transparent-web.png

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.

  1. Key Topics – short phrases deemed to be particularly relevant and interesting across the entire document (i.e. the corpus)
  2. Key Phrases – short phrases deemed to be of particular importance within the scope of a single title, paragraph of text, question, or bullet.
  3. 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):

exampledata-keyphrases

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:

  • 210 principles comprised of 768 artifacts (titles, paragraphs, questions, bullets, …)
  • 767 structural relationships
  • 2470 key phrases
  • 6126 key phrase-principle semantic relationships

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

ray-dalio-principles-radically-transparent

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:

  • To Get the Culture Right…
  • To Get the People Right…
  • To Perceive, Diagnose, and Solve Problems…
  • To Make Decisions Effectively…

The green dots are Topics; the red dots are Principles; and, the purple dots are Subprinciples. Key Phrases appear as pink dots.  The gray dots are Commentary Paragraphs, Questions, Bullets, Figures, etc.

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

ray-dalio-principles-radically-transparent-plus

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

To see a more meaningful visualization of The Principles, check out #Graphitization of Ray Dalio’s Principles: Iteration 2.

Best regards,

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

7 Comments

Filed under Automated Application Architecture Analysis, Business Value, Data Science, Graphitization, How do we think, ModelMate, Progressive Enterprise Architecture Map (PEAM), The Principles

Tagged as , , , , , ,

December 16, 2016 · 1:35 pm

Crossing the EA Chasm: Reflections on the Current State of ArchiMate

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

HBR: Great CEOs See the Importance of Being Understood

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?

For more thoughts on this topic, check out:

Best wishes for the New Year (modeled as a Principal),

Michael Herman
Parallelspace Corporation
mwherman@parallelspace.net

*ArchiMate is a registered trademark of The Open Group.

7 Comments

Filed under ArchiMate, Automated Enterprise Architecture Modeling, Crossing the EA Charm, Enterprise Architecture, ModelMate

Tagged as , , , , , , , ,

December 11, 2016 · 8:56 pm

Crossing the EA Chasm: The Surveyor

This poem is about land surveyors. It, just as easily, could be about enterprise architects, mapmakers, data scientists, bloggers, and journalists – bastions of the past, envisionaries of the future.

The Surveyor

He thrives on patterns,

his marks and monuments

transform a wilderness

and by his carefully tagged

and numbered squares,

neat roads, correction lines

and small cadastral lots

he clothes in certainty,

in geometrical designs,

man’s ancient rights.

He scans the skies,

reading some far-off star

by which he plots

meridians and makes his maps,

stitching a new-found world

into a patchwork quilt,

a net of metes and bounds,

so lands may know their own

and live in peace.

 — DON W. THOMSON

 

Best wishes for 2017. Hold on tight. It’s going to be quite a ride.

Source: http://www.surveyhistory.org/surveyor_poem.htm

1 Comment

Filed under Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm

Tagged as , , , , , ,