I’ve seen software architecture failures (both my own and others) and they take three forms: failure to adequately define requirements and follow principles (bad design), failure to use the architecture correctly (bad processes) and unforeseen uses of the architecture (bad luck?)
I think we can agree that the first two are management problems, and the solution is understood, if not practiced (e.g. peer reviews, training, standards, patterns, etc.) The last failure is a more subtle. I’ve seen cases where a software architecture is well defined and developed, met the needs of the business, supported the development of the software and was a clear success. Yet further down the road the architecture was used, or misused in ways not contemplated to build software functions not considered in the original design and the entire effort failed with the architecture taking the blame.
Good architecture considers unknown future requirements – houses that are expanded, building that are re-purposed, roads that are enlarged but when do you throw in the towel and decide that tearing down and starting over is the best course? Many businesses that have invested in the development of software to support their business don’t want to get the message that their business has changed and evolved to the point that they need to redevelop or replace their software because the core architecture is no longer applicable.
There are things we can do to future proof our architectures, and continued investment in managing “technical debt” by updating and enhancing the architecture can help us improve the flexibility and future usefulness of software architectures, and I will discuss some of these in future posts. But in the end I think that we have to reset our expectations about the life of our software investments. We inherently understand that as a family grows they will often need to move to a new house, but we resist the idea that a business can’t extend the life of their software indefinitely. When we do accept that we need to rework our software we often have unrealistic expectations of how easy a past architecture will make that task (see previous posts on migration.)
In the end, in my experience too many “architecture failures” have actually been management failures and we need to focus on the right place to fix them.