Executable business architecture, with conformance you can verify.
Dexon Architect turns the architecture of the organization into an operable object: not a repository of diagrams consulted before a committee, but the model the real operation runs against. It is what analysts call a digital twin of an organization, built on Dexon BPM — the processes the model declares are the processes the engine executes, so the model cannot drift from the operation.
Seven links, seven editors, one repository.
Executable business architecture only means anything if the artefacts are the objects the platform runs. In Dexon Architect the strategy map, the capability map, the service catalogue and its offerings, the process sheet and its BPMN, the data model and the indicator sheet are each a first-class editor — not seven tools exchanging files, but seven views of one repository, governed by a metamodel that declares what can relate to what.
That is why a change in one is visible in the others, and why “which capability does this process answer to?” has an answer by query rather than by meeting. Ask “which services are exposed if this component fails?” In a documentation repository, the answer depends on someone having kept the diagram up to date. Here it is a query, and it reflects the configuration in force, because there is no second copy.
Administration is predominantly no-code. Low-code expressions exist for calculated fields and rules, where an expression is genuinely the clearest way to say something — but standard customer configuration requires no source-code change, which is what makes it reviewable, migratable and able to survive an upgrade.
One model
Four altitudes over the same organization
Not four tools with four exports. One model you zoom into, where each level constrains the next and the editor enforces the rules that keep it analysable.
Value chain
The level-one map, started from a Porter or ITIL template and renamed into the client’s own language. It declares to whom value is delivered and who assesses it — its value groups and interest groups — and its service and public-value statements. It is the frame everything else hangs from.
Capability map
What the organization must know how to do. Packages are nouns and leaf capabilities are action verbs; type and criticality live only on the leaves; capabilities stay disjoint and evenly grained. The editor enforces this, because a capability map with process names and time sequences inside it cannot be analysed — and that is how most of them end up.
Process sheet
Filled before anything is drawn: identity and purpose, the formal objective, classification, the owning organizational unit and approval date, the service it delivers, the capabilities it operates, and the SIPOC. A process that cannot state its position in the chain does not get a diagram.
BPMN
The paths. Every end is either an expected outcome or a governed exception; every element on the diagram justifies what it contributes to the objective, a constraint, a datum, a rule, a risk or an indicator. A gateway without declared data and rule is not a decision — it is ambiguity that has been drawn.
What the product includes
Every link of the chain, and the editor where it lives
Dexon Architect includes Dexon BPM: what is modelled here is what the engine runs. What follows is not a feature list — it is the sequence of a deployment.
Strategy →
A vision with its big, hairy, audacious goal and its vivid description; objectives, goals and indicators with their dependencies in a graph; a balanced scorecard; initiatives with real dates that drive a Gantt. This is where a strategic objective stops being a slide and becomes something a process can be traced to.
Capability map →
The stable abstraction of what the organization does, independent of org charts and systems. Each capability declares the services that implement it, the processes that realise it and the systems that support it — which produces a heat map: where technology investment concentrates, and which critical capabilities stand without support.
Service catalogue and offerings →
A service carries an owner, a value proposition, a criticality, a cost, the capabilities that implement it and the configuration items that support it. An offering is the concrete, requestable form: its own process, form, service level and price. One service can be offered in several ways without duplicating the process that runs it — and nothing reaches the portal until the offering is complete.
The formal objective →
A structured object on the process sheet, not a paragraph: the stakeholders who receive the value; expected outcomes stated as business states; a satisfaction criterion per outcome with a target, a tolerance, a direction and a declared source; typed constraints; and the risks that condition the design. A process is approved only when that specification is strongly satisfied.
Process modeller →
Value chain, process map by bands and macroprocesses, process sheet with its SIPOC, and a BPMN editor that imports and exports BPMN 2.0 and other interchange formats. What is published runs: routing by formula over the case data, joins that wait for one or all predecessors, and subprocesses launched one per record of a table.
Simulation, execution and cost →
Each process sheet compares what ran with what was designed: transitions outside the design, designed paths nobody takes, the most frequent paths and the load on each, and real duration against expected per activity. It simulates Monte Carlo scenarios on the measured durations and the real frequency of each branch, comparing the base scenario with the alternatives by median and worst case (p50, p90). And it costs the process by activity and by technician from measured work and resource rates, with a cost-value heat map over the capability map.
A scorecard per process →
Every process has its own weighted dashboard of the indicators that contribute to it, subprocesses included. The process map shows a traffic light on each process and the aggregated score of each macroprocess and band — and a process’s light opens its dashboard.
Implementation accelerators →
The value chain starts from an ITIL or Porter template and the capability map from a reference map; an existing process architecture — bands, macroprocesses, processes and subprocesses — is imported from a spreadsheet, showing what will be created and what already exists. The rollout itself is seeded as a project with one activity per step of the method, and a stage does not close while the conformance verifier finds failures in it: Dexon is implemented with Dexon.
Organization, places and stakeholders →
The org chart with its units and roles, the sites with their working calendars, and the stakeholder register. The unit is what indicators align to; the site sets the calendar and holidays the service-level engine discounts; stakeholders are whom process objectives declare they serve — and the journey of each stakeholder group is mapped, stage by stage, over the processes that serve it.
Risk register →
Risks recorded against the object they threaten — a process, a service, a capability — with their assessment and treatment. The objective of each process declares the risks that condition its design, so the register is part of the design rather than an inventory reviewed once a year.
Aligned indicators →
Every indicator declares its formula, source, target, frequency, owner, measurement anchor and its alignment with the organizational unit and the strategic objective it contributes to. That alignment shows which part of an institutional target is held up by which unit and which process — and the target nobody holds.
Ontological data model →
More than a thousand documented entities before you add one, browsable by domain and through a neighbourhood graph. Describe what you need in business language and the search shows, scored, the entities that already resemble it — which is how a data model stops accumulating four tables for the same thing. Each entity declares its data owner and whether it is critical, and the conformance verifier requires a named owner on every critical entity.
Roles and profiles →
Permissions by function, so that “who may change the capability map” has a governed answer and no client profile is all-powerful. It is the difference between an architecture that can be handed over and one that depends on whoever configured it.
The conformance verifier
Conformance is a screen, not a committee
Fifteen integrity rules of the metamodel, evaluated over the whole repository with a findings report — thirteen by machine, and the review of design decisions and the impact reassessment after a change tracked as governed manual checks in the same report. Each finding opens the editor where the gap is fixed. Run it at the end of a stage and it is the release checklist; run it in a governance meeting and it is the agenda. Ask for it in any comparative evaluation: it separates a repository of models from an architecture that is governed.
| What it checks | What it catches |
|---|---|
| A process answers to a capability and delivers a service | The orphan process nobody can state the purpose of — the most common finding on day one |
| A service declares the capabilities that implement it and the configuration items that support it | A catalogue entry with nothing behind it, and a failure whose impact nobody can query |
| An offering is complete: visible, current, with a published process | An entry in the portal that nobody can actually request |
| The objective is verifiable | A process approved on an objective with no criteria, no threshold and no declared source |
| The capability map is well formed | Process names and time sequences inside a map that was supposed to be stable |
| Every process has one owner and an approval date | A process everybody uses and nobody answers for |
| Every activity declares a typed executor | Work that happens without anyone, or anything, accountable for it |
| Every path closes on an outcome or a governed exception | The branch that ends nowhere and gets resolved by email |
| Every gateway declares the question it answers, its data and its rule | A decision nobody can reconstruct a year later |
| Every captured entity has a purpose and a description | A data model that grew as form fields |
| Every indicator is anchored to an object and a declared attribute | The floating metric that measures nothing in particular and answers no question |
| Every change was assessed for impact before it was made | The silent breakage downstream |
Precision
The distinctions this product preserves
Words used interchangeably in a sales conversation that mean very different things in an implementation.
On the roadmap
What arrives next, and when
Each item is available for a demonstration or a proof of concept from the month shown.
Root cause and recommended action
Explain why an indicator moved, which cases explain it and which action is advisable.
The proof
The same repository runs a certified service desk
Dexon ServiceDesk is built on Dexon BPM — on the very repository Dexon Architect models. The service a user requests in the ServiceDesk portal is the service modelled here, linked to the capability it serves and to the process the engine executes; the configuration item in the CMDB is the object the architecture relates to that process. Pink Elephant certified Dexon BPM in twelve ITSM processes that run on that repository: the clearest evidence that what is modelled here executes.
See the twelve certified processes →Dexon BPM capabilities, included
Workflow
Conditional routing, parallel tasks, dynamic approvers, deadlines on business calendars and append-only history — the same engine across every record type.
ETL & integration
REST API, scheduled and event-driven exchange with databases, files and web services, plus directory, email and discovery — with the authoritative source of every attribute on record.
Documents
Version trees, permissions, search by content, signature with time stamp — with document requirements enforced as gates the workflow will not pass without.
BI & KPIs
Scorecards under strategic objectives, targets by period, drill-down from the aggregate to the source record, and projection that never overwrites a measurement.
IT asset management
Inventory through the Dexon Agent, a CMDB that maintains itself, SNMP network discovery, licensing measured on real usage, and remote control recorded on the case.
Bring a process and we will draw its chain
One of yours, with its awkward exceptions. We fill in the process sheet, state the formal objective, model the paths — and then run the verifier in front of you: a finding, its correction, and the verifier run again. It is the least flattering demonstration we can offer, which is exactly why we offer it.