Architecture Introduction

What is Architecture (and what is design)?

There are many views concerning what architecture is - basically they fall into:

Architecture as high-level design
Architecture as the design of the difficult/significant aspects
Architecture as a road-map of change
Architecture as a definition of the external appearance (not the implementation)
Architecture as standards
Architecture as technology policy
Architecture as the project feasibility (design & costing) service

However in the context of this site architecture covers the following:

The definition of the required scope and behaviour (including interfaces) of systems
The way that systems cope with change (or technology and requirements)
The way systems are used, deployed and supported by users.

This will be within the context of business systems and also with special consideration to open-source projects. So some of the ideas we will discuss may be relevant for the support of other types of open-source project.

By design I mean the details concerning an implementation, even if it is high-level or hard - it takes time and lots of resources. Implementing projects must be responsible for design and it is not the focus of this site (although I am keen to help any implementation project).

When generating architecture we will explore architectural methods and approaches; and provide templates and advice that may be useful in other areas.

Metaphors

The term architect when used in the IT field clearly borrows on a view of the role and duties of a real architect (who designs buildings and more). It is not surprising therefore that when people try and define the responsibilities of an IT architect they also look for parallels in real architecture. More than that even when considering the approach to doing IT architecture they look at the approach used by real architects.

IT systems are not buildings - and therefore (at the very least) a very clear view is needed of the differences and similarities of these different domains.

Similarities

The architect is responsible for the essential solution tailored for the client.
An architect needs to have knowledge (or appreciation) of a range of quite different disciplines and needs to work with specialists in these areas to bring together an overall solution. These disciplines on one hand are structural engineering, electronics, plumbing, build techniques etc.; and one the other hand software development, networking, infrastructure, data design etc.
The architect needs to persuade and understand a client - and communicate, persuade and cajole colleagues, sub-contractors, managers.
An architect needs to do upfront design work - but also is on hand to be consulted during the project.
The architect could be, but usually is not the project manager - and certainly not if the project is significant.

As I produced this list (and I am sure more bullets could be written) I think a pattern develops, the similarities seem to be about personal role and possibly personality profile. What does not seem to be in this list is anything about technology or professional techniques (no doubt common techniques are used for successful persuasion, these again are personality skills).

Differences

Real Architects are concerned with aesthetics. Although Apple has shown that aesthetics is important to computer interfaces, in terms of IT Architecture aesthetics is not an important consideration to the client (possibly it is to the IT professional). A cost cutting shortcut is often seen as ugly to an IT professional even where other engineering disciplines would perhaps consider it inspired. Possibly the equivalent IT concept might be consistency, or simplicity - but that is not an aim in itself rather it is a means, for example to provide simpler/cheaper build or maintenance. In real architecture aesthetics is usually the primary aim - and achievement in this area differentiates the great from the merely competent. And aesthetics can be provided by highly complex and contrasting designs.
Real Architects have a professional body, training and have a financial responsibility in the quality of work; they are required to have professional indemnity insurance. In IT everyone can have the title of architect and it means many different things. In most cases IT architects have little personal risk if there ideas do not succeed (this risk is often left to IT project managers). As a result, IT architects have a much more difficult time with enforcement compared to real architects - in a building project sub-contractors would hardly ever question a design except for clarification (and in case of blunders).
Buildings are rarely designed with future flexibility or change in mind - today this is a major consideration for most IT projects.
The level of risk associated with technology and requirements complexity is a major issue in IT, but is rarely an issue in real architecture.
Because of the high cost of rework, the nature of the build process and the need to meet planning regulations no significant building project can start until several architects drawing have been produced. In IT however efficient development tools allow software coding to start with no upfront design work. Indeed this is considered good practice by some.
In the physical work materials decay over time and in real architecture this is a major issue in determining the life expectancy of a building. Material failures are typically very expensive to rectify, where rebuilding is not feasible complex techniques are used to explore the scope of decay and the problem leading to lengthy remedial work. Software does not decay, and although IT infrastructure does age its replacement is typically not problematic (see the next bullet however concerning technology redundancy).
In IT, systems become redundant relatively quickly, either because of technology advancement or because the requirements have changes over time to become radically different. In the physical world building techniques have changed dramatically over the years as have aesthetic styles. However a building built using bricks compared to pour-in-place concrete is still just as useful and old designs still have a place next to new styles. Buildings are knocked down to make room for new buildings, but this is exceptional not the rule - most buildings are expected to last as long (if not longer) as its materials.

Reviewing these differences highlight a trend, IT systems and physical buildings are quite different and not just in the obvious sense (one being made mostly of bricks, the other mostly of logic); for example they are also different in behaviour over time.

An important exception to this trend concerns the professionalism of and risk taken by real architects compared to IT architects. This is important because I believe that this must change if IT Architects (as a body) are going to fully play an equivalent responsible role as that achieved by Architects.

Judging Metaphors

This analysis gives us a way of judging metaphors from the world of real architecture.

We certainly can learn lessons about the general role and place of an IT Architect within a project or an organisation. It also however highlights a relative weakness in IT Architecture - because the term is used so lightly and because IT Architects generally are not personally responsible for the success of their ideas and designs then IT Architects will not have the same status in IT as real Architects have in their field.

However the technical problems and aims are quite different and therefore there is no reason to believe that a technique or practice used in real architecture has any relevance in IT - and these metaphors should be treated with scepticism.

Common Examples

IT Architecture like a City Planner. It now seems to me highly unlikely that the problems faced by an IT Enterprise Architect are remotely those faced by a city planner. Often this justifies a high-level "power-point" view of IT architecture, but in real architecture (and, I think, in city planning) details are important and are specified by the architect.
IT Architect on a building site. Actually this metaphor seems quite strong where used to explain the role of an architect during project implementation - clarifying the design and addressing "blunders" in the design. However on a building site design is rarely done in parallel with the implementation and this is rather common in IT. Of course the metaphor does not address the role of an architect outside project implementation. Does this metaphor describe a Technical Authority? I'm not sure.
Architects drawings. In a different section I discuss the Zachman Framework. My view is that in building documentation is needed for the build, in IT they are needed for maintenance and this seems important consideration.

Conclusion

Real World

Real Architecture is about producing a beautiful building (or park etc.) and meeting client requirements. The architect is responsible for producing a design to enough detail so that many sub-contractors can work together to realise the building. These designs are needed to cost the project and to get regulatory permission for the project. During the implementation the architect clarifies the design and fixes design problems (which may be blunders or may be relatively minor omissions in detail). After a project is completed an architect will have little to do with the maintenance of the building - and the drawings and documents produced for the build are more than sufficient when planning significant changes to the building.

IT Systems

IT Architecture is about producing a system which will be useful for a long time meeting the client's current requirements and changes to those requirements. An Architect is responsible for defining the scope of a system, its technologies and structure. The architects work may be used to "sell" the project to the client and to estimate costs but is not generally needed for regulatory permission. Detailed design work can be done by the developers etc. During the project the architect attempts to enforce the structure and technology specified as well as scope.

A significant responsibility of an architect is to ensure that documentation exists to maintain the system, this to ensure that this system has a long useful life. However the difficulty is that the documentation produced just to start/form and then implement the project is not generally sufficient for post project system maintenance.

The duties of an IT Architect

In defining what an IT architects duties there are a number of considerations.

Resource availability. An IT Architect could be (I believe should be) a senior experienced IT professional who could develop code, set-up infrastructure, analyse business requirements, project manage, train users and man a help desk. All these are full jobs in their own right. In a small company you might have an IT department of one person and he would rightly argue that his duties included all those on my list plus some - and that he was also the IT Architect. But one man is not going to deliver significant IT capability. As soon as you needs grow then your IT team must grow and people specialise. So in defining what an IT Architects duties are you must also exclude duties otherwise you just gave a person who does everything which is unlikely to be optimal.
The analysis done in the "Metaphors" section exploring the role of IT Architecture different to physical-world architecture. In short that IT Architecture is about producing an IT which will be useful for a long time meeting the client's current requirements and changes to those requirements and technology changes.
The way IT skills are generally organised (software development, project management, infrastructure, data etc.). Using the role metaphor of IT Architects being similar to physical-world architects; IT Architects have a responsibility of bringing these areas together to provide solutions.

I believe that responsibilities of IT Architects can be defined as:

Producing an overall framework design that shows how different IT components (physical, software etc.) and skills are used to provide end-to-end solutions.
- The framework should facilitate future change of requirements and technology. I.e. the cost to deal with this change should be minimised or contained.
- The framework should include details of the business aims and model being supported (and how) so that the impact of business change can be managed.
- The framework should include details about technology assumptions being made so that technology developments (which change these assumptions) can be managed.
- The framework should include details about the way systems are used deployed and supported.
- The architect should enforce and therefore take personal responsibility as to the frameworks adequacy.
Defining design details where required especially between boundaries (e.g. interface definitions, project (i.e. within a programme) scope descriptions, software component / host mappings etc) to enable implementation to scale.
To provide end-to-end solutions (within the context of the framework) to meet specific client requests. This should include technical details about development, infrastructure and the use of COTS products.
To produce (or have produced) adequate documentation of what was implemented to enable ongoing maintenance.
Not to get bogged down in implementation details that could be [better] done by point resources. Again this is to enable implementation to scale.

Implicit in this are the required responsibilities of any senior members of a team, including accountability, communication and persuasion.