The Awkward Silence
What Iâ€™ve experienced is that the team can start to regress when faced with discussions around what kind of architecture to aim for. With a backlog chock full of customer pleasing functionality the architectural conversations might begin to take a bit of a back seat as the focus is on fleshing out the walking skeleton with features. Naturally the nervousness starts to set in as the engineers begin to wonder when the architecture is going to get the attention it rightly deserves. Itâ€™s all very well supporting a handful of â€œfriendlyâ€ users but what about when you have real customers whoâ€™ve entrusted you with their data and they want to make use of it without a moments notice at any hour of the day?
The temptation, which should be resisted, can be to see architectural work as outside the scope of the core backlog â€“ creating a separate backlog for stuff â€œthe business does not understandâ€. This way can lead to a split in the backlog, and potentially even two separate backlogs â€“ a functional and a non-functional one. This just makes prioritisation impossible. Also burying the work kills transparency, eventually erodes trust, and still doesnâ€™t get you the answers you really need.
Instead, the urge should be to frame the architectural concerns in terms the stakeholder does understand, so that the business can be more informed about their actual benefits. In addition, when â€œThe Architectureâ€ is a journey and not a single destination there is no longer one set of benefits to aim for there are multiple trade-offs as the architecture evolves over time, changing at each step to satisfy the ongoing needs of the customer(s) along the way. There is in essence no â€œfinal solutionâ€ there is only â€œwhat we need for the foreseeable futureâ€.
Tell Me a Story
So, what do I mean by â€œgood storiesâ€? Well, the traditional way this goes is for an analyst to solicit some non-functional requirements for some speculative eventual system behaviour. If weâ€™re really lucky it might end up in the right ballpark at one particular point in the future. Whatâ€™s missing from this scene is a proper conversation, a proper story â€“ one with a beginning, a middle, and an end â€“ where we are today, the short term and the longer term vision.
But not only do we need to get a feel for their aspirations we also need quantifiable metrics about how the system needs to perform. Vague statements like â€œfast enoughâ€ are just not helpful. A globally accessible system with an anticipated latency in the tens of milliseconds will need to break the law of physics unless we trade-off something else. We also need to know how those exceptional events like Cyber Monday are to be factored into the operation side.
Itâ€™s not just about performance either. In many cases end users care that their data is secure, both in-flight (over the network) and at rest, although they likely have no idea what this actually means in practice. Patching servers is a technical task, but the bigger story is about how the team responds to a vulnerability which may make patching irrelevant. Similarly database backups are not the issue itâ€™s about service availability â€“ you cannot be highly available if the loss of an entire data centre potentially means waiting for a database to be restored from scratch elsewhere.
Most of the traditional conversations around non-functional requirements focus entirely on the happy path, for me the conversation doesnâ€™t really get going until you start talking about what needs to happen when the system is down. Itâ€™s never a case of â€œifâ€, but â€œwhenâ€ it fails and therefore mitigating these problems features heavily in our architectural choices. Itâ€™s an uncomfortable conversation as we never like discussing failure but thatâ€™s what having â€œgrown upâ€ conversations mean.
Although Iâ€™ve used the term â€œstoryâ€ in this postâ€™s title, many of the issues that need discussing are really in the realm of â€œepicsâ€. However we shouldnâ€™t get bogged down in the terminology, instead the essence is to remember to focus on the outcome from the userâ€™s perspective. Ask yourselves how fast, how secure, how available, etc. it needs to be now, and how those needs might change in response to the systemâ€™s, and the businessâ€™s growth.
With a clearer picture of the potential risks and opportunities we are better placed to design and build in small increments such that the architecture can be allowed to emerge at a sustainable rate.