Future Proofing Your Enterprise Architecture

In the past few years, IT has enabled a sea-change in the way businesses are run. From green screens to Web 2.0, we have come a long way. But one concern that never goes away is whether the IT investments being made are worth the money, and whether they will stand the test of time.

In this context, enterprise architecture (EA) has been promoted as essential for the longevity of IT investments. EA is based on sound principles, but its implementation must address not just current business, but also how it will change in the future. If the points of change are planned for, then a future-proof IT infrastructure becomes reality. In this article, we look at the key drivers of change, and how enterprise architectures can be used to address these drivers.

Change in today’s IT landscape is driven by three key kinds of factors: business, technological, and environmental.

Let’s explore each of these in a little more detail, in terms of their constituent parts, and how they can be addressed:

Business Drivers

The main business drivers that lead to changes in the IT landscape are:

Functional Changes

Changes to the functionality of systems are perhaps the most common driver for IT change. Functional changes range from minor modifications to existing systems, to development of new systems. When changes are undertaken with a tactical viewpoint as opposed to a strategic viewpoint, the result ranges from hard-to-manage applications to a fragmented landscape, which exists to serve only point requirements.

At an application level, tactical changes come from small, short-term changes to add functionality in an ad-hoc fashion. Eventually, this leads to an unmanageable application or to a duplication of functionality across applications. To mitigate this, it is important to first define what the application is expected to do, and stick to that definition. An application that does one thing well is always better than one that does multiple things badly. Also think in terms of granular functionality as opposed to making a specific change. This will help drive service orientation in the long run.

At a landscape level, tactical changes come from quick-fix applications that eventually stick around longer than they were supposed to. To mitigate the risk of such changes, it is essential to think long-term in the context of the business itself. Most businesses will have a roadmap for at least three to five years if not more, and it is important to align changes to this roadmap so that the IT and business roadmaps are in synergy. The landscape is then driven by this synergized roadmap, and be business-agile.


Consolidation in a business can occur either as a result of a drive to merge divisions together, or a merger or acquisition. When divisions or companies have their own landscapes, as is mostly the case, there is also a duplication of systems. When a consolidation of such landscapes takes place, there is a propensity to retain these systems. This, however, leads to higher maintenance and a potentially fragile and unpredictable integration between systems.

To address this risk, a consolidation must begin with an inventory of systems and their functionality. Where duplication is found, one system of record needs to be identified for such duplicate functionality, and other systems must then be transitioned to use this system instead. Service orientation is an excellent paradigm to be considered when looking at such a scenario. Building business-oriented, coarse-grained service interfaces and choosing the systems that implement these interfaces ensures that the applications that need the service are not tied to the implementing applications, but to the functionality instead.