design_meta

Y-1.1.1 Contents

⚙ Y-1.1.1 Global content

Metadata, what is in it? Just having data, there are a lot of questions to answer:
📚 Information data is describing?
⚙ Relationships data elements?
🎭 Who is using data for what proces?
⚖ Inventory information being used ?

🔰 Too fast .. previous.

🎭 Y-1.1.2 Guide reading this page

Why is Jabes interesting?

Everybody is looking for a solution to mange the challenges with information processing.
As far I know there is nothing on the market for solving those challenges. There are many tools for detailed topic but no one covering all the interactions.

The break-up of: Logic, Concept, Context

Aside the standard questions there is the following break-up:

Logic (Y-1.*): The principles what Jabes solves.
Concept (Y-2.*): Jabes Metadata artifacts, domains & layers
Context (Y-3.*): Measuring maturity of information processes

Measuring maturity is added because without any metrics any change is disputable.
Lean six sigma is based on having metrics. Metrics are important, however, ignoring everything that doesn´t have a metric, is a very bad idea.

Needed knowledge to read this

Basic knowledge:

Information processing, see "elucidation".
insight on the gaps at information processing, see "summary".
understanding what is going on in the technical ICT world, see "SDLC".
understanding what the organisational information challenges are, see "BPM".

⚙ Y-1.1.3 Local content

Reference	Squad	Abbrevation
Y-1 Concepts & Basic standards
Y-1.1 Contents	contents	Contents
Y-1.1.1 Global content
Y-1.1.2 Guide reading this page
Y-1.1.3 Local content
Y-1.1.4 Progress
Y-1.2 Goal & Principles	jabespr_02	Principles
Y-1.2.1 What are the issues with information processing?
Y-1.2.2 Functional process principles
Y-1.2.3 Break-up: Technical ⇄ Functional
Y-1.3 Identification naming standard	jabespr_03	ID
Y-1.3.1 Understanding Logic, Concept, Context
Y-1.3.2 Understanding - Communication language
Y-1.3.3 Unique identifier knowledge containers (1)
Y-1.3.4 Unique identifier knowledge containers (2)
Y-1.4 Foundation & commercials	jabespr_04	NGO-C
Y-1.4.1 Recap basics Jabes mindset
Y-1.4.2 Jabes foundation tasks
Y-1.4.3 Commercial Jabes products
Y-1.5 Spin offs - preliminaries	jabespr_05	SP
Y-1.5.1 Adding visualisations and other tools
Y-1.5.2 Information canvas three*six layout conform Zachman
Y-1.5.3 Metadata artifacts for BI reporting
Y-1.5.4 Jabes Wiki Collaboration
Y-1.6 Jabes basics maturity	jabespr_06	CMM3-JBS
Y-1.6.1 The organisation in a nine-plane
Y-1.6.2 Continuous improvement of the organisation
Y-1.6.3 Maturity: frameworks, applications
Y-2 Jabes Metadata
Y-2.1 Demand: backlog, proposals, issues	jabesmt_01	Dev
Y-2.1.1 Knowing what is going on
Y-2.1.2 Determining opportunities feeded by suggestions
Y-2.1.3 Explainable decisions: demand
Y-2.2 Design: product building - validations	jabesmt_02	Val
Y-2.2.1 Change initiation
Y-2.2.2 Product build design
Y-2.2.3 Product validation design
Y-2.3 Build: product & validate	jabesmt_03	Backlog
Y-2.3.1 Product build realisation
Y-2.3.2 Product validate Materials
Y-2.3.3 Product validate Artifacts
Y-2.4 Consolidate into specifications - operations	jabesmt_04	Ops
Y-2.4.1 Product service evaluation
Y-2.4.2 Usage in the operation cycle
Y-2.4.3 Knowing what is gong on
Y-2.5 Decoupled ERP connections	jabesmt_05	DC-ERP
Y-2.5.1 Completeness of metadata artifacts
Y-2.5.2 Technology - Functionality, data products
Y-2.5.3 Analytical plane - Operational plane, BI&A
Y-2.6 Jabes Metadata maturity	jabesmt_06	CMM4-JBS
Y-2.6.1 Cargo Cult
Y-2.6.2 Maturity: frameworks, applications
Y-2.6.3 Information contracts
Y-2.6.4 External references
Y-3 Maturity
Y-3.1 Muda Mura Muri	jabesad_01	M-3M
Y-3.1.1 Enabling motivating the workforce
Y-3.1.2 3M Technology
Y-3.1.3 3M Information (organisation) and Technology
Y-3.1.4 3M Information Communication and Technology
Y-3.2 Technology	jabesad_02	M-Tech
Y-3.2.1 Technology enablement
Y-3.2.2 Maturity fundaments technical infrastructure
Y-3.2.3 Maturity Planes: Technology, Operational, Analytical
Y-3.2.4 Measuring internal & external services
Y-3.3 Information (organisation) and Technology	jabesad_03	M-IT
Y-3.3.1 Enable the organisation using technology
Y-3.3.2 Maturity fundaments organisation alignment technology
Y-3.3.3 Data Driven processes - Functional
Y-3.3.4 Combining internal & external services
Y-3.4 Information Communication and Technology	jabesad_04	M-ICT
Y-3.4.1 Enable the organisation using technology
Y-3.4.2 Enterprise mission assurance
Y-3.4.3 Ethical and social values
Y-3.4.4 Optimizing optimized organizational processes
Y-3.5 Visualisation Inquiry & Auditing	jabesad_05	CMM-VIA
Y-3.5.1 "culture, organisation, vision" What to measure?
Y-3.5.2 "operational mission: value streams" What to measure?
Y-3.5.3 "state of the art technology" What to measure?
Y-3.5.4 Closed loops in project management
Y-3.6 Maturity of Maturity	jabesad_06	CMM5-JBS
Y-3.6.1 Maturity scopes
Y-3.6.2 Maturity of measurements for maturity
Y-3.6.3 Organizing administrative processing
Y-3.6.4 How to start with a Jabes product realisation
Y-3.6.5 Following steps

⚒ T-1.1.4 Progress

done and currently working on:

2024 week 2
1. Moved all old content to SDLC design
2. Ready to put Jabes content here.
2024 week 6
1. Draft content Jabes done, some details to do.
2. The maturity details are requiring to do those topics (BPM BiAnl) far more in details
2024 week 10
1. Details maturity from the BPM organisation added.
2024 week 13
1. Draft version finished.
2. Stakeholder owner to be found at""Shape" - Tactical.

Planning, to do:

Metadata details PMIT from a Word approach
Metadata details PPIC from free mind idea
Metadata glossary data dictionary DDIC
Updates in maturity details BIAnl

Y-1.2 Goal & Principles

The Jabes goal is:

Bring information processing to a higher maturity level.
Enable what is done for information processing to get understandable documented.
Enable better continuous improvements of organisations by using more mature information processing.

These goals seems to be that very common sense logical that the question is: why is this not already done?

Y-1.2.1 🔰 What are the issues with information processing?

The challenges with inoformations processing are numerous.
The answer, "why this is not already done?", is manyfold:

There is a cultural vendor locking, not only by technology suppliers but also by management consultancy. Behaviour: Stick to what always was done.
Frameworks and tools (applications) are a challenge to bootstrap into organisations just for the new unknown thing. Behaviour: Stick to what always was done.
Technology for realisation of frameworks with tools (applications) just recently became available.

To change this, is a challenge on his own.

⚒ Information processing is still technology driven.

Where the goal is expected to be organisational process driven, the reality is:

Focus on the latest available technology:
machines, cloud.
Focus on the latest hypes for functionality:
Databases, blockchain, Artificial Intelligence
For an organisation financial budgets are a requirement.
Focus on the financials distracting to KPI-s: personal interest.

To change this, is a challenge on his own.

⚙ The common gaps wiht information processing hat are touching everybody:

❶🕳	No available verified independent processes maturity levels
❷🕳	No standard quality of processes results delivered, only ad hoc BI reports
❸🕳	No standard quantity of process load delivered, only ad hoc BI reports
❹🕳	No standard feedback for posibble required changes and/or innovations
❺🕳	No standard base reporting on plan and execute for process changes
❻🕳	No standard base reporting for planning expected processes load

Everybody wants to change this, but nobody is in a position to do so.

⚖ The Challenges of Lean Administration

(C.Roser 2016) One major part of modern economy is administrative processes, which includes things like making offers, procurement, accounting, engineering, research, and many others. By some estimates, more than half of the cost of producing companies are in administration. Up to 80 percent of the lead time is due to administration. A lot of the principles behind lean can be used in administration. However, there are also some unique challenges that are less prominent in manufacturing.

Complications in Administrative Settings:

It is difficult to observe actual work

The work content is much less standardized

The work flow is much less standardized

Proposed Approaches:

Contextual Inquiry / Interview

Do It Yourself

As mentioned above, most of the ideas and methods behind lean will also work in administration. Some lean tools are even designed specifically for administration (e.g., the swim lane diagrams). In any case, you should not overlook your administrative processes when you work to organize your industry!

Y-1.2.2 🎭 Functional process principles

process life cycle

There are two lines in the life cycle:

From Request to Demand.
Pull "how it gets organized":
- Ideate, Asses
  Customer alignment: promises expectations
- Enable, Plan
  Alignment resources: internal external
From Demand to Delivery.
Push "how it is made":
- Demand, Backend
  Operational assembly including planning
- Frontend, Delivery
  Product quality Control & handover

This is a very basic simplified approach. A figure at the right side

modelling processes

Trying to understand how processes are interacting the petri net theory is interesting. The possible lack of an execution policy is human natural approach. Petri Net (Wikipedia)

A Petri net, also known as a place/transition (PT) net, is one of several mathematical modeling languages for the description of distributed systems. It is a class of discrete event dynamic system. A Petri net is a directed bipartite graph that has two types of elements: places and transitions. Place elements are depicted as white circles and transition elements are depicted as rectangles. A place can contain any number of tokens, depicted as black circles. A transition is enabled if all places connected to it as inputs contain at least one token.

Y-1.2.3 📚 Break-up: Technical ⇄ Functional

Technical tools enablement

❶The technology drive approach is focussing on middelware / tools.
❷Expectations are business processes will benefit automagically.
The prioritizaion is not in favor of the organsisation but for external supppliers.
Jabes middleware

A figure:
See left side

Platforms, middleware are needed to enable transformations. Their implementations are doing some (not all) technical options for functional compliancy goals.
Categorized in a nine-plane:

	Explanation			Explanation
NwC	Communication (network)	- -	C	Confidentiality
Mdl	Application Platform	- -	I	Integrity
HOS	Operating System (hardware)	- -	A	Availablity

	HOS	Mdl	NwC
C	👐	👐	👐
I	👐	👐	👐
A	👐	👐	👐

Functional information processes

❶ The functionality driven approach is focussing on information processing request⇄result.
❷ Technology is sufficient in place & maintained for doing the needed information transformations.
The is a sensible prioritizaion favoring the organisation.
Jabes generic process

A figure:
See right side

Information processing for business missions are the "value streams". Their implementations requires alignment to compliancy rules set by regulations or internal visions.
Categorized in a nine-plane:

	Explanation			Orchestrationn
BmV	Business missions value	- -	F	Functional
VsP	Values stream Processes	- -	C	Compliancy
DaP	Data as Product	- -	T	Technical

	BmV	Vsp	DaP
F	👐	👐	👐
C	👐	👐	👐
T	👐	👐	👐

Change: the ICT innovation

In the centre:
💡❗✅ Have platforms a defined maturity level conforming their nine-plane
💡❗✅ Have information value streams a defined maturity conform their nine-plane

Y-1.3 Identification naming standard

Jabes was triggered by the question how to implement a new version of a tool in a controlled planned way. Changing the portfolio by an update an obvious action. A glossary and data dictionary not needed by the limited number of involved persons.
What was not realised as "Proof of concept":

👁 Important in all cases is a well understanding by all being involved by a shared "glossary" shared "Data Dictionary" (DD).
👁 Important is also that the maturity of tthe product and/or process is measurable.
Doing changes improvement without any feedback on the achieved impact is a walk in the dark.

Important in all cases is an accepted method of standard recording of what has been executed for the documented achievements.

Y-1.3.1 🔰 Understanding Logic, Concept, Context

A good understanding is a prerequisite. A attached list of used definitions is a common approach. The technical solution for that is a data dictionary. A business glossary can be defined as a collection of unique business terms and definitions that helps understand the data assets key characteristics.

data dictionary

Data Dictionary (tech Target)

Data dictionaries can be valuable tools for the organization and management of large data listings. These are some of the biggest benefits of using a data dictionary:

provides organized, comprehensive lists of data;

easily searchable;

provides reporting and documentation for data across multiple programs;

simplifies the structure for system data requirements;

reduces data redundancy;

maintains data integrity across multiple databases; and

provides relationship information between different database tables.

However, data dictionaries can also prove difficult for some to manage. Here are some of the downsides:

lack of functional details regarding data;

diagrams that are not always visually appealing; and

can be difficult for nontechnical users to understand.

glossary

Data Dictionary vd business glossary (Collibra)

People often confuse the meanings of a business glossary and a data dictionary, but they are two distinct tools that work together to make an organization’s data more meaningful.
A business glossary is concerned with defining business terms from a logical perspective in a way that humans can understand. Organizations use a business glossary to:

Create a shared language around data related terms

Give visibility into how vocabulary may differ across departments

Ensure agreement and consistency between business content and technical data

Data dictionaries, on the other hand, describe specific data elements in a way that databases can understand. Organizations use a data dictionary to:

Provide consistency in data collection and use across tools

Enforce the use of data standards

Show the relationships between data assets

Y-1.3.2 🎭 Understanding - Communication language

Solving the gap in understanding:

missions - goals 👉🏾 architecture of business processes (PPIC)
understandable explanations 👉🏾 wiki (DDIC)

Levels in communication, architecture

The text is refering Mark Richards. "How to create an effective software architecture roadmap" (techtarget)

The iteration model
The iteration model demonstrates how the architecture and related software systems will change and evolve on the way to a final goal. Each large iteration segment represents one milestone goal of an overall initiative, such as updating a particular application database or modernizing a set of legacy services. Then, each one of those segments contains a list of every project involved in meeting that milestone. For instance, a legacy service modernization iteration requires a review of the code, refactoring efforts, testing phases and deployment preparations. ...

The portfolio model
Once an architect has an iteration model in place, the portfolio model injects reality into the roadmap. In this stage, the architect or software-side project lead analyzes the feasibility of the overall goal. They examine the initiative, the requirements for each planned iteration and the resources available for the individual projects within those iterations. The portfolio model documents what needs to happen in each of the small projects. ...

The prioritization model
The third component of the software architecture roadmap is prioritization. In this model, the architect, in conjunction with business analysts and stakeholders, reprioritizes and reschedules work based on factors like staff availability, budget size and conflicts between concurrent projects. "You start reprioritizing the projects and moving them around, keeping the dependencies in mind ... and make sure that dependencies are actually preserved," Richards said. ...

Understanding: Wiki collaboration

Human interaction, closing gaps. Wiki (Techtarget)

Wikis are commonly used for knowledge management, project collaboration and intranet applications. They are a great resource for businesses, teams and individuals who need to share information quickly and efficiently.
Wikis provide the ability to link related pages of information together using hyperlinks, which makes them ideal for creating connected networks of data. This provides an easy way to organize information, making it easier for users to access the data they need.

Another part in communication is using viusalisations: UML (Wikipedia)

The unified modeling language (UML) is a general-purpose visual modeling language that is intended to provide a standard way to visualize the design of a system. UML provides a standard notation for many types of diagrams which can be roughly divided into three main groups: behavior diagrams, interaction diagrams, and structure diagrams. ...
In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.

Y-1.3.3 📚 Unique identifier knowledge containers (1)

Unique identifiers are enablers for exchange, trade. The regulation and supervision are required to be independent.
Environment areas of interest:
💡❗✅ PMIT: Product Middleware Information Technology - transformers
💡❗✅ PPIC: Product Portfolio Information Communication - functional processes
💡❗✅ DDIC: Data Dictionary Information Communication - knowledge

Basic naming structure

This uniform identifier enabling exchange and trade using the structured information of a product more easily comprises 5 mandatory elements. The elements of the life phase and the codename, type-version of the product are set and maintained by the owner. The other three are set by standardised guidelines.
The structure:

The identifier for:
- "PPIC" Product Portfolio Information Communication
- "PMIT" Product Middleware Information Technology
- "DDIC" Data Dictionary Information Communication
The code for sublevel metadata for type of product
An identification of the organization having this product
A code for the life phase of this product
A code for the name, type and version of the product

colons (:) are used to separate these elements. No other punctuation marks are allowed.

Product metadata sublevel

The string "ICT" for software and information processing

The string length is three characters.
Other strings are possible to align with the owner of the “PPIC” standard:

HMD Health care medical devices
HPC Health personal care
PBL Buildings in the physical world
Sph Science Philosophy

Organisation identification

A 6 byte hexadecimal string grouped in three strings in the format: XX-XXX-XXX

XX
- first byte: authority issuer-id 🚧➡ This Should be zeroes when only internal used.
- Second byte: checking valid construct.
  Check byte is based on the integer value of the first and the following 6 bytes (unsinged). The values is: 255–(integer value) modulo 251
XXX , three bytes part of numbering Should be zeroes when only internal used
XXX , three bytes part of numbering

Product life phase

An identification format is a combination of the project class and a project identification. The project class has the limited set of consolidated values:

"ACT" Active Life , machine / tool / platform
"DCM" Decommissioned product
"EOL" Out of support product, registrations archived for legal concerns
"FRN" Product is marketed with franchise
"LSN" Product is got externally leased / hire
"TRD" Product is on the market for trade

The role of product might change into a tool depending on how it is used at an organization.
An identification format is a combination of the project class and a project identification. The project class has the limited set of values:

"BLR" Active Back log request waiting,
marker for static objects not a process activity
"LCM" Life Cycle management, software platform or processing
"QIC" Information management points of concern.
Several optional points of concern are:
- Security – Confidentiality trustworthiness
- Information quality – Integrity, reliability
- Explainable PII – privacy, data minimalization, legal obligation- legitimate interest
- Explainable AI – algorithms logical functional technical – confusion matrix
"INO" Initial new objectives
"POC" Test proof of concept, only temporary short living

Product code for the namen, type version

For an organization a free to choose character string. The length in bytes is 21. Allowed are Unicode chars. The version is a number separated by a “-“

Notes:

The total length in bytes of the "organization identification" (8 bytes binary), “product life phase”, and “Product code for the name, type and version” is 32 bytes
The portfolio identification will only be used as a value. Special characters is not a problem
Other identifications are also used as element names. In an element name it is not well feasible to uses special characters aside the underscore “_”.
Instead of a underscore a hyphen “-“is used in intended human readable text.

Y-1.3.4 📚 Unique identifier knowledge containers (2)

The organisational internal context is where accountability and responsibility for functional processes are. Unique identifiers are enablers for auditing, knowledge maturity.
Environment areas of interest:

💡❗✅ PMOV: Product Middleware operational values - transformers
💡❗✅ PPVS: Product Portfolio Value streams - functional processes

Y-1.4 Foundation & commercials

The knowledge of the Jabes metadata and framework should not be closed. The split in a Foundation for regulation supervision and commercial usage result into:

The non commercial Foundation being a requirement.
Knowledge maintained by the Foundation to be open source.
Funding of the foundation is mandatory by commercials that will use.

There is an impediment by dependicies by this to start building Jabes.

Y-1.4.1 🔰 Recap basics Jabes mindset

⚒ The V-model, Concurrent engineering.

There are dependencies in organisational changes. A free format of work to do something, is clueless.
The way out of randomness: Disciplined agile .

The V-model is well known for engineering.
A figure, see right side

⚒ The Siar model

one dimension:
- Simple customer relation for request-result
- a serial flow of instructions: 0,1,2,3,4,5,6,9
two dimensions:
- Pull - Push
- Backend - Frontend
- PDCA (lean agile) - DMAIC (Lean Six sigma)
three dimensions:
- Hierarchical control
- Decentralised Business Intelligence
- Consolidated Business Intelligence
- Optimizing the organisation, business within the business

A figure, see right side

⚒ pid process control

When there is a measurement control adjustment becomes a known theory. However this theory is not simple at all.
PID control (wikipedia) > In theory, a controller can be used to control any process that has a measurable output (PV), a known ideal value for that output (SP), and an input to the process (MV) that will affect the relevant PV.
Using this kind of control there is effect that in the beginning things are going worse before improvements are seen. Why would the reason for that be?
Some possible options:

knowing the effects with change options instead of trial/error attempts
The announced change is micro managed harming the existing operations
The announced change is not correct, not wanted and being disputed

Y-1.4.2 🎭 Jabes foundation tasks

⚒ Why a Unique identifier?

Benefits of a unique PPIC -PMIT - DDIC identifiers are:

Enables exchange of all kind of details on technoloyg products.
Enables exchange of all kind of details on information products.
Easier review on completeness and quality level of a product.
Standard way of monitoring project progress an project status for products.

⚒ Why a standard metdata structure?

Benefits of a unique PPIC -PMIT - DDIC indentifiers are:

Enables exchange of all kind of details on a product.
Easier review on completeness and quality level of a product.
Standard way of monitoring project progress an project status for products.

Y-1.4.3 📚 Commercial Jabes products

	HOS	Mdl	NwC
C	👐	👐	👐
I	👐	👐	👐
A	👐	👐	👐

⚒ Why a standard metadata structure?

❶ The structure defining the platform enables maturity measurements.
❷ Maturity measurements will easily show if there is a fit for functional usage.
❸ Independent auditing of the maturity is an opening for commercial activities.
❹ Implementations with a manual for usage and fit for usage, easy activities.
Jabes middleware

A figure:
See left side

	BmV	Vsp	DaP
F	👐	👐	👐
C	👐	👐	👐
T	👐	👐	👐

⚒ Why a standard metadata structure?

❶ Describing information processes structured, enables maturity measurements.
❷ Maturity measurements will easily show if there is a fit for functional usage.
❸ Independent auditing of the maturity is an opening for commercial activities.
❹ Implementations with a manual for usage and fit for usage, easy activities.
Jabes generic process

A figure:
See right side

Y-1.5 Spin offs - preliminaries

Jabes is not a silver bullet for everything. A lot is to use from other sources. Some ideas for: Spin off, addons:

Tools adding functionality
Maintaining information in a 3*6 canvas conform Zachman.
Metadata artifacts for BI reporting

Preliminary is a knowledge wiki "data dictionary", " data glossary".

Y-1.5.1 💡 Adding visualisations and other tools

Example: a software solution showing marvellous visualisations

Dragon1 Dragon1 platform includes powerful enterprise architecture tools offering support for strategic planning, analysis, design, innovation and continuous improvement. For visualizing and managing information from companies, ecosystems, intelligent business solutions and technology domains. ..
Visualization Data tools to make informed decisions, faster, better and smart by means of strategic blueprints as management reports. Design, monitor and steer the ongoing changes as a team, building the enterprise 4.0.

detailed daily planning with analyses & forecasting

Examples:

Atlassin jira, confluence
Microsoft Planner

Y-1.5.2 💡 Information canvas three*six layout conform Zachman

⚒ Component: Zachman

Wiki Zachman

The Zachman Framework is not a methodology in that it does not imply any specific method or process for collecting, managing, or using the information that it describes.

Challenging is: ontology all levels in one pass.
Split up:
🤔 High level architectural functional design:
(1) Logical, Conceptual Contextual.
🤔 Solution engineering, technical architecture:
(2) Logical, Physical Detailed.

⚖ ⚙ 💡 Ideate Architecting and engineering conform Zachman

❓ During ideate there are no fixed ideas putting them in a canvas. A SAAS solution helping to build up a mindset is a welcome option.
⚒ The SAAS options and web technology are at that level these days, it should be doable.

Y-1.5.3 💡 Metadata artifacts for BI reporting

⚒ Issue: no central point for publishing on a dashboard

HL7
Health Level Seven or HL7 is a range of global standards for the transfer of clinical and administrative health data between applications. The HL7 standards focus on the application layer, which is "layer 7" in the Open Systems Interconnection model. The standards are produced by Health Level Seven International, an international standards organization, and are adopted by other standards issuing bodies such as American National Standards Institute and International Organization for Standardization. Health organizations typically have many different computer systems used to process different patient administration or clinical tasks, such as billing, medication management, patient tracking, and documentation. All of these systems should communicate, or "interface", with each other when they receive new information or when they wish to retrieve information. HL7 International specifies a number of flexible standards, guidelines, and methodologies by which these healthcare systems can communicate with each other.
Business Intelligence reporting is not having something like those open standards.
The result: lock-ins by dedicated ERP suppliers or building it all on prem in house.

⚖ ⚙ 💡 uniform standard for presenting BI&A reports

Y-1.5.4 💡❗✅ Jabes Wiki Collaboration

⚒ Component: Enterprise Ontology 101

There is a claim of a "single version of the truth" for describing something what is going on for achieving a goal. The problem is several people are having a different perspective on the goal an the context of actions.

⚠ Multiple interpretations of an element.
This is a different understanding in metadata, ontology. In a document dated 2006 enterprise engineering J.Dietz an example is given.

Strategy goal: transport of person(s).
- From location A to location B.
- Applicable transport option: a car.
Car driver goal: using a car enabling going from A to B.
- Needing information for useable roads.
- Expected behaviour of the car.
- How to avoid unwanted situations during transport.

Wanting to use functions:
❷ lights,
❸ wheels (includes steering),
❹ brakes,
❺ motor.

Car technician goal: having the car workable for the driver.
- Adjusting technical implementations as far as possible on requests by the driver.
- Only the way it should behave explaining to the driver.

Creating and maintaining:
❷ lights,
❸ wheels (including steering),
❸ brakes,
❹ motor.

	HOS	Mdl	NwC
C	👐	👐	👐
I	👐	👐	👐
A	👐	👐	👐

⚒ Issue: wiki gap for understanding middleware architecting & engineering

Wiki tools are common approaches, to add:

Unique identifier
Categorization conforming:
technical requirements - specifications in a nine plane
Explanation in used language for:
the Strategy-Tactical-Operational Steer-Shape-Server nine plane
Embedding in the abes metadata

	BmV	Vsp	DaP
F	👐	👐	👐
C	👐	👐	👐
T	👐	👐	👐

⚒ Issue: wiki gap for understanding Information processes architecting & engineering

Wiki tools are common approaches, to add:

Unique identifier
Categorization conforming:
technical requirements - specifications in a nine plane
Explanation in used language for:
the Strategy-Tactical-Operational Steer-Shape-Server nine plane
Embedding in the abes metadata

Y-1.6 Jabes maturity

The ecosystem Jabes is about:

Foundation: Several metadata frameworks
Foundation: regulation and supervision on usage
Commercials: trade by interactions exchange at content
Commercials: maturity auditing of product & processes

The components are all by bootstrapping artifacts using metadata having a maturity level. Functionality building up by bootstrapping completing and improving continously.

Y-1.6.1 👁 The organisation in a nine-plane

Interactions are either instructed by autority (vertical) or by regulated work alignment at the same context level (horizontal).
A nine-plane for actions and materialized artifacts:
Jabes within the 9plane

A figure:
See right side

Y-1.6.2 👁 Continuous improvement of the organisation

Jabes completing and improving continously process is a cycle interacting with customers with thier goal of information processing.
A nine-plane for actions,e volatile moments:
devops Jabes

A figure:
See right side

Y-1.6.3 👁 Maturity: frameworks, applications

💡❗✅ Building Jabes

The building of Jabes will be a lot of pioneering. A bootstrap approach while developing the product is possible.

I have several ideas worked out into more details. The whole approach of a Jabes prodcut is needing several types of persons to realize for the magnitude and scope.

Needed is a team with more competencies I have.
An idea for composing a team:

An enthusiastic performer understanding Jabes able to promote the product to prospects.
A data enthusiast helping in selecting and configuring the backend database.
An agile / lean person translating what is currently done into Jabes.
Data scientist defining and using the information that is generated into stories that are predictive prescriptive.
Designer front end user interface.
Legal support for running a business.
Financial administration also doing support in choices.
...(what we will hit during the adventure)...

Some properties to implement are:

The database should support blob artifacts aside the classic elements for free formatted content. Free fomratted content could be a pdf or jpg file.
The used metadatamodel for possible elements should become standardized one.
Exporting and importing to other databases based on a product identification should be easily possible.
The product identification is to be retrieved from a registrar or using a range for local usage.

There are artifacts mentioned that should not part of the venture building the product.
These two artifacts with the jabes framwork should be isolated into foundations.

⏳ Using Jabes

Jabes could be build in a bootstrap approach.
This is the current state, nothing being build yet.
A pity because there are many frameworks but there are hardly tools supporting those in a holistic approach. The result is:

When information is created it is difficult to find it again when it is needed.
From the coast saving argument the required information is avoided to get created.
From challenges in managing required information it is avoided to get created although there are mandatory obligations.
No one is going for an improvement initiative, for everybody being a frontrunner is a financial and operational risk.

Y-2 Jabes Metadata

Y-2.1.1 Demand: backlog, proposals, issues

Building a product for storing, manipulating, export, import, information requires a data model and a metadata model.
Metadata for PMIT (technology) , PPIC (information value stream) are the ones most appealing.

🎭 Y-2.1.1 Knowing what is going on

⚒ Knowledge: prodcut specifications

A simple requirement to know from each prodcut:

Strategic specficiations
Tactical specficiations
Operational specficiations

Note the hierarchical approach, it allows different kind of perspectives.
The intention is: not ❌ matching this to hierarchical authority.

⚖ Decision for product knowledge

The simple knowledge question for specifications is not that easy. The needed information is scattered and diffuse in locations and used type of documents. The practice of building software of not documenting anything because of achieving deadlines of deliveries, doesn´t help.
To decide: centralise all what is there under a identification of the product.

hyperlinks when the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining content on specifications into a jabes database.
What is the game changer in this?
✅ ⚠ Getting better knowledge what the specifications / expectations on products are.
💰 ⚠ This is an investment to enable changes, there is no immediate advantage.

🎭 Y-2.1.2 Determining opportunities feeded by suggestions

⚒ Knowledge: Proposals, issues

A simple requirement to know for each product:

Strategic suggestions
Tactical suggestions
Operational suggestions

Note the hierarchical approach, it allows different kind of perspectives.
The intention is: not ❌ matching this to hierarchical authority.

⚖ Decisions for suggestions knowledge

The simple knowledge question for suggestions is not that easy. The needed information is scattered and diffuse in locations and used type of documents. The practice of building software of not documenting anything because of achieving deadlines of deliveries, doesn´t help.
To decide: centralise all what is there under a identification of the product.

hyperlinks when the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining content by issues proposals into the jabes database. It is a suggestion box these days often indicated as the backlog.
What are the game changers in this?
✅ 🚧 There is an applied categorization by design in place for identified products.
✅ ⚠ Incidents & problems are known in the ITIL framework, but there is no way to get those aligned with decisionmakers for changes.
💰 ⚠ This is an investment to enable changes, there is no immediate advantage.

🎭 Y-2.1.3 Explainable decisions: demand

⚒ Decisions for change

Decisionmakers have by the previous information:

knowledge on the products and their specifications
knowledge of suggestions by experiences or new ideas

What additional wanted is known as:

"BI&AmpA business intelligence information", predictions for the change outcome

⚖ Monitoring the change process

✅ 🚧 Any change is not possible in a single cycle, many cycles will be needed.
⚠ 💰 Doing a change without knowing how to monitor the progress is a root cause for too many uncertainties going into failures. Failing fast can minimize impact with failures.
Good practice is better: knowing what is going on and what to expect.

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining of requirements into the jabes database:

Strategic requirements
Tactical requirements
Operational requirements

❷ Defining, & maintaining in the jabes database how content by:

ideas, issues suggestions are connected to requirements
existing specifications are connected to requirements

What is the game changer in this?
🎯 Changes are well explainable controlled.

Y-2.2 Design: product building - validations

🎭 Y-2.2.1 Change initiation

⚒ Activating teams for a change

After decisionmakers have approved the change and it is initiated. Additional requirements are possible during the project. Engineering and validation teams can start using:

Strategic requirements,
Tactical requirements,
Operational requirements,

Design for build and design for validation.

⚖ Monitoring the design process

Knowing how the change process is evolving for what is done and what is planned is important information for feed-back. Registration actions, documenting progress is a requirement to do underpinned analyses and reporting.
✅ 🚧 Any design is not possible in a single cycle, many cycles will be needed.

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & progress building design into the jabes database.
❷ Defining, & progress building validations design into the jabes database.
What are the game changers in this?
🎯 Design build and design validations are well explainable controlled.
🎯 Design build and design validations are executed in parallel.
🎯 Activities can start without all materials components in place.

🎭 Y-2.2.2 Product build design

⚒ Creating, engineering product design

There are many choices during design, build & validation.

build artifacts in house from available raw material
use components / materials from others. Bill of materials (bom)
How to realise compliance aspects from the requirements

⚖ Monitoring the design build process

⚠ 💰 Doing design without documenting that is useless. Not knowing progress is unpractical by all uncertaintities. Failing fast can minimize impact with failures.
Good practice is better: knowing what is going on and what to expect.

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining of build design into the jabes database:

Strategic design
Tactical design
Operational design

Content can be:

hyperlinks where the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

What are the game changers in this?
✅ 🚧 There is an applied categorization by design in place for identified designed artifacts.
✅ 💰 common usual practice: using ad-hoc office tools or placed without references in code.
💰 ⚠ This is an investment to fulfil compliance requirements. The construction design uses a standard approach instead of one of many the ad-hoc ones.

🎭 Y-2.2.3 Product validation design

⚒ Creation validation design

There are many options for validations:

Verify used components / materials (bom) from others on their specifications
Combine several functional requirements for validations ignoring technology details
Focus on only technology details ignoring functionality (compliance aspects).

⚖ Monitoring the design validation process

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining of vaidations design into the jabes database:

Strategic validations
Tactical validations
Operational validations

Content can be:

hyperlinks where the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

What are the game changers in this?
✅ 🚧 There is an applied categorization by design in place for identified validation artifacts.
✅ 💰 common usual practice: using ad-hoc office tools for this.
💰 ⚠ This is an investment to fulfil compliance requirements. The validation design is using a standard approach instead of one of many the ad-hoc ones.

Y-2.3 Build: product & validate

🎭 Y-2.3.1 Product build realisation

⚒ Realisation - validation execution

After anything has been desinged it can be realised. As soon the realisation of an artifact is done, a component is delivered it can be validated. Engineering and validation teams can plan their activity for what is possible and what has priority:

Strategic realisations,
Tactical realisations,
Operational realisations,

Realisations in the engineered construction and their validations.

⚖ Monitoring the design realisation, validations executions

⚠ 💰 Doing realisations without documenting the constrcution and validation results, is useless. Not knowing progress is unpractical by all uncertaintities. Failing fast can minimize impact with failures. Good practice is better: knowing what is going on and what to expect.

A figure:
See right side

⚙ To build Jabes product

❶ Defining construction results from engineering design into the jabes database.
❷ Defining validation results from validations design into the jabes database.
What are the game changers in this?
🎯 The construction of engineered design is well explainable controlled.
🎯 Validations validations are clear, usable to transform into specficiations.
🎯 A engineering mistake is possible quickly corrected or mitigated.

🎭 Y-2.3.2 Product validate Materials

⚒ Quality assurance Materials

The quality of materials, from other parties retrieved sources, should be:

According at least expected specifications in the design or better
According at least expected specifications of the supplier or better
being a well documented item for the resulting product object

⚖ register used materials quality for the product

⚠ 🕳 Not ❌ knowing the quality of used materials for the product is showing a gap in compliancy, legal accountability. It will be a matter of time this gap will be a mandatory solved by regulations when it not already so.

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining material validations results into the jabes database:

Strategic validation results
Tactical validation results
Operational validation results

Content can be:

hyperlinks where the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

What are the game changers in this?
✅ 🚧 There is an applied categorization by design in place for validation results.
✅ 💰 common usual practice: using ad-hoc office tools or avoid to do this.
💰 ⚠ This is an investment to fulfil compliance requirements. These compliancy requirements might be not in place at the moment. They expectation is: this will become common like all mature market products. The validation results use a standard approach.

🎭 Y-2.3.3 Product validate Artifacts

⚒ Quality assurance build artifacts

The quality of build artifacts, composed in the construction should be:

According at least expected specifications in the design or better
According at least expected specifications by compliance requirements or better
being a well documented item for the resulting product object

⚖ register produced artifact quality for the product

⚠ 🕳 Not ❌ knowing the quality of produced artifacts for the product is showing a gap in compliancy, legal accountability. It will be a matter of time this gap will be a mandatory solved by regulations when it not already so.

A figure:
See right side

⚙ To build Jabes product

❶ Defining, & maintaining composed artifact validations results into the jabes database:

Strategic validation results
Tactical validation results
Operational validation results

Content can be:

hyperlinks where the specifciations are stored at a reliable persavive location
Embedded documents (blob - binary long objects) into the jabes database (persavive)

What are the game changers in this?
✅ 🚧 There is an applied categorization by design in place for composed artifact results.
✅ 💰 common usual practice: using ad-hoc office tools or avoid to do this.
💰 ⚠ This is an investment to fulfil compliance requirements. These compliancy requirements might be not in place at the moment. They expectation is: this will become common like all mature market products. The validation results use a standard approach.

Y-2.4 Consolidate into specifications - operations

🎭 Y-2.4.1 Product service evaluation

⚒ Evaluation of the new product

When a changes and validations are finished, being done, the decision to accept it as the new product is the final step.
After that:
❶ Register the new product wiht at least a unique version identifier.
❷ Consolidation of the construction details engineering details in the jabes database into the specfication area.

⚖ Get the new product published to who should be informed

There are possible mandatory regulations in place to fulfil this legal action.
When there is processing of personal information done, this is becoming a usual requirement.

A figure:
See right side

⚙ To build Jabes product

The consolidation process, all tabels and metadata should exist.
What is the game changer in this?
🎯 Products are well controlled.
🎯 Products are well documented.
🎯 Products legal obligations are fulfilled.

🎭 Y-2.4.2 Usage in the operation cycle

⚒ Evaluation of the new product

When the product is active in the operational cycle, not everything will be perfect.
What to do:

be aware of incidents and problems, don&actet ingore them.
solve issues that have known root causes.
escalate issues with unknown root causes.

The quality of the service is not expected to be stable, the operational process is to be monitored.

⚖ Strategic alignment

There are three operational cycles to manage :

Correct processing conform specificiations, capacity monitoring & forecasting.
Incorrect processing, failing by specifications or by wrong expectations.
Change of the processing technology or change of functionality.

The visuslisations for these three are look alikes.

Question: Why is there not something diagonal in the communications between the parties ❓
For an escalation with a impossible outcome to achieve nothing:
💣 bypass engineering, bypass customer relations. Validation and the enabler decide anything.
💣 bypass enablement, bypass validation. Engineering and customer relations decide everything.

Strategic alignment Venkatraman ea
12 manage venkatraman

Venkatraman ea argue in 1993 that the difficulty to realize value from IT investments is:
❶ firstly due to the lack of alignment between the business and IT strategy of the organizations that are making investments, and
❷ secondly due to the lack of a dynamic administrative process to ensure continuous alignment between the business and IT domains.

(yellow) Strategy Execution: Business is strategy formulator, IT is implementor follower.
(red) Technology Potential: Business strategy drives IT strategy, the organisaton follows.
(green) Competitive Potential: emerging IT capabilities drives new business strategy.
(blue) Service Level: The role of business strategy is indirect. "It should work."

Proceed: running the operational process, attention for incorrect processing to manage.

A figure:
See right side

⚙ To build Jabes product

None, the cycle is closed.
✅ Jabes is filling the gap of a dynamic administrative process.

What is the game changer in this?
🎯 An imporves process in operation.

🎭 Y-2.4.3 Knowing what is going on

A figure:
See right side

⚙ To build Jabes product

None, the cycle is closed.

What is the game changer in this?
🎯 A next controlled iteration for change optional to start.

Y-2.5 Decoupled ERP connections

Having a product, Jabes, that supports life cycles of:

Technology: Platforms - middelware tools,
Functionality: Information / data products,
Product: portfolio complete with specfications,
Product: construction usage instructions,

is no guarantee of correct usage of the Jabes product.
Knowing what to do, what has been done, is important information for improvements in the life cycle processes.

📚 Y-2.5.1 Completeness of metadata artifacts

Adding ERP & maturity

Question is this all that is needed ❓ For Enterprise resource planning (ERP), customer relations (ERP), Security information &event monitoring (SIEM SOAR) there are many solutions in the market.

		⟳ A ⇅
	PMOV	PMIT	*-CMM
I ⇄	PPIC		PPIC	⇄ R
	PPVS	ERP	ERP
		⇅ S ⟳

Use existing ERP solutions in their area of interest.
Just placing the Metadata identifiers in a nine-plane in the SIAR canvas.

Every plane, area of interest, is covered.
What is the game changer ❓
🎯 Focus on information value streams (PPIC).
🎯 Focus on technology enabling value streams (PMIT).
🎯 Focus on maturity of components and the organisation (*-CMM).

📚 Y-2.5.2 Technology - Functionality, data products

Technology focus (PMIT)

For the technology the context is about technology aspects. The demand, transformation backend-frontend and delivery are similar.
Different:

Control Asses - Enable

A figure:
See left side

Functionality focus

For the information value stream the context is about functional aspects. The demand and delivery are similar. The accountability and responsiblity are important to have clear.
Different:

Transformation backend-frontend
Control Asses - Enable

A figure:
See right side

📚 Y-2.5.3 Analytical plane - Operational plane, BI&A

BI&A datawarehouse

Not knowing what is going on is bad. The usual approach is building a huge environment for BI&A reporting. This is a bizar approach not known, not seen in lean agile.
💡❗✅ Simplify operational monitoring in the analytical plane.
From: "Data Mesh Delivering Data-Driven Value at Scale" (book), the data (product) quantum.
Data mesh- data product

A figure:
See left side

BI&A analytical plane:
🎯 Add a control connection at transformation process. (control: speed, safety)
🎯 Add a monitoring connections at transformation process (show: speed, safety, capacity)
For the moment: very classic basic and modern.

A figure:
See right side

BI&A analytical plane:
🎯 Use activators control, mesh experience, for the process. (speed, safety)
🎯 Add dashboarding, mesh experience, for the process (speed, safety, capacity)
For the moment: very classic basic and modern.

Y-2.6 Jabes Metadata maturity

The ecosystem Jabes is about:

Foundation: Several metadata frameworks
Foundation: regulation and supervision on usage
Commercials: trade by interactions exchange at content
Commercials: maturity auditing of product & processes

The components are all by bootstrapping artifacts using metadata having a maturity level. Metdata building up by bootstrapping completing and improving continously.

⚒ Y-2.6.1 Cargo Cult

Pretending being in control

Just following: "There is nothing quite so useless, as doing with great efficiency, something that should not be done at all." The question: Cargo Cult Agile or a true Agile Mindset? (Kasia Bartos)
Jabes generic process

When it is hard to notice the difference between the Daily Scrum and the classical “status update for the manager”, we can feel that something is not right.
When team members are complaining that “Scrum Events take up so much time, while we have work to do”, then it is easy to figure out, that there is no buy-in among employees for the whole idea of Scrum and some important ingredient is missing: the Agile Mindset needs to be developed. When Scrum is done without promoting the real Agile Values, we might be dealing with Cargo Cult Agile. I would add that there is possible something wrong with the promoted agile behaviour.

Source: Feynman, Richard P. (June 1974). "Cargo Cult Science":
In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they´ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas -he´s the controller- and they wait for the airplanes to land.
They´re doing everything right.
- The form is perfect.
- It looks exactly the way it looked before.
- But it doesn´t work. No airplanes land.
So I call these things cargo cult science, because they follow all the apparent precepts and forms of scientific investigation, but they´re missing something essential, because the planes don´t land. If you expect motivated proficient autonomous staff and doing micromanagement there is a contradiction. The real question for help would be solving the essentials.

👁 Y-2.6.2 Maturity: frameworks, applications

💡❗✅ Building Jabes

The building of Jabes will be a lot of pioneering. A bootstrap approach while developing the product is possible.
Metdata is scoped in the nine- plane covered by the SIAR cycle.
Changing content in Jabes application should be done by staff responsible for the activity. When there are desing and build steps involved both are part of the same team.

💡❗✅ Local Meta

Tables for a Jabes database are mentioned with their goals relationship and intentions for usages.
Wat is not on this page:

metadata contend for PMIT (technology middleware)
metadata contend for PPIC (functional information flow)

The PMIT was tried using Word and that looked very promising.
To do: pages with content from that POC (proof of Concept).

🎭 Y-2.6.3 Information contracts

⚒ data warehouse

The data warehouse data-lake is concept being in use has no logical source for his function.
A mindset change is needed.
❶ Needed is storage for the new analytics plane content.
This is not a copy from operational information but new created information from sensors in the data (product) quantum.
❷ A data warehouse concept conform agile lean is needed.
The data warehouse has the logical function of balancing the work in process in the information value stream.
❸ change:
When new information is created applied in the operational plane it should be archived in the operational plane.
❹ change:
When new information is created and used by others in a chain a logical chain should be presetn in an operational plane.

⚒ Data contracts

Data / information contracts is about:

Who is accountable for what kind of information
Who is responsible for what kind of information
What are the restrictions with the information usage
What are the retention policies for the information
For what moments(When) the delivery is agreed to what location
what are the access logging obligations
what is the cost alignment
Additional legal obligations

📚 Y-2.6.4 External references

Global compliancy

These references are at the index, thea are a shared interest.

Local references

The focus is on the science behind process life cycles.
A limited list:

link , newstopic interest	who, source	date
Cargo Cult Science	Feynman, Richard P.	(June 1974)
A Solid Foundation for Business Agility with Disciplined Agile The PMBOK® Guide—our flagship publication	PMI
Data Mesh Delivering Data-Driven Value at Scale	Zhamak Dehghani (book)	(2019)
Data Mesh, a Gentle Revolution in Data Management	Guillaume Bodet	Zeena 2024
VUCA is an acronym that stands for volatility, uncertainty, complexity and ambiguity qualities that make a situation or condition difficult to analyze, respond to or plan for. Understanding how to mitigate these qualities can greatly improve the strategic abilities of a leader and lead to better outcomes.	Techtarget	202302
BANI vs. VUCA: How Leadership Works in the World of Tomorrow The BANI model goes a step further and helps companies consider the chaotic and completely unpredictable impacts that can have a major impact on their operations.	WU Executive Academy of Vienna	202210

Y-3 Maturity

Y-3.1 Muda Mura Muri

Going for lean, agile, doing more with less is mostly about cost saving. Only having the focus on cost saving is not real lean. The leading example or lean is TPM, toyota car manufacturing (Japan). That approach embraces avoiding evils. Similar to the "law of conservation of energy" there is "law of conservation of evil". 🤔 waste, the only problem ❓

⚖ Y-3.1.1 Enabling motivating the workforce

Work to do: solving cultural challenges by their root-causes.
(N.Dean Meyer) Poor teamwork is rarely a matter of interpersonal difficulties, or a lack of knowledge of how to work together. This is why so many teambuilding efforts produce sparse results.
The right way to build high-performance, cross-boundary teamwork is to get to fundamentals. Find out why the nice people in your organization don't team, and then address the root causes of incentives, culture, structure, and the internal economy.
A shortlist:

Real Reason 1: Incentives
Real Reason 2: Culture
Real Reason 3: Structure
Real Reason 4: Resources

See also elucidation: "E-1.3.1 Recognizing the 3M evils"

⚙ Y-3.1.2 3M Technology

⚒ Recognizing the three evils

❌ I - Processes & information
✅ T - Tools, Infrastructure
❌ C - Organization optimization

This is a copy from: "T-1.6.2 Incentives, Culture, Structure, Resources"
Basic principles are at elucidation: "E-1.6 Maturity 3: three DTAP layers (ICT ITC)"
Details for underpinning why these issues are important are in that technology chapter "SDLC: design - devops".

Maturity id	SubId	Source	Context
CMM-4IT -0-Muda			Waste
	SDLC-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-3	T-2.3.2 DLC data life cycle	Conceptual
	STRC-1	T-2.4.2 Steer Shape Serve - within technology pillar	Structural
	STRC-2	T-2.5.3 Identity Access	Structural
	STRC-3	T-1.3.2 Running, Maintaining - Developing Building	Structural
CMM-4IT -0-Mura			Uneveness
	SDLC-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-2	T-2.3.1 ALC middleware	Conceptual
	DTAP-3	T-2.3.2 DLC data life cycle	Conceptual
	STRC-1	T-2.4.2 Steer Shape Serve - within technology pillar	Structural
	STRC-2	T-2.5.3 Identity Access	Structural
	STRC-3	T-1.3.2 Running, Maintaining - Developing Building	Structural
CMM-4IT -0_Muri			irrationality
	SDLC-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	SDLC-2	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-1	T-1.3 Lean Agile: Vmap dimensions & perspectives	Conceptual
	DTAP-2	T-2.3.1 ALC middleware	Conceptual
	DTAP-3	T-2.3.2 DLC data life cycle	Conceptual
	STRC-1	T-2.4.2 Steer Shape Serve - within technology pillar	Structural
	STRC-2	T-2.5.3 Identity Access	Structural
	STRC-3	T-1.3.2 Running, Maintaining - Developing Building	Structural

⚒ Fighting & Decreasing the three evils

This is a never-ending story full off uncertainty with a lot of surprises.
When nobody does it an unmanageable anarchy is a possible outcome, harming everybody. When somebody is doing it he could get blamed and exiled for his actions. The best option would be anybody is doing it, ⚠ do not expect that too happen.

⚙ Y-3.1.3 3M Information (organisation) and Technology

⚒ Recognizing the three evils

✅ P - Processes: cyber/adminstrative
❌ T - Managing technology service
❌ O - Organization optimization

This is a copy from: "B-1.6.2 Incentives, Culture, Structure, Resources" (to do)
Basic principles are at elucidation: "E-2.6 Maturity 4: Data Driven Processes"
Details for underpinning why these issues are important will be in that business chapter "BPM: design - devops".

Maturity id	SubId	Source	Context
CMM-4AS -0-Muda			Waste
	MCRM-1	B-1.2.3 Avoid micro management	Conceptual
	MCRM-2	B-1.2.3 Empower staff	Conceptual
	MCRM-3	B-1.2.3 Focus ➡ core competencies.	Conceptual
	RACI-1	B-1.2.3 Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-1.2.3 Tasks, roles, aligned to accountabilities.	Conceptual
	CYBR-1	B-1.3.1 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	B-1.3.1 Cyber mindset to value streams	Conceptual
	SRVT-1	B-1.3.3 Information functional process technology alignment	Organisational
	SRVT-2	B-1.3.3 Information safety & regulations	Organisational
	SRVT-3	B-1.3.3 Information operational process technology alignment	Organisational
	CYBR-3	B-1.3.4 Involved staff: understanding, using feedback loops	Conceptual
CMM-4AS -0-Mura			Uneveness
	MCRM-1	B-1.2.3 Avoid micro management	Conceptual
	MCRM-2	B-1.2.3 Empower staff	Conceptual
	MCRM-3	B-1.2.3 Focus ➡ core competencies.	Conceptual
	RACI-1	B-1.2.3 Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-1.2.3 Tasks, roles, aligned to accountabilities.	Conceptual
	CYBR-1	B-1.3.1 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	B-1.3.1 Cyber mindset to value streams	Conceptual
	SRVT-1	B-1.3.3 Information functional process technology alignment	Organisational
	SRVT-2	B-1.3.3 Information safety & regulations	Organisational
	SRVT-3	B-1.3.3 Information operational process technology alignment	Organisational
	CYBR-3	B-1.3.4 Involved staff: understanding, using feedback loops	Conceptual
	STRC-1	B-1.3.4 Functional Sensors information value stream	Structural
	STRC-2	B-1.3.4 Technical Sensors information value stream	Structural
	STRC-3	B-1.3.4 Functional Metrics information value stream	Structural
	STRC-4	B-1.3.4 Technical Metrics information value stream	Structural
CMM-4AS -0_Muri			irrationality
	MCRM-1	B-1.2.3 Avoid micro management	Conceptual
	MCRM-2	B-1.2.3 Empower staff	Conceptual
	MCRM-3	B-1.2.3 Focus ➡ core competencies.	Conceptual
	RACI-1	B-1.2.3 Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-1.2.3 Tasks, roles, aligned to accountabilities.	Conceptual
	CYBR-1	B-1.3.1 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	B-1.3.1 Cyber mindset to value streams	Conceptual
	SRVT-1	B-1.3.3 Information functional process technology alignment	Organisational
	SRVT-2	B-1.3.3 Information safety & regulations	Organisational
	SRVT-3	B-1.3.3 Information operational process technology alignment	Organisational
	CYBR-3	B-1.3.4 Involved staff: understanding, using feedback loops	Conceptual
	STRC-1	B-1.3.4 Functional Sensors information value stream	Structural
	STRC-2	B-1.3.4 Technical Sensors information value stream	Structural
	STRC-3	B-1.3.4 Functional Metrics information value stream	Structural
	STRC-4	B-1.3.4 Technical Metrics information value stream	Structural

⚒ Fighting & Decreasing the three evils

⚙ Y-3.1.4 3M Information Communication and Technology

⚒ Recognizing the three evils

❌ T - Technology service alignment
✅ I - Improve organization to optimization
❌ P - Processes: cyber/adminstrative

This is a copy from: "A-1.6.2 Incentives, Culture, Structure, Resources"
Basic principles are at elucidation: "E-3.6 Maturity 5: Organization Optimization"
Details for underpinning why these issues are important will be in that business chapter "Analytics: design - devops".

Maturity id	SubId	Source	Context
CMM-4OO -0-Muda			Waste
	ORRM-1	A-1.2 Promote get strategical support for feed-back loops OR	Conceptual
	ORRM-2	A-1.2 Get support & implement operational feed-back loops	Conceptual
	ORRM-3	A-1.2 Get support & implement tactical feed-back loop	Conceptual
	ORRM-3	A-1.2 Get support & implement strategical feed-back loop	Conceptual
	MCRM-1	A-1.3.1 Avoid micro management	Conceptual
	MCRM-2	A-1.3.1 Empower staff using real Lean	Conceptual
	CYBR-1	A-1.4 A-1.5 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	A-1.4 A-1.5 Cyber mindset to value streams	Conceptual
	STRC-1	A-1.3.3 A-1.4 Functional Sensors information value stream	Structural
	STRC-2	A-1.3.3 A-1.4 Technical Sensors information value stream	Structural
	STRC-3	A-1.3.3 A-1.4 Functional Metrics information value stream	Structural
	STRC-4	A-1.3.3 A-1.4 Technical Metrics information value stream	Structural
	RACI-1	A-1.5 Clear accountabilities responsibilities value stream	Conceptual
	RACI-2	A-1.2.2 Tasks, roles, aligned to accountabilities.	Conceptual
CMM-4OO -0-Mura			Uneveness
	ORRM-1	A-1.2 Promote get strategical support for feed-back loops OR	Conceptual
	ORRM-2	A-1.2 Get support & implement operational feed-back loops	Conceptual
	ORRM-3	A-1.2 Get support & implement tactical feed-back loop	Conceptual
	ORRM-3	A-1.2 Get support & implement strategical feed-back loop	Conceptual
	MCRM-1	A-1.3.1 Avoid micro management	Conceptual
	MCRM-2	A-1.3.1 Empower staff using real Lean	Conceptual
	CYBR-1	A-1.4 A-1.5 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	A-1.4 A-1.5 Cyber mindset to value streams	Conceptual
	STRC-1	A-1.3.3 A-1.4 Functional Sensors information value stream	Structural
	STRC-2	A-1.3.3 A-1.4 Technical Sensors information value stream	Structural
	STRC-3	A-1.3.3 A-1.4 Functional Metrics information value stream	Structural
	STRC-4	A-1.3.3 A-1.4 Technical Metrics information value stream	Structural
	RACI-1	A-1.5 Clear accountabilities responsibilities value stream	Conceptual
	RACI-2	A-1.2.2 Tasks, roles, aligned to accountabilities.	Conceptual
CMM-4OO -0_Muri			irrationality
	ORRM-1	A-1.2 Promote get strategical support for feed-back loops OR	Conceptual
	ORRM-2	A-1.2 Get support & implement operational feed-back loops	Conceptual
	ORRM-3	A-1.2 Get support & implement tactical feed-back loop	Conceptual
	ORRM-3	A-1.2 Get support & implement strategical feed-back loop	Conceptual
	MCRM-1	A-1.3.1 Avoid micro management	Conceptual
	MCRM-2	A-1.3.1 Empower staff using real Lean	Conceptual
	CYBR-1	A-1.4 A-1.5 Cyber mindset staff, no physical artefacts	Conceptual
	CYBR-2	A-1.4 A-1.5 Cyber mindset to value streams	Conceptual
	STRC-1	A-1.3.3 A-1.4 Functional Sensors information value stream	Structural
	STRC-2	A-1.3.3 A-1.4 Technical Sensors information value stream	Structural
	STRC-3	A-1.3.3 A-1.4 Functional Metrics information value stream	Structural
	STRC-4	A-1.3.3 A-1.4 Technical Metrics information value stream	Structural
	RACI-1	A-1.5 Clear accountabilities responsibilities value stream	Conceptual
	RACI-2	A-1.2.2 Tasks, roles, aligned to accountabilities.	Conceptual

⚒ Fighting & Decreasing the three evils

Y-3.2 Technology

Only having the focus on IT4IT, getting a mature Technology Life Cycle Management (LCM) requires understanding an acknowledgment of layered structures.
Understanding an acknowledgment of the ALC-V* types .
Dedicated characteristics for:

This technology pillar
Each layer in this technology pillar
Way to manage this technology pillar

⚖ Y-3.2.1 Technology enablement

There are several challenges. They are a complex myriad on their own:

DTAP approaches maturity for LCM additional distinct layers

⚒I landing zone processes 👉🏾 Operational plane
⚒T hardware- operating system 👉🏾 Tools middelware
⚒C landing zone monitoring 👉🏾 Analytical plane

SDLC compliancy maturity layers

⚒I Operational plane 👉🏾 Functional processing
⚒T Tools middelware 👉🏾 CIA conforming
⚒C Analytical plane 👉🏾 Measuring functionality

Functional maturity

⚒T Up to date 👉🏾 Infrastructure
⚒I Cots vs "build" 👉🏾 Processes - functionality
⚒C Regulations 👉🏾 SDLC maturity layers

⚙ Y-3.2.2 Maturity fundaments technical infrastructure

⚒ Solving impediments

From the three ICT, ITC interrelated scopes:

❌ I - processes & information
✅ T - Tools, Infrastructure
❌ C - Organization optimization

This is a copy from: "T-1.6.3 Maturity fundaments technical infrastructure"
Basic principles are at elucidation: "E-1.6 Maturity 3: three DTAP layers (ICT ITC)"
Details for underpinning why these issues are important are in that technology chapter "SDLC: design - devops".

Maturity id	SubId	Source	Context
CMM-4IT-1			Network
	C1	T-1.4 On Premise services	Segmentation, zones, isolation
	A1	T-1.4 On Premise services	maximum single speed
	A2	T-1.4 On Premise services	Total throughput
	C2	T-1.4 On Premise services	Encryption
	I1	T-1.4 On Premise services	Robustness
	I2	T-1.4 On Premise services	Virtualisation impact
	C5	T-1.5 Software as a Service - Cloud	Segmentation, zones, isolation
	A5	T-1.5 Software as a Service - Cloud	maximum single speed
	A6	T-1.5 Software as a Service - Cloud	Total throughput
	C6	T-1.5 Software as a Service - Cloud	Encryption
	I5	T-1.5 Software as a Service - Cloud	Robustness
	I6	T-1.5 Software as a Service - Cloud	Virtualisation impact
CMM-4IT-2			Machines
	A1	T-1.4 On Premise services	CPU
	A2	T-1.4 On Premise services	Volatile Memory
	A3	T-1.4 On Premise services	Persistent Storage sizing
	A4	T-1.4 On Premise services	Persistent Storage throughput
	C1	T-1.4 On Premise services	Robustness
	C2	T-1.4 On Premise services	Recoverability
	I1	T-1.4 On Premise services	Virtualisation impact
	A5	T-1.5 Software as a Service - Cloud	CPU
	A6	T-1.5 Software as a Service - Cloud	Volatile Memory
	A7	T-1.5 Software as a Service - Cloud	Persistent Storage sizing
	A8	T-1.5 Software as a Service - Cloud	Persistent Storage throughput
	C5	T-1.5 Software as a Service - Cloud	Robustness
	C6	T-1.5 Software as a Service - Cloud	Recoverability
	I1	T-1.5 Software as a Service - Cloud	Virtualisation impact
CMM-4IT-3			operating system
	C1	T-1.4 On Premise services	Segmentation, zones, isolation
	A1	T-1.4 On Premise services	DNS central repository
	A2	T-1.4 On Premise services	Identities central repository
	C2	T-1.4 On Premise services	DNS central repository
	C3	T-1.4 On Premise services	Identities central repository
	I1	T-1.4 On Premise services	Robustness
	I2	T-1.4 On Premise services	Middleware Connections
	C5	T-1.5 Software as a Service - Cloud	Segmentation, zones, isolation
	A5	T-1.5 Software as a Service - Cloud	DNS central repository
	A6	T-1.5 Software as a Service - Cloud	Identities central repository
	C6	T-1.5 Software as a Service - Cloud	DNS central repository
	C7	T-1.5 Software as a Service - Cloud	Identities central repository
	I5	T-1.5 Software as a Service - Cloud	Robustness
	I6	T-1.5 Software as a Service - Cloud	Middleware Connections

⚒ Flow Orchestration

To increase the flow when the fundamental technical infrastructure are the root cause of the withholding for increasing mission values, try to pinpoint. Adding more hardware is a simple and often not too costly.
⚠ The downside of this easy approach is that is often not the real bottleneck. In that case the problems will not decrease but will increase. Capacity for solving issues is only available with limitations.

⚙ Y-3.2.3 Maturity Planes: Technology, Operational, Analytical

⚒ Solving impediments

From the three ICT, ITC interrelated scopes:

✅ I - processes & information
✅ T - Tools, Infrastructure
❌ C - Organization optimization

This is a copy from: "T-2.6.2 Maturity Planes: Technology, Operational, Analytical"
Basic principles are at elucidation: "E-1.6 Maturity 3: three DTAP layers (ICT ITC)"
Details for underpinning why these issues are important are in that technology chapter "SDLC: design - devops".

Maturity id	SubId	Source	Context
CMM-4IT-4			Tools, Middelware
	C1	T-2.2.1 ALC-V1 Technical	Data governance
	C2	T-2.2.2 ALC-V2 Technical	Data governance
	C3	T-2.2.3 ALC-V3 Technical	Data governance
	C4	T-2.3.3 Data / Information provisioning	Data governance
	C5	T-2.3.1 ALC middleware	Technology
	I5	T-2.3.1 ALC middleware	Technology
	A5	T-2.3.1 ALC middleware	Technology
	C6	T-2.5.3 Identity Access	Security
	S1	T-1.6.2 Incentives, Culture, Structure, Resources	Structure
CMM-4IT-5			Operational plane
	C1	T-2.2.1 ALC-V1 Technical	Data governance
	C2	T-2.2.2 ALC-V2 Technical	Data governance
	C3	T-2.2.3 ALC-V3 Technical	Data governance
	C1	T-2.2.1 ALC-V1 Technical	Data governance
	C2	T-2.2.2 ALC-V2 Technical	Data governance
	C3	T-2.2.3 ALC-V3 Technical	Data governance
	C5	T-2.3.1 ALC middleware	Technology
	I5	T-2.3.1 ALC middleware	Technology
	A5	T-2.3.1 ALC middleware	Technology
	C6	T-2.5.3 Identity Access	Security
	S1	T-1.6.2 Incentives, Culture, Structure, Resources	Structure
CMM-4IT-6			Analytical plane
	C1	T-2.2.1 ALC-V1 Technical	Data governance
	C2	T-2.2.2 ALC-V2 Technical	Data governance
	C3	T-2.2.3 ALC-V3 Technical	Data governance
	C5	T-2.3.1 ALC middleware	Technology
	I5	T-2.3.1 ALC middleware	Technology
	A5	T-2.3.1 ALC middleware	Technology
	C6	T-2.5.3 Identity Access	Security
	S1	T-1.6.2 Incentives, Culture, Structure, Resources	Structure

⚒ Flow Orchestration

Having multiple parties involved the misunderstanding on:

goals for organisational missions
Technical goals for perfection

Are a key factor for decisions, there is:

The easy way is shallow: sufficient is good enough as start.
⚠ Wat looks sufficient can be far of functional compliancy.

A basic alignment could start at understanding what kind of processes ALC-VC1 ALC-V2 or ALC-V3 is applicable for wat kind of cases.

⚙ Y-3.2.4 Measuring internal & external services

⚒ Solving impediments

From the three ICT, ITC interrelated scopes:

✅ I - processes & information
✅ T - Tools, Infrastructure
✅ C - Organization optimization

This is a copy from: "T-3.6.2 Combining internal & external services"
Basic principles are at elucidation: "E-1.6 Maturity 3: three DTAP layers (ICT ITC)"
Details for underpinning why these issues are important are in that technology chapter "SDLC: design - devops".

Maturity id	SubId	Source	Context
CMM-4IT-7			Up to date
	S1	T-3.1.1 Context difference: functional 👁 technical	Structure
	C5	T-3.2.3 BI&A, SIAR panopticon	Technology
	I5	T-3.2.3 BI&A, SIAR panopticon	Technology
	A5	T-3.2.3 BI&A, SIAR panopticon	Technology
CMM-4IT-8			Cots vs "build"
	S1	T-3.1.1 Context difference: functional 👁 technical	Structure
	C1	T-2.2.1 ALC-V1 Technical	Data governance
	C5	T-3.2.3 BI&A, SIAR panopticon	Data governance
	I5	T-3.2.3 BI&A, SIAR panopticon	Data governance
	A5	T-3.2.3 BI&A, SIAR panopticon	Data governance
	S2	T-3.5 Jabes - Use Portfolio management	Structure
CMM-4IT-9			Regulations
	S1	T-3.1.1 Context difference: functional 👁 technical	Structure
	I1	T-3.1.1 Context difference: functional 🕳 technical	human understanding
	I2	T-3.1.2 BI&A Data governance	Look ahead
	I3	T-3.1.3 The question for descriptive analytics	measure
	I4	T-3.2.2 Maturity Bi&A	closed loop
	C5	T-3.2.3 BI&A, SIAR panopticon	Compliancy
	I5	T-3.2.3 BI&A, SIAR panopticon	Compliancy
	A5	T-3.2.3 BI&A, SIAR panopticon	Compliancy
	S2	T-3.5 Jabes - Use Portfolio management	Structure

⚒ Flow Orchestration

Knowing what is going on (BI&A) and using that for improving the business missions wiht their organisation is an old dream to become reality.
It is difficult because of different type of interests.

Any change can harm somebodies personal interest in the organisation. A command resistance to change.
Using technology to change technology has the connotion harming the interest in the status quo interest at technology.
Doing analyes of how processes are behaving performing, working is not common knowledge. A change in attitude is required.

Y-3.3 Information (organisation) and Technology

Combining IT4IT with then organisation requires mature alignment of Process Life Cycle Management.
Acknowledemtn of hierarchical and matrix structures.
Understanding an acknowledgment of the ALC-V* types.
Dedicated characteristics for:

This business / organisation pillar
Each layer, ALC-V*, in this business / organisation pillar
Way to manage this business / organisation pillar

⚖ Y-3.3.1 Enable the organisation using technology

There are several challenges. They are a complex myriad on their own:

Running processes for missions

⚒P ALC-V* type processes 👉🏾 Demand - Transform - Deliver
⚒T Using technology services 👉🏾 Interactions about processes
⚒O Human capabilities, knowledge 👉🏾 Workforce enablement

Changing processes for missions

⚒P change processes 👉🏾 PDCA & DMAIC of value streams
⚒T standardised approaches for tools 👉🏾 Metrics & Sensors for value streams
⚒O Human capabilities enabled 👉🏾 lean culture

Changing missions by visions

⚒P Tasks - Roles, Regulations compliancy 👉🏾 Hierarchical & matrix, External aligned
⚒T Explainable Understandable Ethical 👉🏾 In control for decisions & processes
⚒O Workforce culture, social culture 👉🏾 Organisational and public social engaged

⚙ Y-3.3.2 Maturity fundaments organisation alignment technology

⚒ Solving impediments

From the three PTO, BPM interrelated scopes:

✅ P - Processes: cyber/adminstrative
✅ T - Managing technology service
❌ O - Organization optimization

This is a copy from: "B-1.6.3 Maturity fundaments processes Cyber/administrative "
Basic principles are at elucidation: "E-2.6 Maturity 4: Data Driven Processes"
Details for underpinning why these issues are important are in that organisational business chapter "BPM: design - devops".

Maturity id	SubId	Source	Context
CMM-4AS-1			Access Data
	T1	B-1.4.3 Data sources locations known	Technology
	O1	B-1.4.3 Data sources accountablity known	Security
	P1	B-1.4.3 Data sources content quality known	Reliability
	T1	B-1.4.3 Data destinations locations known	Technology
	O1	B-1.4.3 Data destinations accountablity known	Security
	P1	B-1.4.3 Data destinations content quality known	Reliablity
CMM-4AS-2			Platforms usage
	T1	B-1.3.2 ALC-V1 in control serviced by technology	Technology
	T2	B-1.3.3 ALC-V2 in control serviced by technology	Technology
	T3	B-1.3.4 ALC-V3 in control serviced by technology	Technology
	O1	B-1.3.2 ALC-V1 clear functional operator instructions	Integrity
	O2	B-1.3.3 ALC-V2 clear functional operator instructions	Integrity
	O3	B-1.3.4 ALC-V3 clear functional operator instructions	Integrity
	O4	B-1.3.2 ALC-V1 clear information authorisations	Security
	O5	B-1.3.3 ALC-V2 clear information authorisations	Security
	O6	B-1.3.4 ALC-V3 clear information authorisations	Security
	P1	B-1.3.2 ALC-V1 in control at the organisation	Process
	P2	B-1.3.3 ALC-V2 in control at the organisation	Process
	P3	B-1.3.4 ALC-V3 in control at the organisation	Process
CMM-4AS-3			Monitoring
	T1	B-1.3.2 Applicable technical sensors in ALC-V1 streams	Reliability
	T2	B-1.3.3 Applicable technical sensors in ALC-V2 streams	Reliability
	T3	B-1.3.4 Applicable technical sensors in ALC-V3 streams	Reliability
	T4	B-1.3.2 Applicable functional sensors in ALC-V1 streams	Process
	T5	B-1.3.3 Applicable functional sensors in ALC-V2 streams	Process
	T6	B-1.3.4 Applicable functional sensors in ALC-V3 streams	Process
	O1	B-1.3.2 ALC-V1 clear technical operating metrics	Reliability
	O2	B-1.3.3 ALC-V2 clear technical operating metrics	Reliability
	O3	B-1.3.4 ALC-V3 clear technical operating metrics	Reliability
	O4	B-1.3.2 ALC-V1 clear functional operator metrics	Integrity
	O5	B-1.3.3 ALC-V2 clear functional operator metrics	Integrity
	O6	B-1.3.4 ALC-V3 clear functional operator metrics	Integrity
	P1	B-1.3.2 Analytics metrics at ALC-V1 streams	Reliability
	P2	B-1.3.3 Analytics metrics at ALC-V2 streams	Reliability
	P3	B-1.3.4 Analytics metrics at ALC-V3 streams	Reliability

⚒ Value Stream Orchestration

To control the value stream when there are issues, try to pinpoint.

It could be technical infrastructure having limitations in their flow.
Adding more hardware is simple and often not too costly.
⚠ 💣 The downside of this easy approach is that is often not the real bottleneck. In those case problems will not decrease but will increase.
Metrics & Sensors for the performance of a value stream are required.
⚠ 😲 This requires a culture change because these metrics & sensors are not a common mindset. Although very sensible to have, it got lost in: DWH, Data lake, Big-data paradigms.
It could be dependencies in the functional logical processing.
Real problem analyses requires more than a quick bypass.

Capacity for solving issues is only available with limitations.
Lean methodlogy: The Structure: A3

⚙ Y-3.3.3 Data Driven processes - Functional

⚒ Solving impediments

From the three PTO, BPM interrelated scopes:

✅ P - Processes: cyber/adminstrative
✅ T - Managing technology service
✅ O - Organization optimization

This is a copy from: "B-2.6.3 Maturity Planes: Technology, Operational, Analytical"
Basic principles are at elucidation: "E-2.6 Maturity 4: Data Driven Processes"
The details for underpinning why these issues are important are in that organisational business chapter "BPM: design - devops".

Maturity id	SubId	Source	Context
CMM-4AS-4			Data preparation
	O1	B-2.1.1 Organisation Lean Mindset policy	Lean agile
	O2	B-2.1.(2,3,4) Organisation Lean culture realisation	Lean agile
	T1	B-2.2.1 Logical Process algorithm (business rules)	Integrity
	T2	B-2.2.2 Financial and other public regulations compliancy	Integrity
	T3	B-2.2.3 Technical security regulations, & visions compliancy	Integrity
	T4	B-2.2.4 Logical Process algorithm (business rules)	Integrity
	P1	B-2.4 Metrics & sensors policy	Process
	P2	B-2.4 Metrics & sensors realisations	Process
	O3	B-2.5 Organisation processes life cycle management	Process
CMM-4AS-5			Transformations
	O1	B-2.1.1 Organisation Lean Mindset policy	Lean agile
	O2	B-2.1.(2,3,4) Organisation Lean culture realisation	Lean agile
	T1	B-2.2.1 Logical Process algorithm (business rules)	Integrity
	T2	B-2.2.2 Financial and other public regulations compliancy	Integrity
	T3	B-2.2.3 Technical security regulations, & visions compliancy	Integrity
	T4	B-2.2.4 Logical Process algorithm (business rules)	Integrity
	P1	B-2.4 Metrics & sensors policy	Process
	P2	B-2.4 Metrics & sensors realisations	Process
	O3	B-2.5 Organisation processes life cycle management	Process
CMM-4AS-6			Data delivery
	O1	B-2.1.1 Organisation Lean Mindset policy	Lean agile
	O2	B-2.1.(2,3,4) Organisation Lean culture realisation	Lean agile
	T1	B-2.2.1 Logical Process algorithm (business rules)	Integrity
	T2	B-2.2.2 Financial and other public regulations compliancy	Integrity
	T3	B-2.2.3 Technical security regulations, & visions compliancy	Integrity
	T4	B-2.2.4 Logical Process algorithm (business rules)	Integrity
	P1	B-2.4 Metrics & sensors policy	Process
	P2	B-2.4 Metrics & sensors realisations	Process
	O3	B-2.5 Organisation processes life cycle management	Process

⚒ Value Stream Orchestration

Having multiple parties involved the misunderstanding on:

goals for organisational missions
Technical goals for perfection

Are a key factor for decisions, there is:

The easy way is shallow: sufficient is good enough as start.
⚠ Wat looks sufficient can be far of functional compliancy.

Alignment will need underpinned advices.
⚠ Harming personal staff interests without interest easily goes into a backlash harming the organisation.

⚙ Y-3.3.4 Combining internal & external services

⚒ Solving impediments

From the three PTO, BPM interrelated scopes:

✅ P - Processes: cyber/adminstrative
✅ T - Managing technology service
✅ O - Organization optimization

This is a copy from: "B-3.6.3 Summary Advice organisational leaders "
Basic principles are at elucidation: "E-2.6 Maturity 4: Data Driven Processes"
Details for underpinning why these issues are important are in that organisational business chapter "BPM: design - devops".

Maturity id	SubId	Source	Context
CMM-4AS-7			Corrective
	RACI-1	B-3.2.- VSM Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-3.2.- VSM Tasks, roles, aligned to accountabilities.	Conceptual
	O1	B-3.3.2 Compliancy to regulations and additionals	Process
	T1	B-3.3.2 Compliancy to regulations and additionals	Integrity
	P1	B-3.3.2 Compliancy to regulations and additionals	Availablity
	O2	B-3.4.1 Hoshin Kanri maturity evaluation	Process
	T2	B-3.4.2 Rational decision underpinning.	Integrity
	P2	B-3.4.3 Process Purpose, solution reasoning, formula usage.	Availablity
CMM-4AS-8			Algorithms
	RACI-1	B-3.2.- VSM Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-3.2.- VSM Tasks, roles, aligned to accountabilities.	Conceptual
	O1	B-3.3.2 Compliancy to regulations and additionals	Process
	T1	B-3.3.2 Compliancy to regulations and additionals	Integrity
	P1	B-3.3.2 Compliancy to regulations and additionals	Availablity
	O2	B-3.4.1 Hoshin Kanri maturity evaluation	Process
	T2	B-3.4.2 Rational decision underpinning.	Integrity
	P2	B-3.4.3 Process Purpose, solution reasoning, formula usage.	Availablity
CMM-4AS-9			Regulations
	RACI-1	B-3.2.- VSM Clear accountabilities responsibilities.	Conceptual
	RACI-2	B-3.2.- VSM Tasks, roles, aligned to accountabilities.	Conceptual
	O1	B-3.3.2 Compliancy to regulations and additionals	Process
	T1	B-3.3.2 Compliancy to regulations and additionals	Integrity
	P1	B-3.3.2 Compliancy to regulations and additionals	Availablity
	O2	B-3.4.1 Hoshin Kanri maturity evaluation	Process
	T2	B-3.4.2 Rational decision underpinning.	Integrity
	P2	B-3.4.3 Process Purpose, solution reasoning, formula usage.	Availablity

⚒ Value Stream Orchestration

Knowing what is going on and using that for improving the business missions wiht their organisation is an old dream to become reality.
It is difficult because of:

many different type of interests, many involved players
fast changing technical interpretations
a confusing bunch of advices

🎯 Reducing complexity into simple understandable components.

Y-3.4 Information Communication and Technology

Optimizing an organisation is also optimizing their products. Analysing value streams, analysing financial options with predictions, preferable prescriptions, are required activities.
Understanding an acknowledgment of the ALC-V* types.
Dedicated characteristics for:

This reporting & analytics pillar
Each layer in this reporting & analytics pillar
Way to manage this reporting & analytics pillar

⚖ Y-4.3.1 Enable the organisation using technology

There are several challenges. They are a complex myriad on their own:

Supporting running processes for missions

⚒T Using technology for processes 👉🏾 Optimizing existing value streams technical
⚒I Understanding processes 👉🏾 Optimizing existing value streams functional
⚒P Human capabilities, knowledge 👉🏾 Involve workforce to operational research

Supporting Changing processes for missions

⚒T change processes 👉🏾
⚒I standardised approaches for tools 👉🏾
⚒P Human capabilities enabled 👉🏾 ..

Supporting Changing missions by visions

⚒T Tasks - Roles, Regulations compliancy 👉🏾 ned
⚒I Explainable Understandable Ethical 👉🏾 e s
⚒P Workforce culture, social culture 👉🏾 ged

⚙ Y-4.3.2 Enterprise mission assurance

⚒ Solving impediments

From the three TIP, Bianl interrelated scopes:

✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative

This will be a copy from: "B-1.6.2 Maturity ? "
Basic principles are at elucidation: "E-3.6 Maturity 5: Optimizing optimized organizational processes". Details for underpinning why these issues are important are in that organisational business chapter "BIAnl: design - devops".

Maturity id	SubId	Source	Context
CMM-4OO-1			OR Enable Metrics
	I01	A-1.2 Operations Research into Information processing	Process
	I02	A-1.3 Lean Processing into Information technology	Process
	P01	A-1.4 Goal technical metrics in ALC-V* streams	Process
	P02	A-1.4 Goal functional metrics in ALC-V* streams	Process
	P03	A-1.4 Applicable technical sensors in ALC-V* streams	Process
	P04	A-1.4 Applicable functional sensors in ALC-V* streams	Process
CMM-4OO-2			Technology
	I03	A-1.2 Understanding of information security	Process
	I04	A-1.3 Understanding applicable risk objectives	Process
	I05	A-1.2 Understanding impact of decsisons on persons	Process
	I06	A-1.3 Understanding of applicable business rules	Process
	T01	A-1.4 ALC-V1 serviced by technology understood	Technology
	T02	A-1.4 ALC-V2 serviced by technology understood	Technology
	T03	A-1.4 ALC-V3 serviced by technology understood	Technology
	T04	A-1.4 ALC-V1 functional instructions understood	Integrity
	T05	A-1.4 ALC-V2 functional instructions understood	Integrity
	T06	A-1.4 ALC-V3 functional instructions understood	Integrity
	T07	A-1.4 ALC-V1 information security understood	Security
	T08	A-1.4 ALC-V2 information security understood	Security
	T09	A-1.4 ALC-V3 information security understood	Security
CMM-4OO-3			Operational DMAIC
	P05	A-1.4 Using technical metrics in ALC-V* streams	Process
	P06	A-1.4 Using functional metrics in ALC-V* streams	Process
	I11	A-1.5.3 Data retrieval process known	Integrity
	I12	A-1.5.3 Data sources locations known	Technology
	I13	A-1.5.3 Data sources accountability known	Integrity
	I14	A-1.5.3 Data sources content quality known	Reliability
	I15	A-1.5.3 Data transformation process known	Integrity
	I16	A-1.5.3 Data transformation accountability	Integrity
	I17	A-1.5.3 Data destinations locations known	Technology
	I18	A-1.5.3 Data destinations accountability known	Security
	I19	A-1.5.3 Data destinations content quality known	Reliability
	I20	A-1.5.3 Data delivery process known	Integrity

⚒ Value Stream Orchestration

To control the value stream when there are issues, try to pinpoint.

It could be technical infrastructure having limitations in their flow.
Adding more hardware is simple and often not too costly.
⚠ 💣 The downside of this easy approach is that is often not the real bottleneck. In those case problems will not decrease but will increase.
Metrics & Sensors for the performance of a value stream are required.
⚠ 😲 This requires a culture change because these metrics & sensors are not a common mindset. Although very sensible to have, it got lost in: DWH, Data lake, Big-data paradigms.
It could be dependencies in the functional logical processing.
Real problem analyses requires more than a quick bypass.

Capacity for solving issues is only available with limitations.
Lean methodlogy: The Structure: A3

⚙ Y-4.3.3 Ethical and social values

⚒ Solving impediments

From the three TIP, Bianl interrelated scopes:

✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative

This will be a copy from: "A-2.6.2 Maturity ?
Basic principles are at elucidation: "E-3.6 Maturity 5: Optimizing optimized organizational processes". Details for underpinning why these issues are important are in that organisational business chapter "BIAnl: design - devops".

Maturity id	SubId	Source	Context
CMM-4OO-4			Change staff capabilities
	AH1-1	A-2.1.1 Manage in uncertainties presenting for certainties	Skills
	AH1-2	A-2.1.1 Manage to unknowns expecting them got known in time	Skills
	AH1-3	A-2.1.1 Support reduce complex question into smaller ones	Skills
	AH2-1	A-2.1.2 Understanding the Cyber Security gap, helping to close	Skills
	AH2-2	A-2.1.2 Understanding: gap plant management, helping to close	Skills
	AH3-1	A-2.1.3 Understanding the goal of closed loops	Skills
	AH3-2	A-2.1.3 Helping, going for closed loops operational planes	Skills
	AH3-3	A-2.1.3 Helping, going for closed loops analytical planes	Skills
	AH3-4	A-2.1.3 Helping, going for closed loops change processes	Skills
	AH4-1	A-2.2.1 Willing to adapt changes in the change process	Skills
	AH5-1	A-2.2.2 Support better engineering options during changes	Skills
	AH5-2	A-2.2.2 Be ethical as far as possible in constraint setting	Skills
	AH6-1	A-2.2.3 Acknowledge predictability: VSM Quality & quantity	Skills
CMM-4OO-5			Change Processes Mangement
	BH1-1	A-2.3.1 Value stream (VSM) Understanding processes related	Knowledge
	BH2-1	A-2.3.2 Understanding business value streams variations	Knowledge
	BH2-2	A-2.3.2 Alignment business VSM questions to technology	Communication
	BH2-3	A-2.3.2 Improvements business VSM aligned to technology	Communication
	BH2-4	A-2.3.2 Understanding the role of decisions, architecture	Knowledge
	BH2-5	A-2.3.2 Layers decision alignment: business VSM & technology	Communication
	BH2-6	A-2.3.2 Alignment business VSM to technology for all decisions	Communication
	BH3-1	A-2.3.3 Understanding duality: process-centric ⇄ data-driven	Knowledge
	BH3-2	A-2.3.3 Alignment duality: process ⇄ data business, technology	Communication
	BH3-3	A-2.3.3 Understanding deviance Ideal process, process reality	Curiosity
	BH3-4	A-2.3.3 Improvements business VSM aligned for priories	Communication
	BH4-1	A-2.4.1 Understanding closed loops in VSM processes	Knowledge
	BH4-2	A-2.4.1 Improvements using closed loops in VSM processes	Communication
	BH5-1	A-2.4.2 Understanding closed loops: functional, technical	Knowledge
	BH5-2	A-2.4.2 Improvements using all kind of closed loops	Communication
	BH6-1	A-2.4.3 Understanding theh shop floor by ..	Curiosity
	BH6-2	A-2.4.3 Structuring what should be known of processes by ..	Curiosity
CMM-4OO-6			Tools Process Change
	JW1-1	A-2.5.1 Change culture change: standardised journal activities	Structure
	JW1-2	A-2.5.1 Use standardised journals for reporting & analytics	Structure
	JW2-1	A-2.5.2 Document information for the implementations T-Units	Structure
	JW2-2	A-2.5.2 Document maintenance specifications T-Units	Structure
	JW2-3	A-2.5.2 Document functionality operations T-Units	Structure
	JW3-1	A-2.5.3 Document data contracts input & delivery	Structure
	JW3-1	A-2.5.3 Document Functional transformations business rules	Structure

⚒ Flow orchestration

Having muliple parties involved the misunderstanding on:

goals for organisational missions
Technical goals for perfection

Are a key factor for decisions, there is:

The easy way is shallow: sufficient is good enough as start.
⚠ Wat looks sufficient can be far of functional compliancy.

A basic alignment could start at understanding what kind of processes ALC-VC1 ALC-V2 or ALC-V3 is applicable for wat kind of cases.

⚙ Y-4.3.4 Optimizing optimized organizational processes

⚒ Solving impediments

From the three TIP, Bianl interrelated scopes:

✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative

This is a copy from: "A-3.6.2 Summary Advice organisational leaders "
Basic principles are at elucidation: "E-3.6 Maturity 5: Optimizing optimized organizational processes". Details for underpinning why these issues are important are in that organisational business chapter "BIAnl: design - devops".

Maturity id	SubId	Source	Context
CMM-4OO-7			Plan Structure
	RACI-1	A.2.4.3 VSM Clear accountabilities responsibilities	Conceptual
	RACI-2	A.2.4.3 VSM Tasks, roles, aligned to accountabilities	Conceptual
	RACI-3	A.3.5.2 Advisory Tasks, roles, aligned to accountabilities	Contextual
	RACI-4	A.3.1.1 Advisory knowledge in improving the organisations	Contextual
	O1	A-3.1 Hoshin Kanri basics, check act	Process
	O2	A-3.2 Hoshin Kanri planning to do and do	Process
	P1	A-3.3 Real lean understanding, aligning, promoting	Integrity
	P2	A-3.4 Rational decision underpinning	Integrity
	T1	A-3.5 Rational decision underpinning	Capability
	T2	A-3.6 Rational decision underpinning	Capability
CMM-4OO-8			Let it happen
	RACI-1	A.2.4.3 VSM Clear accountabilities responsibilities	Conceptual
	RACI-2	A.2.4.3 VSM Tasks, roles, aligned to accountabilities	Conceptual
	RACI-3	A.3.5.2 Advisory Tasks, roles, aligned to accountabilities	Contextual
	RACI-4	A.3.1.1 Advisory knowledge in improving the organisations	Contextual
	O1	A-3.1 Hoshin Kanri basics, check act	Process
	O2	A-3.2 Hoshin Kanri planning to do and do	Process
	P1	A-3.3 Real lean understanding, aligning, promoting	Integrity
	P2	A-3.4 Rational decision underpinning	Integrity
	T1	A-3.5 Rational decision underpinning	Capability
	T2	A-3.6 Rational decision underpinning	Capability
CMM-4OO-9			Closed loop
	RACI-1	A.2.4.3 VSM Clear accountabilities responsibilities	Conceptual
	RACI-2	A.2.4.3 VSM Tasks, roles, aligned to accountabilities	Conceptual
	RACI-3	A.3.5.2 Advisory Tasks, roles, aligned to accountabilities	Contextual
	RACI-4	A.3.1.1 Advisory knowledge in improving the organisations	Contextual
	O1	A-3.1 Hoshin Kanri basics, check act	Process
	O2	A-3.2 Hoshin Kanri planning to do and do	Process
	P1	A-3.3 Real lean understanding, aligning, promoting	Integrity
	P2	A-3.4 Rational decision underpinning	Integrity
	T1	A-3.5 Rational decision underpinning	Capability
	T2	A-3.6 Rational decision underpinning	Capability

⚒ Flow orchestration

Knowing what is going on (BI&A) and using that for improving the business missions wiht their organisation is an old dream to become reality.
It is difficult because of different type of interests.

Any change can harm somebodies personal interest in the organisation. A command resistance to change.
Using technology to change technology has the connotion harming the interest in the status quo interest at technology.
Doing analyes of how processes are behaving performing, working is not common knowledge. A change in attitude is required.

Y-3.5 Visualisation Inquiry & Auditing

Measuring the maturity for a scope goal is the way to go.
Scope at a high level reflects:

✅ culture, organisation, vision
✅ operational mission: value streams
✅ state of the art technology

Note there is perspective change for evaluating maturity.
The mentioned aspects are behaving quite different when wanting to measure them using some metrics. Different visualisations are needed for eauy understanding.

👁 Y-3.5.1 "culture, organisation, vision" What to measure?

Determining Maturity (CMM) in a dashboard

All of the follwing aspects to evaluate for maturity:
❶ I-CMM- Steer (cyan) missions by information value streams
❷ C-CMM- Shape (blue) the organisation
❸ T-CMM- Serve (orange) misions by middleware - technology

Basic values for CMM

There will be twelve metrics for each of the three levelled stages.
The total of measuremnts is 36.
Each measure has a value of 0 - 5. (one decimaml)
Retrospective cisualisation: a circle for a 360 (polar/radar diagram).

The value of 0 is used when there should be something but noting is noticed.
A missing value (.) is used when in the situtions it is not applicable.

How to visualize CMM?

A radar diagram using four quadrants having each of the three that attributes as proposal:

bottom: the muda mura muri levels.
The Technology set low because of generic conceptual issues.
right side: basic capabilities.
Technology and enablement are feeling just sufficient but
information processing suffers from misalignments.
left side: standard capabilities.
Enablement just sufficient but
information processing and technology are suffering from misalignments.
top: advanced capabilities.
🤔 There is room for improvement.

The goal of this to determine the suitability of an organisation to do information processing. Using technology requires a fit for the operating by the user.
Jabes desing validate

A figure:
See right side

valid from - valid thru

Evaluation the organisation has a limited period of validity. It easily broken by a major event like an outsourcing, reorganisation. It takes many months tor become stable after an event.
⌛ After an event any existing CMM's are invalidated, three months to wait for a new review.
⏳ After three years an independent renewal for the CMM should be done.
For long term insight it is interesting how the visualisation in time would change. Any measurement is only a snapshot on a moment.

👁 Y-3.5.2 "operational mission: value streams " What to measure?

Determining Maturity PPIC value streams

This is far more difficult than the complicated maturity of an organisation.
The Problem of Industry 4.0: Data! – Part 2

Maybe you have worked with an ERP software that has lots of data. But all too often, an analysis is completely flawed merely because the data in it is wrong.
..
By the way, having good data is not cheap. It is said that automotive companies pay around €50 000 just to maintain the data for one part number over its lifetime (not development or production, merely keeping the data up to date). Due to the complexity of their products, automotive companies are usually better at this, but even makers of washing machines or bicycles pay around €8000 per part number to keep the data at least somewhat straight.
...
But… is it a correct number or is it widely off? Again, garbage in, garbage out! If you want data-based decision making, your data better be good!

Column: Wake up, information professionals! Whether we like it or not: Ehumancipation of information is at full strength (R.Maes 2024).
For organizations this means a fundamental change: where they are still looking for information to support their business, they enter an information world within they must know how to develop, position and sell their self. This world is volatile, uncertain, complex, ambiguous going into brittle anxious nonlinear incomprehensible.

A classic dashboard visualisation

The following aspects to evaluate during a period -journey:
❶ value stream capacity usage (left)
The bottleneck that is the most limited constraint is the one where delays at 80% usage will occur. 80% is a mathematical rusticated from throughput, Litte´s law (MIT 1961).
❷ Performance value stream information throughput. (right)
❸ What resources are left or is there a shortage?
❹ What is to be processed / delivered?
❺ Alerts, e.g. overload and underload in the organisation
The result will be simple approach known from many technical solutions. For that similarity the visualisation is a classic one.
💰 It is a complete different approach of usual EIS, DSS because it is presenting what is happening. There is not an attempt to:

doing an analysis what could be improved,
insight on financial results of processes that are in execution,
give an immediate answer for what to do.

Understanding what is going on, is required before going into proposals.
A simple dashboard would look like:
Jabes design validate

A figure:
See right side

The capacity has a scale from 0 to 100%. Adjusting needs to be a planned change. The throughput has numbers related tot the "product" just some fake numbers in the example.

valid from - valid thru

⌛ The shortest period is day when evaluating the work done by teams.
The details in processes could be shorter or longer dependent on what the process is. All of them can use metrics and dashboards.
⏳ After every day the results are archived and used for trend analysis.
Trend analysis doing predictions on the change in performance change in capacity is more interesting for tactical and strategic decisions.

👁 Y-3.5.3 "state of the art technology" What to measure?

Not another dashboard presentation

These are challenging ones:

Is the technology getting outdated?
Not being in support by the supplier anymore
Vulnerable software possible being brought out of service or more likely getting confronted with data breaches.
Are there more cheaper options for used technology at equal quality level, equal service level?
Is the mission better solved in quality better serviced in a re-engineered solution?
Is the mission still valid or is expected to get obsolete?
Are there new missions in the pipeline to get covered by solutions with technology?

Trendanalsyes is the first step for predictions.
Inflation-Adjusted-Price-Change-since-1998-USA-1024x499.png

A figure:
See right side

Different Aspects of Seeing a Shop Floor—Gemba vs. Data Another big advantage is that data often includes historical data. This makes it a lot easier to see trends, which in turn makes it a lot easier to counteract a worrisome trend before it becomes a problem. Charts and diagrams can really help here!

The water strider - source of information

When getting to know lean better I was missing the role of the "Functional Manager". Used to know him as the person knowing what is going on about the product and processes. He is oositioned within the organisation (steer). Found him again with a different name, using several names: scrum master, product owner, water strider, mizusumashi.
❗ There is an important difference between the "physical" and "Cyber / administrative" worlds for this one.

valid from - valid thru

⌛ Once introduced each product line has his own life expectation.
Some are relative short active (weeks) but may be are seasonally repetitive. Others product lines are after some years obsolete.
⏳ When the expectation is a product line will stop, for the continuity of the organisation a new one should be ready.
Being capable of developing new products in time is a maturity level of the organisation.

👁 Y-3.5.4 Closed loops in project management

One more thing. There should be a closed loop in project management. See The goal:

Managing the load in portfolio projects
Managing portfolio project proceedings
Predicting financial cost and delivery moments

The source for this is information on what has happened, wat should happen. These are administrative artifacts to maintain in tables. See "A-2.4 Enabling aligned lean process cyclesA-2.4 Enabling aligned lean process cycles""
There is one (red caption) at each stage, totals to four. In a figure:
Jabes product

A V-model approach is appropriate for high strategy level, intermediate tactical, short term operational. The reporting & dashboarding is left out of scope for Jabes.

Y-3.6 Maturity of Maturity

The ecosystem Jabes is about:

Foundation: Several metadata frameworks
Foundation: regulation and supervision on usage
Commercials: trade by interactions exchange at content
Commercials: maturity auditing of product & processes

The components are all possible build by bootstrapping. Bootstrapping will create many versioned results.
Metadata artifacts have a maturity level by improvements.
Maturity building up by bootstrapping will be completing and improving continuously.

⚒ Y-3.6.1 Maturity scopes

Pretending being in control

The follwing scopes:
💡❗✅❶ culture, organisation, vision
💡❗✅❷ operational mission: value streams
💡❗✅❸ state of the art technology
All of these three to evaluate for maturity.

Context confusing: business - cyber technology

There is a lot of misunderstanding between normal humans and their cyber colleagues. That culture is not necessary, should be eliminated. A translation of words to start:

ICT	Business		ICT	Business		ICT	Business
Strategy	Control	-	Functional	Target-Value	-	Confidentiality	People
Tactical	Orchestration	-	Compliancy	Communication	-	Integrity	Processes
Operational	Realization	-	Technical	Information	-	Availability	Machines

Note that the asset "Information" is a business asset not something to be pushed off as something incomprehensible "cyber".
Confusing: ICT Business

A figure:
See left side

Consolidations

Using the same structure over and over again enables consolidations. Consolidations is done by controlled by a specified mathematical attribution based on percentages of the total value.

Goal: a workforce culture that is open for helping each other.
👉🏾 A shared business glossary & data dictionary is assumed.
👉🏾 Communications are assumed to be direct without mediators.

👁 Y-3.6.2 Maturity of measurements for maturity

💡❗✅ Building Jabes

The building of Jabes will be a lot of pioneering. A bootstrap approach while developing the product is possible.
Measuring maturity has the challenges of applicable scope.

PPIC Input value stream(s)
PPIC Result value stream(S)
PMIT Technology base

The process of evaluation of quality, maturity is most logical placed at the delivery of the push.

The SIAR model in a table using metadata contexts:

		⟳ A ⇅
	PMOV	PMIT	*-CMM
I ⇄	PPIC		PPIC	⇄ R
	PPVS	ERP	ERP
		⇅ S ⟳

The backend processes for operating technology (PMOV) and Portfolio product value streams (PPVS) are internal.

ERP tools are common approaches for resource planning and customer relations (CRM).

Expecting everything to be solved immediate is too opportunistic. Environment areas of interest to do in stages:

PMOV: Product Middleware operational values - transformers
skilled staff for the job in the value stream are indispensable.
We need to understand first what is expected by processes in value streams.
PPVS: Product Portfolio Value streams - functional processes
As long the processes for missions set by values streams are not clear, it is impossible to do something controlled about them.

🎯 Let´s go out, see the shop floor and organize our administrative processing!

⚙ Y-3.6.3 Organizing administrative processing

The wish for organisational control

(H.Watson, R. Kelly Rainer, C.E Koh, 1991)

EIS Definition and Characteristics
Researchers have used a variety of definitions for EIS (Pallet and Laska, 1990; Turban and Watson, 1989). For our purposes, an EIS is defined as a computerized system that provides executives with easy access to internal and external information that is relevant to their critical success factors. While a definition is useful, a richer understanding is provided by describing the characteristics of EIS. Research (Burkan, 1988; Friend, 1986; Kogan, 1986; Zmud, 1986) shows that most executive information systems:

are tailored to individual executive users

extract, filter, compress, and track critical data

provide online status access, trend analysis, exception reporting, and "drill-down" (drill down allows the user to access supporting detail or data that underlie summarized data)

access and integrate a broad range of internal and external data

are user-friendly and require minimal or no training to use

are used directly by executives without intermediaries

present graphical, tabular, and/or textual information.

...
Why Previous Efforts Failed
There are many reasons why previous efforts to bring computer support to senior executives have failed. Understanding these reasons is important because they provide insights into what problems must be overcome if an EIS is to be successful.
One of the difficulties involves the executives themselves. Many of today´s senior executives missed the computer revolution. Consequently, they may feel uncomfortable using computers, have poor keyboarding skills, or believe that "real" executives do not use computers.
Another difficulty involves the nature of executive work. Previous studies provide a better understanding of what senior executives do and insights into how computer support must be delivered (Isenberg, 1984; Kotter, 1982; Mintzberg, 1975).
Executives busy schedules and travel requirements are not amenable to long training sessions, do not permit much uninterrupted time for system use, and do not allow a system to be employed on a daily basis (Albala, 1988). The result is that senior executives are unlikely to employ systems that require considerable training and regular use to be learned and remembered. Because senior executives have ready access to staff personnel to fulfill their requests for information, any system must prove to be more responsive than a human (Rockart and DeLong, 1988).
.....
Finally, many previous systems have contained little information of value to senior executives, whichis a problem related to a lack of understanding of executive work. This lack was exacerbated by systems designers who often possessed excellent technical knowledge but little business knowledge (Reck and Hall, 1986). This condition is improving as organizations recognize that business kills and the ability to interact with executived are critical.
.....

That is a nice article, obviously nothing really has changed all those years.
There must be something essential missing.

Basic organisation control

Question, what could be missing 🕳:

Mission Control using a portfolio with processes
Lacking insight on performance of missions
misalignment and wrong expectations within organisations

The Jabes proposals 💡 are , hopefully, tackling the gaps:

portfolio insight for missions insight
Focus on missions by simple understandable dashboards
Maturity Measurement of an organisation

Risks to avoid ⚠ :

Defining simple metrics. Don´t make just another copy of the operational with the intention finding something.
Using simple metrics. Don´t use those as KPIs.
Understand the executive work.
There are many conflicts for decisions makers to solve that are not suitable for an information dashboard. How the value streams are performing and what the expectations for those are:
- It is not only the situation on the moment. Expectations for the future are far more interesting.
- Future scenarios are not suitable for a dashboard. The ideate stage is the moment of new not yet existing ideas.
- Financial metrics are most easily to report. These are not automatically the organisation mission and vision.

Advanced organisation control

Understanding metrics and how to align them with the mission, there is still a gap with the vision. Imagine a huge complicated machine to operate. What kind of dashboard that would need and what kind of knowledge to do that trained. Being prepared to act in unprecedent situations.
Assuming anything can be solved by information processing is missing the complexity of a changing world.

⚙ Y-3.6.4 How to start with a Jabes product realisation

🎯 Vision for missions

The goal of jabes:
❶ A holistic knowledge framework how to manage administrative/cyber processes.
❷ Tools supporting the holistic knowledge framework for real realisations.
⚠ There is a strong relationship between those two. The framework is useless without practical realisations. Practical realisations are not possible without the framework.

The market situation, opportunities, challenges:

There is nothing like this in the market. Many tools exists, many good frameworks exists, but there is no coordinated holistic approach.
The demand for a holistic tool is huge although unmentioned. Sings by complaints:
- Not knowing how flows of information processes are working
- Not knowing how information is processed by what business rules
- missing insight oversight in information security
- lacking level of compliancy to regulations. For example the GDPR
There are many challenges to get coordinated solved. They are not solved by some tool.
- Organisation culture, see "Y-3.1 Muda Mura Muri"
- Issues in approaches for:
  - Tools - Technology, see "Y-3.2 Technology"
  - Business objectives, see "Y-3.3 Information (organisation) and Technology"
  - Changeover advices, see "Y-3.4 Information Communication and Technology"
- Just changing is unsatisfying. Forsight measuring improvements is needed.
  See "Y-3.5 Visualisation Inquiry & Auditing"

💰 Minimal viable product

It is blue ocean situation, a new market with little competition or barriers. Innovation an opportunity. Standaardisation for enabling information package exchange a future single point for aligning agreements.

Use a naming convention,
a proposal "Y-1.3 Identification naming standard"
Have control datasets in place for managing administering: proposals progress results changes.
See "Y-3.5.4 Closed loops in project management"
The level of Hoshin Kanri should be possible in relationships.
See "A-3.4 Planning optimised lean organisations"

To start with:

PPIC data contracts, PPVS compliancy
See "A-1.5 Shape: (Information) Technology."

Follow up with the change adding:

PMIT technology tools,
PMOV process assembly instructions
See "A-2.5 Realizing Aligned lean process cycles."
reporting, dashboarding on project activities, portfolio status
See "Y-3.5.4 Closed loops in project management"

⟳ Bootstrap implementation

❶ Starting to build is having a first customer toe learn from. Adjustments to do in the framework and in the realisation are expected events.
❷ The building of Jabes product is in itself a administrative/cyber product. Also that one is input for adjustments an is a product to be defined in Jabes.

⚙ Y-3.6.5 Following steps

The organisation powered by ICT in a ship like constellation. The engines (data centre) out of sight below visibility. Serving multiple customers (multi tenancy) for the best performance and the best profits on all layers.

There are six pillars in a functional and technical layer. Within the the three internal pillars linked access is possible by an imagemap over the given figure.

When wanting going logical forward:
🔰 Math forward

👐	C-Steer	C-Serve	C-Shape	👁	I-Data	I-Jabes	I-Know	👐
👐	r-steer	r-serve	r-shape	👁	r-data	r-jabes	r-know	👐

Design Meta&Maturity

Y-1 Concepts & Basic standards

Y-1.1.1 Contents

⚙ Y-1.1.1 Global content

🎭 Y-1.1.2 Guide reading this page

Why is Jabes interesting?

The break-up of: Logic, Concept, Context

Needed knowledge to read this

⚙ Y-1.1.3 Local content

⚒ T-1.1.4 Progress

done and currently working on:

Planning, to do:

Y-1.2 Goal & Principles

Y-1.2.1 🔰 What are the issues with information processing?

⚒ Information processing is still technology driven.

⚙ The common gaps wiht information processing hat are touching everybody:

⚖ The Challenges of Lean Administration

Y-1.2.2 🎭 Functional process principles

process life cycle

modelling processes

Y-1.2.3 📚 Break-up: Technical ⇄ Functional

Technical tools enablement

Functional information processes

Change: the ICT innovation

Y-1.3 Identification naming standard

Y-1.3.1 🔰 Understanding Logic, Concept, Context

data dictionary

glossary

Y-1.3.2 🎭 Understanding - Communication language

Levels in communication, architecture

The iteration model

The portfolio model

The prioritization model

Understanding: Wiki collaboration

Y-1.3.3 📚 Unique identifier knowledge containers (1)

Basic naming structure

Product metadata sublevel

Organisation identification

Product life phase

Product code for the namen, type version

Y-1.3.4 📚 Unique identifier knowledge containers (2)

Y-1.4 Foundation & commercials

Y-1.4.1 🔰 Recap basics Jabes mindset

⚒ The V-model, Concurrent engineering.

⚒ The Siar model

⚒ pid process control

Y-1.4.2 🎭 Jabes foundation tasks

⚒ Why a Unique identifier?

⚒ Why a standard metdata structure?

Y-1.4.3 📚 Commercial Jabes products

⚒ Why a standard metadata structure?

⚒ Why a standard metadata structure?

Y-1.5 Spin offs - preliminaries

Y-1.5.1 💡 Adding visualisations and other tools

Example: a software solution showing marvellous visualisations

detailed daily planning with analyses & forecasting

Y-1.5.2 💡 Information canvas three*six layout conform Zachman

⚒ Component: Zachman

⚖ ⚙ 💡 Ideate Architecting and engineering conform Zachman

Y-1.5.3 💡 Metadata artifacts for BI reporting

⚒ Issue: no central point for publishing on a dashboard

⚖ ⚙ 💡 uniform standard for presenting BI&A reports

Y-1.5.4 💡❗✅ Jabes Wiki Collaboration

⚒ Component: Enterprise Ontology 101

⚒ Issue: wiki gap for understanding middleware architecting & engineering

⚒ Issue: wiki gap for understanding Information processes architecting & engineering

Y-1.6 Jabes maturity

Y-1.6.1 👁 The organisation in a nine-plane

Y-1.6.2 👁 Continuous improvement of the organisation

Y-1.6.3 👁 Maturity: frameworks, applications

💡❗✅ Building Jabes

⏳ Using Jabes

Y-2 Jabes Metadata

Y-2.1.1 Demand: backlog, proposals, issues

🎭 Y-2.1.1 Knowing what is going on

⚒ Knowledge: prodcut specifications

⚖ Decision for product knowledge

⚙ To build Jabes product

🎭 Y-2.1.2 Determining opportunities feeded by suggestions

⚒ Knowledge: Proposals, issues