IT Architecture Aspects

Often when we are validating IT Architecture we talk about the need to cover the aspects of architecture. This blog Briefly introduces them, and their usage.

The aspects are:

  • People
  • Information & Governance
  • Processes & Roles
  • Tools & Technology

When do we need to consider the aspects of architecture?

Always. Wether you are looking at a conceptual architecture, a high level design or a low level design we should consider all the aspects, and may make conscious decisions not to include some of them (this should be documented)

If we do not consider them usually we consider a design to be incomplete. In many companies we often talk about tools and technology, but I have often seen the other aspects missed. A technology solution by itself is rarely enough if we havent made plans on how to operate, and govern it.

Lets break it down into pieces:


Our architectures need to show the people involved in an architecture. This includes the stakeholders, and the people who are operating the solution. A design should be showing that the right people, teams or roles are involved. It should be showing who is doing what.

Not doing this risks that we may not be scale-able, or even worse, may not have the capability to operate a technology design.

Information and Governance

A design should show what information runs through a system – and how we govern it, throughout the information life cycle. Information is a valuable resource and it needs to be governed and protected. We need to understand where it is kept, how it is transmitted, and who is performing what kinds of operations on it.

The structure of the information as part of a system as well as where it is kept can have a key part in the success or failure of a system.

Not considering information and governance can have huge consequences. A lot of people consider GDPR as a first consideration because companies can be fined up to 4% of their annual global turnover (or up to 20 million Euros).

Because GDPR has had so much much attention I wanted to specifically mention it here. It is not enough to have an architecture that is compliant. GDPR is concerned primarily with personal information. Theres a lot of information out there that is not relating to personal information that also needs governance.

Processes and Roles

Within our systems we normally have processes – either manual or automated. Processes tell us in a repeatable what who does what, and when they do it. I talk about processes & roles quite often because they are key to being able to build a scalable organization that mitigates risks.

Not having processes and roles normally has a big hit to operational efficiency and scalability. Organisations can work without having them formally defined but it means that inputs and outputs might be varied, and the ability to take a top level view or have business agility is compromised.

Tools & Technology

Tools & Technology

Understanding which software or hardware are being used together, and how they are being used in order to provide the technical solution.

I don’t feel I need to explain this one too much because I think its the area of IT & architecture that people seem to understand the most.

What About The Organization?

Where I work we have added an extra aspect – the organization. Technically you could cover the Organization as part of people, but working in a large IT Service provider across many industries has meant that we specifically want to emphasize the points around organizational structure; knowing we have agreements between teams, and which teams do what…. Internally we call the IT Aspects, the Five Aspects, so people from my organization may be wondering why i only mentioned four.

Summing It Up…

Its normally fairly obvious when we have an architecture design that is not considering all of the architecture aspects. Its quite easy to come up with a list of risks associated with missing each aspect, beyond the basic examples I give.

When I look at an architecture I don’t explicitly look for a section of a document or any written statement acknowledging that the aspects have been considered – that would be too much. I am looking at the architecture as a whole.

I might see Tools & technology realized in a Visio diagram of a platform, combined with an application co-operation view in archimate, or I might see it in a series of archimate views. The important thing is not specifically how the aspects are considered, the important thing is that they are.

If we consider individual viewpoints for a moment, not all aspects are considered in all viewpoints. A technology layer view may consider tools and technology, but by design doesn’t consider people. People are not the focus of a technology view.

If you present an architecture design for review that hasn’t considered all the architecture aspects, then the chances are its not a complete architecture design, and there are going to be risks, costs, or further design needs that will have to be considered in the future.

Considering the architecture aspects is a good way to see missing parts of your design now – if you are not designing things, sure you may end up with something that works, but the chances are it isn’t efficient.