Dragon1 EA Method


    This page describes the vision on the concept of Architecture Principles as part of the Dragon1 Way of Thinking.

    Fig 1, A principle is a working mechanism

    Architecture Principles Standard

    A Dragon1 Open Standard

    Just ask any architect how important architecture principles are. Most likely the architect finds them most important.

    What is an Architecture Principle?

    In Dragon1 the definition of architecture principle is:

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

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

    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.

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

    A mechanism is a part of a (conceptual) system, often consisting of a set of smaller parts, which performs a particular function. Freedom of movement and behavior is often constrainted by the form of the parts. Think of your knee or a coffee machine. A working mechanism is the way 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 and artificial intelligence are all terms refering 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 that 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.

    Example of Architecture Principles

    An architecture of an enterprise is a total concept, that is: a coherent set of concepts.

    For example the following items are business concepts:

    • "Self Service"
    • "Zero Waste"
    • "Business Process Orientation".

    These business concepts can be made part of a business architecture.

    Each concept has a principle, its concept principle.

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

    The Principle of Business Process Orientation

    If the concept "Business Process Orientation" is made an architecture concept, then its principle 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 infered, measured and demonstrated. The behavior of an implementation of this concept can be predicted. Here is a link to 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 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 it 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 decyphered 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.

    Example List of Architecture Principles

    Below is a pragmatic list of concept principles. These statements are true (highly likely) 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 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 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 (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 continu 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 understand or use 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 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 controled emperically, 5) not always you are refered 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 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 bsuiness service and try to see how to come up with a new secure open business service concept.

    At 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 for 20 meters, have a wide bridge that is flat or have a large and tall church that still feels cosy.

    Next the architect questions him- or herself how to make a combination of concepts work that answers to a set of requirement. For that he of she needs to dive into the principles of the concepts, the working mechanisms: how does it work aparat and how do I get it 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 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

    Best Practice on Architecture Principles

    Dragon1 is a best practice for architecture principles. The picture below draw an high level overview of how working with architecture principles can be easily embedded into any organization that want to realize one of the five 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.

    This image shows the Dragon1 best practice in working with 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 concept and discuss with the stakeholder the best option. Take for instance the cloud concept. There are many types of cloud, 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 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 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 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 how Block Chain works. You see, visualized it is much better to understand and to communicate than with a written down principle short statement.

    Blockchain Principle

    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 decribes the whole way of working of a concept is called the First Principle. Principles that describe parts of a concept are simple called principles.

    The Way of Working Definition

    Read more about the Dragon1 Way Of Working Definition on Architecture Principles here.