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

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

Technology Adoption Models: A Comprehensive Guide

This article documents 20 technology adoption models that the author has encountered over his 45+ year career …some models that he didn’t realize he knew about ;-).  Here they there are, in no particular order.

NOTE: Each model progresses from left-to-right along an unspecified timeline.  The implication is that it is possible to superimpose two or more models on top of each other for deeper understanding and for creating more tangible, more illustrative, depictions of your corporate, product, and project strategies.

An example is: 10. Technology Adoption Lifecycle illuminated by the Gartner Hyper Cycle.

Technology Adoption Models

NOTE: Click on any of the figures to enlarge them.

1. Crossing the Chasm: Technology Adoption Lifecycle

1. Crossing the Chasm-Technology Adoption Lifecycle

2. Social Evolution: Creation of Nation State

2a. Social Evolution-Creation of a Nation State

2b. Social Evolution-Defining Principles

3. Phases of Foundational Technology Adoption

3. Phases of Foundational Technology Adoption

4. Phases of Design and Action

4. Phases of Desire and Action

5. Phases of Understanding

5. Phases of Understanding

6. Classic Enterprise Solution Sales and Adoption Lifecycle

6. Classic Enterprise Solution Sales and Adoption Lifecycle

7. ICRVA (I CRaVe A) Process

7. ICRVA (I CRaVe A) Process

8. Three-letter Words

8. Three-Letter Words

9. Gartner Hype Cycle

9. Gartner-Hype Cycle

10. Technology Adoption Lifecycle illuminated by the Gartner Hyper Cycle

10. TAC-Hype Cycle

11. World Wide Web Consortium (W3C): Tenth Anniversary

11. World-Wide Web Consortium (W3C)-Tenth Anniversary

12. Systems Co-existence and Migration

12. Systems Co-existence and Migration

13. Embrace, Extend, and Extinguish

13. Embrace-Extend-Extinguish

14. Take-off Velocity (v2)

14. Takeoff Velocity-v2

15. From Mainframe to Blockchain

15. From Mainframe to Blockchain-header

0_BJ5SrrZXvXqhi8QMiXj9mw

16. Progressive Improvement through Continuous Transformation

16. Progressive Improvement through Continuous Transformation

progressive-improvement-thru-continuous-transformation-1-0-1progressive-improvement-a-1-0-1progressive-improvement-b-1-0-1

17. Liedtka-Ogilvie Design Thinking Modelf0c4ccea6b32d4fa772046d3646d0ff018. CB-Insights NExTT Framework

CB-Insights NExTT Framework

19. Exponential Growth Model

19. DarrelO-Exponential

20. Exponential Growth Model coupled with the Gartner Hype Cycle

20. DarrelO-HypeCycle

References

[1] Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers (https://en.wikipedia.org/wiki/Crossing_the_Chasm)

[2] Michael Herman (https://www.linkedin.com/in/mwherman/)

[3] Phases of Foundational Technology Adoption (https://www.linkedin.com/pulse/blockchain-foundational-technology-michael-herman/)

[4] Michael Herman (https://www.linkedin.com/in/mwherman/)

[5] Michael Herman (https://www.linkedin.com/in/mwherman/)

[6] Michael Herman (https://www.linkedin.com/in/mwherman/)

[7] How We Think About How We Work (https://hyperonomy.com/2016/05/09/how-do-we-think-about-how-we-work/)

[8] Unknown (with apologizes from the author)

[9] Gartner Hype Cycle (https://www.gartner.com/en/research/methodologies/gartner-hype-cycle)

[10] Gartner Hype Cycle (https://www.gartner.com/en/research/methodologies/gartner-hype-cycle) and Michael Herman (https://www.linkedin.com/in/mwherman/)

[11] World Wide Web Consortium (W3C): Timeline Graphic (https://www.w3.org/2005/01/timelines/description)

[12] Microsoft Corporation (https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish)

[13] Unknown (with apologizes from the author)

[14] Unknown (with apologizes from the author)

[15] Medium.com: From mainframes to blockchains. How to look at the future. (https://medium.com/@ben_longstaff/my-framework-for-how-to-look-at-the-future-of-blockchain-719f4243491f)

[16] How We Think About How We Work (https://hyperonomy.com/2016/05/09/how-do-we-think-about-how-we-work/)

[17] Designing for Growth: A Design Thinking Tool Kit for Managers (http://www.designingforgrowthbook.com/)

[18] CB-Insights NExTT Framework (https://www.cbinsights.com/)

[19] The Current and Future State of Digital Wallets (https://www.continuumloop.com/standards-digitalwallet-part-11-16/).

[20] Gartner Hype Cycle (https://www.gartner.com/en/research/methodologies/gartner-hype-cycle) and Michael Herman (https://www.linkedin.com/in/mwherman/)

Resources

  1. Phases of Foundational Technology Adoption (https://www.linkedin.com/pulse/blockchain-foundational-technology-michael-herman/)

 

Leave a comment

Filed under Uncategorized

The Message is the Medium: Multiprocess Structuring of an Interactive Paint Program – Beach et. all

References

Beach

Click here: The Message is the Medium: Multiprocess Structuring of an Interactive Paint Program – Beach et. all

Discussion

Daniel, regarding our discussion about the multi-process structuring of the Indy Ledger Node and how Anthropomorphic Design might be able to help, checkout the attached conference paper that describes a Paint application created by Eugene Fiume, a cohort of mine while we were in grad school together at the University of Waterloo. [Eugene is now Dean of Applied Sciences at Simon Fraser University.]

It’s an easy read …focus on page 279 and onwards: the concepts of Administrator, Overseer, Worker, Secretary, and Listener processes.

NOTE: The paper starts on page 277 of the proceedings. The paper is a total of 11 pages.

 

Leave a comment

Filed under Uncategorized

Business Choreography and the #TrustedDigitalWeb

1. Business Choreography Segment – Trusted Digital Web webcast

Business Choreography Segment (1 minute)
Trusted Digital Web / Hyperonomy Business Blockchain / NEO-NATION: Annual Report 2019

choreography-

2. Business and Service Choreography Discussion – Twitter

choreography2

#Composition speaks to the #concentration or #centralization of value, assets, and processes. #Choreography is about the interplay that takes place #naturally between #decentralized value, assets, and processes. #TrustedDigitalWeb #iDIDit

 

choreography1

#Service #Choreography: the idea underlying the notion of service choreography can be summarized as follows:

“Dancers dance following a global scenario without a single point of control”

Wikipedia: Service Choreography

 

Leave a comment

Filed under Uncategorized

Clique Speak

Definitions

clique-speak

10 Examples

  1. “…it’s not like we’re considering any of those topics for the first time.”
  2. “We may want to limit discussion if people that are new to the work, such as yourself, insist on rehashing things that we’ve already discussed.”
  3. “I know it will take time for you to trust that we’re trying to do the right thing for the community, Web, and Internet in general.”
  4. “Unfortunately, trust of that level takes months to years to develop and regular interaction and demonstrating over time that we have the best interests of the community at heart is all we can do to make you believe that we’re trying to do the right thing here.”
  5. “There are things that have strong consensus, such as dereferencing a DID gives you a DID Document.”
  6. “It’s incredibly difficult to navigate all of that if you haven’t been a part of the community since it’s beginning…”
  7. “There are discussions that keep coming up repeatedly that many in the community have explored multiple times and so rehashing those discussions is not useful if there is consensus on the topic.”
  8. “We’ve been having these topical discussions for a few years now and we’re probably through most of them.”
  9. “We need to be careful to not retread territory that we’ve already covered.”
  10. “You are also potentially re-opening discussions that we have consensus on, so we need to be careful not to do that because if we do that, lots of decisions that were finalized end up being reopened and we’ll waste a tremendous amount of time coming back to the same conclusion we came to many months/years ago.”

Leave a comment

Filed under Uncategorized

Social Evolution and Technology Adoption

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
April, 2019

Social Evolution

Wanderer-NationState

Figure 1. Social Evolution of Policies, Procedures, Processes, and Technologies

Social Evolution and The Technology Adoption Life Cycle

TechnologyAdoptionCurve-wikipedia2.png

Figure 2. Social Evolution and The Technology Adoption Life Cycle

References

Phases of Foundational Technology Adoption

Figure 3. Phases of Foundational Technology Adoption

 

2 Comments

Filed under Uncategorized

2019 Q1 Update DID Specifications Efforts

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
April 3, 2019

DID-specification-efforts

Figure 1. DID Specifications Ecosystem

Coexistence-Examples-Executive Summary

Figure 2. Comparison: did-uri-spec URI Syntax Examples and “DID ABNF” URL Syntax Examples

Coexistence-Generic-Baseline-Grammar

Figure 3. did-uri-spec Grammar (using ABNF notation)

DID-ABNF-AB

Figure 4. “DID ABNF” (AB) Grammar (using ABNF notation)

References

  1. Decentralized Identifier URI Specification (did-uri-spec): “DID ABNF” Comparison & Coexistence v0.23 webcast

 

Leave a comment

Filed under Uncategorized

What is the difference between “Indy” and “Sovrin”?

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
March 2019

[Originally published here: https://twitter.com/mwherman2000/status/1105290408467156992%5D

Q: What’s the difference between Indy and Sovrin? …what’s the that:

  1. Differentiates between the software platform (Indy) and the governance framework (Sovrin), and
  2. Describes how they come together.

Here is an answer…

Indy-Sovrin-Triangle

Leave a comment

Filed under Uncategorized

The #OpenToInnovation Principle: Internet protocols and standards not only need to be open, but more importantly, open to innovation

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

At a recent #BCTechSummit HyperLedger Indy developer bootcamp event in Vancouver, I was fortunate to be part of a conversation where Sam Curren (@telegramsam) was talking to a small group of developers about the importance, over the course of history, for Internet protocols to not only be open, but more importantly, open to innovation …innovations that might succeed as well as innovations that might fail.

“If you look at important Internet protocols like TCP-IP that enable packets on a network to carry any type of data including text, email messages, web pages, etc, and, later on, streaming audio and streaming video, who could have imagined it? It’s vitally important for Internet protocols to not only be open but open to innovation …innovations that might succeed as well as innovations that might fail. No one can foretell how the specifications we’re creating today will be used in the future.” Sam Curren, March 11, 2019

 

Leave a comment

Filed under Uncategorized

Giving Grammars Written with ABNF Notation the Respect They Deserve

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

At one level, the Augmented BNF (ABNF) notation is simply a convenient textual approach for describing a grammar. In turn, a grammar is a description of the allowable linguistic constructs permitted in a particular language or any other syntactic construction. Examples of common and emerging grammars written using ABNF notation include:

More importantly, a grammar that conforms to the ABNF specification (RFC4234-4) is also an executable program.  That is, a grammar is the source code for program (written in the ABNF notation (aka ABNF programming language)) that recognizes and, optionally, processes a piece of text (string of tokens) that conforms to the grammar’s specification (expressed using ABNF notation).

Summary: The “ABNF Principles”

The “ABNF Principles” include:

  1. “ABNF” is a specification for a notation for describing a grammar.
  2. “ABNF notation” is the notation described in the ABNF specification for describing a grammar.
  3. A grammar is a description of the allowable linguistic constructs permitted in a particular language or any other syntactic construction.
  4. RFC4234-4 is a formal specification for ABNF notation.
  5. A grammar expressed using ABNF notation is intended to be executable.
  6. A grammar expressed using ABNF notation is the source code for a program that can be read, interpreted, compiled, and/or executed by a human, interpreter, compiler, or virtual machine, respectively, in a way that conforms to the ABNF formal specification.

Best Practices for Developing Grammars Written using ABNF Notation

  1. As in any software development project, it is of primary importance to understand the scope of the functionality, inputs, and outputs of the intended software (aka requirements).
  2. One of the best, commonly accepted ways to understand of the scope of the intended software to be developed is to work through the following series of artifacts:
    1. User stories, which in turn are decomposed into
    2. Use cases, and
    3. Requirements, and
    4. Specifications
  3. Use automation together with the use cases to create an automatable testing framework starting early in the project – automatically validating the the grammar against the test cases (derived from the use cases) on an ongoing basis.

NOTE: These artifacts can be developed iteratively using an agile or other type of development framework. It doesn’t require a waterfall approach.

 

 

Leave a comment

Filed under Uncategorized

SerentityData: Variable-byte, Statistically-based Entity Serialization & Field Encoding

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
February 2019

The SerentityData Entity Serialization and Field Encoding library fulfills Blockchain Requirement 1 for the Universal UBL (UUBL) extensions to the UBL 2.2 business document schema specification:

Requirement 1. Compact and Efficient Binary Serialization

The requirement for extremely compact and efficient binary serialization of each entity (and subentity) can be fulfilled by various software serialization solutions including SerentityData Variable-byte, Statistically-based Entity Serialization. The SerentityData project can be found on Github. SerentityData is the author’s preferred solution.

Design and Implementation Strategy

Design Principles

  1. Statistically-based Encodings (STE): For a particular datatype (e.g. Signed Int 16 or Unsigned Int 64), some data values representable by this datatype will be used more frequently than others (e.g. 0 (zero), 1, small integer values, etc.) and there should be a way to encode these statistically more frequent values using as few bytes as possible (compared to larger data values).
  2. Variable-byte Encodings (VBE): Over the lifespan of a persisted field (e.g. an Unsigned Int 64 blockchain block or transaction serial number), the initial values of the field will have small values (0, 1, 2, 3, …) and over the course of a long time (years or decades) grow to have very large values. As few bytes as possible should be used to represent small values and this should be less than the number of bytes required to represent very large values.
  3. Application-adaptive Encodings (AAE): Every application or application data domain will require:
    1. A different subset of the available datatypes, and
    2. Each data type will have a different statistical distribution of application-dependent data values.
  4. Single-byte Encodings (SBE): Very common (application-dependent) data values, on a datatype-by-datatype basis, should only require 1 (one) byte of storage. For example, for specific applications, the following values would be candidates for single-byte encodings:
    1. Data value TRUE of datatype Boolean and data value False of datatype Boolean
    2. Specific data values of small whole numbers (e.g. 0, 1, 2, 3, 4, 5, … n) where, depending on the application and datatype, n might be 10, 32 (days of the month), 60 (seconds in a minute), etc. The values do not have to be contiguous.
    3. Specific data values of negative numbers (e.g. -1, -2, -3, -4, -5, … m) where, depending on the application and datatype, m might be -10, -20, etc. The values do not have to be contiguous.
    4. Specific data values of Enum datatypes. The values are usually contiguous but there is no requirement for them to be contiguous.
  5. Support All Datatypes (SAD): It should be possible to encode all possible datatypes and all possible data values for the selected data types.  The current list of supported data types includes:
    1. Signed Integer 16
    2. Signed Integer 32
    3. Signed Integer 64
    4. Unsigned Integer 16
    5. Unsigned Integer 32
    6. Unsigned Integer 64
    7. Byte
    8. Signed Byte
    9. Enum
    10. Byte Array
    11. Boolean
    12. Boolean
    13. Char
    14. String
    15. ASCIIString
    16. Address
    17. Guid
  6. Standalone, Compact, and Efficient (SCE) Implementation
    1. Standalone: The entity serialization and field encoding libraries will not rely on any external source code or callable binary libraries.
    2. Compact: The entity serialization and field encoding libraries will be compact enough to be useful and desirable to execute:
      1. Off-chain in a traditional computing environment including server, PC, tablet, and mobile device, as well as
      2. On-chain in a smart contract (virtual machine) execution environment
    3. Efficient: Highly efficient code execution to be useful and desirable to use in a fee-based, smart contract (virtual machine) execution environment
  7. Storage Compatibility (SC): Compatible with any data storage technology capable of storing variable-length arrays of bytes representing the field encoded and entity serialized data.
  8. Runtime Compatibility (RC): The current design and implementation of the entity serialization and field encoding libraries is compatible with .NET Core 2.0 or later.
  9. Versioning Support (VS): Support for versioning at the entity serialization as well as entity encoding levels; including support for multiple applications, serializations and encodings in the same library.
  10. Entity Extensibility and Backward Compatibility (EEBC): Entity declarations can be extended through the additional fields without losing backward compatibility with previously serialized entities.
  11. Support for ByteArray and String Null-Valued References (NULLS): Support for null-valued references to ByteArrays and Strings – in addition to zero-length and non-zero length ByteArrays and Strings.

Assumptions

  1. There exists a code generation tool that takes as input a description of an entity, its fields and their datatypes that will create the sequence of calls into the entity serialization and field encoding that performs serialization/deserialization and field coding/decoding for a target entity declaration (e.g. a C# class declaration).

Implementation Notes

  1. The reference implementation of the entity serialization and field encoding libraries is called SerentityData and is implemented using .NET Core 2.0, C#, and Visual Studio 2007 Community Edition.

Roadmap

Features that are unsupported in the current release:

  1. Collections and Mappings: next on the queue
  2. Nested Entity Declarations: An entity declaration that has a field whose datatype is another entity declaration.

Field Encoding Strategy

TODO

Byte 0 Mapping

In the Variable Byte Encoding scheme used to represent the value of a datatype, the first byte of an encoded field value (Byte 0) is the most important. For Single-byte Encodings, Byte 0 needs to encode both the datatype of a particular value but also the value itself.

Given there are only 256 unique values that Byte 0 (or any single byte) can assume, certain trade-offs must be made to accommodate the range of application-driven datatypes required and the number of possible single-byte, double-byte, and triple-byte optimizations that are possible. This is where statistical knowledge of the range of values that a particular datatype required by an application is important.

Byte 0 Default Mapping

Figure 1 below is an example of the current default set of Byte 0 mappings.

SerentityData1.pngFigure 1. Byte 0 Default Mapping Table

Data value 0 (zero) is currently not assigned.

Single-Byte Encodings

TODO

Two-Byte Encodings

TODO

Three-Byte Encodings

TODO

Longer Byte Encodings

TODO

Performance

TODO

Sample Use Case

An example of a distributed business application designed to be used with SerentityData is the following SerentityDapp.Perfmon for on-chain [blockchain] performance monitoring and recording.

NCP-001 SerentityDapp.Perfmon v0.7Figure 2. SerentityDapp.Perfmon Data Model – Onchain [blockchain] Performance Monitoring and Recording Example

Appendix A – SerentityData Field Encoding Details

Supported Data Types

02-datatypes

Special Use Cases

21-specialcases

Field Buffer Configurations

A. Buffered Values

  • 3 Fields = FieldEncodingType + Buffer Length + Buffer Bytes
Use Case 0. 16-bit Buffered Value

 

33-usecase0

Use Case 1. 32-bit Buffered Value

 

48-usecase1

 

Use Case 2. 64-bit Buffered Value

 

53-usecase2

B. Headered Values

  • 2 Fields = FieldEncodingType + Value (stored in the 16-bit, 32-bit, or 64-bit Buffer Length field)
Use Case 3. 16-bit Headered Value

 

59-usecase3

Use Case 4. 32-bit Headered Value

 

73-usecase4

Use Case 5. 64-bit Headered Value

 

78-usecase5

C. Value Constants:

  • 1 Field = FieldEncodingType (representing a specific constant value for a particular datatype stored represented an FieldEncodingType op code)
Use Case 6. 8-bit Value Constants

85-usecase6

D. Null ByteArrays

 

Use Case 7. Null-valued reference to a ByteArray

 

92-usecase7

E. Short Length ByteArrays

  • 0, 1, 2, 3 bytes in length
Use Case 8. 0-byte ByteArray

 

100-usecase8

Use Case 9. 1-byte ByteArray
105-usecase9
Use Case 10. 2-byte Byte Array
110-usecase10
Use Case 11. 3-byte Byte Array
115-usecase11

 

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

1 Comment

Filed under Uncategorized