Over the years, I’ve been part of the design/architecture process for countless technology engagements. Sometimes as the lead architect, sometimes as a reviewer and sometimes in the early discovery phase. Something that still surprises me is how frequently non-functional requirements are not given enough consideration. Ensuring that both functional and non-functional design requirements are clearly understood can make the difference between success and outright failure.
Let me start by explaining what I mean by functional vs non-functional design. Functional requirements have the form, "the system shall do/provide something".
Examples include:
The system shall provide object level storage The system shall securely store objects at rest and in-transit The system shall provide an Application Programming Interface (API) While functional requirements are the foundation of systems requirements, architecture conversations should also include non-functional requirements. They refer to the quality of the system. They commonly focus on areas such as scalability, durability, compliance, performance and availability. They are sometimes referred to collectively as the "ilities" for obvious reasons.
Let’s now consider possible non-functional requirements that could be associated with the functional requirements of the object storage system described above.
The object level storage will have a durability of 99.999% The object level storage will have an availability of 99.95% The object level storage will scale to support 10 billion objects and transaction rates of 100,000 object reads per second. With a better understanding of the difference, why do non-functional requirements often play less of a role in the design process than they should? It’s often the case that business or technology owners haven’t give them enough thought. This is especially the case for internal systems. This is changing as organisations move towards developing internal platforms, platforms that need to provide Service Level Agreements (SLAs), but these rarely have any hard penalties, unlike external facing public paid services. Creating arbitrary non-functional requirements that are not tied to a constraint, service quality or provide a valuable competitive advantage lead to unnecessary complexity and cost.
Everything should be made as simple as possible, but no simpler - Albert Einstein.
As an architect, it's our responsibility to get to the core of the problem the system will solve and potentially the competitive environment that system will reside in. This will ensure that both functional and non-functional requirements are clearly expressed.
So is that it, are we done? Not quite, The other activity that’s worth investigating is projecting into the future and asking yourself the question:
How easy would it be to evolve the system as the non-functional requirements change over time?
The two requirements that will probably dominate the thought process are scale and performance, with availability and durability being third and fourth. It’s good practice to understand at what point the system architecture needs to significantly change to accommodate future growth. While it’s generally the case that most non-functional requirements include some element of projected future demand, if the system architecture will only accommodate marginal additional growth without significant redesign, it makes sense to invest a little extra effort now to avoid a lot of extra effort later. Understanding how a system can change and the level of confidence that the business has in the projected future requirements will help ensure that you build in flexibility in the right areas.
Designing a system against its functional requirements is generally the easy part, incorporating non-functional requirements makes the problem more challenging and is the space that differentiates great architects from good architects.