This post opens the “How is it built and how does it run” group.

The first three chapters can feel like silos: each one introduces its own set of information. Here, those inputs start to shape the design. This is where you set direction for the solution.

Your solution strategy should fit the goals from chapter 1, operate within the non-negotiables from chapter 2, and respect the boundaries and partners from chapter 3.

Early in a project this chapter can be short. That is normal. The strategy grows as you learn, as constraints become concrete, and as decisions are made.

Chapter 3 is the last chapter in the “Why and where” group. It is where you draw the line between your system and the outside world.

If that line is unclear, failures show up eventually: unclear responsibilities, failing integrations, and mismatched expectations.

This chapter is split into two views:

• Business context: who interacts with the system, and what value or information is exchanged.
• Technical context: what interfaces exist, and how integration actually happens.

Chapter 2 is part of the “Why and where” group. It is the chapter where you write down the rules you cannot break.

This is not about what you prefer. It is about what your organization, environment, or stakeholders already decided for you.

If you do not document constraints early, they still shape the architecture. You just discover them at the worst possible time.

Constraints also have a positive side: there are thousands of ways to build the same functionality. A short list of non-negotiables helps you narrow down options early, before you invest in the wrong direction.

I have seen teams pick a public cloud technology because it fit the solution, while the product had to run air-gapped on-premises. Or because it was “hot” (call it: conference-driven design), while operations would only support a single platform. Money got wasted before someone finally said: this was never negotiable.

Chapter 1 is part of the “Why and where” group. The audience for this chapter is everyone involved in the project. Even nontechnical stakeholders should read and understand it.

It is the chapter that can prevent a lot of confusion later. You lay the foundation for everything that follows. Not by adding too much detail (there are other chapters for that), but by making the intent explicit.

If you do not know why you are building this application and who it is for, you and your team cannot design it properly.

After my talk “Arc42: The Art of Simple Software Architecture Documentation” at Bitbash 2026, a surprising number of people reached out.

Not just with nice talk, but with can you share the slides?. People told me they saw the deck as a reference guide.

That was the trigger to write it down properly.

When the same question comes back again and again, it usually means the same thing: arc42 is widely known, but it is hard to find practical guidance and shareable examples.