Future Architectures
There are many great quotes about predicting the future. One of the most popular, and one of my personal favorites, is from Nils Bohr - a Nobel laureate in Physics – who famously quipped that "Prediction is very difficult, especially if it's about the future."
If predicting the future is so difficult, then the role of the Enterprise Architect in defining future architectures is a high risk task! And yet, this is a key part of what enterprise architects do on an almost daily basis. There is an ever-emerging continuum – from the past through the present to the future – and as a history graduate I am well aware of our need to position future architecture needs as an evolution from the past and the present. We can only deliver architectures that evolve from their heritage and legacy, or that make a break from the past.
One of the unique characteristics of enterprise architecture is its aim to provide a coherent sense of direction across the multitude of investments that are made in separate projects and change programs.
Enterprise Architecture does this by leveraging three characteristics of change investment:
- Direction is whether a change moves towards the future architecture or not.
- Magnitude is the degree to which a change contributes towards those future architecture needs.
- And Velocity is how quickly we can make positive changes towards the future architecture needs.
So coming back to my theme in this blog – are there any laws that can help us to think about future architectures and help us to predict and forecast future architecture needs? These seven tips are adapted from Gilbert Heebner – who worked as chief economist for The Philadelphia National Bank, and published his Seven Laws of Forecasting in the 1980s[i].
- EA repeats itself; EA does not repeat itself. Future architectures are not completely random – they evolve from past and current ideas. Target architectures are limited by the possibilities within the current architecture. Big data, SOA, cloud and mobile are all part of future EA landscapes, but each of them has origins in the past; for example, SOA is based around the concepts of component and modular design that go back to the 1960s and 1970s, while mobile is part of an ongoing move that brings intelligence to many devices (from washing machines to cars, and mobile phones to spacecraft). Future architectures always evolve from current architectures.
- From time to time major shocks – often unanticipated – throw future architectures off course. The financial crisis of 2007-2008 changed the direction of many enterprise architectures. For example, Lloyds TSB did not anticipate that they would takeover HBOS to form Lloyds Banking Group, or that subsequently they would need to sell off the part of their business under the TSB brand. Future architectures need agility and flexibility to change direction and embrace the unexpected.
- The consensus of EA forecasts is more often right than wrong. If there is a general agreement on the future of EA amongst fellow practitioners, then the chances are that is going to be the future needs. Keep an eye on what your competitors and leading practitioners are doing, because that is the future!
- Adherence to a single EA approach can be dangerous to your forecasting health. Current architectural practice can become less valid as conditions change. For example, off-shoring and outsourcing IT development became commonplace in recent years, but this requires excellent communication, often across cultural and linguistic boundaries. Many EA teams focus on separated, modular, layered IT components, while ignoring the need to incorporate similar architectural design principles in products, process or brand, leaving these business components more vulnerable to rigidity and silos.
- Forces for architectural change work relentlessly, but on an uncertain timetable. We cannot always rely on ongoing stakeholder support or funding; we cannot control the appetite for transformational change. Our architectural forecasts are more likely to be correct on cause and effect, while they are likely to be less reliable on timing. So when you develop roadmaps, be aware of the need to adjust timings on a regular basis.
- Exceptions, exemptions, waivers, omissions, exclusions – these are always important. These things can easily slip into historical obscurity and become forgotten. They are often not documented because they are not part of the current EA landscape. But we need to remember when we have decided to ignore the official roadmap and take a diversion. There may be a good reason for a detour, or there may not, but it is an important part of the future direction, so we need to document the rationale behind decisions to take an alternative route.
- Decisions are more important blueprints. How you arrive at an architectural decision or forecast is more important than the forecast itself. It is the architectural debate and reasoning that creates understanding and insight. Creating awareness of the constraints implied in current architectures and options available for future architectures is the most valuable role of the enterprise architect.
Predicting the future is always hard, but when we define future architectures they must always evolve from current architectures; we must be prepared to change direction and embrace the unexpected; we need to keep an eye on contemporary practice and the direction that others are taking; we need to vary our EA approach to meet the needs of all stakeholders; we must constantly revisit roadmaps and adjust timings to allow for the uncertain pace of enterprise transformation; and we must monitor any diversion from the predicted roadmap.
Above all, we need to remember that it is the rationale behind our decision-making process that is more important than the definition of the future architecture. It is how we forecast the future that is more important than what we predict the future to be!