Just Enough Architecture

How much architecture is just enough? Is a common question I get which I will try to address in this blog.

Determining the right level of architecture design can be challenging; its very easy to get caught in a loop of over engineering for some people, and hard to know where expectations start and end for others. So what is the right level?

The High Level Design

The high level design template I created for work runs to 42 pages. Its an extremely long document that was built out of necessity. It has a lot of helping text and example views. It attempts to do a couple of things:

  • Provide a document structure that is ISO42010 compliant
  • Provide a document structure that provides Business, Data, Application, Technology Descriptions, and can be aligned to TOGAF
  • Provide extra spaces for common integrations and considerations we have within our own organization.

It aims to be usable by architects of very different levels of experience. When new architects look at it – it can be scary. Even though I wrote it, I really do not like it. I have discussed my thoughts on documenting architecture in document templates in the past, and I would much rather focus on the views we need to see to address the concerns of the stakeholders than trying to crank something into a rigid template.

Architecture View Points

I previously showed in this blog this diagram of the different types of viewpoints I like to consider as a minimum in a design, and my HLD template covers these, however there are times this can be considered overkill.

HLD Viewpoints
Viewpoint Structures

We determine standard viewpoints in architecture to make sure the concerns of our stakeholders are addressed and communicated. For architecture to make sense, it has to provide value. There are cases where it may not make sense to create all the views shown above.

An Example – Transforming On Premise Services to the Cloud

For example, lets say we have a team that’s been supporting on premise versions of Exchange & SharePoint, and we are creating an architecture as part of a proposition to extend the scope of services they provide to include Office 365 cloud based solutions.

If we are going to consume office 365 as a cloud service it may not make sense to create technology views, given that the technology layer is by Microsoft. It doesn’t provide value to anyone for me to rehash Microsoft’s standard material in ArchiMate.

In the same way, if we are going to be reusing an existing team, with existing processes, it doesn’t make sense to redefine all the processes – we simply do the definition for the things we need to specifically provide. If creating a specific view doesn’t make sense, there’s probably no need to create it. There are cases when its not obvious to your audience why a view doesn’t make sense – and you can document that.

If it doesn’t make sense to do a technology view, you may want to mention the reasons why in the service realization view for example. Sometimes if you just miss something, it will lead to an unnecessary volley of questions that could have been avoided if you had just written a sentence.

We are telling stories

We are trying to tell a story to our stakeholders, and explain an often complex set of elements and their connections. We are also trying to address stakeholder concerns and provide consistent easy to understand architectures. We should structure information in a way that is easy to consume. Sometimes that means changing the way a standard template is, or building custom views to clearly indicate our subject to our stakeholders. I spoke about telling stories in a previous blog on Improving ArchiMate Modelling Quality.

Documenting what we need to

Last week I was designing a solution based on Microsoft Sentinel in Azure. The challenge here is in the way that solutions are built – I could go into great detail about how data sources connect into the analytics engine, how rules are created and processed, and how they trigger playbooks. This is all detailed at some length in various places in Microsoft, and to define everything doesn’t make much sense.

But I did have to define a basic skeleton of azure architecture at an application level, because without it, it wouldn’t be possible to understand my architecture at all in a connected way without experience on Sentinel – which I cannot assume my audience has.

Not missing the essentials

There are some things you always need for an architecture design to be complete – and forgive me if you have heard this before:

An architecture should define and show how it meets the concerns (or requirements) of different stakeholders, and identify and manage related risks.

Without that an architecture is not complete, and will raise problems and there will be consequences in the future. The same thing is true if you do not design to meet the needs of all your stakeholders.

I speak often about things such as the architecture aspects, and architecture principles, and security non functional requirements – the point of these things is always the same – to ensure that we have captured the needs of our stakeholders.

Summing it up

Anyone who focuses on just creating a document is missing the point of architecture practice – its not providing its full value if its only a documentation exercise – its the process of creating a design that mitigates risks and meets requirements that is really providing the benefit – documenting is a natural part of that process, but at the end of the day, personally I do not care how big an architecture is, as long as it provides value to its identified stakeholders. I previously wrote a blog 8 reasons not to leave architecture to the end of a project – which could have also been titled 8 reasons not to think of architecture as a documentation exercise. Architects need to understand our standards, and be able to maintain a balance between what is too much and what is too little. Above all, architects must think.

Stakeholders in Architecture

Architects have many stakeholders in different areas. Even if we need to be customer focused there are still other stakeholder requirements to consider, This blog shows some of the stakeholders I typically consider.

In ArchiMate terms a stakeholder is a person or some group of people who are interested in the outcome of an architecture. They are the people we provide value to. Stakeholders are part of the motivational layer because we normally talk about stakeholders in the context of motivation. This doesn’t mean to say that an actor cannot be a stakeholder. Sometimes I may model a stakeholder in a motivational model and have an actor of the same name. .

When I say we need to consider our stakeholders, for me, this normally means some kind of interaction with them. Considering their needs as an architect is good, but you get more value if you actually ask the stakeholders what they would like to see. We can engage with stakeholders in many ways; the exact technique that’s best often depends on the number of stakeholders we have. You may consider an end user to be a stakeholder, but in an organization with 1000+ end users its not feasible to talk to each one individually – you may introduce surveys, or find team leads that are representative of such a wide audience. Business internal active structure elements can be assigned to the stakeholder element.

Lets look at some of the stakeholders I typically like to see considered in large projects.


Architects shouldn’t work in complete isolation – if an many architects are working on the same solution which sometimes happens in big bids they should be actively communicating with each other and a lead architect who ensures things are kept together with each other. Different teams may have their own architects; they are often stakeholders in each others architecture. For example, In a larger organization a product may require usage of other products. To provide a web solution we may need a database at the back-end, which could be supplied by another team. If I was creating the full web solution i may have requirements towards the architects in the SQL team and they may have limitations on their standard service. Deviations from standard need to be supported by someone and if I am expecting the SQL team to support something non standard i need to specify what and get an agreement. We provide value to SQL team because we use their service and they provide us value for the same reason.

The Customer

When I ask anyone defining an architecture, they are usually considering the defined needs of the customer. If responding to a request for proposal then its normally fairly easy because requirements are usually fairly clearly stated. Quite often I have seen customer requirements being the only requirements considered when responding to bids, which is bad, as other requirements can impact things.

The Customer Business Owners / Buyers

In product design I don’t think of the customer as a single role – there are several; there’s a need to consider the end users, but also the needs of the team that are buying your product – the business owners. Normally a business unit considering buying a product has to justify an expenditure to their organization. You can facilitate that for example buy having requirements around reporting. Not just delivering standard reports from applications but thinking about your value proposition and how to support it. A simple way of doing that for example, may be showing usage over time in a report, or building something custom so that a customer buying your service can show their management what a good investment is. If your customer wins with their manager, everyone wins.

Your Sales Team

To facilitate a need to sell things a design should consider the needs of your sales team. Sales becomes a much easier proposition if you have solid numbers. Look at how companies like Microsoft do it – when they make a statement like “Azure has shown a 200% growth in the last year” people pay attention. When you have those kinds of metrics and hard data points, products almost sell themselves. To make this happen however somehow that information needs to be captured and tracked. potentially part of an architecture design should cover how this happens so it can be completely automated. This can have a significant impact.

The Operations Team

In a modern organization considering the needs of the operations team in its design can save huge operations costs and radically reduce the number of incidents and escalations. Often, A solution needs to be automated as far as is possible – which includes having needs around monitoring, or even AI Ops. These days we can go a long way towards automating and managing incidents and problems. To have operational efficiency there should be standardized usage of tooling wherever possible, and standardized processes.

In some organizations operations teams try to manage this themselves but the needs of tooling and operations should impact into the overall design of any architecture you are planning to run in continuous services

The Security, Quality, & Risk Teams

Most organizations have requirements around ISO standards such as ISO20k or ISO27k for example. When there are several sets of requirements around risk and security often organizations have their own security non-functional requirements. A common mistake here is to think that because an organization has an ISO certification that any architecture that’s produced is compliant because the standard processes are.

If a company has promised compliance to an international standard steps need to be taken to ensure they are taken care of. In addition to that, companies have their own goals and risks, and to mitigate them they often have security related requirements.

Your Business Team

Product managers need to make profitable products that are attractive – they have goals, and to meet those goals they have targets normally around profitability, or sometimes around operational goals, or budget constraints.

Its easy to miss – everyone assumes there will be cost efficiency because everyone knows we need to make profit – but when you have it as a requirements, and you manage cost efficiency as a requirement – you show how cost optimization happens and it forces you to ask questions which may yield positive results.

Summing it up

The reason i felt a need to write this blog was that I hear a lot about being customer centric in different organizations and focusing on providing top quality services to customers and end users. This i agree with, but i would argue that unless you consider all the stakeholders when designing solutions, you are not achieving that objective. If you build architecture only considering customer requirements, it is much like building a house on quicksand. It could be the best house in the world, but without solid foundations it will crumble.