IT architectures are enjoying a renaissance. The reason? They promise benefits that are more sought after than ever. But they are not always easy to explain to your non-IT colleagues.
An IT architecture is a set of technical guidelines and standards to guide the enterprise in satisfying business needs. It comprises sets of policies, rules, guidelines and standards that guide the technical choices organizations make. These choices help implement business strategies with an eye to the future.
At their most granular level IT architectures identify preferred technologies and vendors, templates, tools and methods, and standards for, say, applications and interfaces.
Think city planning regulations when you think IT architecture. These are guidelines that establish what can and can’t be done; they act as brakes on the size, shape and position of such things as roads, walkways, buildings, lighting and water systems.
IT architectures are easy to get wrong. Benefits are difficult to isolate and costs have a habit of spiraling. They sacrifice local autonomy in favour of overall synergy, so they frequently give rise to political tension.
Four Different Strategies
IT architectures can be grouped into four strategies according to their features and benefits. Bruce Rogow of Differentis refers to these as architectures that consolidate, connect, innovate or re-platform.
Consolidate architectures emphasize IT cost reduction and systems simplification. They use a range of building blocks (business process, re-usable modules or software components).
Connect architectures emphasize interconnecting across an enterprise and even between enterprises. They identify standard interfaces and middleware.
Innovate architectures emphasize adaptability. One purpose is to support experimentation by the business to create new business products and processes.
Re-platform architectures take advantage of technology advances. They replace existing platforms, development methods and mind-sets (the host at the centre versus the personal device at the centre).
Stay, Sway or Keep Away
Once deployed, you might expect the IT architecture to be mandatory. Not so. There are times when compliance should be obligatory: a stay. But there are also times when compliance can and should be optional: a sway. And there are other times when it shouldn’t apply at all: it’s best to keep away.
You need to segregate common services such as email and security into the one enterprise-wide foundation architecture. Then design top-down according to business needs. Finally, develop the technical design, and document the architecture with ease-of-access and maintenance as primary considerations.
Because IT architectures constrain what people can do, they are bound to cause tensions from time to time. So architectures need to be backed by adequate authority. IS alone lacks the necessary leverage, so authority should be vested in an Architecture Committee that includes both IS and business colleagues.
Design is best carried out by specialist architects, although it’s ultimately the responsibility of the Architecture Committee. Bringing them together either physically or virtually in a team (commonly called a Design Authority, reporting to the CIO) is an arrangement that usually works well.
Compliance Is The Key
Architectures are a waste of time unless they’re complied with at the appropriate level. The first step in gaining compliance is to get enthusiastic support for the concept from the people who are affected. That depends on doing two things well: communication and training.
Although compliance is the aim, there are bound to be instances where exceptions are justified. The process for dealing with exceptions must be very transparent.
Designing and deploying an IT architecture is not a one-off exercise; it’s a continuing process. Fail to update your architecture and soon the benefits will begin to erode. That raises the question of how you measure the benefits in the first place.
A good example of architectural value comes from Barnardo’s, a U.K. charity. With a staff of 145, IT is organized as a central service supported by regional teams. The architectural policy is one of strict standardization. IT runs at less than 60 percent of the cost norms for equivalent distributed computing arrangements in local governments. “But our challenge is to reduce IT costs yet further – down by 17 percent in the next two years, with no deterioration in service.”
My favourite example of architectural guidelines that lead to buying choices comes from J.P. Morgan Chase, the giant financial services firm, headquartered in New York City. Following a major architectural and product review, JPMC now uses the terms ‘Buy, Hold, Sell’ to categorize every technology in the organization. Now those are terms that their business really understands!
Dr. Marianne Broadbent is Group Vice President and Global Head of Research for Gartner’s Executive Programs.
