Own how your business works
One verified model of your organisation’s services, from requirement to running process, with the audit trail built in.
Requirements, designs and code kept in step by hand drift apart. URDAD holds them in one technology-neutral model, each service held to a contract, and generates the diagrams, documents, tests and running processes from it. Your teams evolve it together in governed projects, with AI proposing and people deciding.
Try the playgroundRequest a trial
It runs in the browser, with nothing to install and no sign-in.
The method, measured on our examples
- Specify 76 service contracts, stating 101 refusals and 117 guarantees
- Design 23 processes across 25 responsibility domains
- Generate 35 diagrams and 3 documents, none drawn by hand
Counted on every build from the 3 example models, each of which opens in the playground.
Outcomes
Why URDAD?
Nothing drifts out of step
What was specified is what is documented and what runs, without anyone keeping them in step. Requirements, design and processes are one model, every diagram and document is regenerated from it, and the optional execution environment runs the approved processes as modelled.
The full argument: nothing drifts out of stepChange who does the work, not the process
Insource, outsource or automate a service without changing any process. Processes request services by contract, never naming who provides them, so a person, system or partner can answer. Contracts are reused anywhere, and the model, naming no technology, outlives the systems implementing it.
The full argument: change who does the work, not the processEvidence for audit, as a by-product
Answer an auditor’s “why does this step exist?” from the model itself. Every requirement is traced to the step meeting it, every change is signed off and recorded, and stored data no service uses is found. The tool keeps the evidence and certifies nothing itself.
The full argument: evidence for audit, as a by-productOne model everyone can read
Business and technical people share one understanding of what the organisation does, each responsibility domain owning its part. Documentation generated from the model explains every diagram in words, so its readers need to know nothing of URDAD.
The full argument: one model everyone can read
Where URDAD fits
Domain-driven design teams
Bounded contexts with contracts at their boundaries, checked as you model and tested without writing a test.
For DDD teamsBanks, insurers and financial services
Every change evidenced, every provider held to contract, and the record kept for your auditors, under DORA, GDPR or POPIA.
For financial services
AI assistance
AI that proposes, people who decide
The AI assistant turns informal requirements into proposed model elements and checks the model against them. Because the model is precise, its proposals can be checked, and none of them becomes part of the model until a person accepts it.
Reviewed one by one
Every proposal is accepted or rejected by a person, and nothing reaches the model or a co-editor before then.
Verified like everything else
An accepted proposal is an ordinary element of the model, so verification and the phase gates check it exactly as they check one made by hand.
Provenance on every element
Each accepted element records the requirement it came from, and is flagged when that requirement later changes.
Your model, your provider
The language model, hosted or your own, is chosen by an administrator and reached only by the server.
The method
How it works
Specify
For each service which the business must provide, state its contract: who needs it, when it is refused, and what it guarantees when it is not. Entities grow from the data the contracts carry, never apart from them.
Design
Allocate each requirement to a lower-level service or an activity, and orchestrate them into a process. The same is then done one level down, by your team, another domain’s team or an external provider.
Verify
The tool checks every process against its contract as you model. It can also test it with cases generated from the model, so nobody writes a test.
Execute
Optionally, the execution environment runs the approved processes as modelled, with people and existing systems answering. Every answer is checked against its contract.
Evolve
Every change is made in a project, reviewed, signed off and activated. The diagrams, documents, tests and running processes then follow.
What you get
The tool suite
Model once
One model of what your services must do and how, from which every diagram and document is drawn, shared by everyone at once.
- Nobody draws or redraws a diagram; every view is generated from the model.
- A team edits the same model together, live, with every change recorded.
- Each process is checked against its requirements as you work.
Govern change
- The model changes only through projects, each taken through phases to sign-off.
- Roles say who may do what; regulated projects add the checklists their rules require.
- A permanent record of who changed, reviewed and approved what.
Execute and test
- The approved processes run as modelled, with no hand-written program to drift from them.
- Tests are generated from the model, so nobody writes a test, a stub or a data set.
- Every answer is checked against its contract, and the party at fault is named.
Share and integrate
- Documentation generated from the model, and published where your people already read.
- Processes and decisions to and from BPMN and DMN, so you are never locked in.
- Connects to your identity, delivery, secrets and AI providers without tying you to one vendor.
Positioning
URDAD and BPMN
BPMN draws what happens, in which order, and who does it. URDAD, on the other hand, starts from what a service must achieve, i.e. when it may be refused and what it guarantees, and checks every process against that. Each does its own job well, and one can use both, as the tool imports processes and decisions from BPMN and DMN and exports them back.
Choose BPMN when
- You want to document an existing process quickly.
- Your people, a partner or a regulator already read or ask for BPMN.
- The process is genuinely unstructured.
- Processes are owned and run one at a time on a BPMN engine you already have.
- You need a standard that many tools support.
- You need a mature execution engine today.
Choose URDAD when
- The model must last, and be shared across the organisation.
- Requirements must be traceable and verifiable, e.g. when an auditor asks why a step exists.
- Every service needs a contract from which its tests are generated and to which its providers are held.
- Services may move between your own teams and external providers.
- One model should drive documentation, tests and execution, without being redrawn.
Research
Where URDAD comes from
URDAD (Use-Case/Responsibility Driven Analysis and Design) has been developed and published in peer-reviewed journals and conferences since 2007.
- Technology Neutral Business Process Design using URDAD
- Generating MDA's Platform Independent Model using URDAD
- URDAD as a semi-formal approach to analysis and design
See it for yourself
Try the playgroundRequest a trial
Not ready for either? Browse the resources, i.e. the method, example models and specifications.