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 Project Portfolio 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 and Talitha Wijnands 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 an organization's current and future state enterprise architecture and its associated projects, facilitating transformation.
Dragon1, as an open standard, provides 300+ entity classes and relationships between these entity classes to create models, views, and visualizations 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 initiated to implement these transformations within 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 individuals are referred to as 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 their 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 a subject or object, these are referred to as 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 concerns, needs, and requirements of the owner/client and stakeholders are addressed and incorporated into 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, such as models, views, and diagrams, of the organization's structure, architecture, and transformation. You can apply this approach to any aspect, domain, or layer, as well as to stakeholder-specific requirements.
1.3 The Structure of Dragon1
The Dragon1 Method consists of four 'ways': the way of thinking, the way of working, the way of representing, and the 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 this standard, the conformance requirements for implementations of the language given in this section apply.
A conforming implementation:
- Shall support the language structure, generic metamodel, relationships, layers, cross-layer dependencies, and other elements as specified here on the Dragon1 resources part
- Shall support the standard iconography as specified and summarized here on the Dragon1 resources part of this website
- Shall support the data, model, viewpoint, view, and visualization mechanism of Dragon1
- Shall support the language customization mechanisms specified here on the Dragon1 resources part
- Shall support the relationships between entity classes as defined and specified
- May support the example viewpoints and views described on the Dragon1 resources part
- Readers are advised to check the 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.