Dragon1 EA Method















    About

    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. Principle statements always should have four parts at minimum: cause, effect, enforcement, result.

    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 principle and an architecture principle are also like a pattern. The are an arranged/fixed and/or repetitive configuration of elements.

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

    Knowledge is that 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, measure, infer or demonstrate the working mechanism. If the person cannot do that, most likely the statement is not a principle statement but a general rule or guidelines.

    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 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 but a principle, because it describes a working mechanism that can be infered, measured and demonstrated. Here is a link to a wikipedia page on business process orientation with reference to literature about process orientation.

    The way of working and result described in the principle statement is always 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.

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

    Norms, values, general rules, guidelines, starting points, aims, goals and objectives. All these things are very important. but they are NOT principles, design principles or architecture principles. They are normative statements but not always true.

    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?

    The main difference between principles and for instance general rules or guidelines is, that principles are working mechanisms (measurable and demonstratable). 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 principles down as general rule or guideline, under pressure they will always fail! But if you write principles down as working mechanisms they will always withstand pressure. As principles are always true, they will never fail!

    Many architects are accustomed using architecture principles as 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 General Rules (or Guidelines) that wil 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)

    These statements are NOT principles, but general rules and guidelines. Beneath these statement lie the principles. These statement 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 and 3) not always the process is controled emperically.

    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 statement above do not have scientific articles backing them up, of no scientifi 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 there 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

    In the list below 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)

    Many of these concepts you will already recognize. They are specializations of functions or quality aspects. Functions in fact are general concepts.

    You will also see generalizations and specialization of concepts in the list: computing, client computing, server computing, client server computing.

    In the menu on the left you find different types of architectures that go into detail for the architecture principles mentioned here.

    A basic list of 100 common architecture principles is:

    Enterprise, Governance and Business Concepts and their Principles

    1. Separation of Concerns - By separating concerns, ...
    2. Modularity - By grouping functionality into modules, ...
    3. Simplicity - By creating a system that is as simple as possible, ....
    4. Diversity - By creating a so diverse as possible situation, ...
    5. Standardization - By standardizing the way of ..., it is ensured that ...
    6. Centralization - By centralizing ...
    7. Decentralization - By decentralizing ...
    8. Single Source of Truth - By having only one official source ...
    9. Buy before build - By buying before building ...
    10. Product differentiation -
    11. Business Need Prioritization -
    12. Business Agility -
    13. Product Value Maximization -
    14. Process Management / Process Orientation
    15. Product Management / Product Orientation
    16. Service Management / Service Orientation
    17. Client Management / Customer Orientation
    18. Office Orientation (Using Buildings to organize work)
    19. Plant Orientation (Using Plants for production)
    20. Outsourcing
    21. Offshoring
    22. Sustainability
    23. Adaptivity
    24. Production
    25. Zero Waste Production
    26. Series Production
    27. Mass Production
    28. Code of Governance
    29. Transparency
    30. Openness
    31. Business Continuity
    32. Innovation
    33. Transformation
    34. Business Transformation
    35. Digital Transformation
    36. Strategy Planning

    Information Concepts and their Principles

    1. Asset Management (Maximize value of assets)
    2. Accountability
    3. Multi-Channel Management
    4. Omni Channel Management
    5. Dependability
    6. Availability
    7. Confidentiality
    8. Authenticity
    9. Integrity
    10. Patenting / Intellectual Property / Copyrighting

    Application and Data Concepts and their Principles

    1. Application Coherence
    2. Interoperability
    3. Enterprise Application Integration (EAI)
    4. System Life Cycle Management
    5. Reuse maximization
    6. Data Hiding
    7. Data Encapsulation
    8. Loosely Coupling
    9. Interfacing
    10. Service Broker and Consumer
    11. Rules Engine
    12. Canonical Domain Model (CDM)

    Technology / IT Infrastructure Concepts and their Principles

    1. IT Service Management
    2. Capacity Planning
    3. Power consumption reduction
    4. Monitoring
    5. Automated Monitoring
    6. Redundancy
    7. Deduplication
    8. Robotization
    9. Automation
    10. Digitization
    11. SAN
    12. NAS
    13. DMZ
    14. Single Sign On
    15. Computing
    16. Client Computing
    17. Server Based Computing
    18. Client Server Computing
    19. Cloud Computing
    20. Virtualization
    21. Network Virtualization
    22. Application Virtualization
    23. Server Virtualization

    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.