I've been reviewing some software architecture documents as part of a training course today, where the authors had restated the non-functional requirements. Given that the non-functional requirements are some of the key architectural drivers, restating them in the architecture document is something that I recommend and like to see, so I was pleased that this had been done here. The thing that really struck me, though, was how nobody had seemed to question the requirements that they had been given. While most were okay, the availability requirement really stuck out as being extreme, for what is basically a desktop-based CRUD application.
The system must be available for 99.99% of the time, from 9am to 6pm London time.
With a duration of 9 working hours, this availability requirement means that only about 3 seconds of downtime can be tolerated. As a general guide, I'd say that availability figures of 99% and above mean that you have to start thinking about different types of architectures that include characteristics such as automatic (or very fast manual) failover, clustering, no single points of failure and so on. Clearly, a change in the architecture has a knock-on effect to the cost, potentially turning a £100,000 project into a £1,000,000 project. Whenever you're given non-functional requirements, always be prepared to ask the stakeholders whether they really *need* them and remember to emphasise that added complexity doesn't come for free.
Simon lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.