Coding the Architecture - availability tag

NFRs for system replacements

Wed, 28 May 2008 10:35:00 GMT

As software architects, we tend to write about non-functional requirements a lot; particularly about how they should be defined and challenged because of the influence they have. One of the reasons for talking about NFRs a lot is that, in the majority, project teams don't give them the attention that they should. And here's a great example that's slightly different from the story where none of the NFRs were defined.

As is the case in most organisations, technology has a limited lifespan. Perhaps the business evolves, the technology becomes harder to maintain, etc. Whatever the reason, many organisations regularly look at replacing their existing systems with solutions that are shinier and more buzzword compliant.

In one of these cases, an organisation put together a 125 page specification for the replacement system detailing exactly what the system should do along with some details of the non-functional requirements. However, out of those 125 pages, only 1 of them featured the NFRs, and they can be summarised as follows.

Performance : the system must be fast.
Scalability : the system must be able to support 100 messages per second.
Availability : the system must be available 24x7.
Security : only certain individuals are permitted to access the system.

Credit where credit is due ... at least some thought was put into the non-functional requirements and conversations to explore those requirements aren't starting from scratch. But on the other hand, those requirements are meaningless!

I want to end this post on a positive note, so let me contrast this story with another replacement project that I've been involved with recently. In this instance, the team *had* thought about the non-functional requirements and had detailed definitions for what they should be. This is excellent, particularly considering that the non-functional requirements surrounding the current implementation are vague in nature. System replacements are an opportunity to revisit what's important, and that includes the non-functional aspects too.

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.

Nines

Wed, 26 Sep 2007 22:21:00 GMT

I've been reviewing some software architecture documents as part of a training course today, where the authors had restated the non-functional requirements. Given that the non-functional requirements are some of the key architectural drivers, restating them in the architecture document is something that I recommend and like to see, so I was pleased that this had been done here. The thing that really struck me, though, was how nobody had seemed to question the requirements that they had been given. While most were okay, the availability requirement really stuck out as being extreme, for what is basically a desktop-based CRUD application.

The system must be available for 99.99% of the time, from 9am to 6pm London time.

With a duration of 9 working hours, this availability requirement means that only about 3 seconds of downtime can be tolerated. As a general guide, I'd say that availability figures of 99% and above mean that you have to start thinking about different types of architectures that include characteristics such as automatic (or very fast manual) failover, clustering, no single points of failure and so on. Clearly, a change in the architecture has a knock-on effect to the cost, potentially turning a £100,000 project into a £1,000,000 project. Whenever you're given non-functional requirements, always be prepared to ask the stakeholders whether they really *need* them and remember to emphasise that added complexity doesn't come for free.