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

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 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. Here’s a great diagram that explains this concept. (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).

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: Process Groups and Activities

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

Best regards and best wishes for the New Year,

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

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

Web 7.0 DIDComm Agent Architecture Reference Model (DIDComm-ARM) 0.25

A Design Guide for Software Architects and Developers working on DIDComm Agent-based Software Systems

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

The Web 7.0 DIDComm-ARM whitepaper is being released publicly for the first time today.

Your comments and feedback on the DIDComm-ARM, its layered models, and Web 7.0 (seventh layer in the DIDComm-ARM) will be greatly appreciated.

You can find us on Twitter @ https://twitter.com/web7arch (hashtag #web7).

Download

Abstract

The purpose of this document is to introduce and describe the DIDComm Agent Architecture Reference Model (DIDComm-ARM) and the DIDComm Notation. The latter is a graphical modeling language used to design and model DIDComm Agent-based software systems.

The goals for this document are three-fold:

  • Better understanding of the active components of DIDComm Agent-based software systems and how these components rely on and interact with each other,
  • Introduce a new graphical modeling language, DIDComm Notation, to aid architects and developers in visualizing new architectures and designs for DIDComm Agent-based software systems, and
  • Describe a layered architecture reference model, DIDComm-ARM, to help guide the design and creation of the broadest range of DIDComm Agent-based software systems possible.

DIDComm Notation contains elements for modeling:

  • Conventional REST/HTTP clients, agents, and services
  • DID Addressable REST/HTTP clients, agents, and services
  • DIDComm clients, agents, and services
  • DIDComm agents that utilize Verifiable Credential message attachments
  • DIDComm mesh networks
  • DIDComm user agents
  • Virtual web drives and keystores

Collectively, these categories of DIDComm Notation modeling elements (and their interrelationships) define the DIDComm Agent Architecture Reference Model (DIDComm-ARM). The DIDComm-ARM contains multiple layered architecture models:

  • Layer 0 REST/HTTP Agent Model
  • Layer 1 DID Addressable REST/HTTP Agent Model
  • Layer 2 DIDComm Agent Model
  • Layer 3 DIDComm Agent with Verifiable Credential Attachments Model
  • Layer 4 DIDComm Agent Mesh Network Model
  • Layer 5 DIDComm User Agent Model (Appendix A)
  • Layer 6 Web 7.0 DIDComm Agent Architecture Model (Appendix B)

The intended audience for this whitepaper is a broad range of professionals interested in furthering their understanding of DIDComm for use in software apps, agents, and services. This 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.

The primary audience is software architects and developers designing and creating DIDComm Agent-based software systems[1].

This document is an independent work product produced by the author(s) and is neither a W3C, DIF, Sovrin Foundation, nor a ToIP work product – unofficial, official, or otherwise.


[1] At the time this document was being conceived (Winter 2022), few, if any, resources were able that focused on the needs of software architects and developers trying to design and create DIDComm Agent-based software systems.

1 Comment

Filed under Uncategorized

[OLD] DIDComm Agent Architecture Reference Model (DIDComm-ARM): A Preview

The final released version of this whitepaper can be found here:

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

The following is an excerpt from a whitepaper I’m working on. Early feedback is always welcome.

BREAKING NEWS: I’ve added some of the more recent revisions that have been made to the DIDComm-ARM to this preview post:

  • Layer 4 DIDComm Agent Mesh Network Model
  • Layer 5 DIDComm User Agent Model

Examples of these models can be found at end of the blog post.

DIDComm-ARM 6-Layer Model

Each of the DIDComm-ARM layers is illustrated using a characteristic scenario:
• Layer 0 REST/HTTP Agent: Complete Model
• Layer 1 DID Addressable Agent: Complete Model
• Level 2 DIDComm Agent: Complete Model
• Layer 3 DIDComm Agent with Verifiable Credential Attachments Model: Complete Model
• Layer 4 DIDComm Agent Mesh Network Model: Complete Model
• Layer 5 DIDComm User Agent Model: Complete Model

The layers of the DIDComm-ARM model can be organized into feature matrix based on each layer’s use of DID Addressability and DIDComm Messaging.

Figure 44. DIDComm-ARM 6-Layer Feature Matrix

Each model is described in the following sections.

Layer 0 REST/HTTP Agent Model

Figure 17. Layer 0 REST/HTTP Agent: Complete Model

Layer 0 REST/HTTP Agent model is the simplest scenario: a plain text message is transmitted “in the clear” between a REST/HTTP Client and REST/HTTP Agent. The REST/HTTP Client needs to know or determine the Internet address of the REST/HTTP Agent Receiver. In this scenario, the Internet address is determined using conventional means; a DID Registry is not used nor is it part of this scenario.

Layer 1 DID Addressable REST/HTTP Agent Model

Figure 18. Layer 1 DID Addressable Agent: Complete Model

The Layer 1 DID Addressable Agent model builds on top of Layer 0 by including a DID Registry and associating, in this scenario, a person to each of the agents and using the person’s decentralized identifier (DID) to lookup the Internet address of the Receiver REST/HTTP Agent; in this case, Bob.


Layer 2 DIDComm Agent Model

Figure 19. Level 2 DIDComm Agent: Complete Model

The Layer 2 DIDComm Agent model builds on top of the Layer 1 DID Addressable Agent model by replacing the REST/HTTP plain text messages (and protocol) with authenticated, encrypted DIDComm messages. The Sender in this scenario is ABC Grocery’s DIDComm Client; the Receiver is David’s Cabbages’ DIDComm Agent.

Layer 3 DIDComm Agent with Verifiable Credential Attachments Model

Figure 20. Layer 3 DIDComm Agent with Verifiable Credential Attachments Model: Complete Model

The Layer 3 DIDComm Agent with Verifiable Credentials Attachments model builds on top of the Layer 2 DIDComm Agent scenario by enabling the use of DIDComm Message Attachments and using this capability to attach a verifiable credential to a DIDComm Message. In this specific scenario, a purchase order verifiable credential is issued by ABC Grocery’s DIDComm Client and sent as a DIDComm message attachment to David’s Cabbages’ DIDComm Agent.

Layer 4 DIDComm Agent Mesh Network Model

Figure 43. Layer 4 DIDComm Agent Network: Complete Model

The Layer 4 DIDComm Agent Mesh Network Model builds on the previous layers of the DIDComm-ARM by replacing the point-to-point DIDComm Message routing between a client and an agent or an agent and a second agent with a graph-based message routing solution to support mesh network routing of DIDComm Messages. This model can be thought of as an extension or elaboration of the how Mediators and Relays work with the DIDComm Routing pattern (https://didcomm.org/book/v2/routing).

What do Decentralized Identifiers Identify?

A decentralized identifier should be interpreted as a unique reference or identifier to a concrete something (aka subject): a person, an organization, a business document (purchase order, invoice, etc.), an education credential, a car, a boat, a house, a software module, a deployed instance of a software module, etc.
Everything else in a decentralized identifier-based software system is addressed by dereferencing or resolving the decentralized identifier to obtain something else (e.g. a DID Document, Revocation List entry, Service Endpoint addresses (via a second level of indirection through the DID Document)).
For example, the “id” field in a verifiable credential should be the unique identifier for the concrete object (aka subject) that the verifiable credential is an instantiation of.
The following are examples of subjects and their software agents to help clarify the above points.


People and Agents
Alice and Bob are people. In addition, each of Alice and Bob have their own software agent. Each software agent has one or more endpoints that are used to receive messages from other parties. Usually, an agent will also have an Origin capable to sending messages to another agent’s endpoint (as illustrated below).

Figure 28. People and Agents

In a decentralized identifier-based software system, each person is expected to have one or more unique decentralized identifiers. In the example low, Alice, the person, has the decentralized identifier did:person:1234 and Bob, also a person, has a decentralized identifier of did:person:5678 (see below).

Figure 29. People, Agents, and Decentralized Identifiers (DIDs)

Layer 5 DIDComm User Agent Model

Figure 49. Layer 5 DIDComm User Agent Model

Leave a comment

Filed under Uncategorized

Facts, Opinions, and Folklore: A Preliminary Taxonomy

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

This preliminary taxonomy attempts to characterize the differences between facts, options, folklore, and related terminology. Your feedback is appreciated.

  • Facts
    • True Facts – Truths – Hard Facts – 100% true
    • False Beliefs – believed to be true but are, in fact, false
    • Fake Facts – knowingly or purposely 0% true (100% false)
  • Perturbations of the Facts
    • Misunderstood Facts
    • Misconceived Facts
    • Misstated or Miscommunicated Facts
  • Opinions
    • Feedback that may or may not be true
    • Vague
    • Poor recollected
    • Subjective opinions
    • Humorous/satirical
  • Folklore
    • Feedback originating with a fourth party and passed on by a third-party

Leave a comment

Filed under Uncategorized

Trusted Digital Web (TDW2022): Characteristic Information Scopes

Figure 1. Trusted Digital Web (TDW2022): Characteristic Information Scopes (based on the Social Evolution Model

Leave a comment

Filed under Uncategorized

Verifiable Credentials Guide for Developer: Call for Participation

Want to contribute to the World Wide Web Consortium (W3C) Developers Guide for Verifiable Credentials?

W3C is an international community that develops open standards to ensure the long-term growth of the Web.

A new W3C Community Note Work Item Proposal entitled Verifiable Credentials Guide for Developers has been submitted and you can help create it.

I want to invite everyone interested #DigitalIdentity, #DecentralizedIdentity, #VerifiableCredentials, #TrustOnTheInternet, and/or #SecureInternetStorage to join this key group of people who will be defining and creating the W3C Verifiable Credentials Guide for Developers.

Please contact me directly or post an email to public-credentials@w3.org

Links

Leave a comment

Filed under Uncategorized

Bootstrapping a VDR-based Fully Decentralized Object (FDO)/Credential Platform: VON Example

Michael Herman (Trusted Digital Web) 8:35 PM
What are the common/known strategies for bootstrapping a VDR-based decentralized credential/object platform? …asked naively on purpose.

  • Strategies for placing the first/initial DIDs in the VDR?
  •  …presumably purposed to be the initial Issuer(s) of verifiable identifiers on the platform?

Best regards,
Michael Herman
Far Left Self-Sovereignist

Stephen Curran 5:37 PM
In Hyperledger Indy, which is a permissioned public network, the first transactions are a DID for one of the  “SuperUser’s (aka “Trustee”) of the network, and DIDs for the initial node operators that verify the transactions.  From there, DIDs for additional nodes are added, DIDs for other Trustees and then DIDs of other types of users (Endorsers, authors), who in turn create other DIDs and object types. 
If you look at von-network (https://github.com/bcgov/von-network) you can spin up a little network (4 nodes in docker) and see the transactions that are used to start the network. In that, the seed for the Trustee DID is well known, so once you’ve started the von-network, you can control it. In a “real” network, that seed (and associated private key) would of course be protected by that first Trustee.
For Sovrin, a ceremony was video’d of all the initial Trustees and Stewards (node operators) when MainNet was started in 2017.

VON Blockchain Explorer

Reference: http://greenlight.bcovrin.vonx.io/browse/domain

Reference: http://greenlight.bcovrin.vonx.io/browse/pool

Initial DID Transactions

Initial Node Transactions

First SCHEMA Transaction

Leave a comment

Filed under Uncategorized

Trusted Digital Web: 8-Layer Architecture Reference Model (TDW-ARM)

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

Github: https://github.com/mwherman2000/TrustedDigitalWeb

After about 2.5 years, I finally have an ARM that I like and a code base that is starting to show some promise…

8-Layer Architecture Reference Model (TDW-ARM)

Click the model to enlarge it.

Trusted Digital Assistant (TDA) Prototype

Github: https://github.com/mwherman2000/TrustedDigitalWeb

Microsoft “Trinity” Graph Engine

Web site: https://www.graphengine.io/

Github: https://github.com/microsoft/GraphEngine

Verifiable Credential Notarization: User Scenarios 0.25

Verifiable Notarization Protocol (VCNP) 0.25

TDW Agents, Wallets, and VDR: ARM

Leave a comment

June 28, 2021 · 7:54 am

The Verifiable Economy: Fully Decentralized Object (FDO) Example: Bob’s UDID Document

Strongly-typed Code to Generate Bob’s UDID Document

Bob’s UDID Document

{
    "CellId": 6601258412767401213,
    "CredentialCore": {
        "udid": "did:svrn:credential:FD54/8F2B/8D61/9C5B",
        "context": [
            "https://www.sovrona.com/ns/svrn/v1"
        ],
        "claims": [
            {
                "key": "authentication",
                "attribute": [
                    {
                        "key": "publicKey",
                        "value": "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                    },
                    {
                        "key": "id",
                        "value": "#pubkey1"
                    },
                    {
                        "key": "type",
                        "value": "AUTHN-KEY"
                    }
                ]
            },
            {
                "key": "service",
                "attribute": [
                    {
                        "key": "serviceEndPoint",
                        "value": "http://localhost:5304/"
                    },
                    {
                        "key": "id",
                        "value": "#sep1"
                    },
                    {
                        "key": "type",
                        "value": "SEP-TCS"
                    }
                ]
            },
            {
                "key": "testkey1",
                "value": "testvalue1"
            },
            {
                "key": "testkey2",
                "attributes": [
                    [
                        {
                            "key": "publicKey",
                            "value": "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                        },
                        {
                            "key": "id",
                            "value": "#pubkey1"
                        },
                        {
                            "key": "type",
                            "value": "AUTHN-KEY"
                        }
                    ],
                    [
                        {
                            "key": "publicKey",
                            "value": "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                        },
                        {
                            "key": "id",
                            "value": "#pubkey2"
                        },
                        {
                            "key": "type",
                            "value": "AUTHN-KEY"
                        }
                    ]
                ]
            }
        ]
    },
    "Envelope": {
        "kind": "UDIDDocument",
        "encryptionFlag": "NotEncrypted",
        "hashedThumbprint64": "MpUTVq+AYTMEucWUFfMWfsWJRQ6tmO6FGzjAJGMN4T0=",
        "signedHashSignature64": "CLFgZCLJPzozxwB+JjJr7xQdZxgcwbEX4XBsujD+1rCW0sd6T4JFMVFTb86H50HQZ6h7myUld+9pIlbNWS3IPIg11uwYjlzMe32AO+ETCMSEJQJAPN9IJB//C4J2SkAdkK9OszStVsA/GYYtKZQdYSTdDESQCDVw6292N92bIJY=",
        "comments": [
            "Bob's UDID Document",
            "It works!",
            "Created by TDW.TCSServer at 2021-06-15 07:07:09Z"
        ]
    }
}

Leave a comment

Filed under Uncategorized

Hydroponic Pods

Leave a comment

June 2, 2021 · 11:26 pm

NETAGO Downtime – May 20-21, 2021

  • Hardwired ThinkPad laptop
    • Edition: Windows 10 Pro
    • Version: 20H2
    • OS build: 19042.928
    • 716 failures
    • 75.67% downtime

  • WiFi Wireless Lenovo laptop
    • Edition: Windows 10 Pro
    • Version: 20H2
    • OS build: 19042.985
    • 753 failures
    • 6.86% downtime

Leave a comment

Filed under Uncategorized