IT Architecture in a disjointed world

By Pete Buffham

Date 1 January 2010 Tags

Is designing a successful IT architecture really a black art?
Or is the problem in building one and sticking to it?

Most CIOs seem to think they need one, and many people in the business would accept the need for one, if they had it explained to them what their purpose was, but why do so many firms have the difficulty they do?

CIOs employ people called Architects and perhaps letting them drive “the Architecture Process” doesn’t sound a bad idea, but what are the likely consequences if they do? The CIO has to consider not only the technology (the applications and infrastructure) but also business imperatives and the nature of the information required, and understanding all of this can be hard enough, if not impossible (see: Where’s Einstein when you need him). The aim isn’t perfection, but good enough, but it’s easy to spend lots of money getting into a blind alley.

What hinders success, and how can the barriers be removed? Building to an architecture looks very attractive, but where do you start without a green field?

Who should drive?

A pure technology perspective will focus on cost, improving operability and ease of maintenance, achieving more standardisation and simplification. At the same time the temptation to build silos – because they are simpler and quicker – may be hard to resist. Decisions on hosting and support may also take place within a vacuum. This may lead to, or reinforce, bad data management made worse by a paucity of enterprise data; legacy systems become hard and expensive to change, perhaps impeding compliance or the ability to respond to major external events (mergers and acquisitions for example). A technological view of the world may not include what’s keeping the business awake at night.

A purely business perspective is likely to stumble across equally difficult and intransigent barriers (with politics often the biggest). Others include an inability to communicate exactly what it wants, or to recognise the consequences of actually getting it; an inability to realise what is technologically possible at what cost and effort (time) – this is not always an underestimation by the way; a failure to realise how individual initiatives may impede others which in turn means inadequate sponsorship

Not surprisingly, a “pure” view is actually a blinkered one, and a bad basis for getting to practical, useful answers. So “driving” can’t mean control; it means creating the conditions in which the organisation as a whole can come to the right answers.


The CIO has to ensure that the appropriate people from the business are involved in architecture work, and that they are helped to understand what the real options are. The consequences of the architectural decisions need to be spelled out, in terms of cost, and functional opportunities foregone. Ensure that the consequences of the decisions are understood as far up the business as needed, and that they are formally accepted.

Underlying the technical architecture there needs to be a rich picture of the key processes within the business – in particular those which carry most cost, or are most visible to the customer. The neighbouring architectures of partners may also need to be involved, ensuring that the linkages across the operating model are understood, in advance of making technology or other architecturally relevant decisions.

Designing and instituting an IT architecture is as much a business programme as any other; it needs communication and governance too, and will typically require a process to straddle both IT and the business.


The “right architecture” is one that makes acceptable trade-offs, understood by both the demand and supply sides. Generic benefits of building to an architecture are well understood; they involve simplification and standardisation, leading to low-cost, high-quality, agile support, but these things have to be fleshed out with the art of the possible, as well as within financial constraints. Trade-offs cannot be made without understanding both cost and quality, both effort and value, and cannot realistically be made by IT or the business working on their own

An architecture will never be perfect but it has to work, and it has to avoid sinking under its own weight. Failed architecture efforts we have seen have often been more purist for their own – or the business’s – good.

« Back to blog
Subscribe to our RSS feed.
©2018 Differentis   Sitemap Privacy Policy Terms of Use Website by zoomedia