IT Architecture – is it just an Illusion?

IT Architecture

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 www.togaf.info), 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

graph-itc-blog

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.

graph-2-itc-blog

Summary:

IT Architecture Definition

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.

Share
Facebook
Twitter
LinkedIn
Email
Mark Smalley

Mark Smalley

Mark Smalley is a writer, speaker, trainer, consultant and bridge builder at Smalley.IT. Also known as The IT Paradigmologist. He helps people discover where they are and to visualize where they want to be. His main area of interest is the management of IT systems and services. Mark is a contributor to bodies of knowledge such as ASL, BiSL, BRM, COBIT, DevOps, IT4IT, ITIL, VeriSM and XLA. He has spoken at hundreds of events in more than thirty countries.