Before we head off into definitions and categorization, lets just ask the question of all questions..."Why does anyone need an IT Architecture?"

Luckily the answer is simple: you need to invest into abstract descriptions of your system because certain qualities do not just arise when you put one functional component next to the other. Architecture tries to achieve sustainability, dependability, scalability, performance, which are many of the things you do not get right the first time you design a system!

Definitions:

Who could be qualified to define the term “IT Architecture”? Assuming that architecture is also a governance discipline we can start with the definition of COBIT (4.1):

• Enterprise architecture for IT—Description of the fundamental underlying design of the IT components of the business, the relationships amongst them and the manner in which they support the organisation’s objectives

Then of course we have to look into the definition of TOGAF which we regard as the most prominent of all modern IT architecture development frameworks. TOGAF states Architecture has two meanings depending upon its contextual usage:

• A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
• The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time

Last but not least we would like to cite Zachmann, who may be regarded as the "father" of Enterprise architecture:

• A set of design artefacts, or descriptive representations, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change).

The Zachmann framework defines IT Architecture in terms of its goals, the TOGAF framework defines IT Architecture in terms of its contents. We like both approaches and suggest to combine as follows (in the context of OSA):

A set of design artefacts, that are relevant for describing an object such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change). The design artefact describe the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

Types of IT Architecture

In listening to your IT colleagues you will have noticed that everyone associates something different with the term IT architecture. And because there is no generally accepted taxonomy we will just list the most common terms.

• Probably the most encompassing term is “Enterprise IT Architecture”. When you model an enterprise architecture you would typically start with the business processes then map them to applications and finally map those to (infrastructure) components. Here we consider applications to be the digital representation of the business processes.

• In contrast a “Reference Architecture” is considered something that describes a “to be” state and should reflect accepted best practices.

• A “Solution Architecture” describes a particular solution and can include a technical architecture, a software architecture, an information architecture, you might also find a network architecture and data architecture.

The term “Security Architecture” is introduced in one of the next postings.

If you don’t agree please send us your opinion and we might be able to improve these definitions.

Links:

TOGAF: http://www.opengroup.org/togaf/

Modelling standards: http://www.omg.org/

Zachmann: http://www.zifa.com/