Separating the non-functionals

Start by focussing on one thing at a time

I was recently involved in a discussion where we were talking about the best way to increase the scalability of a software system, which is essentially a Java EE web application. The most obvious way to do this is to horizontally scale-out the application across multiple web servers (Tomcat, in this case), although I found it really interesting that the conversation soon turned towards topics such as the performance impact that session replication would have. Important as this is, we had moved on to talk about performance, availability, reliability and failover before finishing the scalability discussion. After all, there are some other options that are available.

My experience indicates that it's really easy to get sidetracked when dealing with non-functional requirements and this is just one such example. Yes, you do need to take a holistic view of your non-functional requirements, but you do also need to take each in turn and look at all of the available options. In this particular example, I had a very clear idea of the scalability requirements but not the availability and reliability requirements. For all I know, it might be okay if a user is forced to log back into the application in the event of a Tomcat node going down.

My advice is this - start by focussing on one thing at a time. On a related note, Think you know what scalability is? is a timely article that provides a good overview of what scalability is all about.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.



Re: Separating the non-functionals

The particular combination of NFRs you mention (scalability and performance, or scalability and availability) seem to often become mangled together into one unidentifiable meta-NFR. The same thing can easily happen with some of the other "ilities" such as extensibility and flexibility. I don't think that they weakly defined, but maybe their real meanings are not well understood outside of the architecture community.

I also often see a similllar blurring of terminology with security-related requirements, especially authorisation and authentication.

Re: Separating the non-functionals

I've had a couple of conversations with people in recent weeks about this sort of thing - namely that NFRs are not independent. When trying to meet one or more NFRs, you're almost always making some sort of trade-off with others.

Take, for example, your example of trying to scale a Tomcat web application - in having session state replication you've also introduced an additional NFR of ensuring that there's consistency of state in the event of a Tomcat failure. By satisfying both the scalability and consistency requirements, you're having some effect on the performance. You could have scalability and only marginally affect performance if you ditched the consistency requirement (e.g. by switching off the session state replication and ensuring that users are tied to a particular instance).

I think it's important to ask 'If I'm going to meet this particular NFR, what am I going to affect and is that going to be acceptable?'


Add a comment Send a TrackBack