Understand a business change before it happens
A research project exploring how explicit rules can explain which changes to business data are valid, and why.
Can an order be released? Does a quote need another approval? Is a supplier ready to use? Answering these questions can involve data, approvals and rules spread across a business application. When a change is blocked, people need to understand what is missing. When it is accepted, they need to understand what the result should be.
The Method investigates an approach called Parametric Model-Driven Architecture, or PMDA, developed by Guilherme Scomparim. Its central idea is to describe business objects and their rules in a model, a structured description a program can read. State is calculated from data using those rules, and proposed changes are checked against the model. This site documents our reading of the method and demonstrates a small part of it.
A simple example: releasing a purchase request
Illustrative business scenario. Proposed for a future prototype; not part of the live demo.
Imagine a company requires manager approval for a purchase above A$5,000.
| Purchase amount | A$5,200 |
|---|---|
| Supplier | Active |
| Manager approval for this request | Missing |
| Requested change | Release the request |
Proposed answer: blocked. This request exceeds A$5,000 and needs manager approval.
With the required approval supplied, the proposal can pass this example's checks. If the amount changes afterwards, the rules should check whether the approval still covers it. The useful result is an explanation tied to specific facts and rules.
How the idea works
- Read the facts. Start with the business record and any related records needed by its rules.
- Work out what is true. Compare that data with the model's definitions. In the demo, an artist's dates determine which State definitions match.
- Evaluate a proposed change. Check whether it applies, calculate the proposed values, and check the result against the relevant requirements.
- Show the result and reasons. Explain which checks passed, which failed and which could not be evaluated.
The rules and input data still need to be correct and current. Computing State does not make stale source data accurate.
What you can try today
The current demo uses the method's original Artist, User and Artefact example. An artefact is a work made by an artist. Choose a scenario, edit a value and see how the reported States and proposed transition change.
You can inspect an accepted proposal, one blocked by a prerequisite, and one rejected by a Condition. A separate scenario shows what happens when several State definitions match the same data. The demo reports that overlap rather than choosing a winner.
This is a local simulation of one example. It does not save records to a business system, enforce real user permissions or implement a complete application platform. The rules for selecting one State and the broader determinism claim remain unresolved.
What we want to test next
The next proposed prototype would take one familiar business decision, such as purchase approval, and show its facts, proposed result and rule-by-rule explanation together. A further experiment would compare the same examples under two versions of a policy.
The longer-term aim is a component that business-software developers can incorporate into their applications. First we need to establish whether it makes real rules easier to understand, test and maintain. That product is not available yet.
Where the method comes from
The project studies Scomparim's published blog and patent material. Our specification distinguishes statements supported by a source from our inferences, engineering choices and unanswered questions. Those distinctions matter because this is still a draft reading.
Only numbered assertions in the specification define the project's normative content. These explanations and the purchase example are orientation.