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 at all are 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 not an effective way of 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 (ie. 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 always should have four parts at a minimum: cause, effect, enforcement and result.

A working mechanism is a part of a (conceptual) system, often consisting of a set of smaller parts, which perform a particular function. Freedom of movement and behavior is often constrained by the form of the parts. Think of your knee or a coffee machine. A working mechanism is a way to show 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 are all terms referring 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 also like a pattern. They are an arranged/fixed and/or repetitive configuration of elements.

A principle is wisdom or scientific knowledge that is captured. And by means of a principle statement that knowledge can be passed through to new generations.

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

If someone claims a statement to be a principle statement, that person must be able to refer to 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 or 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 can fix them. But for that, the architect needs to 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 10 architecture principles like this and have them approved by the CIO and visualize on a monthly basis how well everything in your organization is compliant with these 10 architecture principles.

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 with reference to 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 elements of the concept 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 the same key are used for decryption, which reproduces 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 (ie. highly likely to be true) for every company. You can adopt a statement and make it part of the enterprise architecture for your company. And then when creating solutions and designs, make use of the knowledge in the principle. In that way, the architecture principles will be of impact to 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 there are tens of thousands 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 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 make sure 'this' will always work or will always 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 demonstrable). They are always true, 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 down 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 architecture principles as general rules, aims, laws or guidelines and without the notion of a concept. So when using or learning Dragon1 this is an aspect to take into account.

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. In order 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 wide bridge that is flat 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, he or she needs 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 and 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 the 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, he or she will immediately see if key elements are missing. An architect will see immediately for concepts, by means of its principle, 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 want to realize one of the seven benefits of Enterprise Architecture.

Be sure to always create an architecture principles document. You could, of course, create a large pdf text document. But also should create a small booklet with nice appealing and understandable graphics communicating the architecture principles clearly.

enterprise architecture principle examples of best practices

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

Selecting Architecture Principles

In fact, 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 own 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 you select various types of concepts and discuss with the stakeholder the best option. Take for instance the cloud concept. There are many types of clouds, like a public cloud and a private cloud. Just like there are many types of organizations, coffee machines and car engines. And they all work differently, 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 that supports the scientific claim of your principle. 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 instantly new principles. It will just don't work!

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

Structuring Architecture Principles

In order 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 on.

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 show clearly the working mechanism of a principle, else 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.

In the list linked to every architecture 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 of working of a concept is called the First Principle. Principles that describe parts of a concept are simple called principles.