Architectural entropy: the enemy of the Enterprise Security Architect
Enterprise architecture (including security architecture) can sometimes feel like a thankless task.
It can take many weeks developing a target architecture with senior approval and budget. The problem is, as soon as the architecture is signed off and the ink has dried, it begins to degrade through a process I refer to as ‘Architectural Entropy’.
Entropy, for those who are interested, is a concept that came out of the 2nd law of thermodynamics. It essentially means that things tend to worsen over time. In the case of thermodynamics, the quality of available energy to perform work. However, this process of degradation cannot be reversed without expending more energy.
In the context of Security Architecture, I use entropy to articulate the slow degradation of the defined security architecture over time.
The target architecture on its own is meaningless. Once defined, you then need to spend time and effort turning it into a reality.
The problem is: as soon you begin to do the detailed work, that purity your target architecture represents, begins to degrade. And entropy begins to rise.
Why does this happen?
Building the architecture is inevitably about compromise; however, compromise leads to an increase in architectural entropy; i.e. a decrease in the original quality of the intended target architecture.
Compromise typically begins because of cost.
The architecture is in essence the purest form of the end state. However, inevitably the cost of achieving that state perfectly begins to outweigh the benefits to the enterprise. Through these financial pressures, the first set of compromises normally kick in.
Then there’s technology.
With the architecture representing the gold standard, you’ll start to look at the vendor landscape for potential solutions.
The target architecture effectively represents the requirements that the technology must help the enterprise achieve. You may run a tender-evaluation process, using your target architecture to inform the requirements, to find a potential supplier.
The problem is that you’ll very rarely get a perfect match against your requirements.
So there’s a need for further compromise, leading to judgement calls on the best workarounds that leads to the least impact to your target architecture. To make things worse, initial expectations about suppliers and their technologies that may have been tested as part of pre-contract due diligence, may not pan out as expected.
This doesn’t mean that someone was stretching the truth. Sometimes problems crop up as more detailed analysis and design work is completed. After all the devil is in the detail! Therefore more compromise… leading to more entropy.
What about the challenge of business change: transitioning from ‘A’ to ‘B’?
It is going to be a rare thing to be able to implement your architecture on a completely vanilla (new) enterprise. There will be people, process and technology already in place performing certain roles to achieve defined outcomes.
Therefore, for political and financial reasons, the architecture transition is going to have to consider integrating as much of existing capability as possible; this includes bringing existing idiosyncrasies into the target architecture. So, more entropy!
Despite all of these challenges, the target architecture is finally delivered after several months or years of business change, even though it doesn’t quite look like what you’d originally intended; but at least it is there. Or is it?
What about the increase in entropy over time?
Business changes. Threats become more advanced. Your chosen technology is transitioning into sun-set support arrangements. Day-to-day changes are made as part of support. New systems are added to the environment. Changes in regulatory pressures. I could go on…
Given the upfront capital in terms of time and effort expended by the Security Architect, this can be a disheartening prospect.
However, business is about change and change has to be about compromise.
From the start, in my view, the Security Architect should identify the critical elements of the enterprise’s security architecture that needs to be in place.
Beyond that, I’d recommend focusing on:
• Making sure that security-relevant goals and architectural principles are in place;
• Having an effective management system that is empowered to monitor and improve security; and
• Developing a robust engagement model between delivery, operations and architecture.
Architectural entropy sadly (very much like entropy in the field of thermodynamics) is a fact of life.
Quite simply as a Security Architect, you just need to factor it in.