As a technologist, one can be very tempted to use labels to deprecate something you don’t agree with or don’t understand. This happens with the term ‘Architecture’ all the time. When asked about an older system that we inherited or an application we are tasked with renovating, it is easy shrug off the notion of an underlying architecture. I think when we do that, we short change our ability to understand how a system works and thus making our jobs more difficult.
Most definitions of architecture resolve to the following: A style and method of design and construction.
In the information technology world, we use the word “architecture” to describe patterns and mechanisms and, for the most part, use it to make our case relative to some industry adopted standard. In older systems, or those prototypes that somehow make it into production, we are quick to dismiss them as not having an underlying architecture.
I happen to believe that when you build something it has an underlying architecture, whether intended or not. So any system we should come across in out travels has either a deliberate or accidental architecture.
Architecture does not always mean that someone sat down and deliberated the best way to do something, compiled a standards document and built something eternal. We are all dealing with or have dealt with accidental architectures.
We have all looked at something we inherited, with all of the legacy problems and issues and ask “what were they thinking?”
We have all built or done something that someone else is, or will be, looking at and asking the very same question. (c’mon, you know it’s true – if you don’t, you haven’t built anything…)
The important thing to remember is “architecture happens”, and once established it can become a pattern that is replicated, regardless of whether it was the right thing to do in the first place.
Accidental architectures are easy to create. Most accidental architecture occurs when someone is trying to solve an immediate problem and the impact on the future is not a priority. Accidental architecture can also serve a useful purpose; their successful and not-so-successful characteristics inform us on how we need to evolve our deliberate architecture.
A deliberate architecture is as much about the future as it is about today and is typically built on the bones of the accidental architectures that preceded it.
Developing a deliberate architecture is part archeology, part fortune teller and part problem solving. To define a deliberate architecture, you need to determine the scope and what problem it solves. Once you have defined this, you can constrain the features of the architecture. Defining and constraining the scope helps to reduce the potential mutation of the architecture. Make no mistake; a mutated architecture is also an accidental architecture.
Why look for the architectural patterns?
The value of recognizing that architecture happens is it provides you with a basis to determine motives. If you assume a system was developed randomly by an infinite number of monkeys, you will assume there is no pattern and doing the work to enhance or evolve that system would be difficult. If you look for the architectural patterns, even if they are not obvious, it will provide you insight and a basis for understanding what the developers were doing at the time. As a technology resource, it is your job to provide insight and manage the software assets in your care. Like an anthropologist or archeologist, you need to uncover the motives of those that thought differently from you or those that came before you. To renovate their work, or even replace their works with something new, you need to first understand it.