As architects we use architecture models to explain the construction aspect of our (current and future) vision. We use architecture principles to steer and guide decision making in the direction of the future vision. Together these help enterprises to realise their targets and fulfil their purpose.

Focussing on the architecture principles, can we explain something about their working? How does an organisation get to a workable, effective set of principles? Let’s dig in…

What are architecture principles?

According to the TOGAF standard, “architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.” (The Open Group, 2018)

In my own, more generic view and compact description, “architecture principles are a set of cohesive, prescriptive and decision-supporting guidelines for classes of problems”.

Based on my practice, an effective formulation of an architecture principle at least consists of:

• Statement
  A title and description of the principle. It should describe the context, relevant stakeholders and provides the guiding prescription of the preferred intentions.
• Rationale
  An explanation about why this principle exists and should be applied. The arguments given in the rationale should support discussion and relate to the stakeholders and their goals. Different classes of values should be recognisable in these statements.
• Consequences
  A description of the intended consequences. But also, the accepted side-effects. The latter being very helpful in the discussion with stakeholders.
• Exceptions
  A list of situations when, or where it is accepted to deviate from the principle. Exceptions not listed, strengthen the rationale. The description can also be about the procedure on how to get an exception. A short “no possible exceptions” closes a lot of discussion. It is not preferred but can be very effective.
• Relations
  A mature set of architecture principles has a set of basic, high-level principles, and a set of derived, more detailed principles. They refer to each other. Other relations could be to mission and vision statements, goals, or even legal restrictions. These explicit relations can be helpful when interpreting and applying and assist with the evaluation and (re)formulation of the principle.

Example 1

An extensive example is found in the Dutch Governmental Reference Architecture (NORA). They publish a complete list. In this (Dutch language only) wiki you can click around and find out all details if needed.

• ID: NAP06
• Name: Re-use before buy, before build.
• Statement: Assume government-wide reuse of services, or parts thereof, before buying or having them made.
• Rationale: Reusing services or parts thereof is sustainable and cost-efficient, and this also leads to standardisation of services and information facilities. If reuse is not possible, check whether adaptation to the existing is possible. Only then does the alternative of buying something or building (or having it made) come into view.
• Related to goal(s): Sustainable (goal) Innovative (goal) Uniform (goal) Cost efficient (goal)

The name links to a separate page with all the details, 11 implications, detailed implications for each layer. It also includes a version history and RFC status.

Example 2

The website Itarch.info, the guide to practical and pragmatic IT architecture design has a list of the 10 most common principles.

Architecture Principle 1: Reuse before Buy, Buy before Build

This principle guides in first looking at the reuse of existing solutions that are needed when considering new alternatives. When new solutions are needed, consider buying instead of building.

Rationale

• Improves cost efficiency, reduces the total cost of ownership, reduces complexity and reduces time to market
• Reuse is key to achieving rapid deployment of solutions without major development effort and riskPackaged solution’s built in processes are well tested and based on market standards
• But highly customizing packaged solutions leads to high maintenance costs as it is difficult to follow package upgrades and patches once a solution is customized
• Building solutions from 0 requires functional and technical expertise and experience, adds to risk to deployment and in technical performance

Implications

• Look at internal existing solutions within the company before buying
• Architectural components should be centralized and designed for reuse in order to minimize the cost of developing new systems
• Software license agreements and system development contracts should be written to allow for re-useIf a package solution is chosen, avoid high level (more than 30% of package) of customization

 Example 3

NHS digital, supporting the UK health service, has the same popular principle.

Reuse before buy/build

Digital services should demonstrate that they have sought to reuse existing solutions before delivering new ones.
Where it is not possible to reuse an existing solution, off-the-shelf (commercial or open source) products should be considered. For open source products there should be an appropriate level of contractual support provided.
Only having ruled out the former two options should a new solution be built, either in-house or through third parties.

Rationale Reusing existing solutions will:

• reduce cost and time to market
• promote sustainability
• reduce carbon footprint

Implication Services should:

• conform with the approved Technologies List, owned and managed by AIDA
• use platforms
• have their business case evaluated by technical and enterprise architecture
• have their high-level solution architecture and risk log assessed by Architecture Approval Group

Mixing Rationale, implications, and consequences?

When you carefully read the three examples you will see some consequences in the rationale sections. To be honest, I have seen worse examples and have written worse ones too myself.

A rationale is when you are asked to give the reasoning or justification for an action or a choice you make. There is a focus on the ‘why’ in a rationale: why you chose to do something, study or focus on something. It is a set of statements of purpose and significance and often addresses a gap or a need.

In the NORA example there is a clear link to the goals, the other examples seem to have different interpretations of the terms.

An interesting difference in these examples is the use of implications instead of consequences. A nuance in the English language, probably unfamiliar to most non-native speakers (such as the Dutch author of this blog). Meegan (2012) explains:

Implications are what we think of next because of the Interpretations and Inferences we have come to.
. . . These are ideas that come from ideas.

Consequences, on the other hand, have to do with actions, with what happens when we act on Interpretations or Inferences.
. . . actions that come from ideas.

The consensus in the vast amount of literature as found by Borgers and Harmsen (2018), seems to be the use of the word implication. Focussing on what to think of next, potentially what ought to be done.

TOGAF prescribes the use of implications, referring to the requirements for carrying out the principle. Plus, the recommendation that the impact and consequences should be stated clearly (The Open Group, 2018, Table 20-1). Hence, a combination of the two.

The case studies by Greefhorst and Proper (2011, Chapter 6) have examples of both. When reading the details, the original authors of the principles seem to have mixed the two meanings, or at least have used them inconsistently. This is confirmed in the key messages at the end of the chapter, stating that “the studied organisations are still in the process of improving their approach”.

Why not try to use rationales, implications, and consequences as pure as possible? Will it give a new insight or new strength? Or is this an academic discussion and should we be humble about our own language skills and write an applicable, understandable, and usable set of principles?

About

This deep dive in the fundamentals of architecture principles is part of my explorative research with a goal to improve the quality of the principles and their life cycle processes, contributing to improving the organisations we work for.

Because all enterprise decisions affect people, architects should be aware of moral values and how they steer decision making. My premise is that architects implicitly and concurrently use multiple forms of normative ethics when applying architecture principles.

If you are interested in this explorative research that combines the fundaments in learning theory, feedback loops from cybernetics, architecture best practices, and my preliminary understanding of philosophy and ethics, please contact me at Hans.Nouwens@sogeti.com.

Next

With this basic understanding of what architecture principles are, the next question to be answered is, how are they created and used? Read about this in part 2 of this series.