Architecture Principles

In modern IT I think architecture principles are sometimes misused. You sometimes get the two opposite ends of a spectrum. At one side you have organisations where a lot of effort is put into creating principles but then they are overly complicated, are hidden away in an architecture vault so no one knows they exist and they are not used. The other extreme is where the organisation doesnt have any principles at all.

With this in mind I think its important to understand why principles have a value and where they should be used.

What are principles and why do we want them?

Principles are a list of positioning statements in relation to key questions which will relate to your architecture. If you imagine that we are doing a kids colouring book where the drawings are already in the book and the kid will colour in the picture. The aim is to colour within the lines.

These principles are our architecture lines. They should be used to help guide our decision making to make sure we are colouring within the lines and therefore in a good safe place for the organisation. Sometimes we may need to colour outside of the lines but again our principles can be used to help us understand where we are doing this, why we are doing it and to manage the situation. It may be the case if we colour outside of the lines more than once we need to modify our principles to keep up to date with the changing needs of the organisation.

We should expect that some of our principles will be very static and hardly ever change where as others may change significantly over time.

At their heart though our principles help guide the decision making we will make in IT and ensure we dont make it up as we go along.

What should a principle look like?

A principle should be documented in the following way:

• ID - Each principle should have an ID to make them easily referencable
• Name - The name should be clear, not ambiguous and clear
• Statement - Each principle should have a statement which communicates the meaning of the principle
• Rationale - The rationale should highlight the benefits of the principle. The rationale should also indicate relationships to other principles and indicate conflicts between these principles
• Implications - The implication should hightlight the consequences of adopting the principle in terms of things like costs, resources, etc

Most organisations will find it useful to group their principles into categories of things like:

• General
• Business Principles
• Information & Data Principles
• Application of Technology Principles
• Technology Principles

There is no steadfast rule as to how many principles you should have but obviously the more you have then the more rules you have to play by and the more work is involved in maintaining them.

How should I use them?

The aim of the principles is to guide your actions and decision making in IT to help you be successful.

A large portion of the Integration Playbook is about trying to decide where to use which technology. Because of these kinds of decisions it is a good idea to make sure you have some principles to back up the decision. I always like to think that if I make a decision and document how we got to the decision and what our justification was, then if it is related back to principles then as architects we can look ourselves in the mirror and be sure we made a sensible decision. It may turn out that the decision was right or wrong in the future but when we look back we can be sure that based on the information we had available and the principles we had to guide us then we made what was the sensible decision at the time.

If we get it wrong then one thing we can do is look at our principles and review if the business or environment has changed and if the principles need updating.

Examples of principles

In the playbook I am not going to list out all of the principles you may use because these typically vary a bit by organisation, but a number of companies have published their principles online in the public domain so below is a couple of examples of EA principles.

• University of Birmingham

• 101 Principles of Enterprise Architecture

• Highways England Enterprise Architecture Principles

• Infosys Digital Architecture Principles

Examples of using Principles to Guide a decision

Lets imagine we are considering a new project and its our first attempt to use the cloud. Lets say that we need to implement an API which will be exposed to a partner.

In this scenario there are loads of potential principles which could come into play but lets pretend to simplify things we are focusing on the compute and hosting of the API. The company could have choices about hosting the API on Virtual Machines, Azure Functions, Logic Apps, Web Apps, Containers. Should they use API Management and a bunch of other things to think about.

The architects should be thinking about how their principles may need to change to support this and future scenarios. If its their first journey to cloud then they may not already have principles to help. Probably the first and most important one would be their preferred hosting options. The company needs a principle or more which will guide their hosting decisions. It could be that they have an explicit hosting principle or they could use ones around ease of use, maintainability and maintence choices and others. When it boils down to it though they need a principle which will guide their preference for Serverless vs PaaS vs IaaS vs host on premise.

The mistake here would be for every project to do whatever it fancies. The aim of architecture is to create repeatable approaches that create well known paths through the IT maze and if we create principles and prove them with success on this project then the next project with similar requirements should be to leverage these principles to help them be successful.

Important Principles for Modern Integration

As a minimum I think all organisations need to think about their position on some of the below principles. Having a standard view on these will help you have a consisten approach to architecture across your projects and that would be a reasonable first step forwards in maturity for modern integration solutions.

• API First Approach
• DevOps for Agility
• Cloud First vs Hybrid vs On Premise
• Reuse vs Build vs Buy
• Buy vs Rent
• Low Coupling Interfaces
• Adaptability and Flexibility
• Interoperability
• Coherence
• Data Security
• Data Accessibility
• Iaas vs PaaS vs SaaS vs Serverless vs Physical
• Citizen Developer vs Specialists