IT Architecture

IT Architecture – is it just an Illusion?

Next Story

Vendor performance management - Part 1

The role of architecture in IT

When you are considering IT Architecture I don’t think that anybody would argue with the statements that:

  • Requirements are the input for design activities that result in a design of an Object
  • Design is the input for construction activities that result in an Object that conforms to Requirements

But where does Architecture fit into the picture? Whereas the artefacts Requirements, Design and Object are clearly demarcated and sequentially interrelated, the relationship between Architecture and these other artefacts is more ambiguous.

To which degree is Architecture influenced by an Object’s Requirements? Where does Architecture stop and Design start? Is there a direct relationship between Architecture and Object or is Architecture translated into Design? These questions have puzzled and fascinated me for quite a while and although I haven’t been able to eliminate the ambiguity, I’ve now arrived an explanation that seem to work for me.

A useful definition

The most useful definition of Architecture that I could find was in the TOGAF 9.1 Management Overview (via, adapted from ANSI/IEEE Standard 1471-2000:

“Architecture is the fundamental organization of something, embodied in:

  • its components
  • their relationships to each other and the environment
  • the principles governing its design and evolution”

In other words, Architecture determines the type of Components that will be used to design (and evolve) something, and how they will be used. For instance: red bricks and oak beams will be used to design a Tudor style house. In this definition, Architecture and Design are separate artefacts.

The definition introduces the concept of Environment, which I interpret as the organizational context. An Architecture has been chosen because it’s effective for a particular organization. The Design of an Object within this Environment is informed by both the Requirements for the specific Object, and the generic Architecture that applies to all Designs in this Environment.

The irreversible part of design

Another helpful statement (I forget the source) is “Architecture is the practically irreversible part of Design”. I equate “practically irreversible” with financially prohibitive. Once a house has been built in Tudor style, that’s that. It would be cheaper to build a new house than to change a Tudor house to Bauhaus style. The ‘trouble’ with this statement is that Architecture seems to be part of Design. Apparently there is an architectural part of Design, and a non-architectural part but I can’t think of a name for the non-architectural part of Design.

This leads me to the following understanding:

  • Architecture is determined by the characteristics of the Environment including reasonably expected long-term Requirements
  • Architecture guides and confines the Design of Objects by determining both which types of Components may be used and how




I expect that my post-modernist friends will deride me for creating such a neat-and-tidy model but I hope that it’s food for thought. Comments most welcome, in particular which of these 4 Venn diagrams about the relationship between Architecture and Design seems right.


The following two tabs change content below.
Mark Smalley, also known as The IT Paradigmologist, thinks, writes and speaks extensively about IT 'paradigms' – in other words our changing perspectives on IT. His current interests are the digital enterprise, IT operating models, value of IT, business-IT relationships, co-creation of value, multidisciplinary collaboration, working with complexity, and as the overarching theme, management of information systems in general. Mark is an IT Management Consultant at Smalley.IT and Ambassador at the ASL BiSL Foundation. Mark has spoken at 100+ events in 20+ countries.