Software Architecture Basics: Architecture Characteristics

They open with a warm-up: the hosts ask how the day begins for someone they consider super-productive. Alexander's dog wakes him at 6:30; after the walk, while the household sleeps, he reads or writes an article, then coffee with the family, reading on the way to work and on planes, and another couple of hours in the evening. It works, he says, because he sets his own deadlines and announces them publicly. The chat asks about his reading queue: there is one, books come from Amazon, and a couple arrived around a trip to Yekaterinburg, one by Tanya Reilly. Finishing a book, he turns it into an article with diagrams of his own: authors keep much in the text and supply no pictures. One book lacked a summary table of architecture styles with their stars, so he built it in Excel, totalled the numbers and highlighted in red and green where each style falls short.

Taking chapters four and seven together, the hosts admit, never occurred to them; the next discussion may cover several chapters at once. Kolya explains why the chapter matters: a developer is used to writing a program properly, with fewer bugs, but as an architect he is suddenly asked about scalability, fault tolerance and dozens of other words; each is manageable alone, yet there are so many, and the worst reaction is to decide that all of it must now be implemented. Then comes the argument over the term: the authors dropped both non-functional requirements (the business never ordered them, so there is nothing to sell) and quality attributes (quality tends to be checked after the fact), settling on architecture characteristics as what is critical to a system's success. Alexander likes the chain of reasoning and has retold it on another podcast, but warns that no term is universally accepted: you need all three and how they relate. One host admits these were always non-functional requirements to him — he even ran a conference under that name.

Before listing anything, the authors set three criteria: a characteristic specifies a design consideration outside the domain, influences some structural aspect of the design, and is critical or important to the application's success. Alexander notes that almost everyone loves a trio and recalls the triangle with design balancing on its apex; some characteristics are implicit, the ones that affect structure, and some explicit. He has met many such lists, all different; the authors give three groups: operational, structural and cross-cutting. In another book he also meant to mention, the same things are called emergent properties of a system — what you get once the bricks are assembled: reliable or falling apart, secure or not. He prepared a summary and a video for the discussion, the link went into the chat, and shares his screen.

The operational characteristics are worked through on banking examples. Availability is the familiar count of nines. Business continuity and recovery after failures: an internal tool logs and tracks these numbers, there is a recovery plan, and incident response matters to the regulator too: an outage has to be reported in a particular format. Performance is tightly coupled with utilisation: you used to throw hardware at it, now solutions are reworked to hold performance within limited resources. Systems are split into mission critical and the rest, with different requirements and support. Errors are handled so that they do not reach the user: sometimes asynchrony helps, sometimes the error does not block the main path. Scalability is driven by the seasonality of sales, swings across the day and the days of the month when people are paid; for promotions the load is planned in advance. Structurally, they recently rolled out localisation, counting on more than CIS users, and value dynamic screen configuration and toggles for gradual rollout; many practices came from a Google report on mobile development.

Anton, who gathered requirements as a systems analyst, adds pragmatism: the chapter's list is long but incomplete — across sources, by his reckoning, you can collect close to a hundred -ilities, and most must be deliberately ignored on a first pass. Localisation is critical for an international service and barely matters for an internal one, unless you hire developers abroad or enter a country needing Spanish. It is sensible to pick seven to ten characteristics and fix them with the customer: every extra one costs money, and the conversation is best held in SLA and SLI terms. His tale from an integrator: asked what availability the system needed, the customer said 98 per cent would be plenty; when the service took two days to bring back up he arrived furious — but 2 per cent of a year is, by Anton's own count, at least six days, and the quota had not been anywhere near spent. Performance goes the same way: they say fast, you offer 40 thousand transactions per second, they agree, while ten applications a day are processed.

Anton costs a characteristic by analogy: take three to ten similar projects and estimate from them, since nines are certainly not linear; prices and requirements are published in public procurement, integrators keep their own project database, and project-management communities circulate Excel calculators of some twenty questions. Alexander is unhappy with the chapter's enumerative style: after the list, no instrument appears for working out which parameters you need — and shows yet another book, not the one with the emergent properties, that starts from scenarios and attaches the characteristics that matter in them. He pictures the trade-off as musical chairs — five chairs, six runners — and as the sliders of a game character: the points are fixed, you can be clever or strong, or a balanced mediocrity. A request from the chat brings them to cross-cutting concerns — one host has five talks on security on YouTube — and they proceed by elimination: security can go if there are no personal accounts or the service sits inside a VPN; an archive is pointless without a persistent component; and a layered first-, second- and third-line support process is unnecessary when the users are few, even if large — they get handled by hand anyway. They close with their tradition, a photo with the book cover.