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.

Gaining compliance is the key. Unless they're complied with, architectures are a waste of time. 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: communicating and training.

The key to success in communication is to stress the benefits in terms that are free of technospeak. Think business benefits. If necessary, go back to the principles that formed the basis for the architectural design in the first place.

At the Australian Bureau of Statistics, posters have been used to great effect in getting management buy-in to the architecture. As CIO Jonathan Palmer shared with us, they have also forced many of the IT people to describe things in a way that is meaningful to the business.

Westpac provides a good example of communication through training. CIO Mary Anne Maxwell says: "We arranged architecture overview training sessions for the IT staff. Groups of up to 20 at a time attended a series of sessions lasting up to a couple of hours to gain familiarisation with the principles and benefits. Pretty well all of the 1200 IT staff have been through the process. Each session was introduced by one of my head reports and we trained half a dozen of the senior staff from the architecture group to deliver the course material."

Although compliance is the aim, there are bound to be instances where exceptions are justified. At Lloyd's Register, group IT director Stephen Hand believes in some flexibility. "Where there's high volatility in both business and technology, complying with the architecture can sometimes be a dis-benefit," he says.

The process for dealing with exceptions must be very transparent. The business case for the exception should be the first consideration. That said, the architecture committees should generally be stricter with foundation architectures than with business-domain architectures.

Implementing IT architecture is a process not an event. 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 begs the question of how you measure the benefits in the first place.

A good example of architectural value comes from Barnardo's, a UK charity. With a staff of 145, IT is organised as a central service supported by regional teams. The architectural policy is one of strict standardisation. IT runs at less than 60 per cent of the norms for equivalent distributed computing arrangements in local governments. But Barnardo's is not content with that number. The organisation has set itself the challenge of reducing IT costs yet further: down by 17 per cent in the next two years, "with no deterioration in service".

Left unchanged, the benefits of any IT architecture will deteriorate over time; but settling on an update frequency is tricky. Too frequent adjustments erode the advantages of standardisation. Too infrequent adjustments mean locking the business in electronic concrete.

The frequency of new releases should strike a balance between these two extremes. Every year or two is usually appropriate (rising incidents of sway is a good indicator of the need for an update). Every architecture is eventually superseded, usually when re-platforming takes place after 10 to 15 years, with the cycle starting again.

My favourite example of architectural guidelines that lead to buying choices comes from JP 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 and sell" to categorise every technology in the organisation. Now there is a lexicon that the business really understands!

Dr Marianne Broadbent is group vice president and global head of research for Gartner's Executive Programs