Dragon1 Open Standard: Architecture Principles

Download the enterprise architecture principles diagram as pdf here

Ask any architect how important enterprise architecture principles are. Most likely, the architect will find them very important.

Ask any architect if EA principles have any effects. They likely will say no.

Dragon1 introduces principles as working mechanisms in order to make them much more effective.

The mainstream notion of seeing principles as general rules and guidelines is ineffective in working with principles.

This page describes the concept of Enterprise Architecture Principles as part of the Dragon1 Way of Thinking and as an intermediate result of the ongoing Ph.D/Research of Mark Paauwe.

What is an Architecture Principle?

Let us first define principle and then define architecture principle. Not every principle is an architecture principle (i.e., not every principle is part of an architecture)

In Dragon1, a principle is defined as the enforced way a concept, entity, or system works, producing results.

Self Service is an example of a concept. The Self Service principle describes how Self Service works.

A principle is a working mechanism. Principles are about the way things work. The behavior and result of the way of working can be predicted.

In Dragon1 the definition of architecture principle is:

An architecture principle is the enforced way a concept, being part of an architecture (a total concept), works, producing results.

Principle statements should always have four parts at a minimum: cause, effect, enforcement, and result.

A working mechanism is a part of a (conceptual) system, often consisting of smaller parts that perform a particular function. The form of the parts often constrains freedom of movement and behavior. Think of your knee or a coffee machine. A working mechanism is a way to show how a mechanism works or functions.

A concept is defined in Dragon1 as an approach or idea abstracted from an implementation. A chair, a car, a workplace, and artificial intelligence refer to concepts. (If a concept is implemented into an organization, it is also a capability for that organization). A concept is a conceptual system.

A principle and an architecture principle are like a pattern. They are an arranged/fixed and repetitive configuration of elements.

A principle is wisdom or scientific knowledge that is captured. And using a principle statement that knowledge can be passed on to new generations.

Knowledge is what we can measure, infer, or demonstrate. You don't know if you can't measure, infer, or demonstrate something.

If someone claims a statement to be a principle statement, that person must be able to refer to the literature to measure, infer, or demonstrate a working mechanism. If the person cannot do that, most likely, the statement is not a principle statement but a general rule, guideline, or desired future state of a system property.

The effective Single Source of Truth (SSOT) Principle

Every organization has to deal with data duplication and incorrect versions of data, or better to prevent this.

Any architect can measure, visualize, and predict (failing) working mechanisms in an organization and fix them. However, the architect must write them down as working mechanisms in a short statement.

The short statement of the principle of SSOT could be something like this: By always enforcing, via policies and implementations, that data objects of a certain type are only stored and retrieved from an appointed operational source, it is ensured that no incorrect duplicate versions of data are used in operations (f.i. in reports) and with that the quality of data used by people in their work is increased significantly.

It is very effective and smart to write down at least ten architecture principles like this, have them approved by the CIO, and visualize every month how well everything in your organization complies with them.

Examples of Architecture Principles

In Dragon1, enterprise architecture, or the architecture of an enterprise, is defined as a total concept of the enterprise. It is the coherent set of concepts of an enterprise.

For example, the following items are business concepts:

'Self Service'
'Zero Waste'
'Business Process Orientation'

These three business concepts could all be part of an enterprise architecture.

Every concept has a principle (a working mechanism), the concept principle.

If concepts are part of the enterprise architecture, the principles of these concepts become architecture principles.

The Principle of Business Process Orientation (BPO)

If the concept 'Business Process Orientation' is made an architecture concept, then the concept principle of BPO would be an architecture principle.

The principle statement for the concept 'Business Process Orientation' could be something like this: 'By continuously aligning activities optimally through active quality control, it is ensured that resources are used much more efficiently, and with that mitigating risks and lowering costs and overhead'.

This statement is not a general rule or guideline or a desired future state but a real principle because it describes a working mechanism that can be inferred, measured, and demonstrated. The behavior of an implementation of this concept can be predicted. Here is a Wikipedia page on business process orientation concerning literature about process orientation (of course, a reference to a scientific article would be much better).

The way of working and the result described in the principle statement is always true (i.e., highly likely to be true), at least if all the concept elements are in place.

Compare a principle or working mechanism with a Bicycle. If the chain is missing, it will never work to ride uphill. If the chain is there, it will always work to ride uphill.

The Principle of Symmetric Cryptography

The principle statement of symmetric cryptography could be something like this:'By always encrypting, as sender, text messages using a complex key, only known to the receiver of the text, and using a public domain algorithm, it is ensured that text messages cannot be deciphered by anyone else than the sender and receiver and with that creating safe and secure communication for classified information'.

Figure 1, Principle Diagram Showing how the Concept of Symmetric Cryptography Works.

A symmetric (or secret-key) cryptosystem uses the same key for encryption and decryption. A text block is transformed, via a particular algorithm using a key, into a ciphertext block. The same algorithm and key are used for decryption, reproducing the original plaintext. This is illustrated in Figure 1.

The Principle of Symmetric Cryptography becomes an AS-IS Architecture Principle for a domain if cryptography is done via symmetric cryptography.

List of Architecture Principles Example

Below is a pragmatic list of concept principles. These statements are true (i.e., highly likely to be true) for every company. You can adopt a statement and make it part of the enterprise architecture for your company. When creating solutions and designs, use the knowledge in the principle. In that way, the architectural principles will have an impact on your solutions.

A list of pragmatic principles for any company is:

Data treated as an asset is far more accurate and better suited for decision-making
Reuse before build before buy saves you time and money
Loyal customers strengthen your 'raison d'être'
Motivated employees add value
Business processes automation leads to efficiency in operations
Standardization kills chaos and complexity
But also the other way around: Standardization kills diversity and creativity
Empowerment opens the door to entrepreneurship, creativity and perseverance
Service orientation as opposed to process orientation increases business continuity
Process orientation, as opposed to service orientation, increases optimal resource utilization
Starting up a project only when having a signed-off business case increases the success percentage of a project
Starting up a project without having a signed-off business case is asking for trouble

These are just a couple of principles, but tens of thousands are out there. Find the right ones (in literature) and use them to the benefit of your enterprise.

What is Not an Architecture Principle? A General Rule or Guideline

Desired future states of system properties, norms, values, general rules, guidelines, starting points, aims, goals, and objectives. All these things are very, very important. But they are NOT principles, design principles, or architecture principles. They are normative statements but not always true; therefore, they cannot be a principle (a working mechanism)

Behind these normative statements lies a truth, the rationale, the actual principle. So, the real principle can always be found or constructed. Just answer the question: How can we ensure 'this' will always work or deliver benefits? How can we make sure we can predict behavior and certain results?

The main difference between principles and, for instance, general rules or guidelines is that principles are working mechanisms (measurable and verifiable). They are always true, or else it is not a working mechanism. General rules or guidelines are statements of regulation and intent. They are soft and, under pressure, become optional. But principles stay, even under immense pressure. They continue to work and produce results.

If you write general rules or guidelines and label them as principles under pressure, they will always fail! But if you write down principles as working mechanisms, they will always withstand pressure. As principles are always true (i.e., highly likely to be true), they will never (i.e., not likely) fail!

Many architects are accustomed to understanding or using architectural principles as general rules, aims, laws, or guidelines without the notion of a concept. So, when using or learning Dragon1, this is an aspect to consider.

Examples of the Desired Future States, General Rules (or Guidelines) that Will Fail under Pressure

Consumers Get the Service They Need (Dutch eGovernment Principle)
Maximize Benefit to The Enterprise (TOGAF Principle)
Welcome Changing Requirements (Agile Manifesto Principle)
Emperical Process Control (A core Scrum Principle)
No Wrong Door
Data is an Asset (TOGAF Principle)
The Hospital Works Closely Together With Organizations in the Health Care Chain (Dutch eHospital Principle)

These statements are NOT principles but desired future states, general rules, or guidelines. Beneath these statements lie the true principles. These statements are not true under all circumstances: 1) Consumers do not always get the service they need, 2) things are not always maximized to the benefit of the enterprise, 3) changes are not always welcomed, 4) not always the process is controlled empirically, 5) not always you are referred to by the government to other organizations for your service request, 6) not every organization puts their data on a balance sheet and 7) not all organizations are working closely together.

These example statements are not principles. To turn these statements into principles, one needs to go back to scientific literature where it is proven or made highly likely that certain working mechanisms (principles) do exist. Most of these provided statements above do not have scientific articles backing them up, or no scientific research has been undertaken to prove them.

Why Do Architects Make Use of Architecture Principles?

Architects create designs of enterprise-wide solutions. They start their design at a conceptual level. They create a total concept, which they then detail.

Architects do that because with principles, you can predict behavior and results, and you can find solutions for conflicting and mutually excluding requirements from stakeholders.

Suppose that one stakeholder wants and very open business service and another stakeholder wants a very secure business service, then an architect can draw the three concepts of very open, very secure and business service and try to see how to come up with a new secure open business service concept.

At a conceptual level, this always works. With concepts, you can, for instance, give humans wings, have cars that can drive endlessly on solar energy, have a shop with a glass front that spans 20 meters, have a flat wide bridge, or have a large and tall church that still feels cozy.

Next, the architect questions him- or herself how to make a combination of concepts work that answers a set of requirements. For that, they need to dive into the principles of the concepts and the working mechanisms: how does it work apart, and how do I get them to work together? How can I morph three concepts into one?

Architects create designs at a conceptual level, logical level, and physical level. Other designers, like functional or technical designers, do not start at or cover the conceptual level.

At the logical level, one is not always aware of the concepts and principles, and the principles are already implicitly there, designed in. The logical level designer looks at only the parts of the concept (the elements) to design in detail or to implement.

At a conceptual level, the designer is aware of concepts and principles.

Architects also make use of principles to check whether the key elements of concepts are implemented in the organization. If a specialist looks at a bike, a car, a boat, a house, or a bridge, they will immediately see if key elements are missing. An architect will immediately see concepts, using its principle, and determine which elements are missing.

Types of Architectures Principles

Next to Architecture Principles Dragon1 recognizes the following common types of principles:

Design Principles
Prima facie Principles
Construction Principles
Enterprise Principles
Governance Principles
Business Principles
Information Principles
Application Principles
Data Principles
Security Principles
IT Principles
Solution Principles
'business function principles', like Logistic principles, HR principles, etc.

Best Practice on Enterprise Architecture Principles

Dragon1 is a best practice for architecture principles. The picture below draws a high-level overview of how working with architecture principles can be easily embedded into any organization that wants to realize one of the seven benefits of Enterprise Architecture.

Be sure always to create an architecture principles document. You could, of course, create a large PDF text document. However, a small booklet should also be created with nice, appealing, and understandable graphics that clearly communicate architecture principles.

enterprise architecture principle examples of best practices

This visualization shows the Dragon1 best practice in working with enterprise architecture principles.

Selecting Architecture Principles

You do not select principles, but you select concepts as an architect. The concepts you make part of an architecture. And by doing so, the concepts' principle is made part of an architecture.

And you don't go creating your principles. You make sure you have literature that describes the theoretical foundation and the successful practical application of a concept and the detail of its principle.

You need to know the stakeholder's needs and requirements first, and then you can select a concept based on the requirements and needs. It could be that you select various types of concepts and discuss the best option with the stakeholders. Take, for instance, the cloud concept. There are many types of clouds, such as public and private clouds. Many types of organizations exist, such as coffee machines and car engines. They all work differently, and they have different principles.

Formulating Architecture Principles

Dragon1 has predefined a format for the short statement of a principle and thus for an architecture principle.

A short statement consists of four parts: the action, the effect, the enforcement, and the result. Preferably, a principle starts with the word "By". And you MUST always be able to refer to literature supporting your principle's scientific claim. Because architecture and principles are top-level science, as with dealing with the forces of chaos and entropy, you must know what you are doing! Don't try to invent new principles instantly. It will just don't work!

Example short statement of a principle: By always linking exactly one business goal to exactly one project via tooling and evaluated via reports and quality systems, it is ensured that unnecessary or excessive projects are started up to realize business goals, resulting in saving resources, budget and costs and mitigating risks.

Structuring Architecture Principles

To control the set of architecture principles, you could create a framework diagram with layers and domains per architecture. In every domain, you place the concepts where they have an impact.

This framework diagram can be used to plan and report progress on implementing concepts and their principles.

Visualizing Architecture Principles

Principles are visualized with Principle details diagrams. They explain at a high level or in detail how a system, like a concept, works and produces results. A principle details diagram should always clearly show the working mechanism of a principle; otherwise, it is not a principle details diagram.

Here follows an example of how BlockChain works. You see, visualized it is much better to understand and to communicate than with a written down principle short statement.

Notice how a principle details diagram at least recognizes and mentions the key elements that have to collaborate and how they need to be arranged.

Top 100 list of Architecture Principles

Dragon provides you with a list of 100 modern and common concepts and principles to make it easy to create your architecture.

The list linked to every architectural principle is written down in the format 'concept name' followed by a 'short principle statement'. The short principle statements consist mostly of four parts: action, effect, enforcement, and result. This format ensures we do not write down general rules or guidelines but write down principles (that is: working mechanisms). Where possible, a link to literature is provided, and a link to a detailed description and visualization of the principle.

First Principle

Any concept has principles. The principle that describes the whole way a concept works is called the First Principle. Principles that describe parts of a concept are simply called principles.