The knowledge base article Using Reference Architectures in Ardoq looks at how reference architecture patterns can be used within Ardoq. There has additionally been demand for information on how this can be extended to include the creation of reference architecture patterns within Ardoq, allowing for the definition of in-house and third-party patterns. The approach described within this article presents a simple and flexible mechanism for supporting custom pattern definition.

Note: Ardoq continues to look for improved ways of enabling reference architecture definitions to accelerate delivery and underpin assurance and governance activity. Approaches, such as the one described in this article, will continue to evolve.
​

One of the major challenges of representing reference architectures within a modeling tool is the ability to map all required elements of the diagram to the metamodel. It can also present issues when the elements of the diagram represent abstractions of the elements rather than particular instances of the elements themselves (for example, the concept of a database rather than a specifically identified data store).

The image below shows a typical reference architecture diagram. It contains a lot of useful information, but the elements of the diagram cannot easily be mapped onto metamodel elements without either creating numerous new model types, stretching the definition of existing model types, or losing information content.
​

Fig.1 An example architecture diagram

This article describes a mechanism within Ardoq for capturing the volume of information content carried by reference architectures, without significant modeling overhead and without compromising existing model types.

In summary, this is achieved by representing the elements of the reference architecture as flexible and generic object types. Modelling and building reference architectures using a generic object component type provides several benefits, such as:

The primary building block for the definition of reference architectures is the Design Object component type. The Design Object is a weakly-typed* component type that can be used to represent any element within a reference architecture. The intended purpose of the component can be defined using the ‘Object Type’ text field. Alongside this is a corresponding weakly-typed* reference type called ‘References’. This can similarly be used to represent any relationship within a reference architecture, being flexibly defined by the associated Reference Type text field.

*weakly-typed: where ‘type’ information is flexible and held using a field value, rather than fixed in the identity of the component type.

Fig.2 Metamodel for creating reference architectures as patterns

To begin modeling using the metamodel above, you will need to create the necessary component type, reference type, and fields as described below:

Firstly, edit the metamodel of the ‘Pattern Library’ workspace and add the Design Object component type as a child of the Pattern component type.

Fig.3 Design Object component type creation within the Pattern Library workspace

You then need to create the ‘Object Type’ text field as a field of the Design Object.

Fig.4 Object Type field creation on the Design Object component type

Next, set the ‘Style’ of the component to suit your preferences, and the component type creation is now completed.

Within the ‘Pattern Library’ workspace, you should now create a new Reference Type called ‘References’.

Fig.5 References reference type creation within the Pattern Library workspace

Next create the ‘Reference Type’ text field as a field of the References reference type.

Fig.6 Reference Type field creation on the References reference type

You are now ready to start modeling your reference architecture.

You can create the elements that are part of your reference architecture through the normal Ardoq component creation interfaces, such as Grid Editor, Inventory, or via a visualization. You can also add any descriptions or object type specifications for inclusion in your reference architecture, as well as any references between the design objects.

Fig.7 Bulk manual creation of required Design Objects and References for the reference architecture pattern

Fig.8 Resulting components and hierarchy from manual creation

Once you have created all of the elements within your reference architecture, you can create the required visualization.

Below is a viewpoint definition for displaying the basic data architecture reference architecture defined above.

Fig.9 Example viewpoint definition for the display of a reference architecture pattern with Design Objects

By using the Interactive Blocks visualization, you can customise the layout of your reference architecture to best convey the desired information.

Fig.10 View configuration to apply required grouping and formatting in the Interactive Blocks visualization

You can also adjust the styling of each component to best represent the information you want to communicate. This could be via conditional formatting or custom styles. Once you have configured the reference architecture pattern, you can save this into a presentation for reuse and sharing. The presentation can be linked from the Document URL field on the Pattern component.

Fig.11 A completed pattern for a Basic Data Architecture

As with the patterns described in the article Using Reference Architectures in Ardoq these reference architectures can be linked to Technology Products for governance purposes, or to describe how design objects can be realized.

Shown below is the same reference architecture, but instead of simply creating technologies as more Design Objects, we can use the Includes reference to link to the actual Technology Products intended to realize the Pattern. Doing so, it is easy to see which Patterns reference which Technology Products, which is helpful when creating or changing approved standard technologies. This combines the utility of the existing modeled data with the flexibility of purely design objects.

Fig.12 A completed pattern with technology choices for a Single Page Serverless Application reference architecture

As an alternative to manual pattern creation, the required Design Objects can also be imported into the Pattern Library workspace using either Excel or via the Lucid Visual Importer.

The image below shows the Lucidchart import process for an Azure-based reference architecture. All of the components in the diagram can be imported as Design Objects.

Fig.13 A reference architecture held within Lucid to be imported via the Lucid Visual Importer

Once imported, the objects can be associated with the relevant Pattern component within the resulting Scenario and merged into the Pattern Library. For more information on merging data from Scenarios, please see: How To Merge Your Scenarios And Mainline Data | Ardoq Help

Fig.14 A scenario containing the imported Design Objects ready to be merged into the Pattern Library

Once all parts of the reference architecture are present, the same process can be followed to create the required artefact using the Interactive Blocks visualisation with customised layout and styling.

Fig.15 A pattern imported from Lucid for a Single Page Serverless Application reference architecture

Fig.16 A pattern imported from Lucid for a Single Page Serverless Application reference architecture

Using Reference Architectures in Ardoq

Creating Technology Reference Models and Standards in Ardoq