NFRs for system replacements
An opportunity to revisit what's important
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.
Scalability Principles
At the simplest level, scalability is about doing more of something. This could be responding to more user requests, executing more work or handling more data. While designing software has its complexities, making that software capable of doing lots of work presents its own set of problems. This article presents some principles and guidelines for building scalable software systems.
Software Architect 2008
Just a short note to plug a handful of sessions that Kevin and I are presenting at the upcoming Software Architect 2008 conference, 3rd-5th June, London.
1. Coding the Architecture : From Developer to Architect
The first is a re-run of our popular all-day workshop/tutorial, which is an introduction to software architecture.
This session is an interactive introduction to software architecture and what it means to be a software architect. It’s aimed at software developers who are looking towards their first software architect role, as well as architects that are new to the role. By attending this session you will gain:The session is interactive; with a combination of presentation, group discussion and group working. Throughout the day you’ll be solidifying everything you learn by defining the architecture for a small software system. The overall goal is that you can take the experience gained here and apply it to your own projects.
- An understanding of what it means to be a software architect, and the responsibilities associated with the role.
- An understanding of the trade-offs that are made when making architectural decisions.
- Some experience of what it feels like to be an architect on a bespoke software development project; including gathering non-functional requirements, determining the drivers for architecture, and defining an architecture.
- An understanding that, as a software architect, it’s okay to do some coding.
Read more...
2. Why Software Projects Fail
The next session takes a look at why software projects fail, and how software architects can prevent this from happening.
The industry has a love/hate relationship with the Software Architect role, with many organisations dismissing it because of their negative experiences of architects that dictate from ivory towers and aren’t engaged with the actual task of building working software. This reputation is damaging the IT industry and inhibiting project success. Things need to change. This session looks at some of the reasons why software projects fail, and presents the view that a good, hands-on software architect can be invaluable in addressing these issues and driving the project to a successful conclusion. Software architects are here to help, not to hinder.
Read more...
3. Sharing Architectures
And the last session we're presenting is about *sharing* architectures (as opposed to just writing them down in a document).
The transition from architectural vision to production code is not always an easy one. Of course we plan for a certain amount of change and accept that some decisions will, on occasion, be wrong. However, without effective communication of the architecture and timely feedback mechanisms, can we really expect to see software that we recognise? Whether we’re up to our elbows in an agile team or riding a barrel down a waterfall project, our choice of what we define and how we convey it can have an enormous bearing on how the architecture is reflected in the software. This session takes a look at some techniques for sharing the architecture and not just publishing it.
Read more...
Should be a really good conference ... if you're coming along, please do stop us and say hello. :-)
