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.