⚙ 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.
This page is about Optimizing. 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.
⚒ Three Pillars as an organizational structure
Organisations do exist for a long time.
It is just recently started to view them in more technical scientific way.
There are several stages:
An ad-hoc organisation does create hierarchical leaders. The biological leader of a herd.
In an stadard (repeatable) organisation there are still hierarchical leaders.
It was the technology pushing this.
The organisation powered by technology in a ship like constellation.
The engines (data centre) out of sight below visibility.
In an industrial approach information processing Serves multiple customers (multi tenancy) for the best performance and the best profits on all layers.
There are six pillars in a functional and technical layer.
A futuristic vision is a positive attitude but can easily become negative when too far from reality.
The three internal lines:
Information (Business, Missions Visions, BPM),
Technology (Operations SDLC),
Communication (Information Analytics),
Are getting the attention while the hypes are what is happening by changes externally.
The attention and reactions and hypes are reactive there is a resistance for really change in adapting the new possibilities.
The attention and reactions and hypes are pro-active predictive there is no resistance for really change.
Adapting the new possibilities.
There is an pro-active predictive mindset accepting prescriptive advisories and a vision for enabling disruptive changes.
For the stages four and five a limiting factor is the human in all the loops.
Thinking it would all be solved by AI (artificial intelligence) is disconnecting form that limitation.
For the realisations and evaluations the human should be kept in those loops.
⚒ 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.
Planning, to do:
Patterns for information processing.
Patterns for data processing using a historical component in the operational layer.
Patterns for metrics & sensors.
Details for decisions with all options & probabilities.
Details for value stream being processing lines.
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 Zachamn 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 Zachman 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
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 where the improving of an enterprise started by analysing what is going on and what could be changed to improve.
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 from University of Bath 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.2Understanding the how to change, lean
What is lean?
💣 Most of us have experiences with incorrect lean.
These are usually very negative.
Try to forget those bad experiences and do a restart.
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, Activitiy, Request/Result or Situation, Ideas, Analyses, Request/Result is similar to the PDCA - DMAIC cycle.
IT just is using other words avoiding to start wit a Plan wihtout analyses.
It covers all of:
simple processes: 0 - 9
value stream: left to right
PDCA, lean agile improvements
DMAIC, lean agile problem solving
The duality between processes, transformations, and information, data
four quadrants: Push Pull
realistic human interaction & communication. nine plane
Accountabilities, responsibilities, roles
The model mindset is used over and over again.
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
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 relationships: real lean - operations research - closed loops.
ALC-V2 BI&A Analytical plane
🕳👁❗ What to note:
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?
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?
How to connect operations research to real lean?
How to get to real lean, how to achieve real support?
What is the level of information quality?
Well documented knowledge of accountable & responsible persons
💡❗✅ What to note:
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.3 Getting metrics in administrative/cyber processes
What are interactions in managing operations?
Every process being core business brings value, values stream.
It has some input being transformed into the results.
Input, transforming and delivering are belonging to core business.
There is a central control for managing enablement
The financial and other compliancy control fundaments, all those is the last area.
in a figure:
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)
Process oriented, value stream
Looking at what needs to be done, the focus only on the information for an administrative/cyber product for the value stream.
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.
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
These are basic requirements for understanding processes.
❓A question: where are the accountable, responsible, informed persons?
ALC-V2 BI&A Analytical plane
As long there is no mesh experience but an classic DWh is in place that one should be used for the needed analyses, reporting.
Manual adjustment of reports and advice are the usual approach.
The tools most used for this are: Excel, Power BI
The most tool used for presenting results: Power Point
An improvement to do is improving analytical metrics using sensors.
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.
❹ ❸ The Pull request marketing, sales and the administration is not the product.
❶ ❷ The Push delivery a car, is what the car manufacturing TPS is about.
What do you see for the product flow? Administration is done in virtual cyber world.
For a physcial product: a physial shop-floor
For a cyber virtual product: a datacenter with some flashing lights showing activity
There is a 👓 link for details. See figures:
💣 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, the following is a good approach.
Data driven processing in a figure:
A figure:
See right side
Typical characteristics:
The control postion is at the bottom not at the top of this cycle.
Starting at the right bottom side, there are four stages:
Ideate - Asses (pull)
Enable - Plan (pull)
Demand - Backend (push)
Frontend - Delivery (push)
There is a clear segregation between tooling and the functional logic, algorithm.
The tooling can be standardised in the Demand - Transform - Deliver steps.
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
❓A question: what happened to the control and metrics in the administrative/cyber world?
Already an old but still valid modelling approach: idef0 (process model)
IDEFØ is a method designed to model the decisions, actions, and activities of an organization or system.
IDEFØ was derived from a well-established graphical language, the Structured Analysis and Design Technique (SADT). ...
Effective IDEFØ models help to organize the analysis of a system and to promote good communication between the analyst and the customer.
IDEFØ is useful in establishing the scope of an analysis, especially for a functional analysis.
As a communication tool, IDEFØ enhances domain expert involvement and consensus decision-making through simplified graphical devices.
As an analysis tool, IDEFØ 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.
....
DEFØ 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:
⚒ 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), the data (product) quantum.
The idea: BI&A analytical plane:
🎯 Add a control connection at transformation process. (control: speed, safety)
A moment in time for a change in approach:
A figure:
See right side
⚙ Administrative/cyber: Data Mesh, Experience plane
Not using available information on 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 dashboarding & feedback controls using the analytical plane.
From: "Data Mesh Delivering Data-Driven Value at Scale" (book), the mesh experience.
The idea: BI&A analytical plane:
🎯 Add dashboarding, mesh experience, for the process (speed, safety, capacity)
A moment in time for a change in approach:
A figure:
See left side 🕳👁❗ How to analyse and use operational & analytical metrics?
💡❗✅ For processes, functional algorithms: use Jabes to collect all information.
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.
⟳ A-1.4.4 A living cycloid information system model
Document functional accountabilities
To get covered by documented knowledge in a portfolio are risk assessments:
Security architecture risk impact
Operational risk impact
Privacy - risk impact
Process - risk impact
This is a process in his own with the goal.
This should have been done 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 corrections.
In a figure:
See left side
Data contracts, knowing the goals of value streams
There are two moment in the value stream with a "customer" contact:
Request with an associated needed information input
Result with an associated transformed information output and possible more than just information. A physical object could be also a result.
❶ The goal with the material retrieval:
Know for who the processing is done
Know who is accountable for the retrieved information
get from correct agreed locations
agreed quality of information
A figure:
See left side
❷ The goal with the delivery: , agreed quality of information.
Know for who the processing is done
Know who is accountable for the delivered information
to correct agreed locations
agreed quality of information
A figure:
See right side
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
Inventor
Create new structures
Future-facing
Catalyzes novelty
Leonardo da Vinci, Hedy Lamarr
Diplomat
Mediate between systems
Present-stabilizing
Bridges differences
Kofi Annan, Talleyrand
Philosopher
Reflect & reframe
Meta-systemic
Interrogates assumptions
Hannah Arendt, Niklas Luhmann
Operator
Run and optimize systems
Inner-loop
Ensures functional reliability
Logistics engineers, administrators
Prophet
Envision alternate futures
Horizon-expanding
Disrupts imagination boundaries
Buckminster Fuller, Ursula K. Le Guin
Cartographer
Map system terrain
Knowledge-organizing
Makes complexity legible
Systems analysts, theorists
Trickster
Subvert rules playfully
Fractal-breaker
Reveals cracks in systems
Marcel Duchamp, hackers
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
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):
Workers, operators & administrators: System-1
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.
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.
Enablers & guiders: System-5
“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.
Work to do: solving process improvement issues by their root-causes. (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"
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
Mind set change
These attributes are about culture, enabling the workforce for the technical and administrative components.
Don´t micro manage everything.
Have the requirements for adequate tooling in place an let the workforce do their work.
👓 click on the figure for Jabes maturity organisation.
Deviation to Classic BPM. Not going for a siloed BPM approach but:
Interactions in technology service
Interactions in shaping using operation research analytics
Lean culture goal by enabling interactions
Maturity 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.
Connecting Business & Risk management
There is ❌ not a lot of attention for this kind of knowledge. There is a desire for absolute certainties, the reality is full with uncertainties.
Problems in organisations:
Ambiguity in goals, Complexities for goals
Natural uncertainties at situations
Fast changing volatile circumstances
⚖ A-2.1.1 ❓ What knowledge to use for projects?
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."
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.
🕳👁❗Capable in managing: by uncertainties where certaintity is a desire. 🕳👁❗Capable in managing: with all unknown knowledge where knowledge is wanted. 🕳👁❗Capable in support to reduce complex questions into smaller simplistic ones.
❓ 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 the translation into verifiable understandable realisations.
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, so Agile can likely do this as well.
PP&C, Program Planning and Control, is facing a lot of challenges. The mentioned gaps are not that complex but should get managed.
🕳👁❗Capable to manage the cyber security risk appropiate 🕳👁❗Capable to understand and manage generic risks
💡❗✅ For cyber security and generic risks: use Jabes to collect all information.
⚖ A-2.1.3 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.
🕳👁❗Capable of recognizing organisational issues. 🕳👁❗Capable of escalating organisational issues that result in change.
A-2.2 Feed-back loop - Process results
Connecting Business & Project management
There is ❌ not a lot of attention for this kind of knowledge. There is a desire for absolute certainties, the reality is full with uncertainties.
Problems in organisations:
Ambiguity in goals, Complexities for goals
Natural uncertainties at situations
Fast changing volatile circumstances
⚖ A-2.2.1 ❓ Question: how to do projects?
Project management, a brief history
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.
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 still have no solid foundation.
Agile, disappointments
Learning from experiences. This should no discussion topic, but it is.
Bad experiences are not used to analyse and solved.
Instead the whole approach is getting blamed and replaces with a new one with similar shortcomings.
A review on what is going in at Agile:
what root causes agile disappointments (jim-highsmith)
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
The further out on the edge you get, the greater the incidence of beginners teaching beginners. ...
Capability is equal to knowledge, plus experience, plus decision-making.
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,” ... they have been rebalancing.
That is, reducing the number of Enablers ... while increasing the number of Doers ... .
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.
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, this is nice sum-up to learn from.
🕳👁❗Open for adapt how to change the change process
⚙ A-2.2.2 Influence to: technology & organisation
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.
🕳👁❗Open to adapt and use the knowledge of engineer specialists. 🕳👁❗Ethical mind to avoid the evils as much as possible, at least open in it.
⚒ A-2.2.3 What to change in project management for change
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.
What did change since those years?
NN 0097, Unmanaged - Jack Skeels - Murray Robinson - Shane Gibson
Following agile product development:
unmanaged with jack skeels
critics on what is not going as promised ...
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. And 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 ...
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.
Now, There are really clean measures in place. ...
today, our environments are largely "multi manager environments".
Whatever happens to the loss in productivity can´t be attributed to any manager.
👉🏾 What we end up doing is we start hiring more managers to ... 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.
The 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, and it´s actually a good situation to be agile around.
This is the ultimate expression of the Problem software Agile was trying to solve. ...
💣 ... want you to be told 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 ... that same thing happens. ...
👉🏾 it´s got to be done no matter what now. We can´t afford to fire them anymore. ...
The 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. ...
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.3.1 Process mining
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) is a fundamental lean practice that involves diagraming 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, weel tot understand.
Too complicated: starting with mining without understanding the VSM.
From: "Want to do a process mining project" slides and videos (vdaalst).
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:
How to position process mining in a figure: 🕳👁❗Open for adapt how to use VSM and process mining for change processes.
⚖ A-2.3.2 Business processes modelling
VSM, process mining, processes
The idea of using data, transformed into information for seeing what is going on the shop floor.
In a figure:
See right side
Not all process events will follow the expectation form the VSM map.
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
🕳👁❗Open to adapt how to manage variations in the VSM processes 🕳👁❗Open to architectural decisions at different layers: strategic, tactical, operational.
⚖ A-2.3.3 Business processes Administrative/cyber
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.
🕳👁❗Mindset acknowledging the duality data-driven process driven. 🕳👁❗Mindset acknowledging the difference in assumption on processes and reality. 🕳👁❗Capable of prioritising understanding the VSM of processes and changes.
A-2.4 Enabling aligned lean process cycles
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
A Focus on Information Technology Project Management
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.
...
A Focus on Information Technology Project Management
"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:
ALC-V1 👉🏾 Open loop system
ALC-V2 👉🏾 Simple closed loop system
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.
Gaps In Traditional Project Management
look at the control block picture of the PMBOK´s functions:
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 advances closed loops. A complete approach:
ALC-V3 👉🏾 Advanced closed loop system
🕳👁❗ Awareness of the importance of closed loops, PDCA. 🕳👁❗ Goal: implementing understandable controllable closed loops.
💡❗✅ Use Jabes to collect Closed loop aspects for information and processes.
The line is visualised lineair another option is a circular one.
There are at least two lines, a development line and an operational lines.
The operational line has two closed loops control points indicated by wages.
The goal of these closes loops:
Assurances the retrieved information is within assumed expectations.
For integrity relationships this both technical and functional.
Assurance the to be delivered information is within assumed expectations.
For integrity relationships this both technical and functional.
ALC-V3 process line, closed loops - circular operational
Having a defined value stream the step of prepartion and delivery are logically segregated.
The goal of that segregation:
Assurances the retrieved information is within assumed expectations.
Quality control: no erroneous information being used for the transformation process.
Assurance the to be delivered information is within assumed expectations.
Quality control: no erroneous information being delivered to customers.
A figure:
See left side
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.
The data driven process in a figure:
👓 Click figure for context.
🕳👁❗ Awareness of the sheer number of different closed loops. 🕳👁❗ Goal use all of the controllable closed loops wisely.
💡❗✅ Use Jabes to collect Closed loop aspects for information and processes.
⚖ A-2.4.3 Cubicles - Gemba
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)
🕳👁❗ Well documented knowledge of processes and the information value streams.
💡❗✅ Use Jabes to collect compliancy aspects for information and processes.
A-2.5 Realizing Aligned lean process cycles
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-2.5.1 PDCA cycle administrative support
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 🕳👁❗ A change in changes: document, log, the activities actions and results. 🕳👁❗ Use this journal for: reporting what has happened, predictive expectations.
💡❗✅ Use Jabes to collect compliancy aspects for information and processes.
⚖ A-2.5.2 Working Cell Goal: Aligned Operations
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
The transformation unit - Compliancy
To get covered by documented knowledge in a portfolio are risk assessments:
Security architecture risk impact
Operational risk impact
Privacy - risk impact
Process - risk impact
This is a process in his own with the goal getting the correct requirements.
When a requirement is incorrect, assumptions about wat the transformation unit should be capable of, the change could become worthless.
Some examples:
The access to information is unnecessary left open where limited access is required.
The availability and reliability of the transformation is below waht is needed
Information sources assumed being available are not allowed to be used.
The result of the transformation process is not stable, not conform request, ambivalent.
This can be solved partially during architecting, engineering with validations being involved.
When impossible impediments arise there must be a review on the change at high level.
There is wish for continous feedback, closed loops.
The compliancy part:
In a figure:
See right side
❓ What is expected for a transformation?
The transformation unit - Technical, operational:
❶ A transformation unit should be delivered complying the requirements.
❷ A transformation unit should be delivered with technical maintenance instructions.
The transformation unit - Functional, operational:
❸ A transformation unit should be delivered with operational usage guidelines.
❹ A transformation unit should have safeguards when operational usage guidelines are violated. 🕳👁❗ Well documented compliancy aspects of the transformation unit. 🕳👁❗ Well documented technical maintenance aspects of the transformation unit. 🕳👁❗ Well documented functional usage aspects of the transformation unit.
💡❗✅ Use Jabes to collect compliancy aspects for information and processes.
⚒ A-2.5.3 Document Information retrieval & delivery
Data contracts, transformations
There are several attention point to review:
the used technology for the transformation although that is not complex.
Reusing technology for multiple purposes can simplify a lot.
a well descriptions of the input information needed in the transformation
a simple shared location, shared technology for the data, information, simplifies a lot
Data contracts, transformations, input
Needed defined qualities of information:
know for who the processing is done
know who is accountable for the information being retrieved
from correct agreed locations
agreed integrity quality of information
A figure:
See left side
Data contracts, transformations, result
Needed defined qualities of information:
know for who the processing is done
know who is accountable for the delivered information
to correct agreed locations
agreed integrity quality of information
A figure:
See left side 🕳👁❗ Well documented aspects of the information, input & delivery. 🕳👁❗ Well documented aspects of the transformation funtional business rules.
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 Why How What
Intermediate, zachman surprise
Start with Why (Simon Sinek, 2009)
Sinek says people are inspired by a sense of purpose (or "Why"), and that this should come first when communicating, before "How" and "What"
The difference between architecting (representation) and engineering (specification) is solved by an additional level, six levels instead of the original five.
The ordering of "6W 1h" in the horizontal classifications is not aligned for multiple dimensional relationships.
That is the part where I do it here a little bit different:
Why as content and Which for one of the questions.
"How and What" as the last two.
"Which and Where" the first two.
"Enterprise architecture defined" (lucid))
Named for its creator, John Zachman, this framework uses a structured matrix as a means to view and categorize an enterprise.
The framework consists of a 36-cell matrix, with each cell focusing on a different perspective (such as business owner, planner, designer, and so on).
This matrix gives EA professional insights into the company's assets and how various components of the enterprise are related.
This information can help companies be more agile and help to make better decisions.
⚙ 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.
⚖ A-2.6.5 Jabes Usage advice
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.
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.
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. 
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. 
💣 The result is a risk challenge by vagueness, to differentiate:
Typically:
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.
Before establishing this context, agile methods include four significant attributes. They are:
❶ 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.
.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 realize for the magnitude and scope.
Needed is a team with more competencies I have. 
