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. Dragon1 was originally developed by Mark Paauwe based on several enterprise architecture projects.

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

Dragon1 as standard provides a set of 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 the changed needs of customers and clients. Projects are started up to execute these transformations in the organization.

Some people in and around the organization are concerned with the future of the organization, in terms of value, existence, being an employer, competition and revenue. These people we call owner/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, that 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 unnecessary 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 make sure that all the concerns, needs and requirements from 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 the unique or specific meta-model an organization has.

Dragon1 supports creating artifacts like models, views and diagrams of the structure, architecture and transformation of the organizations. And you can do this for any aspects, 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.

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 the purposes of 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 it can be used correctly by a user.
• 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 means that they 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. To avoid ambiguity, do not use “must” 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.