The Relationship Between Software Architecture And Business Models (and more)
As an architect, how often are you thinking about business models? If every significant architecture decision has business consequences, then knowing the business model and which trade-offs to choose is maybe the most important skill of architects.
But what is the actual relationship between a business model and a software architecture? I’ve been thinking about this a lot because I want a deeper understanding of the implications. If I know how decisions in one space affect the other, I’m going to make better architectural decisions.
It’s not just about business models and architecture, though. There are other systems involved in this tangled relationship. A software system is a model of a domain. Is the business domain the same as the business model? What about the organisation? Conway’s Law suggests it is the biggest influence on architecture.
Software Architecture And Business Models
A business model is a set of decisions about how to create value and who to create it for. The Business Model Canvas is my favourite tool for thinking about business models.
If you’re not familiar, here’s a quick definition of the main elements:
Customers Segments = who do we provide value for?
Value Propositions = what value do we create?
Key Activities = how do we create the value?
Revenue Streams = where does the money come from?
How does all of this relate to the software architecture?
The software architecture is the how. It is the means by which a company creates and delivers some or all of the value proposition to the customer segments.
Implications
The goal of a software architecture is to do the how as effectively and efficiently as possible: to create the most value for the customer segments while minimising the costs and maximising the revenue.
So what is the domain?
Business Model vs Business Domain
The business domain (aka problem domain, problem space) is a sub-set of the world which the business model depends on. A domain is composed of different types of concepts, including:
Entities = things with a lifecycle, akin to a state machine, like a customer or an order
Attributes = characteristics that belong to or describe something else, like a person’s eye colour
Rules = a way to determine what should happen in a given situation, like a legal requirement that citizens must be 18 years old to purchase alcohol
Processes = a sequence of steps involving entities, attributes, and rules, like a job application process
Customer segments are Entities in the domain. Key activities are processes in the domain. Financial transactions which generate revenue are processes in the domain involving rules and entities
Therefore, a business model depends on a problem domain. A business looks at a certain domain and creates a business model as a way of creating a profitable/sustainable business using the entities, rules, and processes in the domain.
Implications
A deeper understanding of the business domain means that business model design can be information rich increasing the chances of making good decisions.
Software Architecture And Business Domains
A software architecture has to implement the domain concepts in order to deliver the how of the business model. There are an unlimited number of ways to model a business domain, however. It is not a deterministic, sequential process.
A large domain must be decomposed into software sub-systems. Where should the boundaries be? Which responsibilities should live in each sub-system? There are many choices to make and the arbiter is the business model.
A software architecture, therefore, is an opinionated model of the business domain which is biased towards maximising the business model.
Implications
When software systems align poorly with the business domain, changes become harder and the business model is less successful.
When developers have to mentally translate from business language to the words in code it takes longer and mistakes are more likely. When new pieces of work always slice across-multiple sub-systems, it takes longer to make changes and deploy them.
It is, therefore, fundamentally important to align the architecture and the domain as well as possible. However, due to the ambiguity of modelling a domain in code, each choice be anchored to the business model: the way of modelling the domain that best suits the business model is the right choice.
Software Architecture vs Organisation Architecture
Conway’s Law implies that the way teams are organized and communicate will be mirrored in the architecture of the software system. So the relationship is that organization architecture influences the shape and communication paths in the software architecture.
Implications
The implications of Conway’s Law are talked about widely. In effect, design your architecture and teams collectively otherwise the architecture of the software will conform to the architecture of the organisation and it may be a painful journey.
Remember, the software architecture is a model of the domain. The boundaries in the software should be designed around domain concepts biased towards the business model. So the architecture of the teams must also follow the boundaries in the domain.
Teams, however, have constraints. There are limitations to how many lines of code and software systems one person can maintain. So the architecture of the organisation also influences the architecture of the software…. software architecture is a compromise between the ideal domain boundaries and the needs of the teams building the architecture.
Software Architecture vs Organisation vs User Experience
A software architecture exposes its value to the world via user experiences (UX). A web page, a mobile app, an API, a wearable device, and many other kinds too.
Is the UX simply a way of exposing an architecture, or, does the UX make demands in this complicated relationship as well?
UX plays a significant role in determining team structure. There is often a debate between dedicated frontend teams vs full stack teams who own a full slice of UI all the way through the domain and the database. Often full stack teams use micro-frontends which is an architectural decision.
Implications
Dedicated frontend vs full-stack teams is a choice which impacts the organisation and the software architecture. And it also affects the cognitive load of teams. So if a team is full stack, using some of their cognitive load means they cannot own as much of the domain. This may impact the domain boundaries in the architecture.
Architecture And Technology
We can’t forget about technology. A software architecture is implemented using programming language technology and runs on cloud platforms. The domain has to be expressed as code and written by the teams in the organization.
As code gets older it becomes harder to change. Technologies eventually become redundant and need to be replaced by newer technologies which enable code be to developed more rapidly.
Implications
Coupling in the software may impact team boundaries. If parts of the code are too tightly coupled or shaped around hard-to-replace technologies, they cannot easily be decoupled to match the ideal domain and team boundaries. Therefore, the domain and team boundaries must conform to the legacy architecture and not vice-versa.
There is great value in designing boundaries well up-front because they will be hard to change later. There is also great value in keeping the code supple and well maintained so it is easy to change because no up-front design will ever be perfect.
Everything Changes, All The Time
There is one final thing to consider. Everything is always changing. The needs of the users in the domain are changing. People expect a constant stream of newer and better innovations. Companies are continuously striving to meet demand with sustaining and disruptive innovation.
Attitudes in society are progressing. The environment is changing (Covid, global warming). Laws and regulations are changing.
Implications
Businesses have to constantly be looking to the future. How do they continue to maintain existing revenue streams while also finding new revenue streams? Business have to be aware of society and their competitors and evolve their business models to stay relevant.
A software architecture has to be flexible to enable the business to explore new revenue streams and to flex as the domain constantly evolves.
The Scope of Software Architecture is Big
A software architecture has a strong relationship to the business model, the domain, the organisation, the user experience, the environment, and it doesn’t stop there.
Software architecture is a huge compromise. Trying to find the least bad solution in a tangled web of love/hate relationships.
Anyone involved in the architecture of software systems has to understand these relationships and their implications. If you ignore one of these relationships your architecture will have a blind spot. If you don’t think about the business model you’ll optimise for the wrong business model. If you don’t think deeply enough about the organisation you’ll have teams fighting an architecture.
Architecture is rewarding because of these complicated relationships. There is always an infinite list of interdependencies and implications to consider. Can you think of any more? Comments welcome.
