Understanding Architecture Architecture Principles: Part 2

In Part 1 we looked at the symptoms experienced by an organisation that does not have Architecture Principles in place. We stated the official TOGAF definition and then discussed the concept of Architecture Principles, exploring the psychological reasons behind their usefulness.

In this article, the second of three, we will look more deeply into the properties of a Principle: We’ll cover the formal structure in which they should be written, and the consideration that must be given to their interaction.

Next time, in the third and final part in this series, we will explore the use of Principles in the governance of an organisation, and I will provide and expand upon a set of Principles which I have designed specifically to support the adoption and governance of platform-based operations within an enterprise.

The Nature of Principles

While on the surface they appear to be basic, common-sense statements, Principles need to be selected with real care, so that they create a harmonious set. If not, they could clash with each other, leading to conflict between teams and slow decision making; or worse, they could work against the aims of the enterprise, and lead it down the wrong path.

Good Architecture Principles are persistent, enduring, and right almost all of the time. This lends them gravitas; they are solid and dependable. Their unchanging nature ensures that they have time to embed themselves into the culture of an organisation; they assume the mantle of accepted wisdom.

Paradoxically, the inherent flexibility of a Principle is also critical. Principles are not absolute, and there can be times when it is better not to follow them. To illustrate this, let’s continue the 10 Commandments analogy from the first article, and consider “Thou shalt not kill.” Pretty much all of the time, no matter how infuriating some people can be, this rule will hold true for your social interactions. However, there are rare circumstances in which the killing of a person is not only necessary, but desirable. For example, to prevent an armed terrorist from harming innocent people.

Likewise, there will be times when Architecture Principles must be broken, for good reasons. This is perfectly acceptable, provided that the decision to go against the Principle is made under governance. In a high-security environment for example, a few IT assets might be kept deliberately disconnected from the internet for security reasons, even if there are general Principles within the enterprise to use networked systems and have connected data.

If the Principles of an enterprise have been designed to support continuation of the status quo, exceptions (and sometimes revision) might be required during major digital transformation to enable a step-change to occur. So, if a “Use Before Buy” Principle is in place, it may have to be suspended temporarily for legacy IT to be cleared out and replaced with more modern tools.

Types of Principle

The Naming of Cats is a difficult matter,

????It isn’t just one of your holiday games;

You may think at first I’m as mad as a hatter

When I tell you, a cat must have

THREE DIFFERENT NAMES.

The Naming of Cats, T. S. Eliot, 1888-1965

For the theorists among you, the TOGAF specification discusses two types of Principle: Enterprise Principles and Architecture Principles.

• Enterprise Principles provide a basis for decision-making throughout an enterprise and inform how the organisation sets about fulfilling its mission. These help to harmonise decision-making across an organisation, and they are a key element in a successful Architecture Governance strategy.
• Architecture Principles (the subject of these articles) are Principles that relate specifically to architecture work. They govern the architecture process, affecting the development, maintenance, and use of the Enterprise Architecture, and they can be considered a sub-set, or perhaps a specialisation, of the Enterprise Principles.

I’d be so bold as to include a third type, Programme Principles. For those of us engaged on large transformation programmes, it can be difficult to ensure that all the sub-projects are working in concert towards a common goal. If you are a consultant, and your customer has a set of Architecture Principles, then it ought to be adopted by default. However, if the customer has little or no maturity in their enterprise architecture capability, then agreeing a set of Architecture Principles specifically for the Programme (Programme Principles) will enable some level of governance to be applied to decisions at least within the scope of the work, and so improve the programme’s chances of success.

How to Write a Principle

When creating a Principle, there are five parts to consider: Name, Definition, Rationale, the Implications of obeying the Principle, and the Consequences of not obeying the Principle:

• Name: Each principle needs a short, pithy name. This is likely the way that people will refer to it, so it needs to be something easy to remember. For example ‘Anytime, Anywhere,’ ‘Use Before Buy’
• Definition: A brief, unambiguous description of the meaning of the Principle
• Rationale: The reasoning for why the Principle is there, perhaps mentioning the business strategy that it supports. e.g., for a ‘Minimal Customisation’ Principle, the rationale might be ‘To enable platforms and applications to be updated quickly and easily, without the need for bespoke integrations, or input from specialist consultants. This supports our ‘Keep It Simple’ strategy.’
• Implications: A statement of what positive things will arise as a result of obeying the Principle. You might also want to indicate how this Principle impacts on particular parts of the enterprise, and how it connects with other Principles. e.g., for ‘Drive Compliance’ the implications might be ‘To ensure that audits can take place efficiently, and so that we continue to operate safely within the law. This is supported by the ‘Useful Data’ Principle, and wherever possible, metrics should be built into automated reports to monitor Compliance.’
• Consequences of not obeying the Principle: A statement of the negative things that will arise if the Principle is ignored. For ‘Drive Compliance’ this could be ‘If we do not meet our expected levels of compliance with Regulation XYZ, then the company may face punitive fines, and individual employees may be held responsible by law enforcement.’

Building Your Set of Principles

Once you have a draft set of Principles, look them over, and ensure that they don’t duplicate, overlap, or contradict each other.

There should not be too many Principles; twenty-five is a good size for an enterprise. Many more than that and the set will become unwieldy, and each one you add will reduce the value of the others. Cull the list if necessary, by removing or combining Principles, to make a manageable set.

Revise the text if needed and make it as concise and simple as possible; this is generally good practice, but is particularly important in international organisations and in global teams, where material may need to be translated into other languages.

Check the levelling of the Principles; they should all be about the same, and at a relatively high-level. If you find that one is running into technical minutia, then it is probably worth removing it from the list of Principles and instead incorporating the information into a policy document, where details can be properly elucidated.

Finally, see if you can group the Principles into themes. For example; Data, Performance, User Experience. This will make it easier for people who will use the Principles to identify the ones that are relevant to their concerns.

Most Importantly: Remember that Architecture is a Team Sport

To be useful, Enterprise Architecture cannot be the output of one mind; that way lies the metaphorical Ivory Tower. If you attempt to create a set of Principles on your own for an organisation, please do not be surprised if they are completely ignored.

To be accepted, Principles must represent the consensus view of the organisation. When people feel ownership of the Principles they will be more motivated to uphold them.

It is good to have this in mind when you are working with customers; as an architect, you can facilitate the development of Principles, bringing stakeholders together in workshops to craft them together. Often, the discussions in such sessions can uncover discrepancies in approach that have been hobbling an organisation for years. In cases like this, you can use the workshop to debate and resolve these issues, and negotiate a Principle that will drive the organisation towards excellence.

About the Author:?Dr Michelle Supper?has contributed to the creation of eight international standards, along with other publications including white papers and guides. She is the EMEA Enterprise Architecture Advisor, in the ServiceNow EMEA EA Team, and the creator of the Guided Architecture methodology.?

Please join the conversation at the?ServiceNow Enterprise Architecture Forum