What If You *Are* Going To Need It?

Business architecture for efficient, effective operation

Back on the C3 project, Chet Hendrickson walked up to me with a design problem. “We’re going to need this so the design is going to be complicated. Oh and we’re going to need that, which complicates things further. And we’re going to need this other…”

“You aren’t going to need it.”

“But we are, and so…”

“You aren’t going to need it. What is the simplest thing that could possibly work?”

Pause. Thinking. “I could do this for now.”

“Okay.”

Away he went.

Curse of Knowledge

Chet’s problem wasn’t that he didn’t know enough. His problem was that he thought he had to solve an overwhelming number of problems at once. Those two mantras—”You aren’t going to need it” & “What is the simplest thing that could possibly work?”—were intended as reminders that it’s okay to do an okay job today & make it better tomorrow. In fact, because of the time value of money & the likelihood of learning, choosing to defer a decision can create value.

Lifeware

I had the good fortune last week of visiting Lifeware, a Swiss-based insurance software company I have worked with for 25 years. I noticed that Lifeware solves certain problems in a more complicated way than is obviously necessary. A quarter century of experience has shown, however, that this “over” engineering is actual the simplest, most pragmatic solution to problems that most business systems choose not to solve.

The next few posts introduce you to the Lifeware business architecture. Each post highlights an element of the architecture, its goals, & its consequences.

Overall Goal

Lifeware manages insurance contracts. It charges its customers per contract per year, so Lifeware’s sustainability depends on managing these contracts with little human intervention. However, insurance is an incredibly complex domain & programming to manage all possible scenarios is impossible.

The overall goal of Lifeware’s business architecture is mostly-automated processing of contracts with computer support when humans need to intervene. After human intervention, automated processing should resume.

Lifeware & its customers are served by achieving this goal. Policy holders & beneficiaries also benefit. Insurance is full of opaque pricing & fees. Explainable, transparent processing allows end customers to understand what they are paying for & what they are getting.

Two Timelines

As if insurance as a domain isn’t complex enough, that complexity is multiplied by operational complexity. There are 2 timelines at work—the real world & the system.

These timelines are eventually consistent. Periods of inconsistency explode the complexity of the system.

1. The customer takes out a contract in Kanton Zürich.

2. At the end of the year, the tax authorities are notified.

3. A week later, “Oh I forgot to tell you. I moved to Kanton Uri in November.”

4. Now what?

   

   Delay Introduces Inconsistency, Multiplying Complexity

If we want to compute automatically, we need to:

• Identify periods of inconsistency

• Reverse & recompute the business processes that took place during inconsistency

Bi-temporality

Computing automatically requires a more complicated notion of time than the obvious. In the next post I’ll introduce bi-temporality, which we not only are going to need, but we need it now.

Software design is not about minimizing design complexity, but rather spending our complexity budget where it can do the most good.