⚙ A-1.1.1 Looking forward - paths by seeing directions
mediation, innovation
When the image link fails, 🔰 click here.
Contexts: ◎ r-shape details on mediation communication ↖ C-Serve context on technology, models ↗ I-C6isr context on organisational control ↙ r-serve details on technology, processes ↘ r-C6isr details on organisational control
The "What" of applying mediation, thinking on innovation
Missing a mature context of systems, enterprises, missions, organisations whatever word is suitable.
Systems Thinking context Five categories and the external makes six, fractals for different perspectives.
The frontend decision makers (system-5) and backend support for decisions makers (system-4) is a duality for the meaning in a system.
It is not the supporting administration neither the working force (technology).
Zachman framework refernces Six * six categories for different perspectives differen references.
A framework is a structure that organizes sets of related artifacts.
It shows the relationships among the artifacts of a chosen subject area and brings a totality perspective to otherwise individual ideas.
A framework makes the unorganized organized, and coherent.
These two ideas are good fit for a better generic structure although both of them are needing adjustments.
The generic structure with a model for tasks & roles DevOps-Portfolio Plan and FrontEnd-BackEnd is for both of them missing. ❶ The first abstraction level for understanding the role and position in the backend for its meaning is that it is about mediation, diplomacy doing ambassady role.
There is no adaption to change.
⚖ The next abstraction level is the innovation vision, changing assets in the system as a whole. Inventions (historic)
A lot needs to get solved, it is about shaping change, adaptions to changes:
⟳ Operational Lean processing, design thinking
📚 doing the right things, internal organisation & external public.
🎭 help in underpinning decisions for the boardroom usage and continuity operations.
⟲ Being in control, being compliant in execution missions.
The "Why" of knowledge for mediation, innovation
Adapting to change is the answer to why mediation and innovation is needed. ❷ ⚙
Alvin Toffler
Toffler coined the term “future shock” to refer to what happens to a society when change happens too fast, which results in social confusion and normal decision-making processes breaking down.
In The Third Wave, Toffler describes three types of societies, based on the concept of “waves”—each wave pushes the older societies and cultures aside.
He describes the “First Wave” as the society after agrarian revolution and replaced the first hunter-gatherer cultures.
The “Second Wave,” he labels society during the Industrial Revolution (ca. late 17th century through the mid-20th century).
That period saw the increase of urban industrial populations which had undermined the traditional nuclear family, and initiated a factory-like education system, and the growth of the corporation. ...
The “Third Wave” was a term he coined to describe the post-industrial society, which began in the late 1950s.
His description of this period dovetails with other futurist writers, who also wrote about the Information Age, Space Age, Electronic Era, Global Village, terms which highlighted a scientific-technological revolution.
Adapting to change is the answer to why knowledge management is needed. In managing knowledge a good system of reference is needed at creation, documenting and retrieving. ❸ ⚒
According to Karl Popper
The growth of human knowledge proceeds from our problems and from our attempts to solve them.
These attempts involve the formulation of theories which must go beyond existing knowledge and therefore require a leap of the imagination.
For this reason, he places special emphasis on the role played by the creative imagination in theory formulation.
The priority of problems in Popper’s account of science is paramount, and it is this which leads him to characterise scientists as “problem-solvers”.
The personal freedom (liberte).
The Open Society and Its Enemies (1945), Popper's' most impassioned and influential social works, are powerful defences of democratic liberalism, and strident critiques of philosophical presuppositions underpinning all forms of totalitarianism.
Falsifiability criterion for demarcating science from non-science:
real support can be obtained only from observations undertaken as tests (by ‘attempted refutations’); and for this purpose criteria of refutation have to be laid down beforehand: it must be agree which observable situations, if actually observed, mean that the theory is refuted.
Adapting to change is an options for avoiding disastrous conflicts. In the quest for power, fame and wealth breaking down all competitors is a fast option but has the possible result of all being destroyed. ❹ ⚖
Plans don't always survive the first moments of a
realisation.
Carl von Clausewitz
ruled out any rigid system of rules and principles for the conduct of war, celebrating instead the free operation of genius, changing historical conditions, moral forces, and the elements of uncertainty and chance. These elements, especially the enemy’s counteractions, give war a nonlinear logic.
Every simple action encounters “friction”, in Clausewitz’s borrowed metaphor from mechanics, which slows it down and may frustrate it.
There is an important change in frictions, wars.
His generation witnessed the collapse of the limited warfare of ancien regimes in the face of the all-out effort and strategy of destruction, or total war, unleashed by the French Revolution and Napoleon.
While very conscious of the changing social and political conditions that had brought about this transformation of warfare, Clausewitz, like his contemporaries, held that the new, sweeping way of war making, culminating in the decisive battle and the overthrow of the enemy country, reflected the true nature of war and the correct method of its conduct.
⚒ Three evolutionary steps for enterprise identifications
There are stages for an enterprises, organisations:
In the first wave the ad-hoc organisation created hierarchical leaders.
A similarity in biology is the leader of a herd.
Resolving conflicts caused by disputes in interests within the community the major task of the leader.
In the "second wave" standard (repeatable) organisations were created in subgroups delegated by hierarchical leaders, captains of the industry.
It was the technology with mass production changing the way of living for the whole group pushing this.
Another aspect is it got serving multiple products / services (multi tenancy) for the best performance and the best profits on all layers.
Without a single leader for the whole conflicts caused by disputes in interests within the community to be solved by an independent force.
In the industrial approach information processing got far more important. A change that is a source for evolution into a next change
In the "third wave" complex (adaptive) enterprises organisations are needed. This breaks with the classical idea of hierarchical leadership, captains that er in lead of activity.
It's technology that has made information available in a way that was previously impossible. Information overload and information bias have become problems that didn't exist before.
Without a single leader for the whole by decisions and conflicting interests within the community That needs to be solved by an independent force.
Redirecting as much of possible for decisions to the edge avoids overloading in the decisions to be made.
This demands a level of acceptance by risks and uncertainties for all in the whole.
There are six pillars columns divided by funnctional and technical ones.
A futuristic vision is a positive attitude but can easily become negative when too far from reality.
Fractal details 6*6 reference frame
When the image link fails, 🔰 click here.
There are details for the complexity in understaning of 6*6 reference frames.
Contexts: ◎ C-Shape 👓 6x6 reference frames ↖ infotypes ↗ techflows ↙ r-c6isr organisational control ↘ I-Jabes technology, models
These fractal details are in shift in the content.
Working in a 6*6 frame for knowledge the problem arose that this is not very well defined at all.
That a 3*3 and 2*2 are conslidation variants of the 6*6 reference frame makes it even harder.
👁 💡 What is needed is a more strict definition of states and relationships for the interactions of content demarcated by cells.
For the SQL usage with tuple theory that was done nicely (Ted F.Codd).
Even when closely related to that when it was build up, it is very difficult to copy that into a complete different setting.
There is a lack of axioma's for the Viable systems (ViSM) as theory although the model is well described.
The responsibility by the good regulator decisions and the activities by good regulator is ambiguous.
When adding safety to systems thinking there is no set of axioma's for safety in the systems.
SIMF is an attempt to do that in organisational control (r-c6isr).
The needed meta data definitions using Jabes should have a well defined foundation.
Derived from a well described systems structure that should be get into a sufficient stable structured sets of definitions.
⚒ The time dimension paste, now, future.
Operations research is the enabler by advising responsible and accountable persons in the organisation.
When a holistic approach for organisational missions and organisational improvements is wanted, starting at the technology pillar is sensible.
Knowing what is going on on the shop-floor (Gemba).
👁 💡 Working into an approach for optimized business and technology situation, there is a gap in knowledge and tools.
The proposal to solve those gaps is "Jabes". ⚒ The world of BI and Analytics is challenging.
It is not the long-used methodology of producing administrative reports.
A lot needs to get solved, it is about shaping change:
⚙ Operational Lean processing, design thinking
📚doing the right things, organisation & public.
🎭help in underpinning decisions boardroom usage.
⚖ Being in control, being compliant in missions.
⚙ How organizations should work
Aligning to organsitional processes requires understanding those basics.
Management books are a big market, usefull fundamental insights scarce.
NDMA Dean Meyer ⚒
Your organizational operating model sends signals that guide people day by day.
Organizational transformation is a matter of "reprogramming" these signals.
So, where do those signals come from, and what can executives "program" in organizations?
Structure: the organization chart that determines people's specialties and the reporting hierarchy
Internal economy: the resource-governance processes that decide budgets (business planning); align resources with business priorities, approve projects, and manage demand
Culture: the patterns of behavior generally manifested throughout the organization
Processes, methods, and tools: the cross-boundary processes, procedures, methods, skills, and technologies that enhance people's competence
Metrics and rewards: the dashboards people use to monitor their work and adjust their behaviors accordingly; the performance metrics (KPIs) that their managers use to judge their work
“Strategic Shaping” - “Concept Design”
In an orientation from outside to inside.
From outside to inside the question is what the position of a system, e.g. entperise, is related to the external environment in context to other systems.
The used terms for the figure with a quadrant are basically two pillars.
Theory Formulation Scientific Technological
Operations Enterprises"
It are the transformations in between that are as important as the subjects.
The result is not a quadrant but a nine-plane. The coordination, brain, in the centre.
It captures:
Intentional structuring of innovative ideas
Translation of mediated dialogue into solvable units
Adaptive planning for unpredictable environments
The diagonals are the ones that are dichotomies and are dichotomies.
The 9-plane is a simplification from the six*six reference area.
Several disciplines, usual four, are connected to a 3-dimensional construction where the time is an important aspect.
⚒ A-1.1.4 Progress
done and currently working on:
2024 week 1 - 9
Started to pick up were I left in 2020
SDLC has become technology (draft), BPM organisation with information processing
The nine-plane and SIAR for lean the fundaments for Jabes.
2024 week 10
Started to rebuild BiAnl. It should become the knowledge, advisory, communication for the organisation.
The disruptive change is abandoning Business Intelligence as an isolated technology topic.
Going for:
real lean, agile, getting some hands on that elephant.
2024 week 12
Realised this topic is the key part. Every level, chapter having a world in topic in his own.
Operational improvements, part 1, was the most easy of these.
It is the agile hype and previous attempts for increasing productivity.
Organisational strategy improvements, part 3, got help by social media.
The abstracted goals are more well known but not an easy fit to
realise in the existing situation.
Organisational strategy improvements, part 3, is were it is
really challenging.
Where technology is the enabler of Jabes and the organisation is the one wanting the benefits,
it is this area of managing changes were Jabes as tool is the game changer.
2024 week 13
Draft version finished including part 2.
Stakeholder owner to be found at""Shape" - Tactical.
2025 week 28
Only the first six chapters 1.1 to 1.6 are updated.
The change:
The "how to organize" resulted in a different VSM (viable system) visual than usual.
The role of mediation & innovation to get a place.
Part 1 was, Operational improvements now seen as initial level-1 or repeatable (easy) level-2
That was the agile hype and all previous attempts for increasing productivity.
In a well defined state with all good regulators, feed back loops in place it is defined maturity level-3
The challenges are in the not that easy part of adapting to external change level-4 and disruptive innovations and level-5.
These abstracted goals are non linear and not well predictable.
2025 week 34
Also 2.1 to 2.6 need to be updated. The twist is that by adding the additional abstraction layer the context gets a duality by abstraction levels.
A-1.2 Reference question: What to change?
Understanding systems and changing systems are several levels of abstraction.
When changing systems the complexity on what should be done increases, it is about unpredictability non-linearity.
The biggest problem with that: the human demand of anything should be predictable and linear.
Challenges for change:
Doing activities as always the same type of construction
Improving the activities for achieving the same
Improving type of construction although same purpose
Creating new type of activities
Creating new type of constructions
⟲ A-1.2.1 About Frameworks for architecture
What are Frameworks?
An important question for context in understanding is: What are frameworks about?
There is a need for a good definition.
Eacoe Enterprise Architecture center of excellence, the ideas based on Zachman by S.Holcman.
One very misunderstood word is “framework”.
Another phrase that may be more useful is a frame of reference.
A framework is a structure that organizes a set of related artifacts.
A framework, therefore, makes the unorganized organized, and coherent.
It is simply a thinking tool.
As a thinking tool, a "true" framework will never have an "output."
Framework elements must be mutually exclusive and collectively exhaustive.
It shows the relationships among the artifacts of a chosen subject area.
Brings a totality perspective to otherwise individual ideas.
Frames of reference are fundamental to any profession or discipline (engineering, chemistry, physics, linguistics, music—anything).
A framework that is in constant update and versioning is troubling.
If it is, it is not (or was not) complete.
A thinking tool is useless when sharing knowledge is not a part of that.
In the context of enterprise engineering:
A proper framework for architects should outline a structure representing the complex interactions between business, information, people, processes, and technology.
Frameworks and strategic planning are the keys to planning, coordinating, and implementing the objectives.
Developed based on goals and overall ojectives they help the smooth functioning of different units, both inside and outside the system.
Frameworks can also organize architecture into different "views" and "transformations" that make sense to various stakeholders.
Thus, views are the other complementary projections of the model.
There is a challenge with this approach, enterprise engineering doesn't have a sound historical foundation, it is a blue ocean.
The previous attempt name business engineering is the same. It emerged with the new hard informations systems in the soft systems .
In 1975, David Smyth, a researcher in Checkland's department, observed that SSM was most successful when the root definition included certain elements. These elements, captured in the mnemonic CATWOE.
The six elements are a fit for the Zachman framework under the condition of a dedicated frame of references.
How are Frameworks used?
Who are the ones that are involved for using those frameworks?
Organizations are adding complexity by mapping different frameworks, languages, and notations to an environment that is already too complex to understand.
As human beings, we are naturally "visually" oriented.
We cannot "see" the essence of a problem or solution in 400 pages of text.
What pages and pages of text on a company’s performance cannot achieve, architecture can, with its visual and graphic impact.
In order to have a profession, there needs to be, there has to be one frame of reference.
You can't roll your own, and you can't have multiple frames of references that are there.
Just removing the EA, Enterprise Architecture, makes it more generic less elitist.
Everything is grouped to humans, people, organisations, that are the base elements for alignments in activities.
Anybody could be stakeholder and benefit from sharing knowledge.
The discipline can be anyone that needs to solve a complex problem for knowledge.
A BMC blog on Eacoe for Framework teels the EACOE endorses the Zachman Framework.
Where are Frameworks used?
A framework a thinking tool is lacking support by tooling. For the mindset:
Because there is no support for a framework at that level using references and figures, there is an move by practitioners into methodologies, practices and guidelines.
A methodology is a set of practices and procedures applied to a specific discipline.
A methodology contains proven processes to follow in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration.
A methodology is a set of practices and procedures applied to a specific branch of knowledge.
A methodology contains proven processes to follow in planning, defining, analyzing, designing, building, testing, and implementing the area under consideration.
An outstanding methodology simplifies and standardizes the process; it can be customized to meet an organization's specific standards and practices.
An outstanding methodology is correct, up-to-date, complete, and concise; it defines deliverables; it has methods, techniques, standards, practices, roles, and responsibilities;
it has suggested timings and sequences and dependencies; and it has associated education.
A methodology should allow you to do something "Monday morning", you shouldn't have to figure out how to take a guideline and turn it into a path.
How can a beginning practitioner be expected to "modify" or "customize" a methodology if they have not actually done Architecture?
Methodologies should provide a predefined path or paths a "roadmap" or a "recipe."
Guidelines or principles are not methodologies.
A guideline might tell you what operations you can do or provide suggestions on deliverables.
⟲ A-1.2.2 About Enterprise Architecture frameworks
What are enterprise architecture frameworks about?
Collection from (Enterprise Architecture center of excellence):
As a note and full disclosure, John Zachman and I (S.Holcman) formed ZIFA - the Zachman Institute for Framework Advancement.
John Zachman's original work has not changed. Yes, the understanding of each cell in John's Ontology has advanced.
The EA reference using the Zachman framework (two dimensions):
Based on the work of John Zachman and John Sowa from IBM and elaborations thereof, the EACOE’s Enterprise Framework™ leverages artifacts, diagrams, and abstractions widely recognized by business and technology professionals.
The first dimension of the Framework contains the six questions (abstractions or interrogatives) that have been used to investigate objects and events for thousands of years.
Each interrogative serves a different purpose and is not interchangeable with the others, each is unique and complete.
Aside the two dimensional six*six strcuture thre is third dimension involving time.
The EA Framework defines how to organize the structures and components.
Business Leaders and architects may use the framework to describe an organization's current, future, and gap analysis states.
The EA Framework is not just "enterprise architecture", it describes the twelve fundamental architectures in an enterprise.
To complement The EA Framework, the Center Of Excellence (EACOE) includes a standard set (methodologies) of skills, practices, definitions, templates, and tools for each step in the process of developing an Enterprise Architecture based on The Enterprise Framework™.
What are enterprises, what is architecture?
“Enterprise” defined:
A definition of Enterprise in this context is any collection of organizations/ people and related things that have a standard set of goals/principles and/or a single bottom line.
Accordingly, an Enterprise can be a whole corporation, a division of a corporation, a government organization, a single department, a project, a team, or a network of geographically distant organizations linked together by common objectives.
The broader the definition of “Enterprise,” the more opportunity there is for integration.
A narrow definition of Enterprise leads to more interfacing. “Architecture” defined.
Architecture is the art and science of representing building (construction) and how components and artifacts are organized, related, and integrated.
Enterprise Architecture keeps businesses agile and flexible. Enterprise Architecture thus promotes business optimization by addressing business and information technology architecture, performance management, organizational structure, and processes.
It employs the framework to describe an organization’s present and future structure and behavior so that they are consistent with its strategic direction.
Implementation Frameworks and/or methodologies
The confusion on framework vs methodology:
For an organization desirous of developing an Enterprise Architecture, there are various self-described frameworks to choose.
Depending on the complexity and scale of the enterprise, they can select from commercial, defense industry, and government frameworks.
Frameworks such as DODAF, MODAF, and TOGAF are classified as Implementation Frameworks and/or methodologies in combination with a framework.
DODAF, MODAF, and TOGAF's so-called "frameworks" are continuously modified and altered.
But how was this by methodologies e.g. DODAF started?
The usual methodology is mentioning the three topics: People - Machines - Processes. It is similar to the DOD (Department Of Defence) Operational - Technical - Systems.
First DODAF concept in a figure.
The first version of the development DoDAF was developed in the 1990s under the name C4ISR Architecture Framework.
In the same period the reference model TAFIM, which was initiated in 1986, was further developed.
The first C4ISR Architecture Framework v1.0, released 7 June 1996, was created in response to the passage of the Clinger-Cohen Act.
It addressed the 1995 Deputy Secretary of Defense directive that a DoD-wide effort be undertaken to define and develop a better means and process for ensuring that C4ISR capabilities were interoperable and met the needs of the warfighter.
Interesting in the original methodology C4ISR areL
is the mentioning of the framework reference.
Through this product-to-cell mapping, the C4ISR Architecture Framework can provide templates and guidelines for modeling the enterprise features that correspond to the Zachman cells.
A next DODAF version for concepts in a figure.
Interesting is that there are 9 area's, a nine plane.
It is a simplification of the Zachman reference.
State of art architecture: requirements.
TOGAF was initiated in the early 1990s as methodology for the development of technical architecture, and has been developed by The Open Group into an extensive enterprise architecture framework.
In 1995, the first version of TOGAF (TOGAF 1.0) was presented.
This version was mainly based on the Technical Architecture Framework for Information Management (TAFIM), developed started in the late 1980s by the US Department of Defense. Togaf
has made a split in the processes by "Applications", without a well defined definition of what those are and "data" without a well defined definition.
The most used framework for enterprise architecture as of 2020 that provides an approach for designing, planning, implementing, and governing an enterprise information technology architecture.
It is typically modeled at four levels:
Business,
Application,
Data,
and Technology.
It relies heavily on modularization, standardization, and already existing, proven technologies and products.
Interesting is that there are 9 area's, a nine plane.
It is a simplification of the Zachman reference.
When looking what it is all about, it is requirement management by an implementation framework, methodology.
❓ Does this help for;
The value stream in the context of only external customer / stakeholder
Translating a vision into missions. in the context for missions to
realizations.
Organisation awarenees: anatomy, route by maps in the context for planning processes.
❌ All of this is missing, it is about requirements in a big design upfront.
No agility in doing only those when clear enough during the journeys.
⟳ A-1.2.3 Changing the way of changing
Innovations with AI support
Enterprise Architecture (EA) is facing an identity crisis, and an opportunity.
A different direction in EA, until now it is about methodologies by observations.
The attempt is for what AI and the role of AI could do but it is hitting the question for why and what to change. 9-systems in AI (2025 Jesper Lowgren)
The tools we’ve inherited were built for stability, compliance, and predictability.
Frameworks like TOGAF and Zachman gave us layered views of the enterprise: data, applications, technology, and business functions neatly separated, connected by flows and models.
These frameworks helped us manage complexity through structure.
In this environment, traditional EA becomes reactive. It cannot simulate, coordinate, or govern agentic behavior.
Its diagrams describe what was, not what could be. Its controls are too rigid for adaptive systems and its models are too static for continuous learning.
The accusations against the Zachman frame reference by EA are not justified if the real story is understood.
The following is what it was really about. Missing is the idea of frames of reference for disciplines.
When that gets aligned, it is
an architectural shift:
From describing components to designing system behavior.
From enforcing control to enabling guided autonomy.
From mapping what exists to modeling what could emerge.
At the heart of EA is a simple but powerful question: What does it take to make an enterprise think, learn, and act as a system?
EA 4.0 demands a new architectural mindset: systemic reasoning. Where meta-modeling shows what’s connected, systemic reasoning shows what causes what.
Architects must now think in terms of:
Feedback loops, not just dependencies.
Causal chains, not just flows.
Trigger conditions, not just milestones.
Emergent behavior, not just designed pathways.
Adaptive governance, not just rigid policies.
Meta-models still matter, but they must be complemented by simulation, scenario design, and behavioral modeling.
The architect is no longer just a structural designer.
They are a systems choreographer, orchestrating how agents, data, and humans interact over time.
The EA 4.0 system in a table.
Ordering these nine systems in the simplified three*three Zachman reference layout could help in the understanding of systems in a prescriptive approach.
The shift is:
The Agentic Shift
We must move from governance as documentation to governance as design.
From frameworks that constrain behavior to systems that condition it.
Data governance in the age of AI must evolve from oversight to embedded ethics.
We must move beyond the illusion that we can check AI’s decisions after the fact.
In a world of high-speed autonomy, post-hoc governance is post-mortem. The
real work lies in designing the boundaries within which intelligence unfolds.
EA rethink
In the relational database era, Edgar F. Codd famously introduced his “normal forms,” guiding data structuring to eliminate redundancy, ensure integrity, and provide predictable access.
In an increasingly agentic world, these principles, while sound for relational databases, fall short in addressing the complexities of autonomous systems.
The Shift in Enterprise Architecture:
from Scaling Productivity to Scaling Intelligence
It starts anew, assuming a fully agentic AI world, and a hypothesis of how such a world would operate.
It is based on Samuel Holcman's EA definition, which I believe is the best: Enterprise Architecture is about Architecting the Enterprise. Simple and all-encompassing.
This is not another linear framework; it’s a dynamic, rotational system that integrates and self-balances across five foundational forces: Strategy, Operating Model, Architecture, Design, and Governance.
Strategy: Intelligence Needs Intent
Operating Model: Autonomy Requires Choreography
Architecture: Structure Shapes Behavior
Design: Meaning Becomes Behavior
Governance: Control Must Become Ambient
The Nine Systems give the enterprise its form - its memory, coordination, and sensing. But it’s the Five Forces that make it move.
They generate direction, apply pressure, and trigger change. One provides the structure; the other, the will.
Together, they create a new kind of cognitive architecture - alive, adaptive, and capable of rebalancing itself in motion as intelligence spreads through every layer of the enterprise.
⟳ A-1.2.4 Non-linear, non predictable change abstraction
Promoting inventions for change
In systems theory, every component, every actor or process, has a role, but these roles aren’t just functional.
They hold ontological weight: they tell us what a thing is within the system.
We can think about this philosophically:
Structural Functionalism (Sociological Systems)
👉🏾 Each role exists to maintain system equilibrium.
Just like the circulatory system and nervous system have distinct but integrated functions in a body, so do roles within organizations, economies, and even knowledge domains.
Philosophical twist, this raises the question: is identity derived from function?
Autopoiesis (Maturana & Varela)
👉🏾 Systems are self-producing. Roles emerge not from external design, but from internal coherence.
Example: In a beehive, no one assigns the queen bee her role; it emerges via molecular triggers and social feedback.
Philosophical echo:
Are roles essential or contingent?
Do they emerge from within us or are they imposed from outside?
Cybernetic Feedback and Role Tensions
👉🏾 Systems rely on feedback loops to regulate themselves. Roles are part of the construction of a system.
Roles that resist to use the feedback loops disrupt the system.
Philosophical twist of introducing the ethics of roles—what happens when a role refuses its systemic responsibility?
E.g., when a journalist becomes an activist, or when a judge refuses neutrality, does the system adapt or collapse?
Differentiation Theory (Luhmann)
👉🏾 Modern systems specialize. The legal system is segregated from the political, which is segregated from the scientific.
These role boundaries prevent systemic contamination but also create islands of meaning.
This leads to deeper philosophical questions:
Can over-segregation blind a system to the whole?
Is there wisdom in cross-role hybridity?
Inventors and diplomats are liminal roles, they bridge boundaries between systems.
They operate in zones of low definition, where rules are not fully formed.
Philosophically, these roles remind us to: true change doesn’t come from playing a part, it comes from redrawing the stage.
The role of inventions in change
If we imagine inventions not as tied to the inventors, but as entities or tools within larger systems, their role becomes analogous to diplomacy in several meaningful ways:
Bridge Builders: Just as diplomacy connects nations, inventions often connect different parts of a system—linking what was with what could be.
For example, the printing press didn’t just revolutionize publishing—it rewired the flow of knowledge across society.
Mediators of Change: Diplomacy navigates tensions, while inventions mediate transitions—between manual to mechanical, analog to digital, physical to virtual.
An invention can smooth friction within a system just like diplomacy seeks to ease international strain.
System Stabilizers or Disruptors: A diplomat might avert war, but can also provoke reactions with strategic maneuvers.
Likewise, an invention can stabilize an industry (e.g., GPS in logistics), or completely upset it (e.g., the smartphone in telecommunications).
Cultural Ambassadors: Inventions, like diplomats, carry the cultural and philosophical DNA of their time.
The bicycle, the phonograph, even electricity—they embody societal dreams, anxieties, and needs.
Adaptation Agents: Diplomats adapt their message to different cultures; inventions, too, are modified and recontextualized when integrated into different systems.
Think of how mobile phones evolved differently in rural Kenya vs. urban New York.
A-1.3 Reference question: How to change?
Managing systems and changing systems are different levels of control.
When changing systems the complexity on what should be done increases, it is about unpredictable non-linearity.
The biggest problem with that is the human demand of anything should be predictable and linear.
Challenges for change:
Controlling the "status quo" in activities and constructions
Improving the activities for achieving the same
Improving type of construction although same purpose
Change Control new type of activities
Change Control new type of constructions
⟲ A-1.3.1 Understanding of the what for change
Defining the scope for approaching change
Understanding Business & Technology Operational is a prerequisite.
There has been a lot of attention for this approach. for some reason it is not being what it has meant to be.
What could be the problem?
Ambiguity in goals, Complexities for goals
Uncertainties for accountabilities
Fast changing volatile circumstances
Entering areas that claimed by others
Searching for an understandable workable definition of "Operations research".
It is the classic area for improving of an enterprise.
The basics starts with observing the operations, the shop floor.
Others did the same using other words, one of them is Lean.
Lean is going a step further by adding a lot of cultural behaviour in allowing changes.
What is operations research (OR), classic
A good source for technology did mention a definition.
This is usable understandable, it could be not a fit for promoting technology. 🤔
What is: OR ❶
Operations research (OR) is an analytical method of problem-solving and decision-making that is useful in the management of organizations. In operations research, problems are broken down into basic components and then solved in defined steps by mathematical analysis.
The process of operations research can be broadly broken down into the following steps:
Identifying a problem that needs to be solved.
Constructing a model around the problem that resembles the
real world and variables.
Using the model to derive solutions to the problem.
Testing each solution on the model and analyzing its success.
Implementing the solution to the actual problem.
Disciplines that are similar to, or overlap with, operations research include:
statistical analysis,
management science,
game theory,
optimization theory,
artificial intelligence and
network analysis.
All of these techniques have the goal of solving complex problems and improving quantitative decisions.
The concept of operations research arose during World War II by military planners.
After the war, the techniques used in their operations research were applied to addressing problems in business, the government and society. ❷ Characteristics of operations research
There are three primary characteristics of all operations research efforts:
Optimization The purpose of operations research is to achieve the best performance under the given circumstances.
Optimization also involves comparing and narrowing down potential options.
Simulation This involves building models or replications in order to try out and test solutions before applying them.
Probability and statistics This includes using mathematical algorithms and data to uncover helpful insights and risks, make reliable predictions and test possible solutions.
❸ Importance of operations research
The field of operations research provides a more powerful approach to decision making than ordinary software and data analytics tools.
Employing operations research professionals can help companies achieve more complete datasets, consider all available options, predict all possible outcomes and estimate risk. Additionally,
operations research can be tailored to specific business processes or use cases to determine which techniques are most appropriate to solve the problem.
Uses of operations research
Operations research can be applied to a variety of use cases, including:
Scheduling and time management.
Urban and agricultural planning.
Enterprise resource planning (ERP) and supply chain management (SCM).
Inventory management.
Network optimization and engineering.
Packet routing optimization.
Risk management.
What is operations research (OR), lean
This classic descriptions of OR is understandable but hardy usable.
The following mentions little parts of lean, is wrrittten by L.Ackhoff OR (Brittanica) ❹
In the 1970s several Japanese firms, led by the Toyota Motor Corporation, developed radically different approaches to the management of inventories.
Coined the “just-in-time” approach, the basic element of the new systems was the dramatic reduction of inventories throughout the total production system.
By relying on careful scheduling and the coordination of supplies, the Japanese ensured that parts and supplies were available in the right quantity, with proper quality,
at the exact time they were needed in the manufacturing or assembly process. ....
A second Japanese technique, called kanban (“card”), also permits Japanese firms to schedule production and manage inventories more effectively.
In the kanban system, cards or tickets are attached to batches, racks, or pallet loads of parts in the manufacturing process.
What is operations research (OR), Scholar Source
This well usable maybe understandable, it is overwhelming by its size and number in topics.
OR: Methods and Applications (2023) ❺
The year 2024 marks the 75th anniversary of the Journal of the Operational Research Society.
On this occasion, my colleague Fotios Petropoulos proposed to the editors of the journal to edit an encyclopedic article on the state of the art in OR.
....
👉🏾 Interestingly, while many recent advances in OR are rooted in theoretical or algorithmic concepts, we are now witnessing a return to the practical roots of OR through the development of new disciplines such as business analytics.
The public sector and service industries also benefit greatly from OR. Healthcare is the first area that comes to mind because of its very large scale and complexity. Decision making in healthcare is more decentralised than in transportation and manufacturing, for example, and the human issues involved in this sector add a layer of complexity.
OR methodologies have also been applied to diverse areas such as education, sports management, natural resources, environment and sustainability, political districting, safety and security, energy, finance and insurance, revenue management, auctions and bidding, and disaster relief, most of which are covered in this article.
....
👉🏾 Over time, linear programming has branched out into several fields such as nonlinear programming, mixed integer programming, network optimisation, combinatorial optimisation, and stochastic programming.
The techniques most frequently employed for the exact solution of mathematical programs are based on branch-and-bound, branch-andcut, branch-and-price (column generation), and dynamic programming.
👉🏾 Game theory and data envelopment analysis are firmly rooted in mathematical programming.
👉🏾 Control theory is also part of continuous mathematical optimisation and relies heavily on differential equations.
👉🏾 Complexity theory is fundamental in optimisation.
Most problems arising in combinatorial optimisation are NP-hard and typically require the application of heuristics for their solution.
....
🕳 In 1979, he published in this journal two articles (Ackoff, 1979a,b) that presented a rather pessimistic view of our discipline.
The author complained about the lack of communications between academics and practitioners, and about the fact that some OR curricula in universities did not sufficiently prepare students for practice, which is still true to some extent. ....
⚙ A-1.3.2 Understanding the how to change, lean
What is operations research (OR), Lean?
💣 Most of us have experiences with incorrect lean.
These are usually very negative.
The lessons learned of what has failed to be taken with us to avoid repetition of those. ❻
Going back to find the "Value Stream" in other words "back to core business".
This is about the PDCA - DMAIC approach.
What is lean
👉🏾 Lean Thinking is about creating the most value for the customer at the minimum cost, which is achieved by minimizing resources, time, energy and effort. ❼
A lean approach to work is about:
understanding what’s
really going on at the place where value is created – commonly known as the gemba.
improving the processes by which products and services are created and delivered.
developing and empowering people through problem solving and coaching.
developing leaders and an effective management system.
❽
Lean thinking and practice help organizations become both innovative and competitive, which in turn allows them to become sustainable.
Lean principles may have their roots in Toyota's factories in Japan, but today lean thinking has come to represent an alternative, superior approach to doing work - no matter what the work is, the sector or the size of the organization.
In a lean organization, problems are opportunities for meaningful learning rather than mistakes to be swept under the rug or quickly resolved.
Managers act as coaches, helping others get comfortable identifying problems and practicing daily continuous improvement. ... ❾
👉🏾 🕳What lean is not :
Headcount reduction (“lean = mean”).
A set of tools: 5S, Kaizen events, value stream maps, andon, visual management, metrics, dashboards, A3, etc.
A program (efficiency, process improvement, performance management, MBO, cost reduction, 6Sigma, etc.) “done” to the people doing the work (and therefore creating value) by management, outsiders or internal expert staff.
Something that only applies to manufacturing or operations.
Training for certifications and belts.
Regimentation through standard work
Promoting real lean, the Siar model
The Siar model: Situation, Input, Actions, Request/Result or Situation, Ideas, Analyses, Request/Result is similar to the PDCA - DMAIC cycle.
It just is using other words avoiding to start with a Plan without analyses. ❿
It covers all of:
simple processes: 0 - 9 in a nine plane
value stream: left to right
PDCA (improve), DMAIC (problem solving)
Dualties between processes, transformations, and information (data)
four quadrants: Push and Pull
realistic human interaction & communication
Accountabilities, responsibilities, roles
Real lean is a complete mindset switch for all being committed or involved.
⚖ A-1.3.3 Getting metrics using sensors (Gemba)
The shop floor, getting data
Seeing the shop floor wanting to do operations research is needing information to work with, in jargon needing data.
Different Aspects of Seeing a Shop Floor—Data
In this series on how to understand a shop floor, I talked a lot about the physical shop floor—which in my view is the more important part.
However, as mentioned in my last post, looking at already collected data also gives a lot of insight into the shop floor. ❶ Depending on the aspect you are interested in, data may be the only way to grasp the situation.
Hence, this post will look deeper into how to work with data to understand the shop floor. ❷
Introduction for the data collecting.
As mentioned in my previous post, using collected data can have a few advantages:
The collection of data can be outsourced.
It's easier to see historical trends.
It's usually numerical, which makes subsequent analyses and calculations easier.
You can track hard-to-see events like infrequent quality mistakes.
On the other hand, data has also a few disadvantages:
It is merely a representation of reality, but this may be flawed (unintentional or intentional).
It shows you only the data and nothing else beyond that. More effort is needed for root cause analysis.
There may be more delay between observation, analysis, and countermeasures.
Hence, using data requires a bit of precaution. ....
Only when you have understood the data, believe it, and have it cleaned up can you finally start to analyze the data.
With a bit of luck, you may even get to the point where you improve something on the shop floor with the help of the data.
Now, go out, understand, verify, and clean your data to understand your shop floor, and organize your industry!
Closed loop, Feedback loop, PDCA
The highest maturity level is aligning the vision mission with what is happening.
The feedback, verification of results with intentions, goals, is the beating heart of
real lean using PDCA. (Plan-Do-Check-Act).
BIDM ❸ This rather provocative seeing a maturity level for BI analytics. The highest level has nothing with a DWH, Data-lake as fundament.
BI analytics is integrated or not in the business process can strongly affect the decision making process.
Hence, we consider this category to be a very important one when delimiting a maturity stage
initiation user driven - activity initiated by the user, process driven - activity initiated by a process
process integration data centric - BI analytics is usually supported by a data warehouse, process centric - BI analytics is integrated in the business processes
processing model (store and analyze; analyze and store)
event stream processing
"closed-loop" environment
Although having the mindset set for BI (Business Intelligence) it is very generic.
😲 Asthonising, seeing the narrow relationships:
real lean - operations research - closed loops - systems thinking.
Seen Gaps for ideas, improvement proposals
❹ The list of the usually seen gaps
🕳👁❗ to note and improve:
What operational metrics are available and what is needed?
What analytical metrics are available and what is needed?
What analytical metrics are more easily done by dedicated sensors?
What is the level of information quality?
How to analyse and use existing operational & analytical metrics?
How to analyse and use operational & analytical metrics?
How to analyse and use existing operational & analytical metrics?
How to connect operations research to real lean?
How to get to real lean, how to achieve real support?
Well documented knowledge of accountable & responsible persons
❺ Solution proposal
💡❗✅ a useful method and practice:
For processes, functional algorithms: use Jabes to collect all information.
Use Jabes to collect information quality aspects and who are accountable, responible.
Use Jabes to collect compliancy aspects for information and processes.
⚒ A-1.3.4 Getting metrics in administrative/cyber processes
What are interactions in managing operations?
Core business process, brings value (positive or negative) ❻ There is a value stream.
some input(s) being transformed into result(s)
Transformations, supply and delivering are responsibilities at the core business organization
A central control point for managing enablement
Financial and other compliancy controls including cyber security are components of the value stream
Situation: ⚖ Identify customer value.
Input: 📚 Map the value stream.
Action: ⚒ Design logical Flow.
Result: 📚
⚙ Establish Pull request. IV - III right to left (bottom)
⚙ Implement Push delivery I - II left to right (upper)
Improve: 🎭 Seek Perfection.
Follow the link 👓 at the figure for elaboration. ❼ Information is not equal by type, it can be:
Core product, optionally an administrative/cyber information. (blue operational
Quality descriptions, version type, source of origin. (yellow)
Additional instructions, controls for the transformation. (yellow)
Product descriptions, related financial artifacts by the transformation (green/yellow)
Request, delivery: events, used tools, performance of tools. (green/yellow)
Made decisions in the core product is new information. (blue operational)
ALC-V2, BI&A the Analytical plane
As long there is no mesh experience (closed loop environment) an classic DWH (data lake) should be used for the needed analyses, reporting. ❽ State of art, most used:
for processing Excel, Power BI. Dedicated BI tools or Python are an option.
for presenting the results: Power Point a CSV file for personal processng as option.
Follow the link at for elaboration 👓:
A first improvement to do is improving analytical metrics using well defined sensors.
Using Sensors Metrics, events, data, information, metrics are needed for:
The administrative/cyber product
The processing by tranformations
❾ There are several kind of metrics, they can describe:
The administrative/cyber product achieved quality, failure rate.
The number of cases processed in time-windows
Used capacity and not used capacity in time-windows
Availability of the capacity in time-windows
❓A question: where are the accountable, responsible, informed persons?
Process oriented analytics closed loops, value stream
The focus only at the information for an administrative/cyber product in ae value stream. ❿ Looking at what needs to be done:
The Kanban request is the one coming in (green punch card)
Some additional resources may be needed. Delivery by suppliers
I The product is reviewed loaded for the intended transformation.
II The result of the product transformation is buffered, ready for delivery.
The product result goes along with the product descriptions / qualities
The mindset for a transformation process "code" "application", in a figure:
The focus in the value stream is a duality:
What material, information, data is visible at the line. (data, information)
What kind of processing, transformations is done on the material. (code, algorithm)
Both viewpoints need a holistic approach because they are highly related and depended.
Follow the link 👓 at the figure for elaboration.
A-1.4 Reference question: Where to change?
Managing systems and changing systems are different levels of control.
When changing systems the complexity on what should be done increases, it is about unpredictable non-linearity.
The biggest problem with that is the human demand of anything should be predictable and linear.
Challenges for change:
Recognizing the "status quo" becomes the problem
Controlled improvements by autonomy in activities
Controlled improvements by autonomy on construction
Ideas & Initiations for new type of activities
Ideas & Initiations for new type of constructions
⟳ A-1.4.1 Optimizing systems by lines in functions
The Toyota Production System (TPS) is a well known example of lean manufacturing that many want to copy as their lean process.
Toyota Production System
is an integrated socio-technical system, developed by Toyota, that comprises its management philosophy and practices.
The TPS is a management system that organizes manufacturing and logistics for the automobile manufacturer, including interaction with suppliers and customers.
The system is a major precursor of the more generic "lean manufacturing". Taiichi Ohno and Eiji Toyoda, Japanese industrial engineers, developed the system between 1948 and 1975.
Originally called "just-in-time production", it builds on the approach created by the founder of Toyota, Sakichi Toyoda, his son Kiichiro Toyoda, and the engineer Taiichi Ohno.
The principles underlying the TPS are embodied in The Toyota Way. ❶ Doing a copycat of how Toyota did and does te work is not the path to succes.
Too often (car) manufacturing TPS is assumed what is lean about.
The system as a whole is what it is really.
Pull 4 ➡ 3 requests managed by marketing, sales and the administration.
Push 1 ➡ 2 result, delivery is what the product is seen.
Marketing, sales and Administration is done in a virtual cyber world.
Once upon a time that was associated with paper-work. ❷ Confusing is When the product itself is not Tangible but also intangible wat was paper-work.
What do you see for the value stream, product flow?
For a physcial product: a physial shop-floor
For a cyber virtual product: a datacenter with some flashing lights
See the figures, there is a 👓 link for details. ❸ The result is a risk challenge by vagueness, to differentiate:
Information (data) as product: ➡ operational plane,
Information as metric: ➡ analytical plane.
💣 Technically running BI & Analytics are using ICT processes very similar to product processes when the core product process is administrative/cyber.
Everything is code logic and everything is data, but not all are equal for business value.
Delivering data products in a cycle
When you want to process information in a value stream, going for the best quality best performance, than you are in the operational plane being supported by analytics for the understanding in what is going on.
The maturity level of the supporting analytics is a challenge on his own. ❹ A data driven processing approach is by a complete cycle with interactions between states.
The interactions can be a transformation or a validation on validity for the flow part of the value stream.
A figure:
See right side
Starting at the bottom right side, there are four stages:
Ideate - Asses
Enable - Plan
Demand - Backend
Frontend - Delivery
Typical characteristics: The control postion, Plan enable, is at the bottom left not at the top of this cycle.
A push is at the top left to rihgt, the pull right to left at the bottom. ❺ There is a clear segregation between tooling and the functional logic, algorithm.
The tooling can be standardised in the Demand - Materials Transformation - Deliver stages.
For standard transformations there is no pressure to use to most hyped tools.
⟳ A-1.4.2 Controls metrics lines in functions
⚖ System, organisation design
The need for controls and metrics is not a surprising one neither a new modern insight.
In the physical technical engineering world it is cornerstone for automation.
For only managing the control - measure feedback there is a theory with many practical realisations.
PID controller ❻ For modelling business processes with the goal of understanding value streams.
An old (1980's) but valid modelling approach:
idef0 (process model)
IDEF0 is a method designed to model the decisions, actions, and activities of an organization or system.
IDEF0 was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). ...
Effective IDEF0 models help to organize the analysis of a system and to promote good communication between the analyst and the customer.
IDEF0 is useful in establishing the scope of an analysis, especially for a functional analysis.
As a communication tool, IDEF0 enhances domain expert involvement and consensus decision-making through simplified graphical devices.
As an analysis tool, IDEF0 assists the modeler in identifying what functions are performed, what is needed to perform those functions, what the current system does right, and what the current system does wrong.
....
IDEF0 concepts designed to enhance communication include the following:
Diagrams based on simple box and arrow graphics.
English text labels to describe boxes and arrows and glossary and text to define the precise meanings of diagram elements.
The gradual exposition of detail featuring a hierarchical structure, with the major functions at the top and with successive levels of subfunctions revealing well-bounded detail breakout.
A "node chart" that provides a quick index for locating details within the hierarchic structure of diagrams.
The limitation of detail to no more than six subfunctions on each successive function.
in a figure:
See right side
❼ Note the line for:
controls.
When the mechanisms direction would be reverted and had the name of metrics ...
What happened to the control and metrics in the administrative/cyber world ❓
⚒ Administrative/cyber: Data Mesh, data product quantum
Not knowing what is going on is bad.
The huge build environment for BI&A reporting: DWH, Data warehouse, Data Lake, Data Lake House with ETL ELT.
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 2020), the data (product) quantum.
🎯 Add a control connection at each transformation process. The control regulator for: speed, safety.
A figure:
See right side
This idea solves BI&A in an analytical plane.
Note the lines for:
controls.
metrics.
This is a moment in time for a change in the information processing approach.
⚙ Administrative/cyber: Data Mesh, Experience plane
Not using available information on what is going on is bad.
The huge cost and efforts for building environments supporting BI&A reporting: DWH, Data warehouse, Data Lake, Data Lake House with ETL ELT.
This is a bizar approach not known, not seen in lean agile. ❾ 💡❗✅ Simplify operational dashboarding & feedback controls using the analytical plane.
From: "Data Mesh Delivering Data-Driven Value at Scale" (book), the mesh experience.
The idea: An analytical plane Although this analsytical plane is not weel defined the intention for BI&A is obvious.
🎯 Add dashboarding, mesh experience, for controlling the processes in speed, safety, capacity.
A figure:
See left side
A moment in time for a change in approach ❗
❿ In all this technology focus driven solutions there a is gap left: KM Knowledge Management.
The gap is not only the thinking but also in the technological support for KM.
A proposal for processes, functional algorithms, safety, risks, decisions and more: use Jabes to create and collect all of that kind of information.
There are several approaches for developing designing systems.
It varies from doing some things by good feelings to very intensive research with controlees loop-backs for good-regulators and knowledge assurance of what and why choices are made and has been made. ❶ The ALC-V3 model is the most sophisticated approach for processes, value streams.
The differences with the other two more simple process models are:
There are no feedback loops in the ALC-V1 model, it is about human assumptions.
In the ALC-V2 model:
Feedback and control loops are fully based on human assumptions & interpretations.
Measurement are addons in additional requests.
With the ALC-V3 model:
Measurements, feedback and control loops are inseparable functions of processes.
Defined goals for what is important have to exist.
Defining functionality is data driven.
Human control and human accountabality is for all these process model the same.
In a figure:
See right side
Follow the link for elaboration 👓. ALC-V3 ❷ In the ALC-V3 model the process line has at least two lines.
The development line:
Retrieval and preparation of information. The structure is logically a star schema.
Reducing the prepared information in an renormalised format.
Developing and a first verification of the code "model" by analysing the results.
Doing a continuous verification of the "model" by analysing the results.
❸ The operational line has:
Retrieval and preparation of information. The structure is logically a star schema.
Reducing the prepared information in an renormalised format.
Executing using the code "model - scoring".
Distributing the results "model - scoring".
Note the introduction of the word "model" where previous the "code" or "program" was used for functionality.
Follow the link for elaboration 👓 AlC-V3
⚙ managing the ALC-V3 line
❹ The quality of the process line is more complex to manage.
There are four artifact lines with dependencies to managing by releases.
The quality of the retrieved information is important and should be monitored.
The quality of the scoring results is important and should be monitored.
❺ There are different type of personalities in this involved. Developing is very different to operations where the accountability gets a more important role.
⟳ A-1.4.4 A living cycloid information system model
Document request & functional accountabilities
KM Knowledge management for the functionality is a process in his own with the goal.
To get covered by documented knowledge in a portfolio are risk assessments:
Security impact ⇄ Operational risk impact
Trustworthiness of the information
Privacy risk impact ⇄ Process risk impact
Trustworthiness of the processing
❻ This is awareness of the Situation with a Rreqeust.
The portfolio options should have been defined during architecting engineering - development and operations.
By not having a generic tool covering this, it is mostly either ignored, forgotten or lost in the portfolio connection.
During reviews what is going on there is a moment for KM corrections.
In a figure:
See left side
Data contracts, knowing the bill of amterials for value streams
❼ These are the Inputs enabling the goal with materials retrieval:
Know for who and what the processing is
Know who is accountable for the retrieved materials, information
Organise from correct agreed locations the agreed quality of materials, information
A figure:
See left side
Portfolio defined transformations by value streams
❽ These are the Activities realised by some ALC methodology.
The Alc-V3 approach is the most complete and most complex one.
Data contracts, fullfilling the goals of value streams
❾ These are the Results of the system, the goal with the delivery.
Know for who the defined processing was done
Know who is accountable for the delivered materials, information
Organise to correct agreed locations agreed quality of materials, information
A figure:
See left side
Service agreements, portfolio alignment
❿
There are several moments in the value stream with a "customer" contact:
Request with an associated needed information input
A validation of the request in validity and acceptability
Result from transformation: information and possible physical object(s).
A validation of the delivery for validity and acceptability
Although the process is often seen as just four steps those steps that verifying the validity and acceptability are as important.
A different set of ordered questions: Where How What Which When Who.
A-1.5 Reference question: when to change?
Managing systems and changing systems are different levels of control.
When changing systems the complexity on what should be done increases, it is about unpredictable non-linearity.
The biggest problem with that is the human demand of anything should be predictable and linear.
Challenges for change:
Minimizing the "status quo" in activities and constructions
A culture in aligned autonomy with feedback for activities
A culture in aligned autonomy with feedback on constructions
In control for Initiations new type of activities
In control for Initiations new type of constructions
⚖ A-1.5.1 Pre-requisite: insight from context to details
Prereq: insight from context to details
Using the hype of AI there are agents that are surrogates for human thinking.
Just see them as surrogates and notice the innovating change of how to think.
Agentic AI Engineering:
The Blueprint for Production-Grade AI Agents (YiZhou 2025)
What I've learned is this: the difference between a clever demo and a reliable AI agent comes down to engineering rigor.
Prompt hacks and intuition alone won't cut it.
Building agents that actually work requires systematic thinking, how they manage context, structure decisions, choose the right models, operate safely, and earn user trust.
That's why I'm sharing a practical framework we've developed through hands-on experience.
Agentic AI Engineering, a five-part discipline that includes:
Context Engineering: Feeding the model the right information at the right time
Feeding the Brain Without Overloading it.
Imagine dropping your smartest team member into a meeting with no agenda, 400 pages of random notes, and the expectation to "just figure it out."
That's what most AI agents face when we naively shove too much, too little, or the wrong kind of information into an LLM prompt.
Context Engineering is the discipline of designing exactly what the agent sees at each step and how.
System Instructions: What role is the agent playing? What goals or rules is it following?
User Input: The immediate request or command
Short-Term Memory: Recent steps, dialogue, or actions taken
Long-Term Memory: Persisted facts, preferences, or prior outcomes
Retrieved Knowledge: Relevant docs, data, or facts pulled from external sources
Tool Definitions & Outputs: APIs, calculators, functions and their most recent results
Every call to the model is like giving it a briefing packet. Context Engineering is about curating that packet for relevance, clarity, and completeness. ...
They remember what they've done, learn what worked, and bring forward only what matters next.
Context Engineering makes this possible through:
Memory mechanisms (short- and long-term)
Context pruning (dropping stale or irrelevant info)
Dynamic injection (pulling in new data only when needed)
It's not static prompting. It's interactive context architecture.
Workflow Engineering: Structuring agent behavior into reliable multi-step processes
Don't Ask the AI to Do the Whole Job in One Breath.
Let's say you hire a brilliant intern and ask them to:
"Read 300 pages of policy docs, find inconsistencies, write a summary, draft a recommendation, and send it to legal... all before lunch."
That intern would fail, not because they’re incapable, but because you gave them a monolithic task with no structure.
The same mistake happens all the time in agentic AI.
Agentic Workflow Engineering is the antidote.
It's the discipline of structuring complex tasks into modular, multi-step processes, where each step has:
A clear objective
The right context
The right tools
And well-defined handoffs to the next step
Workflow engineering gives them that frame.
Break down a task like this, Loop until complete:
Understand the goal
Ask clarifying questions
Plan subtasks
Call tools
Evaluate results
Adjust strategy
Generate final output
Instead of trying to “solve” the whole problem at once, we sequence and scaffold the agent’s reasoning.
Model Engineering: Selecting or tuning the right models for each task
Pick the Right Brain for the Job
Imagine building a Formula 1 car and installing a jet engine, or worse a lawnmower motor. One's too much power with no control; the other simply can't keep up.
That's what it's like when you pick the wrong AI model for your agent.
AI Model Engineering is the craft of choosing (and sometimes shaping) the right brain for every task your agent needs to perform.
It's about balancing performance, cost, latency, and specialization and doing so with precision.
AgenticOps: Testing, monitoring, securing, and optimizing agents in production.
Run Agents Like You Run Critical Enterprise Apps.
Building an agent that works in the lab is easy.
Building one that works in production, under load, with
real users,
real tools,
real deadlines and doesn't crash, hallucinate, or go rogue, is a different game entirely.
It's the discipline of operationalizing AI agents so they are observable, testable, governable, performant, and safe at scale.
This is where agent development shifts from prompt-tweaking to platform thinking.
Context engineering feeds the brain (1) and workflow engineering structures its logic (2) , AgenticOps gives that brain a body, a nervous system, and a safety harness (4).
AgenticOps is the emerging operational layer for agentic systems, think of it as MLOps meets DevOps, adapted for autonomous agents.
It includes:
Evaluation (evals): Measuring quality, behavior, and correctness
Observability: Logging every decision, tool call, and model response
Guardrails: Enforcing policy, compliance, and ethical boundaries
Security: Preventing injection attacks, abuse, or data leaks
Optimization: Improving latency, throughput, and cost at runtime
Lifecycle Management: Versioning, rollback, CI/CD, and agent drift monitoring
If you’re building a system where agents act on your behalf, make decisions, or touch customer-facing systems — AgenticOps isn’t optional.
The first principle of AgenticOps is this: Never ship an agent you haven’t tested thoroughly in simulation.
Unlike traditional software, agents operate probabilistically. Same input, different output. That means we need new testing techniques.
Agentic UX: Designing interfaces that make AI actions transparent, controllable, and trusted.
Designing for Trust, Transparency, and Teamwork
Let’s say you’ve built the world’s most advanced AI agent.
It reasons flawlessly, orchestrates tools like a pro, never oversteps its boundaries, and runs on a finely tuned stack, but then you launch it users don’t trust it.
They hesitate, they override its suggestions, or worse they abandon it entirely.
That’s not a technical failure, that’s a UX failure.
These are in the order of What How Where Who When.
Just add the Which for the decision to be made to complete the set of six.
That is the structured way of engineering stuff.
⚙ A-1.5.2 Pre-requisite: insight for appropiate maturity
Maturity in AI scaling
Using the hype of AI there are agents that are surrogates for human thinking.
Just see them as surrogates and notice the innovating change of how to think.
Applying the CMM maturity 1 to 5 for Agentic AI.
Why Traditional EA Collapses at Scale (Jesper Lowgren 2025)
What EA 4.0 Does Differently:
Static diagrams and periodical roadmaps are no longer suffice.
This shift becomes undeniable at higher levels of AI maturity, where AI agents begin acting with autonomy, multi-agent systems emerge, and decision-making escapes the neat confines of pre-written business rules.
Beyond AI maturity level 2, traditional enterprise architecture breaks.
Not because it’s wrong, but because it was never designed for this kind of
reality.
For the CMM maturity level there are claims of organisations achieved level-5.
Others say we never even reached level-2 or just being at that for the discipline of information processing. I am convinced it is that situation.
Autonomy is a topic well known in Lean. Real lean has a lot of problems in acceptance.
In the Agentic AI Maturity Model, Level 3 marks the point where AI systems shift from tool-like augmentation to autonomous execution.
This means:
Agents are no longer just suggesting; they're acting.
Decision-making is embedded in the flow of operations.
Multiple agents interact, escalating, coordinating, or conflicting in
real time.
Execution and governance must now operate at machine speed.
This level is not about pilot projects or proof-of-concept sandboxes. It’s about production-grade systems that require
real trust, scalable control, and architectural resilience.
Hurdle achieving Level3 AI maturity
What is holding the discipline of information processing becoming more mature?
Traditional enterprise architecture was designed for environments that are:
Human-governed: Decisions are made by people, documented in frameworks, and executed through business process automation.
Predictable: Systems behave deterministically; exceptions are understood.
Static: Architecture updates are planned quarterly or annually, with changes governed through slow governance bodies.
Document-centric: Governance exists primarily in documents, Wikis, PowerPoints, or review boards.
Interesting: that "Document-centric" argument mentions the
real problem of many disperse tools. There is no consistent standard, no tool supporting the standard(s).
But maturity level 3 breaks these assumptions:
Agents act faster than review boards can respond.
Outcomes are emergent, not linear.
Interactions are dynamic and hard to predefine.
Risk manifests through behavior, not structure.
Risk management is including the understanding of distributions of events, the normal distribution is not normal.
The limits of rules … (David Snowden 2025)
A shortlist of the change from what was done as always into a new paradigm of nonlinearity and not full predictability.
It is the cynefin framework area of complex problems.
⚒ A-1.5.3 Mindsets: philosophy for changing systems
The inventor role in a system
While diplomats act within existing structures, working to preserve stability, inventors are more often the ones who bend the arc of what's structurally possible.
Their role could be seen through these lenses:
Architects of New Possibility Spaces
Inventors introduce new parameters into a system—tools, technologies, or conceptual breakthroughs that redefine what the system can do.
Diplomats negotiate within rules; inventors often reshape the rulebook itself.
Disruptive Sense-Makers
They force systems to confront their limits: the telegraph collapsed geographical distances; antibiotics transformed health systems; the internet rewrote communication.
In a way, inventors create problems and possibilities. Their inventions demand new policies, ethics, and institutions—often dragging diplomacy behind.
Mediators of the Material World
Whereas diplomacy operates via language, intention, trust, inventors work with matter, method, and uncertainty.
Their dialogue is with friction, resistance, entropy—and through that, they create tools that others negotiate with.
Preceding Diplomacy
You might say inventors often trigger diplomacy. Consider nuclear physics: the invention preceded a whole new diplomatic language (non-proliferation treaties, arms control talks).
Thus, invention becomes a precondition for new diplomatic architectures.
Philosophical Snapshot: Inventor as a Liminal Agent, between idea and impact—a role both visionary and unsettling.
Not quite political, not entirely scientific—they often occupy a third space.
Like mystics or prophets in older societies, they speak a language before it becomes mainstream.
The typology of system agents
These system agents are a kind of conceptual cast of characters, each playing a distinct role in how systems evolve, stabilize, or transform.
Think of it as the dramaturgy of complex systems.
They’re roles of influence, a person can play multiple agents across time or simultaneously.
Some are system-preserving: Diplomat, Operator, Custodian,
others are system-transforming: Inventor, Trickster, Prophet.
The systemic context: economic, ecological, informational, institutional, determines which agents are empowered or marginalized.
System agents typologies:
Agent type
Core Function
Orientation
Signature trait
Example Figures
Prophet
Envision alternate futures
Horizon-expanding
Disrupts imagination boundaries
Buckminster Fuller, Ursula K. Le Guin
Trickster
Subvert rules playfully
Fractal-breaker
Reveals cracks in systems
Marcel Duchamp, hackers
Inventor
Create new structures
Future-facing
Catalyzes novelty
Leonardo da Vinci, Hedy Lamarr
Philosopher
Reflect & reframe
Meta-systemic
Interrogates assumptions
Hannah Arendt, Niklas Luhmann
Diplomat
Mediate between systems
Present-stabilizing
Bridges differences
Kofi Annan, Talleyrand
Cartographer
Map system terrain
Knowledge-organizing
Makes complexity legible
Systems analysts, theorists
Healer
Restore systemic health
Entropic rebalancer
Mends what’s been fragmented
Social workers, conflict mediators
Custodian
Preserve cultural/systemic memory
Conserving
Protects continuity
Archivists, tradition-keepers
Operator
Run and optimize systems
Inner-loop
Ensures functional reliability
Logistics engineers, administrators
Some individuals or collectives operate between types.
These agents challenge typologies themselves, reminding us systems aren’t static diagrams but living topologies.
Mapping roles Into the VSM (Viable Systems Model):
Enablers & guiders: System-5
Inventor System 4 The part of Adaptation/Future-sensing. Inventors scan the environment, introduce new patterns, imagine futures.
They anticipate discontinuities and trigger adaptive learning or redesign.
Diplomats: System-2 and 3 The part of Operational Coordination + Control.
Diplomats stabilize relationships, optimize communication between subsystems (e.g., departments, nations, stakeholders).
They maintain systemic cohesion in
real time.
Workers, operators & administrators: System-1
“Strategic Shaping” - “Concept Design”
In an orientation from inside to outside.
From inside to outside the question is how to be adaptive to the external environment, other systems.
The used terms for the figure with a quadrant are basically two pillars.
Mediation & Innovation Enterprise Architecture
Operations Research Systems Thinking
It are the transformations in between that are as important as the subjects.
The result is not a quadrant but a nine-plane.
It captures:
Intentional structuring of innovative ideas
Translation of mediated dialogue into solvable units
Adaptive planning for unpredictable environments
The diagonals are the ones that are dichotomies and are dichotomies.
The 9-plane is a simplification from the six*six reference area.
Several disciplines, usual four, are connected to a 3-dimensional construction where the time is an important aspect.
⚒ A-1.5.4 Mindsets: methodogies for changing systems
Using reference frameworks, a special case of discipline
Getting attention, getting funding is starting with a top down approach for what to do.
The Shift in Enterprise Architecture starting with a reference framework.
The fundamental ideas didn't change although there were changes made.
The Zachman Framework Evolution
The horizontal axis is now ordered. The order is relevant for the interactions limiting a model in all possible interactions.
The nature of a grid like this is non linearity because every cell is acting on his own way.
Any idea of simple linear activities by causality should be avoided.
Using reference frameworks, a generic approach
Enabling a bottom up and top down in how to do is requiring several references for the involved different disciplines.
It is the vertical axis that got specialised words. The classic where: Context, Concept, System logic, Technology logic, Tool components, Operations instance.
Using this in a ver technical approach was done in creating the SQL implemntation at IBM with involvement of Zachman.
See C-1.4.2 Design abstractions, John A. Zachman".
That is an area where attention, getting funding is an exception for innovations.
Frictions by fractals bottom top -top down, internal- external
Understanding systems, portfolio, products, is documenting that using a standard.
Pitiful a standard for that missing, everybody is left to do that by his own way.
How should you do documentation?
The Documentation Habit Your Future Self Will Thank You For (A.Ponomarev 2025)
Too much documentation can be overwhelming. Long and complex documents can make people skim through the content, overlooking details or entirely skipping them.
Too little documentation can be just as bad. The lack of instructions can lead to assumptions. And assumptions can lead to errors.
The best approach is to keep documentation lightweight, clear, and searchable. Instead of writing massive documents, focus on what teams actually need.
Try to keep your documentation:
Concise: stick to the most important details
Organized: use headings, bullet points, and short sections
Easy to find: tools like Markdown files, Google Docs, or wikis are some examples for storing it
Remember, good documentation answers questions before they’re asked.
It should guide engineers without forcing them to dig through endless pages.
Shared knowledge should be a helpful tool, not a burden.
Structuring the documentation of activities and products
If we would have a standard reference frameworks for all involved disciplines, what would be the best option for doing the documentation, archiving the knowledge?
DBMS Scheme for project engineering (R Noronha 2025)
Engineering projects are often large and complex endeavours that generate lots of data.
This data can include the dates document are issued, time spent performing activities, quality compliance checks, commodities etc.
Managing this data is crucial in effectively managing the project.
However there are few database systems designed to cater specifically engineering projects.
In a typical engineering project, disparate data management systems are combined together to manage the data.
For example, there may be a payroll processing system to log time, a project management tool to track activities, and a document control package to manage deliverables.
The issue with this methodology is that it would not capture the relationship that each of these databases have with each other, which can lead to inefficiencies such as data duplication or inconsistent data.
Often, with no other better alternatives to capture project data, managers have to resort to using Excel spreadsheets.
While Excel is a good tool to capture simple tabular data, when it comes to non-trivial data Excel often falls short.
It is very difficult to model relationships in Excel.
This is where relational databases shine.
"Managing technology service" is a prerequisite for "processes: cyber/administrative".
The focus should be on the value stream processes, frontend backend.
Optimizing the technology service is operating, execution of lean.
The distractor is starting by the technology connection.
From the three TIP, Bianl interrelated scopes:
✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative
⚒ A-1.6.1 A generic reference framework per discipline
The reference structure 6w1h in a six*six frame
The reference structure as generic structure is simple in a presentation and very complicated for the context by information it can present.
What has happened to that frame of references of Zachman where the references (metadata) for a discipline has to be defined?
It is interpreted as a methodology, examples are: the notes Innovations with AI support (A-1.2.3) and
EA and Zachman (Dragon1)
Missed are that C4isr Tafim Togaf Dodaf are methodologies based on the Zachman framework reference. The higher level abstraction aside an EA discipline is lost.
The Zachman framework reference is ordered by the two axis.
There is also a time dimension but that one is not shown, the importance not aware of.
The Zachman framework reference horizontal order is slightly different in an outside to inside perspective where the engineering inside to outside is the usual used one.
There are no tools based on the fundaments of the Zachman framework reference.
There are no tools supporting the Zachman framework reference with fractals, multiple disciplines, approach.
A long lasting issue is connecting Business & Technology (operations).
There has been a lot of attention for this issue.
It started with Henderson & Venkatraman Strategic Alignment Model (SAM) in a quadrant (1993).
That got an extension into the 9-plane 2000 by Rik Maes. Redefining business: IT alignment through a unified framework .
That redefining to a unified framework approach failed.
The quest for a unified framework
For some reason all what has been presented as the solution are not what it has meant to be.
What could be the problem?
Purpose of having a standard: Create consistency and interoperability.
If something keeps changing and has version numbers flying around like confetti version 1.0 1.1, 1.1.1 2.0, 3.1.59 it's not a true standard it's a moving target standards are all about stability and consistency.
A standard is born from a
real need shaped by experts hammered out through consensus polished and only then officially adopted. Tt's a group effort.
Why fragmentation in many groups each working on the same standard is a problem: you end up with many standards. That is just a fancy say way of saying there's no standard at all.
Getting a standard becomes impossible the more groups or people involved the harder it is to build consensus.
Instead of one clear path you get endless debate competing interests and ultimately gridlock you end up with an 1,800 page standard which has everything in it from everybody
Other values for process improvement to consider
Russell Ackoff on Systems Thinking in Organizations (D.Meyer 2025)
why quality and continuous improvement programs often fail, the need for vision and "discontinuous improvement," and the fundamental importance of systems thinking classic 1994 presentation by renowned systems scientist, Dr. Russell Ackoff (1919-2009)
Key points:
Dr. Russell Ackoff (who knew Deming) speaks about why most continuous improvement initiatives fail, the need for vision and "discontinuous improvement," and the fundamental importance of systems thinking.
Quality: The definition of quality is meeting or exceeding the expecations of customers.
By that standard, so many quality and continuous improvement initiatives fail. The reason is that they have not been imbedded in systems thinking.
System: A system is a whole, which consists of parts which can affect its behavior or properties; and these parts are interdependent, i.e., each is dependent for its effect on other parts. No part of a system has an independent effect on the whole system.
The essential or defining properties of a system (e.g., organizational performance) are properties of the whole system, which none of its parts have. A hand severed from a body cannot write.
No function within an organization alone can deliver products to customers.
A system is not the sum of the behaviors of its parts; it's a product of their interactions.
Principle 1: If you improve the parts taken separately, you can be absolutely sure that the performance of the whole will not be improved.
For example, considering automobiles, if you combine the best engine (say, for example, BMW) with the best transmission (Mercedes) and the best suspension (Jaguar), the car won't run because the parts don't fit together.
Principle 2: When you get rid of something you don't want, you don't necessarily get something you do want.
Finding and improving deficiencies (e.g., defects) is not a way to improve the performance of the system.
An improvement program must be directed at what you want, not what you don't want.
Redesigning a system starts by asking yourself, what would you do if there were no constraints (a clean sheet of paper, a vision).
If you don't know that, how can you design a system with constraints!?
Principle 3: Continuous improvement isn't nearly as important as discontinuous improvement.
Creativity is a discontinuity; it breaks with the chain that came before it.
One never becomes a leader by continuously improving; that's imitation of a leader.
You only become a leader by leapfrogging those who came before you.
Principle 4: It's far more important to do the right things (even if poorly) than to do the wrong things well.
Quality ought to contain the notion of value -- of effectiveness, not just efficiency.
The difference between efficiency and effectiveness is the difference between knowledge and wisdom.
An architect is a good example of a systems thinking.
They design the house; then they design the rooms within the house.
They may modify the house to improve the quality of the rooms; but they never do so unless it simultaneously improves the quality of the house.
That's a fundamental principle of systems improvement.
Until managers take into account the systemic nature of organizations, most of their efforts to improve performance are doomed to failure.
⚖ A-1.6.2 Regulations: technicals & functionals
Compliancy risk management:
Although there are no direct regulations on the technology at this moment, there are many regulations to comply by organisations.
The topics for those regulations are mostly similar Confidentiality Integrity Availability (CIA). The result of a BIA analyses for CIA levels should be verifiable.
💡❗✅ For process requirements & design use Jabes to collect all information:
Alignment to local environments social life circumstances
Public culture, media
Alignment global social awareness, beliefs welfare
Shaping and environment:
Pervasive PDCA , DMAIC
Holistic involvement for improvements & innovations
co-adaptive 4IT
Improvements chain management, operational value stream
Prescriptive analytics
Holistic involvement for improvements & innovations
Forces in the organsisation an abstraction:
From the overhauled strategy alignment model (SAMO) a result is:
three pillars for every type of activities.
Steer: Information - the organisation, missions & visions. Business value
Shape: Communication advice how to do enablement, comply to regulations. Processes
Serve: Technology enabling fulfilment of missions. Data as Product
There are three levels to orchestrate for the
realisation:
Functional Strategy
Compliancy Tactical
Technical Operational
In a figure:
See right side
The words "Shape" "Serve" are clear in their intention.
The word "Steer" didn´t have an immediate association.
Steer synonyms alternatives:
guide - to lead or show the way, especially with intimate knowledge.
direct - to point out the way or provide instructions.
accompany - to go along providing guidance or support.
conduct - To manage or oversee the course of something.
route - To determine the path or course.
usher - o lead or escort, often with a sense of formality.
Abstraction of forces in the organsisation:
There are more lines of power in an organisation. Some of those:
Financial based management. Goal: profits at least enough budget for tasks.
Core business. Goal: Fullfilling the operations for tasks of the organisation.
Green fields. Goal: Improvement, product research, customer relations.
💣 The powers are not equally balanced The core business (operations) is the line having commonly the least influence at strategic level.
The result of that could be (risk) a total loss of all tasks the business was positioned to do.
💡 A proposal for a generic approach for balancing powers.
Steer:
dynamic: operational value stream
static: financial and other values
public: promotion, communication
Serve:
technology enablement: value stream - monitoring - feed back
CEO
The responsibilities of an organization´s CEO are set by the organization´s board of directors or other authority, depending on the organization´s structure.
They can be far-reaching or quite limited, and are typically enshrined in a formal delegation of authority regarding business administration.
Typically, responsibilities include being an active decision-maker on business strategy and other key policy issues, leader, manager, and executor.
The communicator role can involve speaking to the press and to the public, as well as to the organization´s management and employees; the decision-making role involves high-level decisions about policy and strategy.
The CEO is tasked with implementing the goals, targets and strategic objectives as determined by the board of directors.
What has always been done at BPM approaches is thinking in three layers.
For these three layers looking at the anatomy of the components, claiming when the anatomy is changed the physiology will magically become what was intended for the change.
The aspect for the interactions, the neurology of the system ignored.
All the maturity in distinct layers for:
The deviation to classic BPM is not going for a siloed BPM approach but:
Where - Interactions in the technology service and the antipode administration
How - a perspective change in sharing & communicating Information & knowledge
What - Interactions in shaping using operation research, analytics,
Lean culture goal by enabling interactions
Answering the why is the repeating ever lasting curiosity for the system as a whole.
Instead of three layers going for four (STIP) ⚒ S Leadership (Command & Control).
Periodizing the technology system or the enablement of the technology
The common loophole is starting with technology and ignoring the enablement of technology usage.
Maturity 'Cyber/administrative' Attention Points
Attention points for maturity level considerations & evaluations:
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
The reference structure 6w1h six*six
💣 The assumption is made task & roles are organized according capabilities in a:
"Steer",
"Shape",
"Serve"
hierarchy.
There is a conflict: Organizing the organisation is a hierarchical top-down responsibility with the ultimate accountability at the top of pyramid.
There is a conflict in understanding for technology and delivering a service:
The engineering order is: What How Where - Who (internal) When Which
The service order is: Where How What - Which When Who (external)
This Design Shape chapter:
The reference structure "Design Shape" as generic structure is simple in a presentation and very complicated for the context by information it can present.
The abstraction is organized:
There are four references used as chapters: What How Where and When.
Two references are left open: Who and Which. These are the to made decisions.
One reference is the scope to answer, content: Why.
⚙ A-1.6.4 The maturity of: Incentives, Culture, Structure, Resources
Prioritizing in understanding root causes for failing desired change
Work to do: solving process improvement issues by their real root-causes.
Not being mind blocked by only the technology solutions. (N.Dean Meyer)
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.
Real Reason 1: Incentives
Real Reason 2: Culture
Real Reason 3: Structure
Real Reason 4: Resources
See also: "E-1.3.1 Recognizing the 3M evils"
Prioritizing solving root causes for failing desired change
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
The mind set change to facilitating
These attributes are about culture, enabling the workforce for the technical and administrative components.
It is facilitating those others for a defined shared goal.
It is avoiding the leadership in the classic hierarchical approach of dictating in details those others.
Don't micro manage something everything anything .
Have the requirements for adequate tooling in place an let the workforce do their work.
Analysing systems, designing systems, architecting enterprises (What) has constraints.
For systems there is a resistance to change, homeostasis.
All systems are part of something greater where change is certain. Failing to adapt to change can break systems.
🚧 Those constraints include:
Not noticing changing volatile circumstances, there is no what
Avoiding adapting change by lack of knowledge and experience for how
Not knowing where to start to adapt change that has effectful
Missing clear realistic decisions for goals and timelines, when
This is about: Volatility, Uncertainty, Complexity, and Ambiguity
⚠ A-2.1.1 Frictions by management wanting control by causation
Project management, a brief history full of frictions
There is long history doing projects in the administrative/cyber world.
SDM (Dutch Pandata 1970), CAP SDM2
SDM is a methodology based on phasing. For each phase, it is precisely recorded what has been agreed with the parties involved and what needs to be done in the relevant phase.
SDM uses a process-oriented approach, which means that this method is mainly concerned with the planning and organization of the system to be created.
Managing system development projects is the main task of the SDM development method.
The documents in which these matters are recorded are called milestone products.
Prince2, in 1989 a version of PROMPT II eas adopted by the UK Government as standard for information systems (IT) project management.
The "Agile manifesto" 2001 for: lightweight development methods.
In 2005, a group headed by Cockburn and Highsmith wrote an addendum of project management principles, the PM Declaration of Interdependence, to guide software project management according to agile software development methods.
Administrative/cyber projects for intangible systems still have no solid foundation.
Software crisis a brief history
For managing software:
The term "software crisis" was coined by some attendees at the first NATO Software Engineering Conference in 1968 at Garmisch, Germany.
Edsger Dijkstra´s 1972 Turing Award Lecture makes reference to this same problem.
The term The Mythical Man-Month Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975.
The retro perspective for this: What did change since those years?
❓ A-2.1.2 Gaps for understanding requirements to identifications
Learning from experiences - leaders in a hype
Context: Agile, disappointments an example of failing solving frictions.
This should no discussion topic, but it is.
Bad experiences are not used to analyse and solved, the human reaction is a going into a blame game.
Instead the whole approach is getting blamed and replaces with a new one with similar shortcomings.
A review by one of the persons promoting agile, aglity,
"what was the Agile hype" (2025) Jim Highsmith, in a retro perspective.
For this article, I´ll focus on agile disappointments, but skip over the rhetoric. ..
👉🏾 So, I offer six candidates for the root cause of disappointments with agile that hopefully embody this constructive debate sentiment:
Capabilities are spread too thin
Capability is equal to knowledge, plus experience, plus decision-making.
The further out on the edge you get, the greater the incidence of beginners teaching beginners. ...
Performance-People imbalance
The core of the Agile Manifesto and the thinking of its authors reflect a similar idea: Deliver valuable software and Create healthy work environments.
❓ Have we gone far enough towards this goal? Absolutely not. ...
When the agile literature is full of management words like empowerment, self-organizing, empathy, servant leadership, and more, they are concerned that there isn't an equal commitment to accountability and financial success.
Doer-Enabler imbalance
... company had a ratio of about 50% doers and 50% enablers whereas an 85% to 15% was considered an appropriate balance. ...
👉🏾 alls this ratio a “Bureaucracy Mass Index (BMI).”
Other companies who have been dragged into the press recently as “getting rid of agile,” ...
❗ rebalancing: reducing the number of Enablers while increasing the number of Doers.
This is really interesting statement. Is that about the balance withing the fractal of technology or as part of the whole.
With three other parties in the system as a whole and one of those labelled enabling (administration, business) the total ratio is far below those numbers.
A span of control of 3-5 says it all. A total ratio of doers 20% vs others 80% (or worse) could be easily the real situation.
These first three options are about balance in executing the next three are about enablers culture:
Hierarchical Organization Design
In an industry where the manager-to-subordinate span of control hovers around 3-5, ... is achieving a span of 10-15 and relabeling it “span of consulting.”
... reduced management by 40% as many of the individuals moved to their cross-functional teams.
This is where agile gets hard.
Making these kinds of organizational changes, whether in IT or more widely in your organization takes courage and persistence.
❗ However, to reach higher levels of agility, organizational changes will be required, including mindset, management structures and operating models.
Confusion about Methods, Methodology, and Mindset
A software method defines the detailed steps to deliver artifacts identified by your chosen methodology.
Refactoring is a technical method for improving the quality of code.
Daily stand-ups are a collaborative method to keep teams in sync.
Product planning sessions are management methods to plan how to move forward – for a day, a week, or a month.
A software methodology defines your strategy.
It divides software work into activities or steps, each of which may include the use of specific methods, the definition of specific deliverables (a requirements document), and more.
👉🏾 Software development life cycles (SDLC) define the highest-level sequence of processes, with names like waterfall, spiral, or iterative.
This is another interesting statement. It is about methodologies and practices for doers.
More specific it is about doers in software, architects engineers, programmers - coders, testers.
❗ What is missing is knowledge management for the system as a whole.
❓ How is strategy imbedded, how getting transformed from identification to instantiation?
Fixed Mindsets
As companies grow over time the tendency is to become and to attract more fixed-mindset employees.
Maybe the 60-40 mix becomes 80-20. How difficult will it be to introduce agile to an organizational culture with an 80-20 fixed-to-growth mindset?
👉🏾 If you don´t develop an agile mindset for continuous capability improvement, you will never rise above a beginner level and will never fulfill the outcomes envisioned for your agile journey.
Conclusions
In wrapping up this nuanced landscape of agile disappointments, let´s remember that the journey toward agility is as diverse as the individuals and organizations embarking on it.
The challenges range from spreading capabilities too thin to navigating the tricky balance between performance and people.
Yet, amidst these trials, the underlying message is clear, learning from our setbacks, rather than labeling them as failures.
Agile is not a one-size-fits-all solution but a mindset that encourages adapting and evolving. It invites us to embrace change, question our assumptions, and continuously seek improvement.
So, as we reflect on our agile experiences, let's hold onto the notion that every disappointment carries the seeds of knowledge and growth.
After all, in the grand tapestry of our agile journeys, each thread of challenge is interwoven with opportunities for learning, innovation, and, ultimately, transformation.
In the irony of the blame debate in the Agile hype, this is nice sum-up to learn from.
Learning from experiences - doers in a hype
Doers in presenting their knowedge in a pdocast serie: episode "NN 0097, Unmanaged - Jack Skeels - Murray Robinson - Shane Gibson"
Following agile product development critics on what is not going as promised (2024 book review).
unmanaged
Unmanaged: A Deep Dive into Agile Mismanagement
(JS) Unmanaged is a book that comes from my biggest observation, which is Agile is getting applied everywhere.
And the single common denominator that I could see through all the failed Agile implementations, ...
👉🏾 but they wouldn't change anything about the way they manage the organization. ... (MR)I've been on both sides of the fence, client side and service provider side.
My observation is that most clients these days are saying they want to be agile, but 90 percent of clients that claim to be agile are far from it.
And all of the service providers are saying that they are agile. And 99 percent of service providers are far from it. (SG) ... as soon as you hear somebody says we're implementing Agile, that for me is a warning sign. ... it's a culture ...
Going to the topic it mentions three other reasons seen from the operational level.
Productivity Misconceptions and Misapplications of Agile (JS) A hundred years ago: We would have a department, say an assembly line, one manager and maybe eight people, and they're making ... .
So make 200 widgets a week, the manager, make sure that happened.
Today, our environments are largely "multi manager environments".
Whatever happens to the loss in productivity can't be attributed to any manager.
👉🏾 We end up hiring more managers, inversely proportional to productivity. (MR) There has been a big movement over the last few years away from speed and productivity towards focusing on business outcomes and products because you can deliver the wrong things faster.
That's not going to help you.
Predictivity Struggles of Fixed Price, Fixed Scope Projects (JS) By nature, the work we're doing in a project driven organization is: uncertain.
We don´t do the same thing twice. We only do projects for things that haven't been done before. ...
the more innovative you´re trying to be, the more complex the problem, the more creative you´re trying to be, the more uncertainty there is.
👉🏾 Uncertainty means ignorance. We don't know what it is.
This is the ultimate expression of the Problem software Agile was trying to solve. ...
❗ 💣 want you to state exactly how long it will take and how much exactly it will cost.
What happens is companies answer that question.
They say, sure, we'll have it by (...). It's only a cost this much.
And though we can´t even describe it all, you´ll be happy when you get it.
That's what the marketplace sells and buys right now. it´s hard to get out of that. (MR) It´s completely normal for projects on the client side, to be done ... the same:
it's got to be done no matter what now. We can't afford to fire them anymore.
Priority, doing the right things. Importance of Scope in Project Management (JS) You can actually drive the uncertainty of the scope, but it takes technique to do that. ...
It's just that people don't understand how to do that well.
So the first thing you implement is a process, which is, let's make sure we really understand what the client´s asking for. ...
👉🏾 But poorly defined scope and the ignoring of the fact that scope is poorly defined is the biggest problem in almost every digital agency today. (MR) But the scope is pretty unclear even from the client's side. ... If you do your scoping exercise, you spend a couple of weeks all working together defining it. ...
With the previous six others we could put them in a 9 plane as a simplification of a 6*6 matrix.
❌ A-2.1.3 Failing in understanding abstraction concepts, two dimensions
Abstraction scopes in several disciplines
The 6*6 references by J.Zachman (updated 23/8/2025) his
retro perspective on his framework.
The FIRST most important slide I ever created was the “Framework for Enterprise Architecture, the Enterprise Ontology” slide… colloquially>
“The Zachman Framework” because this is a description of (the “meta-models” of) the 36 different types of models that are relevant for designing an object, ANY OBJECT.
The reason this Framework slide is so important is because I didn’t create it… I learned it from Enterprises that designed and manufactured airplanes, computers, coffee pots, garbage cans, etc. plus some personal Architect friends that designed and constructed hundred story buildings, California ranch houses, log cabins, etc.
The Second slide Observations for enterprise design Industrial Age
Any ENTERPRISE “Architecture” or “Design” work would take too long and cost too much.
Siphoning off valuable resources that IT needs to get the code running to replace human labor and justify technology acquisition expenditures in the current accounting period, a legitimate, Industrial Age (2nd Wave) objection.
The media for descriptive representations of Industrial Age Tangible Products is either paper or digital for the Product Design (Framework Rows 1 through 5).
There is a media transformation from the design (paper or digital) to the Implementation, the actual product (Row 6), made of wood, steel, aluminum, titanium, composites, plastic, etc., etc., that is, hard, non-malleable, fixed in shape, materials.
👉🏾 Therefore, the product must be COMPLETELY DESIGNED for all the parts to physically fit together for use and/or operation.
The Third slide Tangible instead of intangible products Information Age
Similarly, the media of the enterprise descriptive representations for design (Rows 1 - 5) is either manual (paper) or automated (digital).
But, in contrast, the media of the enterprise implementation (Row 6) is THE SAME as the media of it’s design (Rows 1 - 5), either manual (paper) or automated (digital)…
therefore, there is no media transformation to fixed-shape, non-malleable materials!
Therefore, enterprises can exist and be operating, even if the Enterprise has never been designed, or is only partially designed, or is composed of “parts” that don’t fit together… i.e. “data” which is not “integrated,” enterprise-wide… i.e. data that is enterprise dis-integrated…
Since the physical implementation of the Enterprise is either paper or digital, that is malleable in both the physical and semantic senses, not rigid like Titanium, or Steel, etc. in tangible products.
Enterprise parts can be modified or shaped to fit as required.
👉🏾 Therefore the entire product, i.e. Enterprise, does NOT HAVE TO BE COMPLETELY DESIGNED, manufactured and assembled for it to exist or to be operating …
🤔 There is that contradiction for a model methodology describing enterprises and that it is about Any Object.
The explanation for the thinking framework is strong about any object.
That is including by nature intangible information objects.
Information objects got created massively in the information age.
(JAZ) To my knowledge, Alvin Toffler was the first serious academic to address the issue of “change.”
He wrote three seminal pieces of work on the subject:
Future Shock 1970
In “Future Shock” he said, “Knowledge is Change and the ever-increasing body of knowledge feeding the great engine of technology creates ever-increasing change.”
This explains the dramatic escalation in the rate of change we are experiencing today and the cautions not to assume any respite looking ahead.
👉🏾 My observation about the Second Wave: The fundamental concept of the Industrial Age paradigm is technology can be employed to extend human ability to work … that is, technology can perform processes “better, faster and cheaper” than they can be performed manually.
Therefore IT justifies the acquisition cost of technology on the number of Full Time Equivalents (FTE’s) an application would displace.
The Third Wave 1980
... The flurry of activity in the domain of Artificial Intelligence is evidence of the shifting paradigm, shifting to the 3rd (THIRD)Wave, “The Information Age.”
👉🏾 My opinion about the Third Wave, the INFORMATION AGE: The fundamental concept of the Information Age paradigm is technology can be employed to extend human ability to THINK … supporting innovation, supporting creativity, supporting disruptive change … that is, assuming that the Enterprise is DESIGNED effectively, eliminating Technical Debt and facilitating CHANGE.
If you cannot show me the inventory of descriptive representations postulated by the Zachman Framework for Enterprise Architecture, the Enterprise Ontology, I KNOW THE ENTERPRISE IS NOT DESIGNED!
And, AI cannot improve the Enterprise design if there is no Enterprise design to improve!
Powershift 1990
... What impact knowledge has on decisons by who is missing.
😲 (JAZ) In fact, as I write this paragraph, I changed my mind … the slide where I developped this “value proposition” is THE MOST IMPORTANT SLIDE I EVER CREATED.
The slide proving the Enterprise can be designed iteratively and incrementally while the Enterprise is operating is second, and the Framework slide itself is downgraded to THIRD!
Reason: because this concept universally dominates EVERY warm body in the Information Technology community if not every live person among ENTERPRISE MANAGEMENT and probably EVERY ACADEMIC institution that teaches or PUBLISHES.
… or REVIEWS ENTERPRISE ARCHITECTURE ARTICLES FOR PUBLICATION, which explains why I had difficulty getting my 3rd Wave articles published in 2nd Wave Academically Acceptable Journals.
An amazing retro perspective. When the way of communicating knowledge is the needed change, 2nd Wave methodologies need adaptions.
The IBM publication .
Understanding the Zachman framework and the hidden intends.
It is big mind-shift for getting understanding the essence behind the zachman framework, demoted to the third place in what is important.
That is even worse.
Most of us are requiring to make money for living, the result is a fall back to methodologies practices where certifications is a market. 👁 I would like to see more, but only found this: Sabsa history
It was there that I met John Zachman and listened to his keynote presentation on the Zachman Framewor, the first time I had encountered his work.
It was a moment of realisation that what we had in the SABSA layered model was conceptually the same as Zachman’s layers.
His language was different and he had analysed the layers into six columns, but otherwise it was so similar.
I went back to S.W.I.F.T. and reworked the model to align the terminology. 👁 Contradictions and omissions are in relationships. Stated are rules but hard to find and difficult to intepret.
Rules by Zachman (SAP leanix) Rule 5: Do not create diagonal relationships between cells.
Columns can be arranged in any order but should have a top-down order starting with the most significant category.
The matrix should provide clear answers to complex questions in this way, and is designed to do so–it will not benefit stakeholders to create diagonal relationships between cells.
No diagonal interactions clearly avoids complexity.
The rows are ordered but cleary not intended to be a linear flow. Not a top down mindset but each cell acting in relationships with its neighbours. This reduces complexity
❓ Columns in any order? Any interaction between cells on a row to sole is too much complexity. That is not making any sense, only by the frustration to see the framework as a recipe by practices is an explanation.
The complexity: Columns are orderd determined by discipline contexts.
An engineering context has the goal to deliver a product.
For the internal actvities the "Which" as goal in a decicions by choices.
A marketing context, sales, service with an external party.
There is a "Who" as goal for decicions by choices.
It would be too easy when those orders would be obvious.
Doing research building up knowledge is similar to engineering although the content will be different.
In the moment research is going to external, getting published columns are shift content needing adaptions.
I used Which for Why but the intention is the same the cell for the goal, "Means" (Strategies & Tactics of Column 6) (BR c066 2021 ).
Notes by JAZ and others showing an evolution
👁 Architecture Abstractions - a technology scope:
Chris Loose used the Zachman framework for T.Codd This is referring the eighties.
It is not mysterious why the people who build buildings, airplanes, battleships, locomotives, computers, all the Industrial Age products that are sufficiently complex to warrant Architecture came up with that set of description representations.
They are answering the six primitive interrogatives that constitute the total set of questions that have to be answered to have a complete description of anything: What, How, Where, Who, When, and Why.
This goes back about 7,000 years to the origins of language … and by the way, I did not invent this classification.
It has been well-exercised by humanity for thousands of years.
If you don't answer all six primitive interrogatives it means that your description is incomplete.
This is really important for engineering work. You are trying to "normalize" each characteristic.
There is an engineering cliche, something like "an elegance in simplicity."
You want to minimize redundancy except where explicitly controlled because redundancy increases complexity which affects manufacturing, operations, maintenance, performance, costs … the entire spectrum of the existence of the product. The only way to "normalize" the contents of any one Cell of the Framework is to see the total set of occurrences for any one 'abstraction' in the context of the entire object.
👁 Acceptance and state of art of the thinking framework.
Observations on Methodologies (nov 2011)
My personal opinion is that the information industry state of the art in Rows 1 (Scope) and 2 (Models of the Business) of all Columns as well as all Rows of Columns 4, 5, and 6, (Who, When, and Why) --if there is any state of the art at all-- is still very limited.
The confusion of five or six rows is mentioned by a choice of including the instantiations or not.
This confusion is important for the failing acceptence. In the early setting that 5th row got intepreted for instances.
The differnece in tangible instances and intangable ones was only recent added, see the most imporatn slide.
From the outset, the Framework for Enterprise Architecture --the "Zachman Framework"-- has been comprised of six Columns and five Rows, six Rows if you include the Functioning Enterprise as a Row.
It is in Row 6 (the Functioning Enterprise) where instance examples are classified. 👁 Common Myths About the Zachman Architecture Framework
a discussion to some of those (2021) repeat the frictions in understanding.
The Zachman Framework is abstract because it is the meta model for the knowledgebase that constitutes the design of an Enterprise.
That is, if there are no descriptive representations ("models") as prescribed by the Zachman Framework for a given Enterprise, that given Enterprise may exist, but it has never been DESIGNED … however big and complex it may be, it has only happened.
The Zachman Framework is simply the same pattern of engineering design artifacts that are created for the production and maintenance of every tangible object that exists with Enterprise names instead of product names.
Widely misunderstood and misrepresented, the Zachman Architecture Framework is simply a thinking tool, not a methodology.
Its fundamentally-neutral position concerning methodology and implementation is the secret to its power and the reason it has proven so enduring. Many aspects of the Framework are misunderstood.
⚠ A-2.1.4 Failing to abstract in many dimensions, most important Time
Understanding an Enterprise as viable system
A geographical map of an organisation is reducing the situation to a moment in time.
For only three dimensions in a 3D projection that is leaving out some of all of the dimensions and all variety for a system.
Just with the focus on:
technology vs administration
Back-end and front-end for what the systems does
Time in the now with each of them a split in supporting and executing.
The nine planes are simplified 6*6 matrices but in this used in fractals, subsystems.
here are many subsystems each of them to get services by a reference frame.
Reference frames that are subsets of the EA reference frame.
The connections are made in fractals by eight-cycles.
Technology (machines): The well known DevOps, eight Cycle Loop refers to a continuous feedback and improvement cycle, often visualized in infinity shape (∞).
Organisation (people): The yet unknown PortfolioPlan is the counterpart of DevOps enabling and prioritizing for what is to be done, also visualized in infinity shape (∞).
Frontend (processes): a hidden Pro-visionBuyer eight Cycle Loop broken up in time and orientation for what the system does (functionality) in creating some things.
Backend (structure) : a hidden MotiveAssets eight Cycle Loop broken up in time and orientation for what the system is transforming (functioning). It is the functional counterpart, antipode, of Pro-visionBuyer.
The question in this is why there are only 4 layers where the 6*6 matrix would suggest there would be 6?
The resources to get external and the product/service external are at the sides for interactions. They are interacting only in one direction when there is a flow.
Those 4 layers are the ones that have a time dimension in the vertical for the system that are expect to adapt to the externals.
A-2.2 Change the position to enabling adaptivity
Chaos in understanding (How) caused by complexity of systems: Log frames, fractals, the matryoshka metaphor.
The simple order of: What How Where question is a chaotic problem.
After we understood what issues there are ("What to change") and going into the How to solve those, the first question is again "What to change".
⚠ Going into details is handing over to others when the size gets to huge.
Challenges by human nature:
Ambiguity in goals, Complexities for goals
Natural uncertainties at situations
Fast changing volatile circumstances
📚 A-2.2.1 Components detailed in contexts
DIKW - data, information, knowledge, wisdom
❓ How to manage something where the knowledge of what when by who is unknown?
DIKW_pyramid (wiki)
The DIKW pyramid, also known variously as the DIKW hierarchy, wisdom hierarchy, knowledge hierarchy, information hierarchy, information pyramid, and the data pyramid,
refers loosely to a class of models for representing purported structural and/or functional relationships between data, information, knowledge, and wisdom.
Typically:
❶ information is defined in terms of data
❷ knowledge in terms of information
❸ wisdom in terms of knowledge
The DIKW acronym has worked into the rotation from knowledge management.
It demonstrates how the deep understanding of the subject emerges, passing through four qualitative stages:
D – data
I – information
K – knowledge
W – wisdom
The DIKW model is often quoted, or used implicitly, in definitions of data, information and knowledge in the information management, information systems and knowledge management literatures, but there has been limited direct discussion of the hierarchy.
Reviews of textbooks and a survey of scholars in relevant fields indicate that there is not a consensus as to definitions used in the model, and even less in the description of the processes that transform elements lower in the hierarchy into those above them.
➡
By the introduction of a common operational picture, data are put into context, which leads to information instead of data.
The next step, which is enabled by service-oriented web-based infrastructures (but not yet operationally used), is the use of models and simulations for decision support.
Simulation systems are the prototype for procedural knowledge, which is the basis for knowledge quality. Finally, using intelligent software agents to continually observe the battle sphere, apply models and simulations to analyse what is going on,
to monitor the execution of a plan, and to do all the tasks necessary to make the decision maker aware of what is going on,
command and control systems could even support situational awareness, the level in the value chain traditionally limited to pure cognitive methods. ➡
David Weinberger argues that although the DIKW pyramid appears to be a logical and straight-forward progression, this is incorrect.
"What looks like a logical progression is actually a desperate cry for help."
He points out there is a discontinuity between Data and Information (which are stored in computers), versus Knowledge and Wisdom (which are human endeavours).
This suggests that the DIKW pyramid is too simplistic in representing how these concepts interact. ...
👉🏾 "Knowledge is not determined by information, for it is the knowing process that first decides which information is relevant, and how it is to be used."
Technology mindset or business one question
The DIKW model as a Cry for help is an opening to review better.
The first questions are what is knowledge about and what is wisdom about?
Wisdom is better to be replaced by insight, the drive for decisions out of choices, the which.
Knowledge is ambiguous, it can be:
Knowing what the meaning of the information is, the technology mindset
Knowing the decisions in Which choice by who should be made in case of a meaningful information event, the business mindset.
The missing's in the DIKW model are the Who and When choices for decisions with insight.
It are not really missing's, it are other dimensions of the DIKW model.
Instead of oversimplified this visual is overwhelming. It is based on the value stream in segmentations.
Applying the DIKW for the good-regulator of viabel systems theory that is controlling the flow in the system, the anatomy of these line becomes more explainable.
In a figure,
see right side ❶ Culture: backend vs frontend ❷ Culture: Technology vs Functionality ❸ Split double lines in Data & Information by backend frontend. ❹ Knowledge in multiple areas each for specific domain. ❺ Consolidation of the knownledge areas to get insight for wisdom in decisions controlling the value stream.
Although there are only four visible layers in the way of it is represented there are actual six.
The similarity to a heart is pure accidental. The knowledge storage areas are part of the brain nervous system as is the insight for decisions.
🎭 A-2.2.2 Components as a whole in contexts
Emercence systems
Emergence a philosopical twist, what is the meaning?
In philosophy, systems theory, science, and art, emergence occurs when a complex entity has properties or behaviors that its parts do not have on their own, and emerge only when they interact in a wider whole.
In physics, emergence is used to describe a property, law, or phenomenon which occurs at macroscopic scales (in space or time) but not at microscopic scales, despite the fact that a macroscopic system can be viewed as a very large ensemble of microscopic systems.
In humanity also called spontaneous order in the social sciences, is a process where some form of overall order arises from local interactions between parts of an initially disordered system.
In technology arrangements can be used as simple physical prototypes for deriving mathematical formulae for the emergent responses of complex systems.
In religion and art, emergence grounds expressions of religious naturalism and syntheism in which a sense of the sacred is perceived in the workings of entirely naturalistic processes by which more complex forms arise or evolve from simpler forms.
Rules gave us predictability. Systems did exactly what we told them to, no more and no less.
Autonomy gave us adaptation and scale. Systems could act without waiting for every human instruction.
Emergence is what happens when multiple autonomous agents interact. Patterns appear that no single agent was designed to produce.
This shift from determinism to autonomy to emergence is not incremental.
Determinism gave us control. Autonomy gave us scale. Emergence gives us a new system logic altogether.
For architecture, emergence shifts the focus from components to the space between them; the interactions, dependencies, and feedback loops that determine whether systems stabilize or spiral.
For design, it means we cannot script outcomes; we must create the conditions and incentives for desirable behaviors to emerge.
For governance, it means static rules and after-the-fact audits are not enough; governance must be embedded at runtime so emergent patterns remain aligned, transparent, and safe.
My interpretation is seeing a visual with a 3*3 layout for components and the describing text is about their interactions.
Adding and interpreting in that:
Interactions in both directions but only vertical-horizontal an never diagonal.
Those interactions transformations are as important or even more than components. These are also 3*3 systems (added also the time dimension 4th).
The whole of those both 3*3 systems we should review to understand.
For understanding not only words will work we need better visuals.
Missing in this is the question of values (not only financial ones) The 4th layer on top and time shift to add.
A digital twin or design of an intangible object
The system you designed is not the system that runs.
The problem to solve is if you don't understand the system there is no way to validate the reality of the intangible system vs what is assumed it is.
The issue to solve first is an understanding of the system. For a intangible system that needs not to be complete any level any point in details can be a starting point.
Changes in the approach for the logic of design itself
The change in IT-architecture:
In deterministic systems, architecture has focused on components: capabilities, databases, services, APIs, pipelines.
The job was to make each block solid and well-defined.
Interaction was secondary and often treated as just “integration.”
When agents become autonomous, what matters most is not just the strength of each part, but what happens in the spaces between them.
That is where emergence happens.
Signals: the messages, triggers, and events that move between agents. These signals decide when an agent activates, how it reacts, and how quickly cascades spread.
Dependencies: the reliance one agent has on another for data, actions, or decisions. Dependencies can multiply risk or create bottlenecks if not managed explicitly.
Stabilisers: architectural safeguards that prevent runaway feedback loops or oscillations. Examples include rate limits, circuit breakers, quorum checks.
The model that breaks most is Governance as it centers on components (such as a process).
It doesn't consider what happens in between, which is where the multiplied risk sits!
What this says is: IT-architecture should move away from practices and from methodologies to become what the meaning of ICT architecture is.
👐 A-2.2.3 The path to instantions from contexts
Adaption to the logic of uncertainties
We are educated for a world of binary logic and exact numeric mathematical formulae.
A statement is either true of false, a measurement is an approach with uncertainties of an exact measurable object.
This is a very limited approach that is not wat the real nature humans are part of is. fuzzy logic
in mathematics, a form of logic based on the concept of a fuzzy set.
Membership in fuzzy sets is expressed in degrees of truth—i.e., as a continuum of values ranging from 0 to 1.
In a narrow sense, the term fuzzy logic refers to a system of approximate reasoning, but its widest meaning is usually identified with a mathematical theory of classes with unclear, or “fuzzy,” boundaries.
Control systems based on fuzzy logic are used in many consumer electronic devices in order to make fine adjustments to changes in the environment.
Fuzzy logic concepts and techniques have also been profitably used in linguistics, the behavioral sciences, the diagnosis of certain diseases, and even stock market analysis.
There are two type of uncertainties that should be treated different.
In 1965 Lotfi Zadeh, an engineering professor at the University of California at Berkeley, proposed a mathematical definition of those classes that lack precisely defined criteria of membership.
Fuzziness as defined by Zadeh is nonstatistical in nature, it represents vagueness due to human intuition, not uncertainty in the probabilistic sense.
Membership in a fuzzy set is usually represented graphically.
Membership functions are determined by both theoretical and empirical methods that depend on the particular application, and they may include the use of learning and optimization techniques such as neural networks or genetic algorithms.
Applying logic of uncertainties, explainable and/or by convention
The missing of an exact theoretical model does not imply the logic is not understandable.
In technical applications, fuzzy control refers to programs or algorithms using fuzzy logic to allow machines to make decisions based on the practical knowledge of a human operator.
The fundamental problem of automatic control is that of determining the appropriate response of the system, or production plant, for any given set of conditions.
Conventional control techniques are based on explicit mathematical descriptions of the system, typically a set of differential equations involving a small number of variables.
Fuzzy control, on the other hand, does not require an exact theoretical model but only the empirical knowledge of an experienced operator.
This knowledge is then expressed as a set of linguistic rules of the form “if [present conditions], then [action to be taken].”
It is very good possible the measure things and create an experience model to what is seen.
It is called machines learning, data-driven, artifical intelligence.
Practical applications of fuzzy logic are not restricted to engineering and related fields.
In medicine, expert systems using fuzzy inference can help doctors diagnose diabetes and prostate cancer.
Management science, stock market analysis, information retrieval, linguistics, and behavioral sciences are just a few of the other domains where fuzzy logic concepts and techniques have been profitably used.
The late 1990s witnessed the development of hybrid systems, which combine the advantages of two or more computing techniques.
So-called neuro-fuzzy systems integrate fuzzy logic and artificial neural networks, enabling a certain form of learning.
Systems with neuro-fuzzy components may be found in fields such as stock market prediction, intelligent information systems, and data mining (see database).
In the late 2020's Large language Models (LLM's) became the solution for almost anything.
Asking questions in human language to machines and getting purposeful answers.
Data science, Process mining, process science
From: "Want to do a process mining project" slides and videos (vdaalst).
How to position process mining in a figure:
Words that are being used are changing fast. This is confusing aspect of an immature discipline.
Data-science is now superseded by AI, Artificial Intelligence, the previous buzz-word was "big data".
The list of words: statistics, data-warehousing, datamining, unsupervised learning, machine learning, supervised learning, data management, business intelligence, shows a more constant vocabulary.
Process science is hardly used, Enterprise Architecture (EA) is more common. Another better but also hardly used systems thinking e.g. viable systems theory VSM ViSM.
Pitiful EA is seen as only a technology topic.
The list of words: simulation, operations research, workflow management, concurrency theory, business process management, operations management, industrial engineering, process modelling, planning and control, shows a more constant vocabulary.
The remarkable missing is a word for: post industrial engineering, information process engineering.
Process mining is positioned as an intersection. The used words are "Process discovery".
This is only the attempt to understand the existing situation of processes in the system.
The next steps would be:
better understanding what to improve, change, or innovate by top-down hierarchical control.
an imbedding of understanding with adaptive improvements, changes, or innovations in a facilitating setting.
Neither of those next steps got mentioned.
Two problematic frustrations as issues being mentioned, these are most likely the fundamental blocking issues for those next steps.
They should get solved by design of systems:
Data-science Traditionally not process centric and a focus on specific tasks or decisions.
Process science Traditionally not data-driven and a focus on modelling (languages) and automation.
📚 A-2.2.4 The path to motivation from materials
Value streams, processes
A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer.
❗ Just focus on the external customer Understanding the Fundamentals of Value-Stream Mapping
Value-stream mapping (VSM VaSM) is a fundamental lean practice that involves diagramming a value stream, which includes all the actions (value-creating and nonvalue-creating) needed to move a product or service from raw material to the arms of the customer, including the material and information flow.
That is rather straightforward, well tot understand.
From: slides and videos (W vd Aalst).
Not all process events will follow the expectation form the values stream, VaSM map.
For the simple value stream: a/ Order, b/ Pay, c/ Deliver, d/ Confirm flow there are many possible variations when the details vary.
The payment might be at an other moment in the flow or the delivery is split by a verification or the payment and billing got a split.
In a figure:
See right side
VSM, VaSM processes, understanding the anatomy
When there is some awareness on values streams there is soon some anxiety to know what it is about, what is going on.
It is a variation of "go and see" (Genchi Genbutsu). I in order to truly understand a situation one needs to observe what is happening at the site where work actually takes place. ⚠ Too complicated: starting with process mining without understanding the VaSM.
From: 'Want to do a process mining project' slides and videos (W vd Aalst).
Many people and organizations contact me to apply process mining.
They all have data and processes.
However, often the prerequisites of process mining are unclear.
On the one hand, process mining is super generic and can be applied in any domain, just like spreadsheets are used in any organization.
Spreadsheets can do anything with numbers.
Process mining can do anything with events.
On the other hand, event data are not just any type of data and the notion of process is very broad.
These slides aim to clarify this. You need to check:
Do my events have a case id, activity name, and timestamp?
Can I sketch the expected process model in terms of the activities in the event log?
(The process will be very different, but you should have some expectations, otherwise it is pointless to talks about processes.)
It is very naïve to replace existing software with something 'fresh'.
Process mining helps to see the main problems and can trigger actions/workflows.
Focus on the 'pain points' and not on the whole to ensure a good ROI.
Low-code automation (e.g., Make/Integromat) and Robotic Process Automation (RPA) help to interface with existing systems.
The process mining process in a figure:
The PDCA cycle is a fit in this seen the PDSA in the figure.
VSM VaSM, processes understanding the physiology
A value stream can be represented in a very simplified way that it too oversimplified.
Adding segmentation (demarcation, deny, deny for functional safety design) resulted in a more overwhelming visual.
There are four process activity areas.
There are four knowledge management areas facilitating activities.
There are four DMZ zones that verify and prepare what should get processed or delivered.
The flow is from left to right in push at the top and pull at the bottom.
In a figure,
see right side ❶ Culture: backend vs frontend ❷ Culture: Technology vs Functionality ❸ Split control for what is possible faced in threats. ❹ Knowledge in multiple areas each for specific domain. ❺ Self managed for knowledge content for each area. The controls, regulators for corrections adjustments is another dimension for this.
Although there are four visible areas in the way of it is represented there are also 2 lines of six stages for the push (top-half technology) and six for the pull (bottom-half marketing/service).
A-2.3 Frictions in managing risks, uncertainties
Analysing systems, designing systems, architecting the (Where) is acknowledging a level of non-predictability in results.
Natural conflict: leaders demand for certainties, predictability.
A system component to fulfil by roles and tasks is Risk Management.
🚧 What to look at in understanding risks:
highlights system vulnerability for what components
not something that can be fully mitigated (how)
absence of clear cause-and-effect in relationships where
incomprehensibility demands humility in decisions when
This is about Brittle, Anxious, Nonlinear, and Incomprehensible
🎭 A-2.3.1 Frictions by wanting certainties but reality are uncertainties
Uncertainties: Epistemic or Reducible - Aleatory or Irreducible
❓ How to manage something where the knowledge of what when by who to do is unknown?
Agile is Not Risk Management (Alone) (Herding Cats, Actionable information for decision-makers .. ) ❶
.... Managing in the presence of uncertainty and the resulting risk means making estimates of the outcomes that will appear in the future from the decisions made today, in the presence of naturally occurring variances, and in probabilistic events during the period over which the decision is applicable.
Without these estimates, there is no means of assessing a decision for its effectiveness in keeping the project on track for success.
➡ There is a connection between uncertainty and risk.
Uncertainty is present when probabilities cannot be quantified rigorously or validly but can be described as intervals within a probability distribution function (PDF).
Risk is present when the uncertainty of the outcome can be quantified in terms of probabilities or a range of possible values.
This distinction is important for modeling the future performance of a project´s cost, schedule, and technical outcomes in the presence of reducible and irreducible risks.
❷
Uncertainties that can be reduced with more knowledge are called – Epistemic or Reducible.
Epistemic (subjective or probabilistic) uncertainties are event-based, knowledge-based probabilities and are reducible by further knowledge gathering.
👉🏾 Epistemic uncertainty pertains to the degree of knowledge about models and their parameters.
This term comes from the Greek episteme (knowledge). Epistemic uncertainties,
These are Event-based uncertainties, where there is a probability of something happening that will unfavorably impact the project.
Are described by the probability that something will happen in the future.
Can state this probability of the event and do something about reducing this probability of occurrence.
❸
Uncertainties that cannot be reduced with knowledge are called - Aleatory or Irreducible.
Aleatory uncertainties pertain to stochastic (non-deterministic) events, the outcome of which is described using a probability distribution function(PDF).
The term aleatory comes from the Latin alea. For example in a game of chance stochastic variability's are the natural randomness of the process and are characterized by a probability density function (PDF) for their range and frequency.
👉🏾 Since these variability's are natural they are therefore irreducible.
These are Naturally occurring Variances in the underlying processes of the program.
These are variances in work duration, cost, and technical performance.
We can state the probability range of these variances within the Probability Distribution Function.
Risk management Agile Process development, critics
❓ How to manage uncertainties, unknowns when going for running a project? Agile is Not Risk Management (Alone) (Herding Cats, ...)
In a figure:
❹
When it is suggested that projects can be managed without estimating the impact of any decisions, probabilistic events, or underlying statistical processes - ... think ... - and proceed at your own risk.
The term Risk Management for projects means something beyond agile concepts. ❺
Let´s look at each of these suggestions that Agile is Risk Management.
First, look at the risk management processes and what they entail in practice.
Risk Identification Agile does not have a formal process for identifying risk.
There is no Risk Register to capture the risks, codify them, assign them ranges or probabilities of occurrence.
Risk Analyses Agile does not provide a Risk Analysis process.
Risk Planning Agile does not provide a process for planning the reduction of risk that is separate from software development.
Risk Tracking Agile does not provide a Risk Register process.
Risk Control Not clear how Agile provides a control function for managing risk.
Communication & Documentation Communication is independent of any process or framework.
PP&C, Program Planning and Control, is facing a lot of challenges. The mentioned gaps are not that complex but should get managed.
PP&C is a tiny subset of Command & Control C&C.
⚖ A-2.3.2 Gaps for understanding information process uncertainties
A Focus on Information Technology Project Management
A closed loop in software-intensive system
Is There an Underlying Theory of Software Project Management (2023 Glen B. Alleman and AnnMarie Oien, PhD).
Software Intensive Systems (SIS) projects traditionally use formal management processes for the system's acquisition or development, deployment, and operation that emphasize in-depth planning.
This approach organizes work into phases separated by decision points.
Supporters of this approach emphasize that changes made early in the project can be less expensive than changes made late in the project. ❻
SIS can be found in a variety of business and technical domains:
Business information systems
the US Government is one of the prominent consumers of ERP systems, finance systems, logistics systems, personnel, and payrolls.
Network-reliant systems
traditional command and control systems found in industry and government, where data is exchanged between disparate physical systems, with large amounts of data used to assist humans in awareness and decision-making processes.
Infrastructure systems
enterprise systems of related business, embedded, or other systems. This infrastructure provides the equipment and capability needed for integrated complex systems to function correctly.
Embedded systems
systems that interact with the physical through sensors, displays, and human command and control for control applications in industry, equipment, and products used to control other systems.
The adaption process & good regulator
"To adapt" means to change a behavior to conform to new circumstances.
Intuitively, an adaptive controller is a control system that can modify its behavior in response to changes in the dynamics of the process and the character of the disturbances. ...
Even agile processes are driven by linear, non-statistical algorithms and need the statistical aspects of the underlying processes.
To be adaptive, the control loop needs to:
Provide control for non-linear processes.
Adaptively tune the control algorithm with no interruption to the controlled process.
Be capable of fast response to changing conditions.
❼
This is nice, these are abstracted versions of my ALC types:
ALC-V1 👉🏾 Open loop system
ALC-V2 👉🏾 Simple closed loop system
Another closed loop, doubling the loops
Before establishing this context, agile methods include four significant attributes.
They are:
Incremental and Evolutionary allowing adaptation to both internal and external events.
Modular and Lean allowing components of the process to come and go depending on the specific needs of the participants and stakeholders.
Time-Based built on iterative, nestled, and concurrent work cycles.
Self-Organizing in the sense that normative guides have little to offer regarding structure and control.
Agile methods rely primarily on heuristics and participative processes rather than normative, rational methods and guidelines.
For gaps in traditional project management (PM), look at PMBOK's control block picture:
There is one feedback loop and two inputs to the process under control. ❌
In PMBOK, the method is based on a Plan, and changes to the Plan are incorporated into the Plan.
There is no capacity for a work reference signal. ❌
The control flow uses performance reports to define the change control signal. ...
There are multiple control signals ❌ both plans and change control are used as a control signals. ...
The dynamics and transfer functions of each process are not specified. ❌ This includes the sample rate and the response rate of each method.
The traditional management process does not define the dynamics of the systems under control and the loop gained for controlling this system.
❽
A question for more advanced closed loops, good regulators.
A complete approach and abstracted versions of my ALC-V3 type:
ALC-V3 👉🏾 Advanced closed loop system
Risk attention point for safety in Cybers/administrative world
Article 21: Cybersecurity risk-management measures,
❓ How to manage something complex like cyber security?
At least there are high level guidelines.
Nis2
1. Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.
Taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation, the measures referred to in the first subparagraph shall ensure a level of security of network and information systems appropriate to the risks posed. When assessing the proportionality of those measures, due account shall be taken of the degree of the entity’s exposure to risks,
the entity’s size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact.
2. The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following:
(a) policies on risk analysis and information system security;
(b) incident handling;
(c) business continuity, such as backup management and disaster recovery, and crisis management;
(d) supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;
(e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
(f) policies and procedures to assess the effectiveness of cybersecurity risk-management measures;
(g) basic cyber hygiene practices and cybersecurity training;
(h) policies and procedures regarding the use of cryptography and, where appropriate, encryption;
(i) human resources security, access control policies and asset management;
(j) the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.
The complexity is a verifiable understandable translation to instantations from identifications.
⚖ A-2.3.3 The quest in understanding abstractions, documenting knowledge
Reasons for doing documentation
👁 The first bullet is the question why to document.
Lean/Agile Documentation Strategies for Agile Teams (Agile Modeling Scott Ambler)
❶
This article explores agile and lean philosophies towards documentation within IT organizations. ...
From AM’s point of view a document is any artifact external to source code whose purpose is to convey information in a persistent manner. This is different from the concept of a model, which is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem.
Some models will become documents, or be included as a part of them, although many more will simply be discarded once they have fulfilled their purpose. ...
Agile developers recognize that documentation is an intrinsic part of any system, the creation and maintenance of which is a “necessary evil” to some and an enjoyable task for others, an aspect of software development that can be made agile when you choose to do so.
There are several valid reasons to create documentation:
Your stakeholders require it. Documentation is fundamentally a business decision.
To define a contract model. define how your system and an external one interacts.
To support communication with an external group.
To support organizational memory.
For audit purposes.
To think something through.
👁 The second bullet point is the question what to document, trade off and balance by values.
👁 The third bullet point is the question how to document.
Remarkable is the assumption to use a disperse set of tools for documentation but not a holistic simple to use for the minimal effort (cost) at the moment that is relevant.
The Jabes proposal in a nutshell
There are four layers:
A unique identifier for ownership and object type and implantation identifications enabling trade & exchange.
A reference framework for disciplines that get a coverage. For each a standardized metadata set enabling exchange.
Ready to use toolset with open source interfaces that implements the reference framework for operational usage
For maturity by quality of items an standard evaluation option for auditing.
Avoiding the effort in everybody has to build a own template a own reference set themself and creating the tools for that is the proposed innovation.
Asking a LLM whether this already is existing, results in a list of building blocks to create that yourself.
Indicators as strategy tactical operations are avoided at the architecting design approach because of the fractal nature of systems.
Seen Gaps for ideas, improvement proposals
❹ Leadership challenges:
A list of common gaps by culture an assumptions for uncertainties 🕳👁❗ to note and improve:
Managing capabality: acceptance of uncertainties where certaintity is a desire.
Managing capabality: acceptance of unknown knowledge where knowledge is wanted.
Managing capabality: Capable to understand and manage generic risks.
Ethical mind to avoid the evils as much as possible, at least open in it.
Open to architectural decisions at different layers: strategic, tactical, operational.
Well documented knowledge of processes and the information value streams.
Managing capabality: to manage the cyber security risks appropiate.
❺ Solution proposal 💡❗✅ a useful method and practice
Use Jabes to collect compliancy aspects for information and processes.
Use Jabes in well documented compliancy aspects of the transformation units.
For cyber security and generic risks: use Jabes to collect all information.
❹ Facilitators in the information processing disciplines challenges:
A list of common gaps in process science, viable systems. 🕳👁❗ to note and improve:
Openess for adapt how to change the change process.
Openess to adapt and use the knowledge of engineer specialists.
support for reduction complex questions into smaller simplistic ones.
Capable of escalating organisational issues that result in change.
Capable of prioritising understanding the VaSM (values streams) of processes and changes.
Openess to adapt how to manage variations in the VaSM processes
Openess to adapt how to use VaSM and process mining for change processes.
Awareness of the sheer number of different closed loops.
A goal to use all of the possible controllable closed loops wisely.
❺ Solution proposal 💡❗✅ a useful method and practice.
A change in changes: document, log, the activities actions and results.
Use Jabes to collect compliancy aspects for information and processes.
Well documented functional usage aspects of the transformation unit.
Well documented aspects of the information, input & delivery.
Well documented aspects of the transformation functional business rules.
Use Jabes to collect Closed loop aspects for information and processes.
Use the Jabes knowledge storage: analysing, reporting, predictions, expectations.
⚠❗ This is not about the operational processes but functionals.
For cyber security and generic risks: use Jabes to collect all information.
❹ Doers in the information processing disciplines challenges:
A list of common gaps in the information processing disciplines. 🕳👁❗ to note and improve:
Mindset acknowledging the duality data-driven process driven.
Mindset acknowledging the difference in assumption on processes and reality.
Awareness of the importance of closed loops, PDCA.
❺ Solution proposal 💡❗✅ a useful method and practice
Use Jabes to collect compliancy aspects for information and processes.
Well documented technical maintenance aspects of the transformation units.
Use Jabes to collect Closed loop aspects for information and processes.
For cyber security and generic risks: use Jabes to collect all information.
⚖ A-2.3.4 The quest for safe information processes not harming the value
Tangible security, safety: design, based on experts proficiency
Physical security is very old even executed pre first-wave because being a matter of survival.
Center of Gravity (CcG), a term (Clausewitz) to identify the source of strength. By protecting the own and attacking the enemy's, strategists can achieve decisive results with minimal effort. Demarcation the sixth D.
Physical security is often broken down into a set of general concepts, the big “Ds” of security – Deter, Detect, Deny, Delay, and Defend.
This division of function is useful for reducing a complex security problem into a set of simpler ones that can be systematically addressed.
A clear demarcation of the perimeter is so vital to the overall security and efficient operation of a site that demarcate can be considered the sixth “D” of security.
The order wit an indication of the transudations:
Demarcation, By establishing clear boundaries, you know exactly where to enforce access controls. (Segmentation)
Deny, When a denial fails, slowing down an attacker gives your team more time to react.
Delay - As adversaries hit friction, overt deterrents reinforce that the environment is hostile.
Deter, When deterrence fails, an environment primed for visibility spot intruders faster.
Detect, With timely detection, your incident response playbooks activates, before escalatation.
Defend Be ready to act for timely actions on threats.
The order: Where How What - Which When Who adapt to external system events.
The internal system adaption: What How Where - Who When Which. This is an essential difference compared to e.g. engineering.
Intangible security, safety: design, based on experts proficiency
35.030 CIS contols v8.1
The CIS Critical Security Controls® (CIS Controls)® started as a simple grassroots activity to identify the most common and important real-world cyber attacks that affect enterprises every day, translate that knowledge and experience into positive, constructive action for defenders, and then share that information with a wider audience.
The original goals were modest—to help people and enterprises focus their attention and get started on the most important steps to defend themselves from the attacks that really mattered.
The CIS Controls have matured into an international community of volunteer individuals and institutions that:
Share insights into attacks and attackers, identify root causes, and translate that into classes of defensive action
Create and share tools, working aids, and stories of adoption.
Map the CIS Controls to regulatory and compliance frameworks in order to ensure alignment.
Identify common problems and barriers (like initial assessment and implementation roadmaps), and solve them as a community.
The CIS Controls reflect the combined knowledge of experts from every part of the ecosystem (companies, governments, individuals), with every role (threat responders and analysts, technologists, information technology (IT) operators and defenders, vulnerability-finders, tool makers, solution providers, users, policy-makers, auditors, etc.), and across many sectors (government, power, defense, finance, transportation, academia, consulting, security, IT, etc.), who have banded together to create, adopt, and support the CIS Controls.
AI Security best practices, based on experts proficiency
In every hype also with AI the design of security is missing, only the old "best practices" are renewed in other words.
AI risk control (Alan Jason 2025) Most organizations are deploying AI—but few are securing it.
Microsoft’s AI Security Risk Assessment is a wake-up call for CISOs, architects, and risk leads.
It’s not just theory—it’s a hands-on framework that maps AI risks across the full lifecycle: from data sourcing to model deployment.
AI systems are built on traditional IT—but introduce novel attack surfaces.
Security must start at the data layer. Hashing, access audits, and versioning aren’t optional anymore.
Model governance is the new perimeter. Version control, red teaming, and fallback mechanisms are essential.
Auditability and explainability aren’t just ethical—they’re operational.
A-2.4 Systems: identification to instantiation (lean)
There is a distraction from the
real business goal that information processing should solve.
A desire for easy solutions without management impact.
The
reality is a needed culture change in management.
What to look at for the why:
Processing, lean workunit: one action point of many
Information Processing: transformations
Technology: just tools for achieving missions
⚒ A-2.4.1 Dualities in the system & model assumptions vs reality
Data driven - process driven
There is strong relationship between two approaches, data-driven, process-driven they can´t exist without the other.
fluxicon disco manual (vdaalst)
Data science is the profession of the future. However, it is not sufficient to focus on data storage and data analysis.
The data scientist also needs to relate data to processes.
At the same time, process analysis professionals need to learn how to incorporate data from the IT systems into their work.
In a figure:
See left side
Assumed processes - reality
When you ask someone about how their process is being performed, or look how it is documented, the structure is typically relatively simple (“First we do X, then, we do Y, etc.”).
However, in
reality processes are much more complex.
👉🏾 There is rework: Steps have to be done again, because they were not right the first time.
👉🏾 Exceptions need to made to deal with special situations, different people perform the same process in different ways, and so on.
👉🏾 So, there is a discrepancy between how people assume that processes are performed and how they are actually executed.
... But looking further, this discrepancy is not even the biggest problem.
After all, to a certain extent it can be expected that not everything is always going according to plan.
💣 The much bigger problem is that in most situations nobody has an overview about how the
real process looks like in the first place.
In a figure:
See left side
Why is it so difficult to have an overview about how the processes are actually performed?
Subjectivity: Everyone has a subjective picture of the process.
Partial view: Specifically for processes there is the additional challenge that there is not one single person that performs the complete process.
Change: Processes change all the time, often while they are being analysed.
Invisibility through digitization of processes. In the old times, a pile of paper on the desk was an indication.
Nowadays a customer case can stuck in the system only hearing about it once the customer complains.
⚙ A-2.4.2 Value in information flow: Feed back, closed loops, Control
VSM, process mining, processes
From: "Want to do a process mining project" slides and videos (W vd Aalst).
The idea of using data, transformed into information for seeing what is going on the shop floor.
In a figure:
See right side
VSM, processes, architectural decisions
Decisions in processes are classifies as architectural. The problem is there are applicable layers for this in the change process or in the specficiations. ISO/IEC 42010
defines requirements on the description of system, software and enterprise architectures.
It aims to standardise the practice of architecture description by defining standard terms, presenting a conceptual foundation for expressing, communicating and reviewing architectures and specifying requirements that apply to architecture descriptions, architecture frameworks and architecture description languages.
In a figure:
See right side
Agile value stream changes - execute
Assume all the specifications are physical stored artifacts in a standard meta model.
When going for change the goal is an adjustment of specifications by the change.
That adjustment is describing new version of the product in the portfolio.
For every activity there is a planning and logging control dataset.
The meta model conforms to the layering in the nine-plane with some differences:
❶ The suggestion box, backlog, known issues, innovation proposals (down left)
❷ design & building the process or components (top left)
❸ validations of the process the process, is at the II (top right)
❹ the specifications with, known issues, is at the IV (down right)
Once a change has been started there is continuous activity for "design/build" and "product validation".
This stops at the moment the enablement is blocked or the new specifications are accepted to be of high quality where no need for change is requested.
A figure:
See left side
Agile value streams change - closed loop
Going for a closed loop control the first actions is a structured registration of activities and results.
For every activity there is a planning and logging control dataset.
All of these control datasets are sources for reporting and analytics.
A standardised centralised approach enables standard reporting solutions.
More important it is an opening to advanced analytics giving more insight more knowledge more wisdom on changes.
The four control datasets:
A figure:
See left side
The transformation unit - technology
There are three levels to orchestrate for the transformation:
Functional (Strategy)
Compliancy (Tactical)
Technical (Operational)
There are three area´s of interest to orchestrate for the transformation:
(Steer) Administration
(Shape) Authentication / Authentication domains
(Serve) Networking
The goal with the transformation: transform the retrieved source materials of information into a new product of information.
Use the conforming assembly instructions and validate the expectations of levels of quality are met.
A figure:
See right side
🎭 A-2.4.3 Adjustments for the Zachman 6*6 systems thinking framework
Abandoning the linear analytical approach to one possible option
The Zachman 6*6 reference frame has two axis:
Identification context, Concept, System logic, System technology, tools components, operational instance
The assumption and usual interpretation is that these are for a linear controlled top-down managed process.
That was never the intention neither a a fit how systems are working.
Worse the ordered engineering flow is denied because a rule was made columns are not ordered.
There was no correction on those rules although that engineering order was made log after that.
👁 💡 Replacing “Why” with “Which” in the Zachman Framework shifts the focus from abstract purpose to concrete decision-making, choosing among viable options based on context, constraints, and priorities.
Instead of asking “Why does this system exist?” we now ask “Which option best fulfils our goals?”.
This aligns better with adaptive planning, scenario modelling, and option evaluation—especially in dynamic environments like enterprise design or AI governance.
Stakeholder the strategist focus on: Purpose, intent, goals by a motivations to answer the why.
Stakeholder the decision-maker want a choice among alternatives in selecting "which one".
At this point the complexity grows beyond the scope of this page.
A split-off for details see 🔰here (6x6 systems lean).
Back to the basics of strategy
IT architects, digital leaders and tech professionals who are curious about the intersection of technology, people and organization.
Do you recognize this? You build technically sound solutions, but:
Business and IT speak different languages about strategy
Vendor relationships become more complex than planned
Technical roadmaps clash with organizational reality
You're reacting more than directing
To discuss:
How organizations influence each other - and why your IT strategy often goes in a different direction than planned
Vendor lock-in as a strategic pattern: when it works for you, when against you
First Mover or Fast Follower? Understanding timing in technology adoption
Navigate between collaboration and competition (with other departments, vendors, partners)
Recognizing which forces drive your strategic direction - and how to leverage them
With real-world examples such as:
Platform owners changing the rules of the game
IT departments evolving from cost center to strategic partner
Technical choices that unintentionally create strategic dependencies
This completely crushes down the idea that strategy is something that is decided in the boardroom.
The idea that change is something that can bed decided on in assumed certainties by assumptions.
How systems fundamentally behave is really driving change.
systems_methodologies_from_first_systems_principles (Patrick Hoverstadt, Lucy Loh 2023 )
This paper argues that when this is not the case,when confronted with a situation where there is not aready-made approach waiting to be deployed, the surestand fastest route to developing an approach that is sys-temically sound is by going back to the roots of systemsthinking and that these are codified in a set of principles. ...
Selecting the easiest-to-understandcomponents from various approaches and assuming thatputting them together will be a systemically soundapproach ignores not only the epistemological differencesbetween approaches but also the questions of coherenceand systemic purpose that are critical in developing amethodology if it is to be genuinely useful. blog referencing Hoverstadt
⚖ A-2.4.4 Integrating systems thinking to lean and more
An origin in thinking on system constraints
The bullwhip effect
is a supply chain phenomenon where orders to suppliers tend to have a larger variability than sales to buyers, which results in an amplified demand variability upstream.
In part, this results in increasing swings in inventory in response to shifts in consumer demand as one moves further up the supply chain.
The concept first appeared in Jay Forrester's Industrial Dynamics (1961) and thus it is also known as the Forrester effect.
It has been described as "the observed propensity for material orders to be more variable than demand signals and for this variability to increase the further upstream a company is in a supply chain". why-leveling
Hence, breaking this vicious cycle of fluctuations can yield great benefits throughout the value chain. Usually, these benefits materialize upstream where your parts come from.
However, these can also be within your own system, where your workers can probably work more efficient if production is leveled.
https://en.wikipedia.org/wiki/The_Fifth_Discipline
The relationship between systems thinking and lean
Systems Thinking and Lean? ((Michael Ballé 2009)
A fascinating question, one not so easily answered, because we’re talking about two very different approaches, one a philosophy as well as a set of tools, the other, a practice.
In its broadest sense, systems thinking is a framework that takes into account the interconnected nature of systems.
It is also a thinking tool, which helps us look at the impact of feedback loops on how a system behaves; analyze specific situations to explain otherwise puzzling behaviors; and design interventions with an eye for potential unintended consequences.
... In the process of developing this capability,Toyota has found that the information the production process receives is at least as important as its delivery capability.
This is pure systems thinking. The ompany started by focusing on the impact of feedback loops on “lead time.”. Lead time is the interval from the moment the customer gives an order to the point when the company collects the cash; it encompasses production and stocking time.
Toyota developed a unique method called the “Material and Information Flow Analysis” to visualize where information flows impacted the process and how.
(This technique became known outside ofToyota as “Value Stream Mapping,” from John Shook and Mike Rother’s bestselling book, Learning to See).
The damage caused by the lack of systems thinking in attempts to apply lean shows starkly in two typical cases.
Many companies have latched onto Value Stream Mapping as a great tool to analyze their processes (which it is).
But when you look at their maps more closely, you often find that the production process is sketched in painful detail, whereas the information flow is barely suggested.
Kanban is about taking all ambiguity out of the information flow to make sure that the final assembly schedule is reproduced “mechanically” throughout the supply chain,avoiding the need for the individual judgments that contribute to the bullwhip effect.
The bottom line: Without an understanding of systems thinking it's hard to get lean right and without the practice of lean techniques it's difficult to make system thinking a day-today reality to concretely improve systems performance. Michael Ballé site the start
Four fields to better understand business
The relationship between systems thinking and lean
https://www.amazon.com/Managing-Systems-Thinking-Dynamics-Business/dp/0077079515
The common scenario when a problem arises in an organization is that management find a solution that is localized and focused on solving that specific problem.
However, the problem may re-occur if the management decisions that allowed the difficulty to arise in the first place are not retraced and examined.
Systems thinking is a framework that enables managers to exploit the commonsense, intuitive responses they may already follow when getting to the root of problems or inefficiencies in their organizations. By unravelling decision-making processes in a logical, systematic way, managers can address issues central to their organization, creating far-reaching benefits. This text is a practical guide to this method, popularized by Peter Senge's "The Fifth Discipline".
It has a readable style, diagrams and anecdotal case studies that provide and explanation of the benefit and "how to" of systems thinking is a business environment.
The text identifies areas of action and a seven-step approaaoch to systematic analysis.
A-2.5 Instantiations conforming identifications
Optimising lean "processes: cyber/adminstrative" is the goal Jabes is helping to focus on.
Value stream processes are core business lines. These are dependent on the quality & quantity of a technology connection.
Where to pay attention on:
Ordening categorizing the thinking mindset is putting them is some framework. The most used one is a quadrant. The advantage is usage for the most simple questions for what to choose.
For example:
Which are the ones that are applicable for a situation
What are the global relationships in this limited setting.
The disadvantage is is that is very limited by that limited options. For example the shown quadrant for systems thinking:
The question of what complexity is hidden too much, is avoiding oversimplification.
A quadrant is a simplification of a 6*6 plane by reduction a consolidation of cells.
A 9-plane is a simplification of a 6*6 plane by reduction a consolidation of cells.
In the 6*6 matrix model there is some agreement but still a lot of confusion. The accepted understanding for the vertical axis is that it is an ordered abstraction. These are:
Context, eg EA: Executive perspective
Concept, eg EA: Business management perspective
System logic, eg EA: Architect perspective business logic
System Technology, eg EA: Engineer perspective for the Physics
Components, eg EA: Technician perspective
Operational instances. eg EA: Enterprise perspective of the internal involved persons.
The confusion immediate starts in wanting to see this ordered vertical axis as a linear flow but the intention is about interactions and transformations in both directions by the neighbours of the cells.
The horizontal axis never got an agreement although a proposed ordering did start.
That ordering is set by an engineering context, a technological perspective, there is also a trade perspective.
The context for the understanding, knowledge resources and skills that are needed are slightly different.
The perspective of being a service by a system in an environment.
The perspective of operating an engineering a service within a system
The trade perspective offering a product/service needing resources:
External: Where do we get the necessary external resources (broadly speaking)
Internal: How do we deploy the internally available resources (operations)
Internal: What will be delivered (operational planning)
Internal: What options exist for improvements and different deliveries (tactical vision)
Internal: When are improvement and change are possible (tactical vision)
External: To whom can what be delivered (the market) sim
The engineering perspective from identification to instantiation:
External: What external resources are needed, inventory
Internal: How do process materials & resources
Internal: Where will the components in processes get executed
Internal: Who has the responsibility for the involved activities
Internal: When will it get processed, the timing
External: To whom will te results get delivered, the motivation of activities
In this way also the horizontal axis is ordered. the same challenge in confusion by wanting to see this as a linear flow but the intention is about interactions and transformations in both directions.
By this we have a geographical map for activities with only horizontale and vertical interactions.
There is however a third dimension of time, for every cell the own history is also interacting from the past in the now to the future.
Although the simple usual presentations are 2D there are really projections of at least three dimensions (3D)!
Uncertain Future: Supporting, enabling changes that could become operational
Estimated Future: Preparing changes that could become operational
The now: Executing the operational activities
The now: Supporting, enabling the operational activities
Paste Known: "what has always been done that way" with known underpinned reasons
Paste Unknown: "what has always been done that way" but the knowledge why has lost
There are more dimensions than these three, these are:
values of any kind, not only financials
the way and options for adaptions, innovation to any kind of changes
Knowledge reference frames to use for content in build maintain and share
The usual oversimplification by models is hiding too much of all these dimensions.
Analysing a system
You need to:
be watching both the short and the long term—the whole system.
watch for what really happens, instead of listening to peoples’ theories of what happens, can explode many careless causal hypotheses.
pay attention to history. We pay too much attention to recent experience and too little attention to the past, focusing on current events rather than long term behaviour.
look for the ways the system creates its own behaviour. Do pay attention to the triggering events, the outside influences that bring forth one kind of behaviour from the system rather than another.
draw structural diagrams and then write equations, to make our assumptions visible and to express them with rigour.
get the beat of the system before you disturb the system in any way, watch how it behaves.
Let’s face it, the universe is messy. It is nonlinear, turbulent, and dynamic.
It spends its time in transient behaviour on its way to somewhere else, not in mathematically neat equilibria.
It self-organises and evolves. It creates diversity and uniformity.
That’s what makes the world interesting, that’s what makes it beautiful, and that’s what makes it work. Remember, always, that everything you know, and everything everyone knows, is only a model. We are too fascinated by the events they generate. In the end, it seems that mastery has less to do with pushing leverage points than it does with strategically, profoundly, madly, letting go and dancing with the system. And remember that power over the rules is real power.
🎭 A-2.5.2 Working Cell Goal: Aligned Operations
A typology of system agents like inventors and diplomats
These aren't occupations—they’re roles of influence.
A single person can play multiple agents across time or simultaneously.
Some are system-preserving (Operator, Diplomat, Custodian );
others are system-transforming (Inventor, Trickster, Prophet).
others are system-describing prescribing (Cartographer, Healer, Philosopher )
Traits of Meta-Agents are fluidly traverse systems, often creating friction or synthesis between domains.
Theyre often understood only in hindsight—misfits in their time, blueprints for the future.
They forge languages where none existed: new metaphors, frameworks, vocabularies.
The VSM outlines five interrelated subsystems necessary for any system (organization, society, organism) to remain viable—able to survive in a changing environment.
Role
Function
Metaphor
system-1
Operational units
Muscles doing the work
system-2
Coordination
Nervous system—managing tension
system-3
Control & optimization
Liver—resource distribution
system-4
Intelligence/Adaptation
Brain—future planning
system-5
Policy/Identity
Prefrontal cortex—purpose & values
A typology of system agents like inventors and diplomats
System 2 – Diplomats stabilize relationships, optimize communication between subsystems (e.g., departments, nations, stakeholders).
They maintain systemic cohesion in real time.
Meta-Agents:
Role
Why They Belong Here
Conductor
Orchestrates timing and synchronization across units
Runs cross-unit rhythm sessions to align calendars, SLAs
Translator
Ensures common language and semantics
Maintains a shared glossary; resolves terminology gaps
Buffer Manager
Regulates safety stocks, capacity and slack
Monitors real-time work-in-progress and adjusts buffers
Gatekeeper
Controls flows at critical interfaces
Screens, routes, and protocols incoming/outgoing requests
Harmonizer
Minimizes friction and conflict in handoffs
Facilitates joint process-tuning workshops
A typology of system agents like inventors and diplomats
System 3 (Meta-Agent) – Diplomats stabilize relationships, optimize communication between subsystems (e.g., departments, nations, stakeholders).
They maintain systemic cohesion in real time, Keeps the present functional and relationships stable.
Meta-Agents:
Role
Why They Belong Here
Steward
Allocates resources and enforces accountability
Rebalances budgets, personnel, assets among operational units
Risk Officer
Anticipates systemic risks and designs mitigations
Runs stress tests, maintains a living risk-heat map
Portfolio Manager
Curates and governs the internal project/service portfolio
Reviews, prioritizes and green-lights unit proposals
Integrator Performance Analyst
Synthesizes operational reports for executive oversight Tracks KPIs, trends and system health
Crafts System 3* review briefs and recommends synergies Publishes weekly dashboards and triggers corrective interventions
Auditor
Verifies compliance, quality and procedure adherence
Conducts rotational audits and publishes deviation reports
How They Interrelate
Conductor ↔ Steward The Conductor surfaces schedule clashes; the Steward reallocates resources to res olve them.
Translator ↔ Portfolio Manager Shared terminology ensures project proposals are clearly understood and evaluated.
Buffer Manager ↔ Risk Officer Real-time buffer metrics feed into risk forecasts and early-warning signals.
Gatekeeper ↔ Integrator Interface controls guarantee only validated data reaches executive summaries.
Harmonizer ↔ Auditor Insights from process workshops inform the Auditor’s compliance checks.
System 4 – Inventors scan the environment, introduce new patterns, imagine futures. They anticipate discontinuities and trigger adaptive learning or redesign.
Thea Sends probes into the future, introducing new potential
Meta-Agents System 4:
Role
Why They Belong Here
Explorer (Horizon-Scanner)
Systematically surveys technological, market, cultural and ecological landscapes for weak signals.
Conducting trend analyses and scanning adjacent domains.
Boundary Spanner
Translates across disciplinary, organizational or cultural divides.
Facilitating cross-domain workshops and residencies.
Visualizes dynamic system architectures, flows, and feedback loops to make complexity legible.
Designing interactive system-maps or causal loop diagrams.
-- Futurist (Prophet) --
Articulates compelling visions that emotionally mobilize stakeholders toward new horizons.
Publishing manifestos, keynote provocations, thought pieces.
Ethnographer
Observes emerging practices, rituals, and user behaviors to ground System 4 insights in lived reality.
Field immersions, contextual interviews, and diaries.
Opportunity Curator (Portfolio Manager)
Curates a balanced set of prototypes, pilot projects, and investments to hedge bets.
Allocating resources across incremental, adjacent and radical bets.
Network Weaver
Builds coalitions and innovation ecosystems—linking startups, labs, universities, and communities.
Orchestrating hackathons, consortiums, living labs.
Scenario Planner
Crafts multiple “what‐if” futures to stress-test current strategies and surface inflection points.
Building detailed narrative maps of plausible futures.
Role
Why They Belong Here
Explorer & Scenario Planner
Combine real-world scouting with imaginative forecasting to ensure visions are both grounded and expansive.
Boundary Spanner & Network Weaver
Translate insights into collaborations, ensuring that breakthroughs don’t remain siloed.
Pattern Reader & Opportunity Curator
Identify systemic leverage points and allocate experimentation resources where returns (or learnings) will be maximized.
Ethnographer & Cartographer
Anchor speculative futures in rich, qualitative data and make them visible through maps and models.
A viable system needs tension between System 3 and System 4:
Too much diplomacy (System 3) = stagnation, over-regulation.
Too much invention (System 4) = chaos, detachment from operational reality.
This dance creates dynamic viability.
The inventor projects horizons, the diplomat grounds transformation within the system’s coherence.
One seeds novelty; the other ensures it doesn’t burn the house down.
System 5 (Meta-Agent) – Harmonizes values between past, present, and future. Ensures transformations serve the system’s deeper identity.
They Harmonizes values between past, present, and future. Ensures transformations serve the system’s deeper identity.
Meta-Agents System 5:
Role
Why They Belong Here
() Philosopher
Questions the system’s premises, ethics, and direction. Defines the “why” behind the what.
Visionary Leader
Channels invention into coherent narratives. Keeps the soul of the system intact amid change.
Meta-Strategist
Reconciles the logic of diplomacy and invention—preserves values while evolving systems.
Cultural Architect
Encodes meaning in rituals, symbols, language—making change feel like continuity.
The end of the hierarchical organisation in the scope of decision making
In the information age, centralized decision-making becomes a bottleneck.
Alberts/Hayes argue that information-rich environments demand empowered actors at the edge who can interpret, decide, and act without waiting for top-down directives.
Dismantling traditional hierarchies challenges entrenched power structures, cultural norms, and comfort zones.
But the payoff, greater innovation, ownership, and responsiveness—is transformative.
Its a human-centered philosophy for leadership, collaboration, and organizational design in the 21st century.
There are strategic goals by “Power to the Edge” (Alberts/Hayes)
Decentralized Decision-Making: Shifting authority from central command to the edge of the organization—where real-time information and action intersect.
Agility and Adaptability: Empowering individuals and teams to respond quickly to dynamic environments.
Trust-Based Networks: Building systems where collaboration and shared awareness replace rigid hierarchies.
The tacticals for adapting the strategy:
From Management to Mastery: The idea that leadership is not a formal role but a personal journey, empowering individuals at the edge.
Facilitators over Bosses: Replacing traditional managers with facilitators or rotating team leads mirrors the shift from centralized control to distributed leadership.
Trust and Autonomy: Emphasizes trust and dialogue over hierarchy—core tenets
Nature as a Model: References to ecosystems (e.g., fish schools, bird flocks, forests) reinforce the idea that decentralized systems can be highly adaptive and resilient.
Dismantling traditional hierarchies challenges entrenched power structures, cultural norms, and comfort zones. But the payoff—greater innovation, ownership, and responsiveness—is transformative.
Bringing it to life: Map Your Value Streams, Build a Facilitation Cadre, Layers in Feedback Mechanisms.
A glimpse beyond: Nature-Inspired Networks, Dynamic Governance (Explore lightweight “policy as code”), Human-Tech Co-evolution (Experiment with AI assistants that surface context and risk at the edge).
By weaving these tactics into your own context, you transform abstract strategy into everyday muscle memory—ultimately unlocking that human-centered, responsive organization the information age demands.
The challlenge in the operations is adaption to the tactics.
Sometimes it is a natural adatpive change by the way the operational work is done.
The operational work however is a result of education, learning, training.
The crux of the challenge lies in translating strategic tactics into everyday operational behaviors, especially when those behaviors spring from formal training, ingrained habits, and learned processes.
To make adaptation more than a “one-off” shift, organizations must weave continuous learning and real-time feedback directly into the flow of work.
Embed Learning in the Flow of Work
Microlearning Moments
Deliver bite-sized tutorials, videos, or checklists at the point of need (e.g., via mobile apps or digital dashboards).
Tie each micro-lesson to a tactical shift (e.g., “How to run a rapid A3 experiment” or “Facilitation prompts for daily huddles”).
On-the-Job Apprenticeship
Pair less experienced operators with rotating “tactical champions” who co-solve real problems.
Encourage shadowing and peer-led debriefs immediately after an adaptation is tried.
Digital Twins & Simulations
Use lightweight, scenario-based simulators to let teams practice new tactics in a risk-free virtual environment.
Enable rapid “what-if?” iterations so lessons learned inform the next real-world cycle.
Create Continuous Feedback Loops
Real-Time Metrics & Visual Controls
Surface leading indicators (cycle time, decision latency, experiment throughput) on shop-floor or digital war-rooms.
Use simple “traffic-light” signals or Kanban boards to spotlight where the new tactics are stuck or succeeding.
Rapid PDCA Cadences
Shorten Plan-Do-Check-Act cycles from monthly to weekly (or even daily) so teams can adapt within days, not quarters.
Document small wins and failures in a shared repository for cross-team learning.
Voice of the Edge
Empower frontline teams to propose tactical tweaks and vote on the most promising ones.
Route their insights directly into leadership forums to keep strategy grounded in operational reality.
Cultivate a Learning Culture
Communities of Practice
Form cross-functional cohorts around each new tactic (e.g., “Lean Experimenters Guild” or “Edge Decision Network”)
Host regular show-and-tell sessions where practitioners demonstrate how they applied the tactic and what they learned.
“Training as a Journey,” Not an Event
Replace one-off workshops with a structured curriculum that combines e-learning modules, coaching clinics, and peer reviews over months.
Award digital badges or rotating leadership roles to spotlight mastery of each tactic.
Leader as Learning Sponsor
Have executives and managers attend the same micro-learning and simulation sessions as their teams.
Encourage them to coach, unblock, and publicly celebrate the adoption of new behaviors.
Align Incentives and Accountability
Edge level metrics
Tie metrics directly to tactical adoption (e.g., “Edge teams reduce approval latency by 50% this quarter”).
Review these metrics in every retrospective, pivoting the tactic or the support model as needed.
Safe-to-Fail Experiments
Architect “innovation sprints” within operations where teams can trial unorthodox approaches without penalty.
Debrief failures candidly—treat them as data to refine the next iteration.
Knowledge-Capture Rituals
Make frontline retrospectives mandatory after every major operational shift.
Store structured learnings (what worked, what didn’t, what’s next) in a searchable knowledge base, tagged by tactic.
Select one operational area (e.g., procurement, customer support) and launch an integrated adaptation program: microlearning, feedback loops, community forums, and metrics.
Track both behavioral adoption (how often teams use the new tactic) and outcome impact (cycle time, error rates, engagement scores). Use these insights to refine the playbook before wider rollout.
Evolve your learning platform into a living “Tactics Library”—ever-growing with new practices, case studies, and coaching clinics. Keep the organization in a perpetual beta of its own best practices. (Institutionalize Continuous Adaptation)
By fusing education, on-the-job practice, real-time feedback, and cultural supports, you turn tactical shifts from isolated reforms into self-reinforcing operational habits.
The result is a truly adaptive engine, where new strategies are mastered—and improved upon—right at the edge.
The end of the hierarchical organisation in the scope of decision making
Jabes documentation a rich structure that supports this edge empowerment:
CES-Jabes aligns enterprise processes with maturity and mission—echoing Agile’s focus on value delivery.
CES (Control Enterprise Systems) ➡ Business processes
Strategic → Vision, leadership, long-term planning
CTO-Jabes focuses on build/run/devops across strategic, tactical, and operational layers.
CTO (Control Technology Operations) ➡ DevOps & IT delivery
Operational → Execution, delivery, short-term responsiveness
This forms a 3×3 matrix—a perfect scaffold for a DevOps maturity model.
The Jabes model doesn’t just support DevOps—it extends it by embedding it in a broader organizational philosophy of sense-making, stewardship, and systemic alignment.
his shift faces resistance. Why?
Legacy systems reward control, not collaboration.
Middle management often fears loss of relevance.
Cultural inertia slows transformation.
But DevOps and Agile offer a pathway to maturity—not just technical, but organizational and human. Your Jabes framework provides the scaffolding to guide that journey.
⚖ A-2.5.3 Document Information retrieval & delivery
⚒ A-2.5.4 Document Information retrieval & delivery
A-2.6 Maturity 4: Change Processes in control
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three TIP, Bianl interrelated scopes:
✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative
⚒ A-2.6.1 Understanding the pillars How and When for the Why
ALC-V3 process line, closed loops - circular change
When the need for change in information processing is high a devops perspective using several closed loops gives other attention points:
Model monitoring supported by the model builders.
Data provision for developpers, delivered by operational support.
Business change requests, reviewed on impact before deployment.
Compliancy in regulations, security adviced before & during development, evaluted regular after deployment.
Process Management, getting to the shopfloor.
Enterprise engineering (J.Dietz) is one of the oldest going into service management with processes. It went into business process management.
💣 To solve: there is no physical shop-floor, how to get the information describing the processes?
Reference: "Want to do a process mining project" slides and videos (WvdAalst).
Historical development:
By modelling (< 1999):
Petri nets, IDef0, BPMN, ...,
A standard Business Process Model and Notation (BPMN) will provide businesses with the capability of understanding their internal business procedures in a graphical notation and will give organizations the ability to communicate these procedures in a standard manner.
Formal methods, enterprise engineering
BPM Business Process management, WFM Workflow management
Simulations (Monte Carlo)
By mining (> 1999):
Process mining
Process discovery
Predictive analytics
Conformance checking
Process mining, four types of basic proces models:
BPMN: The industry standard (here we just use a subset)
Petri nets: The oldest model for concurrent processes, de facto standard in process mining
Process trees: Frequently used in process mining: Block structured, sound by construction
DFGs: Supported by all process mining tools (simple, but no concurrency)
Cubicles - Processes
❓ How to manage processes for values streams when there is hardly anything for them documented?
Frictions by understanding, operating, managing: ALC-V1 ALC-V2 ALC-V3 process types.
These process models are abstracted visualisations what is
realisable by software.
Unclear: Q&Q Quality and Quantity controls in the values stream.
Technology: Getting rid of a waterfall dogma
The statement: "all actions have to be finished before proceeding to the next stage", is not ❌ valid.
A personal experience, a very long time ago, the project manager did claim this.
The root cause was: incentives, culture, structure, resources. Indeed: all of those.
Reducing Lead Time 4 - Development"
Development also has options to reduce the lead time that production does not have, namely concurrent engineering (also known as simultaneous engineering).
👉🏾 In manufacturing, the part can be only in one process at a time.
In development, multiple people can work on the same project.
Similar at: Concurrent_engineering (wikipedia) .
Technology: V-Model, non linearity.
(wikipedia)"
The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models.
The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.
In the visualisation the sequential order of the SIAR-model is included. There are many loopbacks to enable to react and apply change as soon as possible.
Is There an Underlying Theory of Software Project Management (2023 Glen B. Alleman and AnnMarie Oien, PhD)
Abstract: Traditional project management methods are based on scientific principles considered “normal science” but lack a theoretical basis for this approach. ...
This paper suggests that when managing in the presence of uncertainties that create a risk to project success, adaptive control theory may be better suited as a model for
project management in a rapidly changing, dynamically evolving network of statistical processes than traditional linear approaches.
Organisation goal: avoiding hidden costs.
Ethical strategy, not that obivous.
Lean: How to Look Good (An unusual post series)
Managing is not easy. Making the right decisions and improving your company is difficult, especially if the available information is uncertain and incomplete.
Sometimes, managers find it easier to simply pretend to do good and fudge the numbers instead of improving the bottom line. ...
This post looks at another shady trick, where you save money now at the expense of the future of your company.
👉🏾 For continuing success, you need to invest into the future of the company.
Failure to do so will save you money now, but will damage or even destroy the company later.
Unfortunately, some managers are more interested in their career than in their company.
To be fair, some companies are also more interested in their company than in their people, hence often this is also a case of mutual disrespect. ...
👉🏾 A list of evils collected out of the series:
Maintenance is a prime example where the benefit of the expense is delayed.
Similar to maintenance, saving money on quality can also be seen only much later.
Service is almost the same as quality.
Research is another expense with only a future benefit.
Yet another area where you can cut cost now but it suffers later from it, is: training.
Possibly the worst way to hurt a plant is to burn the goodwill of your employees for a quick buck.
Sell Your Plant and Rent It. ... in the long run, renting may be more expensive than owning. It also makes your plant vulnerable.
⚙ A-2.6.2 Deep dives BiAnl
Intra References
BiAnl, OR, is applicable to almost anything in an environment.
The following is about what was doen before in understanding BiAnl:
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three TIP, Bianl interrelated scopes:
✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative
Maturity Attention Points
Attention points for maturity level considerations & evaluations:
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
For "Operational Research: Methods and Applications", it is a collection of the whole area:
The year 2024 marks the 75th anniversary of the Journal of the Operational Research Society.
On this occasion, my colleague Fotios Petropoulos from University of Bath proposed to the editors of the journal to edit an encyclopedic article on the state of the art in OR.
Sponsor, Owner: Jabes
Building up the maturity level questions in the A-2.* series resulted in a logical fit for ownership sponsorship:
Human skills for persons active at "Shape".
Expectations on actvities and knowledgeareas by "Shape"
How Jabes is a fit for activities by "Shape"
That there should be a fit for a Sponsor, ownership for Jabes somewhere was evident.
The idea emerged from a technical challenge "Serve" but belong to the "Shape" domain.
Solving compliancy challenges for "Steer" the organisation made them a customer for the tool not the owner.
A recap: several sever impediments to solve:
ALC-V1, ALC-V2, ALC-V3: ⚠ lack understanding, thwarting initiatives for improvements.
Unclear accountablities for the value stream line: ⚠ gaps, thwarting improvements.
🎯 👁 ❓ The question will be whether people now working in that area are able to shift, adapt.
The ones in the roles for change being the possible problems in changing change.
Risk management should be part of any change process. ⚠ Adding this is another theory requiring fundamentals.
📚 A-2.6.4 Retro perspective on risks &uncertainties by Strategy
What about Risk management (I)?
"MS Co pilot" (chatgpt: IBM HBR Techtarget Wikipedia ,,):
Risk management is the systematic process of identifying, assessing, and mitigating threats or uncertainties that can affect an organization.
It involves analyzing the likelihood and impact of risks, developing strategies to minimize harm, and monitoring the effectiveness of these measures123.
Key steps in the risk management process:
Risk Identification:
This step involves identifying and assessing threats to an organization, its operations, and its workforce.
For instance, it includes evaluating IT security threats like malware and ransomware, as well as natural disasters and other potentially harmful events that could disrupt business operations.
Risk Analysis and Assessment:
In this phase, organizations establish the probability that a risk event might occur and evaluate the potential outcome of each event.
Risk evaluation compares the magnitude of each risk and ranks them based on prominence and consequence.
Risk Mitigation and Monitoring:
Risk mitigation refers to planning and developing methods to reduce threats to project objectives.
For example, a project team might implement risk mitigation strategies to identify, monitor, and evaluate risks inherent to completing a specific project, such as creating a new product.
It also includes actions to deal with issues and their effects regarding a project.
A successful risk management program helps protect an organization from uncertainty, reduces costs, and increases the likelihood of business continuity and success.
By committing necessary resources to control and mitigate risk, businesses safeguard their reputation, minimize losses, encourage innovation, and support growth.
Risk management is an endeavor that begins with requirements formulation and assessment, includes the planning and conducting of a technical risk reduction phase if needed, and strongly influences the structure of the development and test activities. ❶ Active risk management requires investment based on identification of where to best deploy scarce resources for the greatest impact on the program’s risk profile. ❷ PMs and staff should shape and control risk, not just observe progress and react to risks that are
realized. ❸ Anticipating possible adverse events, evaluating probabilities of occurrence, understanding cost and schedule impacts, and deciding to take cost effective steps ahead of time to limit their impact if they occur is the essence of effective risk management. ❹ Risk management should occur throughout the lifecycle of the program and strategies should be adjusted as the risk profile changes.
Why Strategy fails: The link we keep missing:
Human Link (2025 J.Kraayenbrink)
We talk a lot about strategy. Vision, ambition, planning, frameworks, execution… But something keeps breaking.
You can have the best ideas and the clearest roadmap, and still fall short. Again and again.
The reason? In the chain from ambition to impact, one link is consistently weak: Strategic Competency.
This is not just about knowing the strategy. It’s about whether people have the human capabilities to:
Grasp complex realities
Shape bold yet feasible futures
Move systems and people
Deliver under pressure
Adapt in real time
Strategy doesn’t fail in the boardroom. It fails in the gaps between insight and action.
A-3 Encourage the enterprise by decisions in wisdom
A-3.1 Simple information & services
Running an organisation is a special job without a clear define craftmanship.
The variety volatility is too big in the very diverse number of circumstances.
Decision makers are needing information, using other persons skills to help in underpinned decisions.
General focus areas:
🎭 Structure of an organisation
🎭 Culture in an organisation
📚 Missions & visions for the organisation
📚 Processes & information by the organisation
⟳ A-3.1.1 Simple Aligned data management - Process management
The 9-Square Data Management Model offers a robust framework tailored to foster strategic alignment across diverse facets of business operations.
Specifically crafted to address the challenges faced by executives grappling with data-related issues, this model provides targeted solutions and guidance.
By serving as a guiding principle, it facilitates the synchronization of business and data strategies, leading to enhanced efficiency in organizational decision-making processes.
With strategic goals centered around maximizing “return on data”, and clear objectives aimed at improving decision-making, optimizing organizational structure, and delivering exceptional services, this model empowers organizations to harness the full potential of their data assets.
in a figure:
See left side
😉 At this high level, the complementary artifact:
👁 process
is an alternative column topic for:
👁 data.
Data artifacts are materialised the processes are imaginair, only by observation of activities to see.
Using other words, other order:
Performing ➡ Serve
Setting up ➡ Shape
Directing ➡ Steer
⚙ Data Governance - understanding
Understanding the logic concept context on data, information requires a shared vocabulary.
Organisation
Information
Data
Serve
Usable accessible services
Operational information
Data catalog
Shape
Optimised organisation
Tactical information
Data dictionary
Steer
Improved decision making
Strategical information
Glossary business
⚙ Service, product Governance - understanding
Understanding the missions (what), how to product is made, logic business rules (what), requires a shared product knowledge with applicable capabilities.
Organisation
Information
Process
Serve
Usable accessible services
Operational transformations
Specifications products
Shape
Optimised organisation
Tactical alignments adjustments
Verifications products
Steer
Improved visions on missions
Strategical plans for change
Product Portfolio
🕳👁❗Hoshin Kanri, the playing field.
⟲ A-3.1.2 Simple Organising Enterprise Services
⚖ Lean PDCA
The PDCA (Plan-Do-Check-Act) has a long history but at some moment when going to another culture came back with changed concept, context.
The check instead of sell tells having gone in a closed loop.
25 Years after W. Edwards Deming
in a figure:
See right side
Context
Deming
Plan
⇄
Yotei
pre- act of decide or define. Make - refine - schedule/plan - execute
design
Do
⇄
Suru
versatile: "to do", "to perform", also "add" (pull-push)
produce
Check
⇄
chekku
examine in order to determine its accuracy, quality, or condition
sell
Act
⇄
akushon
the fact or process of doing something, typically to achieve an aim
redesign
⚖ Feedback, closed loop
The highest maturity level is aligning the vision mission with what is happening.
The feedback, verification of results with intentions, goals, is the beating heart of
real lean (PDCA). BIDM
BI analytics is integrated or not in the business process can strongly affect the decision making process.
Hence, we consider this category to be a very important one when delimiting a maturity stage.
CMM-5: "closed-loop" environment
in a figure:
All levels strategy, tactical, operational have their closed loop.
Although having the mindset set for BI (Business Intelligence) in the document, the concept is very generic.
🕳👁❗Hoshin Kanri, closed loop.
A-3.2 Vision & mission for Visions & Missions
Running an organisation is a special job without a clear define craftmanship.
The variety volatility is too big in the very diverse number of circumstances.
Decision makers are needing information, using other persons skills to help in underpinned decisions.
General focus areas:
📚 Missions & visions for the organisation
📚 Processes & information by the organisation
🎭 Structure of an organisation
🎭 Culture in an organisation
⟳ A-3.2.1 Strategy Visions
⚖ mission values
Hoshin Kanri:
There should be only three to six main points
these items should be based on a process, not on a target
... you will sooner or later come across an X-Matrix. It is a visually very impressive tool, but I am in serious doubt about its usefulness. It focuses on the creation of the Hoshin items, but to me this approach is overkill, and – even worse – may distract the user from actually following the PDCA, especially the Check and Act parts. ...
Setting the right goals and filtering them through the organization is important in Hoshin Kanri. In my first post I talked in detail about this as the "to-do list."
...
Like the “normal” Hoshin Kanri, this document is done at different levels in the hierarchy, starting with the top executive. These are named rather straightforward as top-level matrix, second-level matrix, and third-level matrix.
A figure:
See right side
Criticsm:
Long-term goals not long-term enough
Often redundant focus on numeric goals
Diluting responsibilities
Where´s the PDCA?
Most Hoshin Kanri documents that I know cover one year. This is usually a good duration, since one year allows for quite a bit of improvement activity.
This duration is also long enough to see the results and review the outcome.
The fit with the SIAR model and PDCA DMAIC is far to nice.
It solves the "closed loop" question. The template Hoshin Kanri template needs a closing arrow.
The information could be included in Jabes.
⚙ Annual financial
The yearly mandatory annual reports based on financial obligations should be well known.
🤔 ❓ Are financial profits the only goal?
To be honest, not❗ budgets are enabling activities whether they are personal or for an organisation.
There should be no shortage but being overflooded with finance is 😉 waste.
🕳👁❗Hoshin Kanri maturity evaluation.
⟲ A-3.2.2 Wishful thinking: in control with missions
⚒ The proces life cycle
Product lifecycle (wikipedia)
In industry, product lifecycle management (PLM) is the process of managing the entire lifecycle of a product from inception, through engineering design and manufacture, to service and disposal of manufactured products.
PLM integrates people, data, processes and business systems and provides a product information backbone for companies and their extended enterprise.
❓Why should PLM be reserved for industry of physical artefacts.?
⚖ Mindset prerequisites: Siar model - static
The model covers all of:
Simple serial process instructions: 0 - 9
Duality between processes:
transformations, processes and
information - data
four quadrants:
Push - Pull
lean agile requests deliveries
Value stream: left to right
External negotiations
PDCA, DMAIC, lean agile improvements
A nine plane, vertical:
Steer, Shape, Serve
Horizontal:
Organisation,
Information - Services
Data - Process
realistic human interaction & communication.
A third dimension, hierarchy in similar structures, a cubic:
strategy, tactical, operational- the foundation
Accountabilities, responsibilities, roles
🕳👁❗ Translation Hoshin Kanri into an organisation.
⚙ Siar model: dData driven mindset
The value stream in the SIAR model covers a lot.
The mindset by this model is used over and over again.
The static element data - information is well to place.
Processing, transforming, is a dynamic process.
A circular representation is a better fit.
The cycle:
Ideate - Asses
Plan - Enable
Demand, Backend
Frontend , Delivery
Customer interaction: bottom right side.
Supply chain interaction: bottom left side. 🕳👁❗Translation Hoshin Kanri into services, processes. 🕳👁❗ Translation Hoshin Kanri into applicable layers in the nine plane * 3 layers.
A-3.3 Ideate Enterprise Enablement
It turns out to be better, easier, describing what successful leaders do than teaching all leaders how to succeed.
A story of the future, broad enough to adapt to change, accurate enough for competitive advantage. They called this skill "vision".
Four challenges:
Your environment is changing fast
You lack the data to make confident decisions
Your operations sprawl with processes
You´re spotting trends that could be good — or not
⟳ A-3.3.1 Enterprise Culture vision
Demings legacy and the Toyota way
25 Years after W. Edwards Deming
He greatly influenced the management of quality in Japan, where he is still revered as one of the great gurus in manufacturing.
Through his influence on Toyota, his ideas are now common in the lean world.
⚖ Lean culture, PDCA
❓ what is
real lean about?
Create constancy of purpose toward improvement of product and service, with the aim to become competitive, to stay in business and to provide jobs.
Adopt the new philosophy. We are in a new economic age.
Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.
End the practice of awarding business on the basis of a price tag. Instead, minimize total cost.
Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
Institute training on the job.
Institute leadership .
The aim of supervision should be to help people and machines and gadgets do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
(see Point 12 and Ch. 8 of Out of the Crisis).
Drive out fear, so that everyone may work effectively for the company. (See Ch. 3 of Out of the Crisis)
Break down barriers between departments.
People in research, design, sales, and production must work as a team, to foresee problems of production and usage that may be encountered with the product or service.
Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity.
Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
Eliminate work standards (quotas) on the factory floor. Substitute with leadership.
Eliminate management by objective. Eliminate management by numbers and numerical goals. Instead substitute with leadership.
Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objectives (See Ch. 3 of Out of the Crisis).
Institute a vigorous program of education and self-improvement.
Put everybody in the company to work to accomplish the transformation. The transformation is everybody´s job.
⚖ Lean, Deadly Diseases
Well that is
real lean, very sensible, far more than that PDCA cycle.
❓ What should be avoided whith
real lean?
He also created a list of the “Seven Deadly Diseases,” which are also sensible.
Lack of constancy of purpose
Emphasis on short-term profits
Evaluation by performance, merit rating, or annual review of performance
Mobility of management
Running a company on visible figures alone
Excessive medical costs
Excessive costs of warranty, fueled by lawyers who work for contingency fees
provides some guidance for categorization of content.
In the scope of processes:
Steer:
❶ Which goals are in scope
❷ Where are processes: scoped goals
Shape:
❸ When there is an action
❹ Who will develop an action
Serve:
❺ What to desing, develop
❻ How to deliver, manage, operate
Don´t force this into a fixed hierarchy role.
Using the V-model for change and improvements is a lean approach for controlled closed loops.
The A3 lean approach for solving issues in existing streams, process lines and, ideate Empathize for defining new designs.
🕳👁❗Using
real lean, do the needed planning and administration.
⚒ 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".
A figure:
See right side
🕳👁❗Have a shared vocabulary at each layer for each domain.
A-3.4 Planning optimised lean organisations
Optimising lean "processes: cyber/adminstrative" is the goal Jabes is helping to focus on.
Value stream processes are core business lines. These are dependent on the quality & quantity of a technology connection.
Where to pay attention on:
T - Business service alignment
I - Business service optimization
P - Business service Functional processes
⚖ A-3.4.1 Do optimize the planner, the decision maker
🎭 Decision-Making doesn´t always improve with more data
The key to intelligent leadership in VUCA is low-data decision making.
Low-data decision making is impossible for computers, which is why volatility causes AI to become brittle and prone to catastrophic error.
But low-data decision making is an inherent power of the brain, which evolved to thrive in unpredictable environments. ...
Prompted your brain to imagine: What if?
To return to that earlier mindset, exit your adult brain´s bias toward abstract reasoning.
Focus instead on identifying what’s unique about every person you meet and every place you visit. ...
You´l know you´re picking up on the exceptional if you find yourself experiencing that childlike power to dream new tomorrows, imagining what could happen next.
📚 Financial gaps to structured approaches
What to evaluate at decisions:
❶ 💰 Not knowing a financial value possible ignores the
real value.
❷ 💰 Executing by financial key performance indicators distract from
real values.
❸ 💰 OpEx, CapEx are financial accounting choices not based on
real values.
Choices made on only financial profits can have big impact on the organisation long term life expectations.
Examples:
Quality of a product has no value at financial reports. Decreasing quality below acceptable level 👉🏾 customers leaving.
Process process reliability has no value at financial reports. Decreasing process reliability. 👉🏾 costly breakdowns, scandals.
Optimizing for short term financial profits. Long term financial inconsistency. 👉🏾 collapsing profitability.
🕳👁❗Accept a level of uncertainties, the future is not known yet. 🕳👁❗Don´t rely solely on financial values. Add other values preferable with metrics.
⚒ A-3.4.2 The closed loop 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.
There is an effect: in the beginning things are going worse then expected, worse than before improvements were done.
Why would the reason for that be?
Options:
the change is by nature causing errors seeking a new balance
not knowing the effects with change options. Instead the approach itself is by trial/error attempts
The announced change is micro managed, harming the existing operations
The announced change is not correct, not wanted and being disputed
Bad scenarios (continuity of the organisation becoming disputable):
💣changing that fast, improvement moments never happen
💣no change at all. Technical and functional debt pillowing up
🕳👁❗Understand and manage the impact of changes.
⚙ A-3.4.3 Translation missions visions into change
🎭 Commnication of visions, missions
The vision and missions should be clear defined to enable clear understanding of the intentions.
An interesting name:
➡ Hoshin Kanri ➡X-matrix
A figure:
See right side
Criticsm:
Long-term goals not long-term enough
Often redundant focus on numeric goals
Diluting responsibilities
Where´s the PDCA?
It is possible to connect to this using the Jabes administrative options.
📚 Define changes by undesrtanding vision & missions
Going for change either using DMAIC (redesign) or PDCA (design) A pull - push flow acting on the values stream are resulting activities.
Starting at the right bottom side, there are four stages in two lines:
IV Ideate - Asses (pull)
⟳
III Enable - Plan (pull)
I Demand - Backend (push)
⟳
II Frontend - Delivery (push)
A figure:
See right side
🕳👁❗Have changes improvements planned aligned to visions missions. 🕳👁❗Execute changes improvements aligned to visions missions.
A-3.5 Realizing optimised lean organisations
Optimising lean "processes: cyber/adminstrative" is the goal Jabes is helping to focus on.
Value stream processes are core business lines. These are dependent on the quality & quantity of a technology connection.
Where to pay attention on:
T - Technology service alignment
I - Technology service optimization
P - Technology service Functional processes
⚒ A-3.5.1 PDCA cycle administrative/cyber support
There are many frameworks, tools that support them in a userfriendly way are hard to find for administrative/cyber processes.
A proposal, Jabes:
All the specifications are physical stored artifacts in a standard meta model.
It is possible to export and import all specifications into another owner or onather identification.
The meta model conforms to the layering in the nine-plane with some little differences:
the backlog, known issues, innovation proposals, is at III (down left)
design & building the process (or components of those), is at I (top left)
validations of the process the process, is at the II (top right)
the specifications with, known issues, is at the IV (down right)
For every activity there is a planning and logging control dataset. 🕳👁❗Have toolings in place that
really support frameworks for
real lean.
⚙ A-3.5.2 PDCA organise the enterprise in the nine-plane
value stream
Having all activities for a process in the nine plane, the question is what happened with the value stream for missions?
The result delivery is going out at the bottom when the visualisation is having "Strategic" at the top.
🤔 Turn the visualisation 90° counter clockwise ⟲.
The value stream will be left to right
The role of the leader changes to an enabler
Lean - pull push
The three "Shape" planes are the "pull" line, shaping the organisation. 🤔 Where is the "push"?
Good alignment by all three lines is needed.
Both are "push":
the three "Steer" (functional business) planes
the three "Serve" (technical enabling) planes
🕳👁❗Have a shared vocabulary at each layer for each domain.
⚖ A-3.5.3 PDCA changing the way of change the enterprise
Using the Jabes framework with a Jabes tooling gives a remarkable visualisation.
Instead of missions - visions or organisation value streams the process of change processes is the change.
Still having nine planes, showing the SIAR model in several levels
Goal: enabling controlled data driven processes at (IV)
Enabling & planning: understanding the nine plane at (III)
Designing building validating the Jabes tool/product at (I)
Delivery of Jabes tool. change in the framework for processes at customers at(II)
🕳👁❗Be open for how to change the change process
A-3.6 Maturity 5: Controlled Enterprise Changes
"Managing technology service" is a prerequisite for "processes: cyber/adminstrative".
Although the focus should be on the value stream processes it starts by the technology connection.
From the three TIP, Bianl interrelated scopes:
✅ T - Technology service alignment
✅ I - Improve organization to optimization
✅ P - Processes: cyber/adminstrative
⚒ A-3.6.1 Maturity tools "Cyber/administrative"
A gap to a structured approach
There is a lot of management jargon hiding the
real goals with all uncertainties.
❓ Would it possible to improve and change in a more structured approach? 💡 Building Jabes
The building of Jabes will be a lot of pioneering. A bootstrap approach while developing the product is possible.
The whole of Jabes is needing several persons to
realize for the magnitude and scope.
Needed is a team with more competencies I have.
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)...
⚙ A-3.6.2 Summary Advice organisational leaders
Maturity Basic & advanced changing the organisation.
The aim, goal, to "act" is the overacrhing elementary element that also is subject to change.
Short
Context
Plan Structure
⇄
Plan
decide or define. Make - refine - schedule/plan for execute
Let it happen
⇄
Do
versatile: "to do", "to perform", also "add" (pull-push)
Closed Loop
⇄
Check
examine in order to determine its accuracy, quality, or condition
⚒ Trying to understand the "where to start" question
It almost impossible to touch an improve a single stations in a line without touching and impacting others.
Trying to do the maturity paragraph for Jabes with only the technology (SLDC) page in draft ready, I got blocked at the end.
A swithc in priority, reordering to do the other two in draft also.
The reason is simple: the perspectives in each pillar are different although it is the same topic, same concepts same context.
Surprising: aligning optimising (bianl) is the most complex topic:
CMM-4IT Technology driven perspectives
CMM-4AS Organisation missions driven perspectives
CMM-4OO The glue and oil for the others:
Solving interest conflicts
advising how to improve
advising how to be compliant to regulations
⚙ A-3.6.4 Following steps
retrospective
Going trough all this again, some experience from the past are resurrected:
The get-away to technology as a solution for what is not well understood as a process.
Watching parody stories and parody cartoons for what is perceived to be not going well.
The switch to how to improve something is a np-hard problem.
other pages
These are design sdlc concepts, others:
Data The ready to use technology available in the market.
Serve previous, Technology SDLC Development Life cycle (next)
Steer previous, Business organisation value streams
When the image link fails, 🔰 click here. 
When the image link fails, 🔰 click here. 
A next DODAF version for concepts in a figure. 
In 1995, the first version of TOGAF (TOGAF 1.0) was presented.
This version was mainly based on the Technical Architecture Framework for Information Management (TAFIM), developed started in the late 1980s by the US Department of Defense. 
Typically:
Autonomy creates scale, Emergence creates risk Can we architect for both? (L.Lowgren LI)
Modular and Lean allowing components of the process to come and go depending on the specific needs of the participants and stakeholders.
For gaps in traditional project management (PM), look at PMBOK's control block picture:
Demarcation the sixth D.
Physical security is often broken down into a set of general concepts, the big “Ds” of security – Deter, Detect, Deny, Delay, and Defend.
This division of function is useful for reducing a complex security problem into a set of simpler ones that can be systematically addressed. 
Reducing Lead Time 4 - Development"
Development also has options to reduce the lead time that production does not have, namely concurrent engineering (also known as simultaneous engineering). 
(wikipedia)"
The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models.
The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.
❶ Active risk management requires investment based on identification of where to best deploy scarce resources for the greatest impact on the program’s risk profile.
Why Strategy fails: The link we keep missing:
Human Link (2025 J.Kraayenbrink) 
.svg)
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. 
💡 Building Jabes
The building of Jabes will be a lot of pioneering. A bootstrap approach while developing the product is possible.
The whole of Jabes is needing several persons to 
