Continuous Architecture in Practice — Episode 1

Back after a break, the club unpacks the first two chapters with a guest, Maxim: an architect with fourteen years in telecom, eight of them heading an IT architecture department, plus spells at a regulator and at a digital bank, now freelancing and teaching IT architecture; the hosts recommend his Telegram channel on architecture and IT solutions. The cover gets its own discussion: this is the first book of a new series on architecture and design, with separate volumes on monoliths and microservices and on APIs. There are three authors, whose names the participants admit are hard — only Pierre comes out confidently; two of the three had a book already, and this one grew out of readers asking how to implement any of it in a real company, hence the case study running through every chapter. The plan is four streams, two chapters each, with the closing pages at the end.

Chapter one opens with definitions of architecture — the building analogy, plans for implementing the system, structure and relationships — and the result strikes the participants as blurred: the authors are quietly introducing a term of their own. Alexander recalls that many architecture books fall into the same trap and drift into reflection, while Maxim calls opening with a definition an outright blunder: one of the quoted definitions has been criticised by everyone, and by his account it was recently reworked — it used to be about a system and is now about something far more abstract. The whole chapter, he feels, gently mocks architects so the authors can distance themselves from the current state of IT architecture and offer their alternative. The purpose of investing in architecture is stated plainly: deliver business value to production quickly and continuously; four reasons follow — quality attributes, principles and standards, reuse and evolution, strategic planning.

The challenges facing architects — focusing on technology instead of business context, fixing organizational problems by technical means, the reputation of people who slow delivery down — strike the participants as inconsistent: they seem to describe different companies — one where, instead of architects, strong engineers pick up the big work themselves, and another a corporation with gates and scaled agile. One host admits the list did not bother him while reading, but talking it through showed that the picture does not add up. Maxim sums it up: the book is really about process, with no revelations about splitting a system into components, only reasoning about tying the architectural process to development; continuous architecture is not a new idea, though these authors have the most coherent version. The Agile principle about the best architectures emerging from self-organizing teams gets its own turn: the point is not to drop architecture but that it should not be imposed from above. In the early 2000s those words were believable, one participant adds; twenty-odd years on we are looking at the architecture self-organizing teams actually grew.

Vova walks through the six principles: move from projects to products; lean on quality attributes rather than functional requirements, which do not narrow the choice of solution; take a decision as late as possible but no later than necessary; use the power of small, since loosely coupled modules evolve more easily than a monolith; architect for the build, test, deploy and operate pipeline; shape the way teams are organized. Maxim recalls that the previous book had, he thinks, seven principles, and picks through them: a product unites a cost centre and a revenue centre, so it can be run by the venture rule of kill or grow, whereas on a project the money is compared once or twice. Splitting requirements into functional and non-functional he calls archaic: the nines have to be attached to a concrete scenario. The power of small is never unpacked — without an answer to why, modularity degenerates into microservice madness. His wish is that the challenges had been mapped onto the principles: answering four challenges with six, without saying which covers which, is not architectural work.

Chapter two opens with the architect's role: when everything funnels through one person, that person becomes the bottleneck, so responsibility for architecture moves onto the team. Maxim sees a direct nod to Frederick Brooks: Brooks suggested recruiting the best people as architects and letting them design, whereas here the answer is that everyone should do architecture, with tooling promised for it. The architect then balances product management, with its growing pile of features and shrinking time to market, against delivery, which ships fast but brittle, with operations nearby; a host notes the thread then dissolves and never returns. There are four activities: quality attributes, whose requirements are written as scenarios using the ATAM method — stimulus, expected response, measurement, environment — with examples such as cloud cost growing by no more than ten per cent; making and recording decisions as the architect's main unit of work; technical debt; and the feedback loop, whose length a host misses in the book — production after a big project, every release, or something smaller inside an iteration. The point is that the architect's job is not a diagram or a document but a change in what runs in production.

Technical debt is split into code-level, architectural and infrastructure-driven, and shows up as slow changes, extra work and a rising defect count. Maxim is hard on the diagrams: the second is drawn in the topology of the first but says something else, and having studied Simon Brown's C4 — Brown endorsed the book — the authors could have said outright that this is a zoom into a box from the previous picture. He finds the book more interesting than evolutionary architecture, where everything rested on fitness functions that no book explained clearly enough to use. The real problem, he argues, is drawn on the diagram of decision levels: at the top there are few decisions but they get recorded, at the bottom there are many and they do not, and the rest of the book is about making the upward arrow work. Among the trends are architecture owned by the team and notations: everyone believed in UML but few use it, C4 and ArchiMate are there too, and diagrams mainly need to be simple, consistent and clear to their audience. The closing Kanban board takes in requests for architectural decisions; in a week the club reads the chapter on data.