The goal of software is to sustainably minimize lead time to positive business impact, everything else is detail, Dan North claimed in a presentation at the QCon London conference describing ways of reasoning about code and how this leads him into an architecture style that may fit microservices.
For North, a thought leader in the IT industry, the purpose of software development is creating business impact, borrowing the term from Gojko Adzic who has popularized the term in his book Impact Mapping. Business impact is an observable effect within an organisation, e.g. new customers or reducing operating cost. The goal of software development is to achieve this business impact, or more specifically minimizing lead time, the time from when an opportunity is discovered until a solution is created. Doing this is easy a couple of times, the hard part is doing it sustainable, leading to North’s earlier description of the goal for software development.
North distinguishes between three types of code, code you recently wrote and know, code everyone knows i.e. code that is well tested and documented and which North calls fabric, and a third part, code no one knows, it’s just there with unclear dependencies and when changed completely unrelated things may happen. The single largest problem in software development for North is the vast majority of code of the third type, code that no-one knows and which represents a cost and a contention. From this North claims that code should either be stabilized or killed off, never left and becoming of the third part, unknown code. This leads North into a couple of patterns supporting this idea and which will lead into microservices.
The first pattern is short software half-life, referring to physics and how fast unstable atoms decay. North believes that code should have a very short software half-life, and in order to get there it’s important to have code with a clear purpose that can be reasoned about, making it possible to deliberately stabilize it or kill it off. He emphasizes that understanding the purpose of code is very important.
The second pattern North describes is fits in my head, referring to James Lewis for coming up with the expression. The pattern is about the ability to reason about code; one way of reasoning about a large system is to break it down, either by simplifying the problem or by ignoring large parts focusing on a specific smaller part at a time. With the same principles it's also possible to reason at different scales, how a method functions, how a module works, how modules communicate with each other, and so on outwards.
From his reasoning North defines an architectural style he calls replaceable component architecture which nicely weaves in the idea of short software half-life and the idea of things that fits in your head together with contextual consistency. All components are completely replaceable, each wrapped in an API hiding the internal details and communicating with each other by sending messages. These components are like little computers passing messages and North notes that is how Alan Kay defined Object-Oriented (OO) programming 30 years ago.
Microservices can be a replaceable component architecture, if you optimize for replaceability and consistency, both which are daily choices that has to be made. One issue North has is with the term microservices, micro implies smaller which is not always better, more replaceable is better.
