Stop reading now if your organisation is easier to navigate today than it was 3, 5 or 10 years ago. The reality that most of us face is that the general ledger that might have cost $100,000 to implement twenty or so years ago will now cost $1 million or even $10 million. Just as importantly, it is getting harder to implement new products, services or systems.
The cause of this unsustainable business malaise is the complexity of the technology we have chosen to implement.
For the general ledger it is the myriad of interfaces. For financial services products it is the number of systems that need to keep a record of every aspect of business activity. For telecommunications it is the bringing together the OSS and BSS layers of the enterprise. Every function and industry has its own good reasons for the added complexity.
However good the reasons, the result is that it is generally easier to innovate in a small nimble enterprise, even a start-up, than in the big corporates that are the powerhouse of our economies.
While so much of the technology platform creates efficiencies, often enormous and essential to the productivity of the enterprise, it generally doesn’t support or even permit rapid change. It is really hard to design the capacity to change into the systems that support the organisation. The more complex an environment becomes the harder it is to implement change.
Most organisations recognise the impact of complexity and try to reduce it by implementing an enterprise architecture in one form or another. Supporting the architecture is a set of principles which, if implemented in full, will support consistency and dramatically reduce the cost of change. Despite the best will in the world, few businesses or governments succeed in realising their lofty architectural principles.
The reason is that, while architecture is seen as the solution, it is too hard to implement. Most IT organisations run their business through a book of projects. Each project signs-up to an architecture but quickly implements compromises as challenges arise.
It’s no wonder that architects are perhaps the most frustrated of IT professionals. At the start of each project they get wide commitment to the principles they espouse. As deadlines loom, and the scope evolves, project teams make compromises. While each compromise may appear justified they have the cumulative effect of making the organisation more rather than less complex.
Complexity has a cost. If this cost is full appreciated, the smart organisation can see the value in investing in simplification.
While architects have a clear vision of what “simple” looks like, they often have a hard time putting a measure against it. It is this lack of a measure that makes the economics of technology complexity hard to manage.
Increasingly though, technologists are realising that it is in the fragmentation of data across the enterprise that real complexity lies. Even when there are many interacting components, if there is a simple relationship between core information concepts then the architecture is generally simple to manage.
Simplicity can be achieved through decommissioning (see Value of decommissioning legacy systems) or by reducing the duplication of data. This can be measured using the Small Worlds measure as described in MIKE2.0 or chapter 5 of my book Information-Driven Business. The idea is further extended as “Hillard’s Graph Complexity” in Michael Blaha’s book, UML Database Modelling Workbook.
In summary, the measure looks at how many steps are required to bring together key concepts such as customer, product and staff. The more fragmented information is, the more difficult any business change or product implementation becomes.
Consider the general ledger discussed earlier. In its first implementation in the twentieth century, each key concept associated with the chart of accounts would have been managed in a master list whereas by the time we implement the same functionality today there would be literally hundreds if not thousands of points where various parts of the chart of accounts are required to index interfaces to subsidiary systems across the enterprise.
One approach to realising these benefits is to have dedicated simplification projects. Unfortunately these are the first projects that get cut if short-term savings are needed.
Alternatively, imagine if every project that adds complexity (a little like adding pollution) needed to offset that complexity with equal and opposite “simplicity credits”. Having quantified complexity, architects are well placed to define whether each new project simplifies the enterprise or adds complexity.
Some projects simply have no choice but to add complexity. For example, a new marketing campaign system might have to add customer attributes. However, if they increase the complexity they should buy simplicity “offsets” a little like carbon credits.
The implementation of a new general ledger might provide a great opportunity to reduce complexity by bringing various interfaces together or it could add to it by increasing the sophistication of the chart of the accounts.
In some cases, a project may start off simplifying the enterprise by using enterprise workflow or leveraging a third-party cloud solution, however in the heat of implementation be forced to make compromises that make it a net complexity “polluter”.
The CIO has a role to act as the steward of the enterprise and measure this complexity. Project managers should not be allowed to forget their responsibility to leave the organisation cleaner and leaner at the conclusion of their project. They should include the cost of this in their project budget and purchase offsetting credits from others if they cannot deliver within the original scope due complicating factors.
Those that are most impacted by complexity can pick their priority areas for funding. Early wins will likely reduce support costs and errors in customer service. Far from languishing in the backblocks of the portfolio, project managers will be queueing-up to rid the organisation of many of these long-term annoyances to get the cheapest simplicity credits that they can find!