Separating the non-functionals

Tue, 02 Oct 2007 11:07:00 GMT

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.

High-Assurance Design

Wed, 18 Jan 2006 20:11:09 GMT

This week, Cliff Berg is doing a promotion of his latest book entitled High-Assurance Design : Architecting Secure and Reliable Enterprise Applications. I'm sure you've encountered this yourself, but on many projects there's often a disconnect between the development team that build the software and the security experts that reside elsewhere in the organisation. I've certainly seen this happen and due to the different skillsets involved, it's hard to get these two groups of people talking the same language. As a result, security is often inadequately implemented and reliability ... well that sometimes doesn't even feature.

If this sounds familiar then Cliff's book might be for you. Stop by the OO, Patterns, UML and Refactoring at the JavaRanch Saloon to see the discussion and have the chance to win a copy.

Coding the Architecture - reliability tag

Separating the non-functionals

High-Assurance Design