Complexity and Enterprise Application Architectures
A client asked us to look at the complexity of their Enterprise Architecture and to come up with a way to measure it, or at least to measure the way it changes over time. Now there is no simple way of calculating a complexity number for an enterprise architecture. Complexity is a quite elusive property, with different meanings to different people. So for this purpose we looked at complexity to be a proxy for effort to maintain, build and manage the systems in the enterprise.
While this still doesn’t make it practical to arrive at an overall number there are a number of aspects that can be used to rate complexity in different categories. At the base of it is the sheer number of “things” that an architecture contains such as:
- The amount of business processes
- The amount of business functions/products
- The amount of different kinds of data
- The amount of interfaces (to users and other systems)
Each of these give rise to complexity by their very nature. If, for example, the amount of business functions doubles then complexity (as we defined it above) would be expected to at least double as well. The minimum unavoidable rise in complexity is linear, directly proportional to the number business functions.
If the additional business functions introduce dependencies upon other systems, then complexity would rise in a non-linear fashion. In the extreme, an increase in size of business function could mean that all business functions have a dependency on each other. In that case the number of dependencies drives complexity up at a faster and faster rate. In mathematical terms the complexity is then proportional to the factorial of the number of business functions. This situation would represent the worst case – in reality any enterprise system would range somewhere between these two. If unmanaged, the complexity growth curve would move towards the worst case scenario. If managed through an appropriate application of enterprise architecture it can be moved closer towards the ideal.
So to rate complexity one has to look at duplication and dependency, e.g.
- How many times is the same kind of data managed?
- How many ways can data updates flow through the system?
- How many different ways is the same basic business process done (e.g. branch vs. internet self service)?
- How many updates to the system have to occur if a fundamental change (e.g. interest rates) occurs?
- How many system interconnects exist, how many of these are duplicated?
Enter the Enterprise Architecture
To try and rate each and every item would however be impractical – just about as impractical as it would be to measure the state of chaos in someone’s backyard shed. Because Enterprise Architecture tends to deal with big pictures and often looks at big changes it needs to be extremely practical. Enterprise Architecture initiatives sometimes get stuck very early because everything appears to be too hard, with every improvement opportunity being blocked because there is no room to move. In this case a good strategy is to start by identifying a list of mostly tactical improvement opportunities that will deliver both reduction of complexity and improvement of business function. The list’s purpose is to allow for improvements that provide space for movement. Once this ‘space’ has been created roadblocks for larger and more strategic improvements are being removed.
Typical Case: Organisational Mergers
A merger between two organisations, if unmanaged, creates a large jump of complexity with sometimes no real improvement in business functions – if two small lenders were to merge, both organisations may have the same five basic types of home loans, but they could now be packaged as 10 different products with 10 different sets of systems to support them. If unmanaged, it puts the organisation onto a substantially faster growth curve in terms of complexity. In an ideally managed scenario, the systems would not only be merged but opportunities arising of leveraging the systems could give rise to new, previously not easy to achieve business functions. This would move the company not only downwards in complexity but also forward in terms of its ability.
