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.
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.