Accidental Architecture
Most IT departments have the best intentions of providing the best quality, coherent solutions, yet market conditions, projects running in parallel and various constraints on budgets, resources or time, often causes what might be defined as Accidental Architecture.
The easiest way to identify cases where you’ve been hit by accidental architecture is when describing your it architecture and look for the works “except” or “but not”. Typical examples include - we have a single-sign system utilized everywhere except…”, “We update all systems to current versions, but not this old system…”.
The accidental architecture seem to be caused by a few main drivers:
- Lack of overview
- Lack of time
- Lack of resources
Lack of overview
When the root cause is lack of overview, the case is often, that decisions and designs are implemented without understanding the entire scope of the problem - or existing procedures and architecture in place. While a good coherent architecture seems to have been designed, it turns out that existing complexities which wasn’t known or addressed causes issues.
Lack of time
Deadlines often seem to be the cause of many issues - and no matter who much time you may a assign to a project, you’ll often need just a little more. As a deadline approaches often shortcuts a made to make the deadline and the shortcuts - which is assumed to be fixed in the next version, but often forgotten and abandoned - until issues arise.
Lack of resources
The issues caused by lack of time and lack of resource may seem similar, but are different. When lack of time causes the issue, the problem could have been solved, whereas lack of resources often happens when budget constraints or lack of knowledge causes an architecture to be chosen which may not be the right solution of the problem at hand.
The lack of resource issue may often occur, when projects are expected to drive enterprise changes - merging billing systems, decommissioning legacy platforms and other issues, which should be done, but often a product development project may not be able to facilitate.
The first step, is to realize there is a problem…
While many organizations fail to realize the existence and the volume, most actually seem to have a fair share of them - and if not handled - probably a growing volume.
Once you’ve realized you have cases of accidental architecture, make sure you address them on your technical debt list and have plan for what to do about the system. While “pure” technical debt most often may cause operational issues, the accidental architecture usually cause customer facing issues and are not recognized as severely as the operational issues caused by technical debt.
The issues introduced by accidental architecture is often complexity, slowly rising operational costs and increased user-support costs. To keep your IT domain alive and moving forward, time and resources must be found continuously to address and resolve the accidents.