Richard's BLOG

Category: IT   Topic: Business Modelling

In my post of Oct 21st, I said that key to our approach to domain modeling is the idea of observational semantics. When we're trying to uncover the business rules for a domain, we don't ask questions such as "when actor A1 starts use case U1, what do the actor and the system do?" Instead, we shift our thinking and ask "when I observe the business running, what changes can I see taking place that I need to describe?"

(Aside: the observing can be actual, if we're modeling a business as-is, or imagined, if we're modeling a to-be business.)

Here's an example of how the shift in thinking can help. Imagine a large commercial bank that can lend the kinds of sums of money you'd need to build a new factory. The contract for such a loan would involve many parties. There would be other banks who were contributing to the loan. There would be the manufacturer. There would be the prime building contractor, and the major subcontractors. And so on.

Each party would need to be involved in drafting, amending, and approving the contract, so lots of documents would circulate between the parties. Eventually, representatives of all the parties would meet in one place at one time to sign copies of the contract. The bank wanted a computer-based system to help them during the process of gathering together all the paperwork needed for a signing meeting.

When we joined the team, they hadn't modeled a change you can imagine happening - "a document has gone missing." The team were focusing on what was going on inside the system when actors invoked use cases, and they knew they had databases that didn't lose data. Once a document was logged in the database, it couldn't go missing. But someone who could imagine observing the business running (without worrying what was IT and what wasn't) could easily see that a real physical document could go missing, independently of what was recorded in a database.

It takes a while to get used to thinking just in terms of observable changes. The hard part is stopping thinking about how change is caused (e.g., which actor invokes a system function). But we've found that thinking about observable changes has helped us build better business models.

Category: IT   Topic: Business Modelling

In the previous two entries, I talked about using observational semantics when modelling a business domain, and about modelling large domains from a number of different points of view.

Here, I want to talk about a third key ingredient of the approach to domain modelling developed by staff of Mitchell Horvath Ltd and InferData Ltd. That ingredient is precision.

Businesses run according to rules. These rules are for business people to prescribe. Yet, in many businesses, the only people who work with precise ways of expressing the business's rules are the developers writing program code.

Let me take quite an extreme example. When a bank converts a sum of money from one currency to another, the result will depend on how many places of decimals are used to express the exchange rate and any intermediate calculations. Because the result depends on the number of places of decimals, that number is something the business should decide. In the banks I've worked with, there are experts in the foreign exchange part of the business who understand these issues, and who employ mathematicians to help them make the necessary decisions.

But in many kinds of businesses, it's common for such precise details to be omitted from business models. There's a widespread opinion amongst business and IT professionals that precise details are somehow "low-level," and only a matter for developers. We think that opinion needs challenging. Much of the precision captured in program code is also a concern for business professionals.

In the book we're writing, we show how to make domain models precise. We're not going to argue that all parts of all domain must be mathematically precise. But we would argue that most business models suffer from too much imprecision.