Tooling · TOOL
Part VI · TOOL-01 to TOOL-20
The organisation does not need another tool. It needs a tool landscape that works together.
Processes, knowledge, requirements, execution, collaboration, data, AI and governance sit in different platforms. That is not wrong in itself. Tooling describes which digital capabilities an AI-native organisation needs, where each kind of information is held, and how the platforms work together under control.
- Knowledge
- Architecture
- Delivery
- Execution
- AI
- Automation
- Analytics
- Collaboration
- Digital Twin
- Governance
The purpose
Tooling does not start with a product list
A tool architecture should not emerge from whichever software has already been bought. First it has to be clear which capability is needed, which enterprise objects it handles, who owns the data and who else has to reach it.
- Organisational needWhat does the business have to achieve?
- CapabilityWhat does it have to be able to do?
- Enterprise objectsWhat does the capability work on?
- Tooling capabilityWhat does a system have to deliver?
- PlatformOnly here does a product name appear.
- IntegrationHow does it connect to the rest?
- GovernanceWho may do what, and how would you know?
TAOM defines the capability first – the product comes after that.
That is why SAP, Microsoft, Atlassian or OpenAI appear here as examples without TAOM depending on them. The capability stays; the product is replaceable.
Five principles · TOOL-01
What makes a TAOM tool landscape
Five tests every platform decision can be measured against.
Capability-led
A tool is judged by which organisational capability it carries – not by how many features it has.
Vendor-neutral
TAOM defines roles, objects, relationships and interfaces. The platform behind them can be swapped.
Open standards
Information has to survive platform boundaries. Interfaces, events and open formats reduce lock-in.
Context-aware
A system should know more than its own record. The links to processes, requirements, knowledge and roles have to survive.
Governed
Identity, rights, data ownership, security, compliance and AI governance belong to the tool architecture, not beside it.
And what follows
Answer these five and you have a target architecture. Skip them and you have a software list.
Not one system for everything
The systems may stay specialised
Every layer has its job. The point is not to merge everything, but to keep the relationships between them manageable.
SharePoint
EA tools
ALM
ERP · MES
Agents
Example platforms are there for orientation, not as a recommendation.
TAOM does not require a monolithic platform. It requires the relationships between platforms to stay manageable.
Who owns which information?
A single source of truth is not a single system
For every kind of information there is exactly one leading system. All the others may show it – only one may change it.
| Information | Leading system |
|---|---|
| Business process | Process or architecture platform |
| Requirement | Delivery platform |
| Business transaction | ERP |
| Policy | Knowledge platform |
| Identity | Identity platform |
| Control evidence | Governance or compliance platform |
| Enterprise context | Digital Twin or context layer |
TOOL-11 · The Digital Twin is not another silo
The connection matters more than the copy
SAP
knows the order.
Jira
knows the ticket.
Confluence
knows the specification.
Signavio
knows the process.
Identity
knows the person.
AI
needs the context.
The Digital Twin does not have to own all the information. It has to understand what belongs together.
TOOL-15 · The new key
AI needs more than access to documents
A general assistant gets
Prompt + document
Enough to phrase something. Not to decide.
An enterprise agent needs
Enterprise AI context
Role · task · process · systems · knowledge · requirements · decisions · controls · permissions · current state
RAG finds information. Context explains what it means for the work at hand.
TOOL-16 · Identity
Whoever acts has to be identifiable
Classic
Person → identity → role → permission
AI-native
Person / agent / system → identity → role → authority → action → evidence
An agent reaching into enterprise systems must not appear as an invisible technical user. Identity, authority and action have to stay attributable.
TOOL-17 · Observability
What runs automatically has to be observable
Too little
Server up / server down
Needed
System state · process state · business outcome · agent activity · quality · deviation · control
That is what turns into feedback, learning and adaptation – which is where tooling connects to the Operating System and the adaptive organisation.
Governance by design
Integration without control scales the mistakes too
Seven questions that have to be answered across every tooling capability.
Identity
Who is acting?
Authority
What may they do?
Data ownership
Which system leads for this information?
Provenance
Where did it come from?
Security
How is it protected?
Compliance
Which rules apply?
Observability
What actually happened?
Together
Only these seven turn connected systems into a landscape you can govern.
Scope
Two mix-ups that get expensive
Tooling
Which digital capabilities does the organisation need?
Describes the target architecture and the roles of the platforms – vendor-neutral.
Integrations
How far are specific systems connected to TAOM today?
Describes reference, linkage, exchange, synchronisation and orchestration – with an honest status. View integrations →
TAOM Tooling
Part of the method
A reference model in the framework, chapters TOOL-01 to TOOL-20.
TAOM Process Studio
One concrete tool
It implements some of these capabilities in practice – and is deliberately connectable. ERP, delivery, knowledge and architecture may stay in specialised platforms. View Process Studio →
TOOL-20 · Target picture
A reference architecture instead of a shopping list
Every platform is assessed against the same scheme – ten questions, always the same ones.
Purpose
Why does it exist?
TAOM reference
Which parts of the method does it support?
Capabilities
What does it have to do?
Enterprise objects
What does it work on?
Data ownership
Which information does it lead?
AI connection
How do agents work with it?
Interfaces
How is it connected?
Governance
Which rules apply?
Key figures
How is the effect measured?
Maturity
How far is the capability developed?
Chapter overview
Twenty chapters – but not twenty products
The grouping is a reading aid. The canonical IDs TOOL-01 to TOOL-20 remain authoritative.
A · Working and knowledge
TOOL-02 Human Digital Workplace
The workplace for people and AI – where tasks, content and assistance come together.
Example platforms Microsoft 365 · Google Workspace
TOOL-03 Enterprise Knowledge Platform
Knowledge, policies, standards, ontologies and the context AI is allowed to reach.
Example platforms Confluence · SharePoint
TOOL-10 Enterprise Collaboration Platform
Meetings, communication and joint work on the same objects.
Example platforms Teams · Slack
B · Designing and delivering
TOOL-04 Enterprise Architecture Platform
Processes, capabilities, applications and architecture relationships.
Example platforms SAP Signavio · LeanIX · TAOM Process Studio
TOOL-05 Enterprise Delivery Platform
Requirements, backlogs, projects, tests and releases.
Example platforms Jira · Azure DevOps
TOOL-06 Enterprise Execution Platform
Runs operational business transactions – finance, procurement, manufacturing, logistics, sales, service.
Example platforms SAP S/4HANA · Oracle · Dynamics · Salesforce
C · Intelligence and automation
TOOL-07 Enterprise Intelligence Platform
AI assistants, agents, search and reasoning.
Example platforms ChatGPT Enterprise · Claude Enterprise
TOOL-08 Enterprise Automation Platform
Flows, interfaces, events, RPA and orchestration.
Example platforms n8n · Power Automate
TOOL-09 Enterprise Analytics Platform
Key figures, analyses and enterprise reporting.
Example platforms Power BI · Tableau
D · Context and connection
TOOL-11 Digital Twin Platform
The connected digital representation of the organisation.
TOOL-13 Enterprise Integration Architecture
Interfaces, events, synchronisation and cross-platform connections.
TOOL-14 Enterprise Metadata Management
Glossary, ontologies, taxonomies and data lineage.
TOOL-15 Enterprise AI Context Platform
Trustworthy enterprise context for AI.
E · Trust and operation
TOOL-12 Enterprise Tool Governance
Rules for selecting, running and retiring tools.
TOOL-16 Enterprise identity and trust
Identity and authority for people, systems and agents.
TOOL-17 Enterprise Observability
Making state, activity and deviation visible.
TOOL-18 Enterprise Security
Protecting access, data and connections.
TOOL-19 Enterprise Compliance
Demonstrable compliance with the rules that apply.
Frame
TOOL-01 Tooling Principles
The five principles the landscape is judged by.
TOOL-20 Enterprise Platform Reference Architecture
The target picture and the assessment scheme for every platform.
Placement
Engineering builds. Tooling enables.
Before: Engineering · ENG
Describes how capabilities and solutions are designed, built, connected and reviewed. View Engineering →
Here: Tooling · TOOL
Describes the digital capabilities and platform structures this work runs on.
In practice
Process Studio, agents, integrations and the Digital Twin implement selected parts of it. To the AI Framework →
Getting started
Do not start with a product. Start with a capability.
Check first which information has to be held, who is accountable for it and which other parts of the organisation depend on it. Then you can decide which platform is right – and how it fits into the enterprise context.