The software works. The business behind it no longer exists.
Published · Author: Stefan Priebsch
“We won’t need a postal address in future. An email address will suffice.”
What sounds like a minor change to a form can turn an entire industry on its head. And what might appear in the backlog as an adjustment to a data field may, in reality, mean that significant parts of the existing business process have become redundant.
A small change
Let’s imagine a company that sells software. Not as a download, but in the traditional way: in a box, on a physical data carrier, with a printed manual.
A customer orders a product. The company takes the order, issues an invoice, arranges for the goods to be picked from the warehouse, hands the consignment over to a logistics provider and waits for the parcel to reach the customer.
The software maps out this process. There are orders, invoices, stock levels, dispatch orders and parcel tracking. There are addresses, delivery charges and delivery dates.
Then the company decides to deliver its products digitally in future. An obvious requirement for the software is now: ‘We no longer need a postal address for the customer. Instead, we’ll ask for an email address.’
That sounds straightforward. Change a field in the data model, tweak a form, perhaps swap out a few validations.
Of course, an email address is not a billing address. Billing data and delivery information serve different purposes. But it is precisely this conceptual ambiguity that is interesting: it shows how quickly we reduce a fundamental change in the domain to the level of individual data attributes.
Because here, it is not simply a data type that has changed. Here, the world that our software represents has changed.
What has actually disappeared?
Let’s consider the business process as it stood: an order leads to a dispatch order. The dispatch order leads to a product being picked from the warehouse. The product is packed and handed over to a delivery service provider. At some point, it is delivered.
Along the way, numerous operational decisions are made: Is the product available? From which warehouse is it dispatched? Which delivery method is used? What happens if delivery fails? How is a return handled? When is the order considered fulfilled?
All these questions are valid. They form part of the business domain because the company sells and dispatches physical goods. However, with the shift to digital delivery, many of these questions become irrelevant.
There is no longer any packaging, no parcel service, no dispatch labels, no physical delivery, no traditional stock levels and no returns in the conventional sense. This means that an entire part of the business process is eliminated. This is not an optimisation of the existing logistics; it is the abolition of the previous logistics system.
And with it, technical concepts, responsibilities, rules and dependencies – which may have shaped the software architecture over many years – disappear. We haven’t simply replaced a postal address with an email address. We no longer need the postal address for delivery.
So what has emerged in its place?
Of course, digital delivery does not mean that an order suddenly no longer requires fulfilment. After all, the customer must still receive what they have paid for. It’s just that ‘receiving’ now means something different.
Instead of sending a parcel, the company might provide a download. Instead of reducing stock levels, it generates a licence. And instead of issuing a tracking number, it grants access authorisation.
The new operational questions are: Is the customer permitted to download the software? How long will the download remain available? Are they allowed to install the product multiple times? What happens if the email containing the download link does not arrive? How is a lost licence key replaced? What happens to the access authorisation if a purchase is reversed?
These questions must be answered. They give rise to processes, business rules and responsibilities. But these are different processes, different rules and different responsibilities to those that have existed until now.
The company has not simply changed the method of delivery. It has redefined what it means to fulfil an order. In the past, an order was considered fulfilled once the goods had been delivered. Perhaps it was only deemed complete once delivery had been confirmed. Today, an order might be considered fulfilled as soon as a valid licence has been issued and the customer has been granted access.
The same technical term can take on a completely different meaning as a result of a change in the domain. This applies to ‘delivery’ just as much as to ‘availability’, ‘stock levels’ or ‘order completed’.
And that is precisely what makes such changes so interesting from an architectural perspective.
If we only change the data model
Let’s now imagine that the development team actually regards the new requirement as nothing more than a change to the data structure.
The postal address becomes optional. An email address becomes mandatory. The existing dispatch process is adapted so that it processes a download link instead of a delivery address. Perhaps the concept of a dispatch order remains in place. A digital dispatch order would then result in a download link being generated and sent by email.
This might work technically. It might even be the most economically sensible solution in the short term, for example during a transitional phase in which physical and digital products are offered in parallel.
However, it becomes problematic if this solution is based on a misconception of the domain. For then we are dragging the technical concepts of physical logistics into a world where they no longer have any relevance.
A download becomes a special case of a parcel. A licence is treated like a stock item. The provision of a digital product must navigate through process steps that were originally designed for physical goods.
What initially looks like the reuse of existing software very quickly becomes a burden. New business requirements must be translated into concepts that were never intended for that purpose. Business rules become scattered across exceptional cases. The architecture preserves assumptions about the business model that have long since ceased to apply.
The software then no longer reflects the current domain, but rather the history of the domain.
The most dangerous changes look harmless
In software development, we often discuss how we can design systems so that they can be easily changed. We talk about things like modularity, loose coupling, extensibility and stable interfaces. In doing so, we often imagine changes as additions or modifications to existing functionality: we create a new field. We’ve discovered an additional business rule, or another process step. After all, this is just a new variant of an existing workflow.
But domains do not always change incrementally. Sometimes entire parts of the reality on which our software is based disappear. A company no longer sells products, but subscriptions. An intermediary becomes a provider in its own right. A service provider automates a service that was previously provided by people. A physical product is replaced by a digital service.
Such changes cannot necessarily be adequately modelled by adding further properties or introducing additional variants of existing processes.
Sometimes we have to accept that a familiar term means something fundamentally different today than it did yesterday. Unfortunately, we do not always recognise changes as such in good time, because the business requirement may not reach us as ‘We are phasing out our logistics’. It arrives as a ticket titled ‘Use email address instead of postal address’.
Architecture begins before the data model
So what should the development team have done? First, understand how the business has changed: Which activities will no longer take place in future? Which new activities are emerging? Which business decisions will become redundant? Which new decisions will need to be made? Which events will mark the progress of an order in future?
The aim is to visualise both the current and future business processes. We do this through collaborative modelling, for example using Architectural Roleplay, Event Storming or Domain Storytelling.
In the current process, we find events such as:
Order placed → Goods picked → Parcel dispatched → Parcel delivered
In the new process, the sequence of events might be:
Order placed → Licence generated → Access granted → Customer notified
Both processes begin with an order. Both serve to deliver the service to the customer. But in between lies a fundamentally different business world. When we visualise the processes, we recognise differences that would hardly be noticeable in a discussion about data fields.
Only on this basis should we decide what impact the change will have on the data model, the components, the interfaces and the architecture as a whole. Perhaps large parts of the existing software can be reused. Perhaps we need a new business component for digital delivery. Perhaps we need to redistribute responsibilities amongst existing components.
We should not make any of these decisions before we have understood exactly which problem we are actually solving.
Not every change is an extension
A common notion of good software architecture is that we should fulfil new requirements through extensions wherever possible, without having to alter existing structures. This is a sensible aim, provided that the fundamental assumptions about the domain do not change.
However, if these assumptions become obsolete, clinging to the existing structures can be extremely detrimental. A system developed for physical dispatch is not necessarily the right foundation for digital delivery. The fact that both processes fulfil an order does not make them variants of the same business process – just as two things do not automatically share the same business meaning simply because we can place them within a common data structure.
Good architecture therefore does not merely consist of accommodating changes through extensions. It must also enable us to remove outdated concepts and redraw business boundaries.
A system that can only grow but not shrink is not truly adaptable. This applies not only to the code, but also to the way we mentally structure our systems.
The real question
The next time someone suggests a seemingly harmless change to the data model, it is worth taking a closer look. Perhaps a business process has just disappeared, a responsibility has been dropped, or a new business model has emerged.
We do not recognise this by the scope of the change in the code; we only recognise it if we understand the domain.
Switching from a postal address to an email address can take a matter of minutes; the elimination of an entire logistics chain certainly cannot.
Changing a data field is sometimes merely the visible symptom of a fundamental change to the domain. Anyone who focuses solely on the data field may miss the actual architectural decision.