Category Archives: How do we think

Tokenize Every Little Thing (ELT)

[Since first writing this article in January 2018, I’ve concluded that Ethereum is not capable of being a platform for Tokenizing Every Little Thing. Ethereum is a one-trick pony x 1500 when it comes to creating large-scale decentralized applications (i.e. Ethereum/Solidity smart contracts are best for creating single, simple entities like alt-coins). Checkout slide 56 of this presentation: NEO Blockchain Vancouver 20180315 Meetup. The NEO Blockchain and NEO Smart Economy is the best available 3rd generation distributed application platform on the planet and improving every day. Michael Herman, March 17, 2018]

[Also checkout the webcast The NEO Smart Economy, Smart Processes, and Smart Data. Michael Herman, April 9, 2018]


 

Just over one year ago, I introduced the concept of graphitization and talked about #Graphitization of the Enterprise. I opened the article with the challenge:

Move beyond digitalization of the enterprise to graphitization of the enterprise.

For 2018 and beyond, the challenge is simpler but more difficult:

Tokenize Every Little Thing (ELT)

To provide more context, let me first quote from the introductory paragraphs of the #Graphitization article.

Here’s a great diagram that explains this concept [graphitization]. (click on the diagram to enlarge it)

graphitization-new-world-of-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).

Why #Tokenization?

Given the burgeoning preoccupation of the world’s business, finance, government, and technology sectors with blockchain technologies, cryptocurrencies, and token-this and token-that, the buzzword for 2018 will be #Tokenization …the creation of tokens (multiple versions of tokens) to represent every thing on the planet …Every Little Thing (ELT).

While individuals, startups and larger organizations are trying to dream up the next big, one-off, token or crytocurrency, why not just admit that, “in the end”, everything will be represented by a token?

Why try to knock these off one at a time (e.g. Bitcoins, Ethers, altcoins, CryptoKitties, letters of credit, auctions, escrow agreements, electronic health records (EHR), electronic medical records (EMR), etc.) when the ultimate goal to to create a universal interconnected graph of ELT (Every Little Thing) in the universe?

Why #graphitize the enterprise when you can #tokenize the universe?

What is #Tokenization?

Let’s get a little computer-sciency for just a minute. A common task to to take an input stream (a string of characters, a stream of data, a data file or database table), analysis it, and convert it into a collection or sequence of higher-level tokens for further analysis (a process that can be applied recursively). Here’s an explanation from Wikipedia

In computer science, lexical analysis, lexing or tokenization is the process of converting a sequence of characters (such as in a computer program or web page) into a sequence of tokens (strings with an assigned and thus identified meaning). A program that performs lexical analysis may be termed a lexer, tokenizer, or scanner… [https://en.wikipedia.org/wiki/Lexical_analysis]

…and later in the same Wikipedia article…

Tokenization

Tokenization is the process of demarcating and possibly classifying sections of a string of input characters. The resulting tokens are then passed on to some other form of processing. [https://en.wikipedia.org/wiki/Lexical_analysis#Tokenization]

Coming up for air… Why not represent ELT that happens in the universe as a stream of blockchain transactions?

  • the events in your life?
  • everything that occurs during a Presidential election?
  • the 24-hour cycle of one day changing into the next?
  • the activity-by-activity and task-by-task execution of a business process?
  • a stream of events from your Internet-of-Things (IoT) enabled car, toaster or refrigerator?

Jim Gray and TerraServer

In one of his several presentations on Scalable Computing (circa 1999), Jim Gray (relational database pioneer and Turing Award winner) describes the TerraServer project in the following way:

[Users navigate] an ‘almost seamless’ image of earth.

SkyServer was a similar project quarterbacked by Gray:

TerraServer allowed access to newly-available satellite imagery with resolution of 1.5 meters/pixel. SkyServer, a collaboration with Alexander Szalay and his colleagues at Johns Hopkins, allowed access to astronomical data from the Sloan Digital Sky Survey. SkyServer led to additional work with astronomical data, … [https://amturing.acm.org/award_winners/gray_3649936.cfm]

Tokenize Every Little Thing

With the advent of blockchain technologies (in particular, the Ethereum extensible blockchain platform), why can’t we embark on a grander mission to tokenize Every Little Thing? …and including all token-pair relationships (TPRs).

What will it take?

What needs to change in the Ethereum blockchain platform? Will Ethereum be able to scale to support modeling, ingesting, organizing, analyzing, and visualizing of Every Little Thing (ELT)?

On your mark, get set, …

Best regards,
Michael Herman (Toronto)

mwherman@parallelspace.net

Other Important References

  • Gordon Bell, MyLifeBits MSR Project (early 2000’s). I remember Jim Gray telling this story but I had trouble finding a proper reference because I thought it was Gray’s story instead of Bell’s.  I now know better but I’ve already finished the above article. A Wikipedia MyLifeBits reference can be found here. YouTube videos can be found here, here, and others over here. Channel 9 videos: Part 1 and Part 2. Computerworld article (2008). Business Inside article (2016).
  • Gordon Bell’s MSR web page.

 

3 Comments

Filed under Architecture Reference Models, blockchain, Business Value, Data Science, Enterprise Architecture, Ethereum, Every Little Thing, graph database, Graphitization, How do we think, Nethereum

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

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

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

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

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

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

Figure 1. #Graphitization Continuous Transformation Model

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

#Graphitization

What is #Graphitization?

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

The primary applications of #Graphitization are:

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

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

References

#Graphitization Continuous Transformation Model

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

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

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

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

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

Standards

NEO Enhancement Proposal (NEP) Standards Author

Projects and Publications

0. SerentityData Graph

Model-based off-chain and on-chain (blockchain) graph data creation, migration, visualization, and analysis

Abstract

SerentityData Graph is an entity-relationship modeling, serialization, and graph analysis solution that supports development of traditional full-stack and blockchain smart contract applications. SerentityData features tight Neo4j integration for on-chain & off-chain graph data visualization and analysis.

Description

SerentityData Graph is an open source, entity-relationship modeling, serialization, and graph data visualization and analysis solution that supports the development of traditional full-stack, blockchain-based smart contract, and Neo4j graph database applications.

Starting from a single data model, SerentityData supports the automatic code generation of entities and relationships that support symmetric development of: (a) off-chain data in traditional multi-tier full-stack applications, (b) on-chain data management for blockchain-based distributed ledger technology apps (dApps), and (c) Neo4j enterprise graph applications.

SerentityData features complete life-cycle integration with Neo4j for on-chain and off-chain graph data creation, migration, visualization, and analysis. Live code walk-throughs and demonstrations will enable you to begin using SerenityData and Neo4j immediately. Github: https://github.com/mwherman2000/serentitydata-compiler

Resources

My blog: https://hyperonomy.com/

Related blog posts

  1. Michael Herman, Blockchain Developer, Enterprise Architect and Data Scientist: #Graphitization Inventor https://hyperonomy.com/2017/05/18/michael-herman-inventor-of-graphitization/
  2. #Graphitization of the Enterprise https://hyperonomy.com/2017/01/02/graphitization-of-the-enterprise/
  3. Tokenize Every Little Thing (ELT) https://hyperonomy.com/2018/01/24/tokenization-of-every-little-thing-elt/
  4. #Graphitization of .NET Applications: Marrying Open EA Data with Graph Databases https://hyperonomy.com/2016/10/19/crossing-the-ea-chasm-marrying-open-ea-data-with-graph-databases/
  5. #Graphitization of Ray Dalio’s Principles: Iteration 1 https://hyperonomy.com/2016/12/29/graphitization-of-ray-dalios-principles/
  6. #Graphitization of Ray Dalio’s Principles: Iteration 2 https://hyperonomy.com/2016/12/30/graphitization-of-ray-dalios-principles-iteration-2/
  7. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 1 https://hyperonomy.com/2017/01/17/crossing-the-ea-chasm-graphitization-of-archimate-3-0/
  8. Crossing the EA Chasm: #Graphitization of ArchiMate 3.0 – Iteration 2 https://hyperonomy.com/2017/02/08/crossing-the-ea-chasm-graphitization-of-archimate-3-0-iteration-2/
  9. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #1 https://hyperonomy.com/2016/10/22/crossing-the-ea-chasm-automating-enterprise-architecture-modeling/
  10. Crossing the EA Chasm: Automating Enterprise Architecture Modeling #2 https://hyperonomy.com/2016/11/04/crossing-the-ea-chasm-automating-enterprise-architecture-modeling-2/
  11. Crossing the EA Chasm: ArchiMate “Keep Calm and Have IT Your Way” https://hyperonomy.com/2016/11/17/crossing-the-ea-chasm-archimate-have-it-your-way/
  12. Crossing the EA Chasm: Open Repository Strategies for Enterprise Architecture https://hyperonomy.com/2016/10/04/the-ea-chasm-open-repository-strategies-for-enterprise-architecture/
  13. Crossing the EA Chasm: Enterprise Architecture Diagrams Your Grandmother (and CIO) Will Love https://hyperonomy.com/2016/10/13/archimate-diagrams-your-grandmother-and-cio-will-love/
  14. #Graphitization of ArchiMate: Getting MMOR from ArchiMate using the ModelMate Master Online Repository https://hyperonomy.com/2017/02/10/crossing-the-ea-chasm-how-to-use-the-modelmate-online-repository-mmor/
  15. #Graphitization of the Amazon Leadership Principles (introducing Personal Leadership Principle Maps) – Iteration 1 https://hyperonomy.com/2017/05/08/amazons-principles/
  16. What are the differences between improving the design (and operation) of an aircraft engine, a muscle car, a large enterprise, and/or an integrated commercial global cloud services platform …all running at hyperscale? https://hyperonomy.com/2017/04/10/whats-the-difference-between-improving-the-design-and-operation-of-an-aircraft-engine-a-muscle-car-a-large-enterprise-and-a-commercial-global-cloud-services-platform/

Live Neo4j Models

  1. http://hobby-icgaeohcoeaggbkeabhldpol.dbs.graphenedb.com:24789/browser/ Userid: ModelMate_Master_Datasets10 Password: YqeZAH4ODEJqglkEsK5p

YouTube Channel: https://www.youtube.com/playlist?list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5

  1. 12. NEO Persistable Classes (NPC) Platform 2.1: Preview https://www.youtube.com/watch?v=N-jiJOZwiFg&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=5
  2. NEO Persistable Classes (NPC) Platform 2.0: Deep Dive https://www.youtube.com/watch?v=Nj4-m2o94VE&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=6
  3. NEO Persistable Classes 1.0: Deep Dive (Video 2 of 3) [Update 1] https://www.youtube.com/watch?v=qwteL1BiCjM&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=7
  4. NEO Persistable Classes Platform 2.2: Structured Storage & Reusable, Indexed, Non-Fungible Entities https://www.youtube.com/watch?v=vnAxyCAZ1ec&list=PLU-rWqHm5p46bIDXPNf4c2JP_AOkopnV5&index=10

Related Github Projects

  1. SerentityData Entity Compiler (serentitydata-compiler) https://github.com/mwherman2000/serentitydata-compiler/blob/master/README.md
  2. NEO Persistable Classes (NPC) Compiler 2.1 (npcc) – Compiler for the NEO Persistable Classes (NPC) Platform 2.1 https://github.com/mwherman2000/neo-npcc2
  3. NEO Persistable Classes V1.0 – An Efficient Object-Oriented Framework for C#.NEO Smart Contract Development (ORIGINAL) – https://github.com/mwherman2000/neo-persistibleclasses

Recognition

  1. NeoDraw – NEO Persistable Classes Platform 2.0: NEO-Microsoft dApp Competition (4th place prize – USD$15,000) – https://neo.org/blog/details/3074 and https://neo.org/awards.html

Keywords

  • blockchain on-chain data modeling symmetric programming data management .NET C# NEO Stratis Ethereum Technical Case Study Developer Best Practices

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

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

  • Business Architecture
  • Application Architecture
  • Technology/Infrastructure Architecture

References

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

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

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

References

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

3. Commercial, global-scale, cloud services platforms

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

References

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

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

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

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

References

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

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

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

6. Large ecosystems of competing or competitive business organizations

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

7. Organization principles and belief systems

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

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

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

References

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

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

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

References

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

9. International standards for visual modeling languages

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

ArchiMate References

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

10. Enterprise Data Management

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

References

  1. RE: Managing Master Data With ArchiMate

11. Parallelspace ModelMate

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

References

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

12. Internet of Things (IoT)

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

References

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

13. Architecture Reference Models (ARMs)

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

References

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

General References

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

Best regards,

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

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

  • ArchiMate is registered trademark of The Open Group.

1 Comment

Filed under ArchiMate, Architecture Reference Models, Automated Application Architecture Analysis, Automated Enterprise Architecture Modeling, Graphitization, How do we think, Microsoft Azure, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

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

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

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:

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

This article is structured as follows:

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

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

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

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

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

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

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

Enjoy.

Amazon Leadership Principles, Core Entities, and Relationships

The text of the Amazon Leadership Principles references specific:

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

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

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

Concrete Entities include:

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

Abstract Entities include:

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

Relationships include:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This slideshow requires JavaScript.

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

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

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

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

Personal Leadership Principle Maps

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

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

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

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

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

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

Specific evidence includes:

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

Next Steps for Iteration 2

Possible next steps include:

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

References

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

Appendix A – Amazon Leadership Principles (and Subprinciples)

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

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

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

Figure 6. Amazon’s Principles (and Subprinciples)

Appendix B – Amazon Leadership Principles

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

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

Leadership Principles

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

Customer Obsession (1)

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

Ownership (2)

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

Invent and Simplify (3)

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

Are Right, A Lot (4)

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

Learn and Be Curious (5)

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

Hire and Develop the Best (6)

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

Insist on the Highest Standards (7)

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

Think Big (8)

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

Bias for Action (9)

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

Frugality (10)

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

Earn Trust (11)

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

Dive Deep (12)

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

Have Backbone; Disagree and Commit (13)

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

Deliver Results (14)

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

Best regards,

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

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

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

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

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

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

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

Answer: None.

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

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

Continuous Transformation 2

Figure 1. Continuous Transformation Model: Aircraft Engines and Muscle Cars

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

Continuous Transformation 1.png

Figure 2. Continuous Transformation Model: Smart Cities, Large Enterprises, and Cloud Services Platforms

Diving Deeper: #Graphitization

To go deeper, checkout #Graphitization of the Enterprise (click here) as well as the list of references below.

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

Figure 3. #Graphitization Continuous Transformation Model

 

progressive-ea-model-1-0-11-peam5-1010

Figure 4. Continuous Transformation Framework: Process Groups and Activities

References

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

Best regards,

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

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

1 Comment

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

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

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

Feel free to contact me at:

PARTIAL PORTFOLIO

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

Microsoft Live Communications Server

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

Microsoft SharePoint Products and Technologies

Client: Microsoft Corporation SharePoint Product Group / Microsoft IT Showcase

Microsoft Exchange Server

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

Metalogix Replicator for SharePoint

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

Microsoft “Alchemy”

Client: Microsoft Web Services Product Group / Microsoft IT Showcase

Parallelspace Vulture

Client: Parallelspace Corporation

Tzunami K-Wise Deployer

Client: Tzunami

Leave a comment

Filed under ArchiMate, Architecture Reference Models, Crossing the EA Charm, Enterprise Architecture, Enterprise Architecture Chasm, Graphitization, How do we think, ModelMate Information Architecture for ArchiMate, ModelMate Information Architecture for Languages

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

#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

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

Introduction
1.1 Objective

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

1.2 Overview

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

Language Structure

3.1 Language Design Considerations

image002.png

Figure. 1 Top-Level Hierarchy of ArchiMate Concepts 0102030509

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.

modelmate-information-architecure-for-languages-3-0-5-overview

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:

  1. Vocabulary of nouns
  2. Vocabulary of verbs
  3. Semantic definitions for the nouns and verbs
  4. Grammar rules for governing the composition of nouns and verbs (grammatical structure)
  5. Grouping and organizing constructs
  6. Visual notation comprised of a set of graphical symbols for each noun and verb
  7. Normative descriptions to guide the creation of visualizations based on the grammar rules and visual notation
  8. Annotation of nouns and verbs with descriptive information (metadata)
  9. Overall structure of a document or model
  10. 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:

01 Vocabulary of nouns (elements) – a vocabulary of words

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

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

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

05 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

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

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

08 Annotation of elements and relationships with descriptive information – metadata

09 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

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

modelmate-information-architecure-for-archimate-3-0-3

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.

mial-for-archimate-1-0-1

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.

01 Vocabulary of nouns (elements)
02 Vocabulary of verbs (relationships) for relating one noun to another
03 Semantic definitions for the nouns (elements) and verbs (relationships)
04  Grammatical structure governing the composition of elements and relationships
05 Collection of domains and layers and aspects
06 Visual notation (iconography) for each element and relationship
07 Normative descriptions of views and viewpoints
08 Annotation of elements and relationships with descriptive information (metadata)
09 Information architecture (model structure) for enterprise architecture models
10 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

How We Think About How We Work

Copyright (c) 2016 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).

Michael Herman (Toronto)

Progressive Improvement through Continuous Transformation

Progressive Improvement thru Continuous Transformation 1-0-1

Progressive Improvement & Learning Process (PILP)

Progressive Improvement A 1-0-1

Progressive Improvement B 1-0-1

Continuous Transformation Process (CTP)

Parallelspace Continuous Transformation 2-0-1

Deliverable Review

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

Parallelspace ICRVA v12-0-2

Parallelspace ICRVA v12-0-2 Complete

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

  1. Awareness (An Overview of what is being described (Information))
  2. Knowledge (The “What” of what is being described)
  3. Understanding (The “How” of what is being described)
  4. Wisdom (Deep Knowledge and Understanding acquired through Experience)

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 – Wisdom
  • Dream – Desire – Want – Need
  • Sensing – Learning – Training – Experiencing
  • Keywords – (Controlled) Vocabulary – Glossary – Dictionary – Taxonomy – Ontology

Michaels Hierarchies

Product Management: 3 Prioritization Levels

  1. Need to have
  2. Nice to have
  3. *Neat* to have

Scalability Levels

hyper-scalability-1-0-1

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

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