Eoin Woods, one of the IASA Fellows has published an article about what he considers to be the top ten software architecture mistakes - mistakes that are too often learned the hard way. Brief excerpts of the ten points are below:
- Scoping Woes. "This is the sort of situation where a simple travel booking system ends up with full expense claim management facilities being built into it, with inevitable repercussions for project costs, timescales and quality...It is really true that no security is needed beyond simple login? Once logged into the system can users really perform any system operation?"
- Not Casting Your Net Widely. "A related mistake that many of us have made is to focus on just a couple of our system stakeholders – classically the acquirer (who is paying for the system) and the end users get all of the attention."
- Just Focusing on Functions. "…unless the system exhibits a whole range of qualities (such as performance, security, maintainability and so on) it is unlikely to be successful."
- Box and Line Descriptions. "There are two reasons why the [single, all inclusive] huge Visio picture doesn’t work well as an architectural description: firstly, it’s trying to show too much information in a single representation, and secondly, no one is really sure quite what each of the different types of symbol that you’ve drawn mean."
- Forgetting That It Needs to be Built. "Common things to watch out for related to building the system include designs that the developers or testers don’t really understand, technologies that they aren’t enthusiastic about or don’t have the time to learn, and new technologies that don’t yet have good tool support or perhaps impose a new and unfamiliar way of working."
- Lack of Platform Precision."…its no longer sufficient to simply say that you “need Unix and Oracle” when specifying your platform. You need to be really precise about the specific versions and configurations of each part in order to ensure that you get what you need. This will allow you to avoid the situation where you can’t deploy your system because someone has helpfully upgraded a library for one part of the platform without realising that it means that something else will no longer work."
- Making Performance and Scalability Assumptions. "Start considering performance and scalability early, create performance models to try to predict key performance metrics and spot bottlenecks and get stuck into some practical proof-of-concept work as your design ideas are forming. This will all help to increase confidence that there aren’t any performance and scalability demons lurking in your design."
- DIY Security. "A mistake made in many systems over the years has been to try to add security into the system using “home brew” security technology. Be it custom encryption algorithms, a developer’s own auditing system or an entire DIY access control system, locally developed security solutions are rarely a good idea. While most of us think we could probably whip up a clever piece of security technology in no time, we’re usually wrong."
- No Disaster Recovery. "The key to getting resources to implement a DR mechanism for your system is to be specific and quantify the cost of system unavailability in a number of realistic scenarios. If you can also estimate the probability of the scenarios occurring then you can use these two figures to convince people that DR is important and to justify a certain level of budget to implement it."
- No Backout Plan. "Make sure that whatever happens during the deployment of your system or upgrade that you have a documented, reviewed and agreed backout plan to allow you to restore the environment to its state before you started deployment."