This blog quickly runs though some basics on architecture principles & how I use them.
The company I work for, has a specific set of architecture principles. Within our hybrid Infra team, we limited it to 5 principles so it would be easy for all architects to memorise and learn them. Whenever someone comes to me with a design idea, or an architecture to review, or even an architecture concern the first thing I do is in the back of my head, think about architecture principles. Principles are in the motivation layer of an ArchiMate model.
I tend to think of a principle in architecture as being the same as a principle in the real world – its a rule that we strive towards achieving. The ArchiMate manual defines it as a statement of intent or general property that applies to any system in a context.
An example principle
I will use a simple example principle. Lets say our architecture board established a principle “Systems must be available 99.9999% of the time”
When we define a principle, it should be a simple statement like above, but normally there is a need to document further the exact meaning and scope of a principle, as well as its issuing authority.
If it was a principle applied to our unit, or is in scope, in our design documentation we would state it – and we could connect it to a set of requirements like this for example:
We might decide that we will not be able to achieve a principle. having a high resilience is often expensive, and we may have a requirement to keep costs low, or to implement interim solutions quickly. The important thing is we:
- identified the principle
- identified how we meet it
- if we cannot meet it,we identify that we cannot meet it
- We flag principles we cannot meet
- We have it agreed with the relevant stakeholder that it is OK to go against the stated principle.
Establishing new requirements
When I drew the view above for the fictional web hosting solution I have sometimes developed in my blogs, i quickly came to thinking of many requirements. I used “…” to represent them above for brevity, but this is another important part of working with principles. Automatically when I started to think about the principle I started to ask myself the question “What do i need to do to achieve it?”.. Suddenly, I started to think about the IT Architecture Aspects and think, I would need to consider people and resourcing, to have resilient processes in place, and so on. Many requirements started to come to mind that I might capture. I may also identify risks when we cannot meet principles.
Had this been a real project i would be validating the principles against the requirements, and I may even define new requirements to meet the needs of the specific principles. I would of course also make sure that in addressing the principles all relevant stakeholders and actors stakeholders were considered.
Of course we do not have to do all our work in ArchiMate, but its a good flexible approach.
Principles have owners. If a leadership team sets a principle, then I would normally say that that leadership team (or someone they nominate) needs to approve any deviation from that principles
Summing it up
Many times I have worked with architectures and stopped work happening early. because I know our principles by heart, and can state that doing something would be a risk and go against our defined business needs.
Principles are a very good way of representing the intent of an organization, unit or specific stakeholders. They can ensure that all the work architects do head in a commonly defined direction.