Solution Architecture 101 : Non Functional Requirements
Non Functional Requirements are the (often) unsaid things in a good architecture, which at times not called out clearly, but missing on them would ensure chaos. Imagine walking up to a newly opened bakery, ordering the best cake offered, and not finding it soft or (worse) salty. When you walk into any bakery and ask for a cake over the counter, you expect it to be at minimum sweet and soft, so you just ask for a cake and not specify all of its characteristics.
So you didn’t ask exactly what you wanted, or the bakery didn’t deliver the cake with least expected features(Minimum Viable Product or MVP) ?
Like I mentioned in my previous article, A Solution architecture is usually an answer to a problem. The problem statement may specify all the business needs functionalities required by the business, but at times may not specify that it should be secure, robust, scalable to the load and above all Reliable. That’s something at minimum expected out of a solution, that it would not fail on the very sight of trouble.
So what are some of these NFRs or Non Functional Requirements or “Itys” which makes an architecture complete. Let’s understand this while staying in this newly opened bakery and looking around :) .
Security:
When you ordered your cake, you expect it to have been prepared in a hygienic environment, with limited employee only access and would have been stored in a pest free area within kitchen before being delivered to you in a clean plate.
Same way an architecture should account for all the security aspects and limit access to only required sources. Application should be hosted in a safe environment (Hygienic Kitchen), and restrict unauthorized access (pests). Database should be safe (clean compartment). It should be able to safely communicate with the users (clean plate) so user data (cake) isn’t compromised at any point in time.
Scalability:
You really liked this new bakery and told all of your friends about it . Next time they all joined you for the trip to the bakery. Now you see there is not enough space in the bakery to seat all of you :( , but bakery owner offered to put some extra chairs outside and accommodated all of you, and that did the trick.
Same way a good architecture would account for scalability to tackle occasional traffic. It should be able to serve all the incoming traffic, without affecting the quality of service. Architecture should be able to accommodate additional hardware whenever required, and in the same way should be able to run on limited resources when traffic is low.
Availability:
Now you are a regular to this new bakery, and can’t start your day without the cake and coffee from this shop. One fine morning you found this shop closed with an ‘under maintenance’ board outside, other day you were a little late to the shop and saw ‘out of cakes’ and ‘out of coffee’ board outside the shop. All the good things about the experience starts turning bad, and you start looking for a diff shop.
A good architecture would make sure the application is available at all times. There would be checks and balances in place to take care of the occasional issues, so that application would be available all the time. Like the bakery shop, if you couldn’t ensure application availability, customers would start to lose confidence and interest.
Maintainability:
First few trips went like a breeze to the new bakery. But eventually you started noticing the food doesn't taste same anymore, It’s a mess all around. Feel good factor about the place starts to fade away. You are not excited at all to come to this place anymore. The New Bakery couldn’t maintain itself.
A good architecture would keep things simple, so components can work on their own as long as its required. Unnecessary Complexities in the system would make it hard to debug issues and fix problems quickly in future. If architecture wouldn’t be maintainable, it would adversely affect the customer confidence in the application.
I hope all of this has been relatable and thus have been helpful to you. I am planning to keep on adding more content in this series.
Don’t get Stuck, Keep Solutioning :)
To be Contd.. — Right Platform Selection, Cloud vs On-Prem infra, Monolithic vs Microservices, Effort Estimations, Staffing, Delivery Plan.
