Software Architecture in the agile World – Part 4: Making decisions with little knowledge

These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents

Max has the challenge that there are a lot of architectural decisions that have to be made. But how can his team make good decisions with only limited knowledge because they build the software incrementally and need decisions early to start developing?

Most architectural decisions can be split into a sequence of partial decisions. And some partial decisions can be deferred to a later – to a moment with more knowledge.

There are three tools to defer decisions: abstraction, simplification and willful ignorance. Let me show you an example:

The software that Max and his team are building needs to store the data of the employees, their skills and the teams.

But not yet in the first couples of days – or even weeks. Max’s team can build some business logic, show it to the stakeholders, get feedback from them and improve the solution without data that is stored.

The system can hold the data in-memory for demonstrations. I call this willful ignorance – you willfully ignore the problem. Willfully means, that you are aware of the consequences and address them accordingly (prepare data for demonstrations, the system cannot be used in production, …).

Once the business logic fulfils the needs of the stakeholders, Max’s team knows what data is involved and can introduce an abstraction – e.g. an interface – that is capable of saving and loading the data. Maybe a simple implementation just serializes the data to binary and save it in a file on a disk. Now the data is persistent. But of course, we simplify the problem here. The performance will not be good enough when the system will be productive. But again, for now, for the sake of getting feedback, it is good enough.

Finally, we remove the simplifications from the system and introduce a production-ready storage solution. But now, Max and his team have much more knowledge about the data involved and its size and kind (relational, graph-based, key-value, document-based, …). Now, making a good decision on what technology to use is much easier.

An architectural decision – like persistence – is not a simple yes or no decision. it is a sequence of partial decisions: Do we need persistence now? What data do we need? How is the data structured? How much data do we have? What are the requirements for load and throughput? What technology is best?

You can find a list of architectural aspects that need to be decided on my architecture cheat sheet.

Continue reading: Changing things without breaking them