1. Dragon1 EA Method: Introduction of the Standard Specification

1.1 Objective of the Dragon1 Standard

Dragon1 is a standard for Enterprise Architecture and Project Management. Dragon1 is an open Method, Framework, and Modeling Language for Visual Enterprise Architecture and Visual Project Management. Here on the resources, part of the Dragon1 website is the specification of the Dragon1 standard:

Dragon1 is developed and maintained by the Dragon1 Foundation and members of the Dragon1 User Groups. Mark Paauwe originally developed Dragon1 based on several enterprise architecture projects.

Dragon1 is a visual modeling language with a metamodel, a set of shapes/icons, rules, roles, and constraints. With that, anyone can model, describe, analyze, and communicate aspects of the current and future state of an organization's enterprise architecture and its projects, realizing transformation.

Dragon1, as standard, provides 300+ entity classes and relationships between these entity classes to create models, views, and visualization of Enterprise Architecture. Such as creating Architecture Design Books.

1.2 Overview of the Dragon1 Standard

Organizations like commercial enterprises and government organizations continuously transform, change, and innovate because of new technologies and changed customer and client needs. Projects are started up to execute these transformations in the organization.

Some people in and around the organization are concerned with the organization's future in terms of value, existence, being an employer, competition, and revenue. These people we call owners/clients and stakeholders. The stakeholders want every transformation or every project to be a success, making the organization stronger than it was before.

In and around the organization, there are also people, architects, who can design, model, and visualize the current state and the future state of the organization in terms of the structure (entities, building blocks, relationships, and dependencies) and the architecture (concepts, patterns, principles, rules, and standards).

They do this for the owner/client and the stakeholders so that they are enabled to make decisions, making sure that all projects deliver results that fit together, avoiding making the organization unnecessarily complex or less adaptive.

The architect fulfills its role by making the strategy, business model, concept designs, architecture, landscapes, and roadmaps visible and clear and aligning them. If the architect documents or visualizes different aspects of some subject or object, these are called views. An architect can create views per type of stakeholder using domain-specific language and communication so the stakeholder understands the picture very well and quickly.

Dragon1 enables architects to ensure that all the concerns, needs, and requirements of the owner/client and stakeholders are addressed and processed in the design and realization of architecture and enterprise-wide solutions.

The Dragon1 modeling languages can be extended and customized to an organization's unique or specific metamodel.

Dragon1 supports creating artifacts like models, views, and diagrams of the organization's structure, architecture, and transformation. You can do this for any aspect, domain, or layer and stakeholder-specific.

1.3 The Structure of Dragon1

The Dragon1 Method consists of four 'ways': the way of thinking, way of working, way of representing, and way of supporting.

The Dragon1 Framework consists of reference models and diagrams containing new disruptive and best practice concepts. These concepts are not part of Dragon1 but come from the industry, and we refer to them.

The Dragon1 Modeling Language consists of entity classes, relationships, viewpoints, and views.

The following open Standards are available:

1. Dragon1 Standard v2.1 - Architecture Principles
2. Dragon1 Standard v2.1 - Business Architecture Modeling
3. Dragon1 Standard v2.1 - Information Systems
4. Dragon1 Standard v2.1 - Measure Enterprise Architecture Success
5. Dragon1 Standard v2.1 - Principles

1.4 Conformance with the Dragon1 Standard

Dragon1 as a method, framework, and modeling language may be implemented in software used for Enterprise Architecture modeling. For this standard, the conformance requirements for implementations of the language given in this section apply.

A conforming implementation:

1. Shall support the language structure, generic metamodel, relationships, layers, cross-layer dependencies, and other elements as specified here on the Dragon1 resources part
2. Shall support the standard iconography as specified and summarized here on the Dragon1 resources part of this website
3. Shall support the data, model, viewpoint, view, and visualization mechanism of Dragon1
4. Shall support the language customization mechanisms specified here on the Dragon1 resources part
5. Shall support the relationships between entity classes as defined and specified
6. May support the example viewpoints and views described on the Dragon1 resources part
7. Readers are advised to check this Resources part of the Dragon1 websites for additional conformance and certification requirements using and/or referencing this standard.

1.5 Terminology

For the purposes of the Dragon1 standard, the following terminology definitions apply:

• Can - Describes a possible feature or behavior available to the user.
• Deprecated - Items identified as deprecated may be removed in the next version of this standard.
• Implementation-defined - Describes a value or behavior that is not defined by this standard but is selected by an implementer of a software tool. The value or behavior may vary among implementations that conform to this standard. A user should not rely on the existence of the value or behavior. The implementor shall document such a value or behavior so that a user can use it correctly.
• May - Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of ‘‘may’’ is expressed as ‘‘need not’’ instead of ‘‘may not’’.
• Obsolescent - Certain features are obsolescent, which may be considered for withdrawal in future versions of this standard. They are retained because of their widespread use, but their use is discouraged.
• Shall or Will - Describes a feature or behavior that is a requirement. Do not use ‘‘must’’ to avoid ambiguity as an alternative to ‘‘shall’’.
• Shall not - Describes a feature or behavior that is an absolute prohibition.
• Should - Describes a feature or behavior that is recommended but not required.