All organizations have to conform to rules and regulations. Some are imposed internally, some are voluntary, others come from regulatory bodies and external agencies. Modeling them enables you to understand their impact and influence on your architecture, and monitor your level of compliance with them or your progress towards implementation of their requirements.

This article explains how to represent company policies and principles, and adopted standards, frameworks and regulatory requirements, such as those published by industry regulators and standards bodies like ISO and NIST.

By following this standard approach to modeling these types of document, you can easily link them to a range of architectural assets in Ardoq to track and demonstrate:

These collections of rules and regulations all share a number of common characteristics which lend themselves to a standard modeling approach:

To reflect these common characteristics, we model them with two primary component types:

The Information Artifact component represents the source document. It has a URL Field that can point to the source document’s location, which might be a reference to a location in a company’s document management system or repository, or in the case of an externally sourced item, such as an international standard or industry regulation, a source location from the issuing authority.

Where there is a hierarchy that is a form of decomposition (with the parents representing a higher level composition of their children), the structured content of the document is represented as a set of Requirement components that are children of the parent Information Artifact component to which they belong. Sometimes a single layer of Requirements suffices to represent the Policy or Standard. And where there is a decompositional hierarchical structure, we can use the Requirement component to represent both the specific requirements (the leaf nodes in the tree) and their higher level parent requirements (the branch nodes in the tree). The hierarchy may have several levels.

Such a hierarchy is therefore modeled in Ardoq by having Requirements that are themselves children of Requirements. We use the same approach to model multiple levels of business capabilities (as described in Getting Started with Business Capability Modeling).

If you wish to offer survey respondents a list of Requirements to choose from, you will need to decide whether to offer the entire hierarchy (all parents and children) or only the leaf nodes. This latter option is easily achieved using the Advanced Search option to select only those Requirement components that don’t have children.

Where the hierarchy in the document is not a form of decomposition (as described above), we recommend that you use a Category component type to represent the branch nodes of the tree, and keep the Requirement component type just for the leaf nodes. This ensures that the organizational branch nodes are never confused with the more significant Requirement leaf nodes.

The real value in modeling these Information Artifacts and their Requirements comes from their connections to other assets. We show below the primary reference types and the component types they can connect to or from. As with all the Ardoq Use Case Solution metamodels, this metamodel is a guide, and can be extended to suit individual circumstances.

Only two reference types are used: Is Realized By and Impacts. But we can see reference connections to a large variety of component types. We’ll step through some examples, using the different types of document represented by the central Information Artifact to show how, in practice, these reference connections can be used to address the questions set out at the beginning of this article.

Corporate policies are designed to provide a framework for decision-making, establish standards of behavior, and ensure compliance with legal and ethical requirements. These too can be modeled with an Information Artifact component that contains one or more Requirement component. One policy commonly adopted by enterprises relates to Information Security, an example of which is given below, modeled using the metamodel given above. The wording of each policy Requirement can be captured in the component Description Field.

The policy, and its adoption and application across the enterprise, might itself be in response to a regulatory requirement (such as GDPR in the European Union). Both the regulation itself and the organization’s policy response can be modeled using the representation discussed in this document. GDPR will be represented as an Information Artifact with each specific GDPR requirement (i.e. the Right to access, Right to be forgotten etc.) represented as a Requirement component. The individual GDPR Requirements will then have Is Realized By references to the relevant policy or policies. The model can thus offer traceability of how each regulatory requirement has been realized.

The scope of these policies can be modeled using the Impacts references from each Requirement of the policy to the components that have to comply. For example, people managers in the organization may be responsible for compliance with the “Employee Training and Awareness” Requirement. Those that are Assigned To a relevant Role in the organization can be connected to the policy Requirement with an Impacts reference link (see How to use Roles in Ardoq for more information about the Role component type).

Other Policy Requirements might similarly impact Organizational Units, Processes or Applications. See Process Playbook: How to Automate Application Ownership for more information on how to implement automated processes in Ardoq.

Architecture Guiding Principles are often adopted by enterprise architecture teams with a view to inform and support the way in which an organization sets about fulfilling its mission.

Below we see the example set of Architecture Principles from the TOGAF Standard modeled in Ardoq:

Having a representation of your Architecture Guiding Principles in Ardoq enables you to link individual principles to other assets in your model. For example, you can indicate assets that are impacted by principles, recording in a Field on the reference whether the asset is compliant or not. Failure to comply with a Principle is considered by some organizations to be evidence of Technical Debt: perhaps compliance with the principle was deferred in the rush to deploy a new solution. The debt needs to be acknowledged, recorded and, eventually, remedied via an Initiative. This can be modeled with the creation of a Tech Debt Item that has an Impacts reference to the Requirement component that represents the transgressed Principle. The example below shows an application, Guidewire BillingCenter, that is impacted by a Tech Debt Item that fails to comply with the Business Continuity Business Principle.

Another common way to classify technical debt is to use a quality model, such as ISO 25010, the product quality model from the Systems and software Quality Requirements and Evaluation series of standards (SQuaRE). Like the Policies and Principles shown above, this is easy to model in Ardoq using the same approach:

Note that you need to license ISO 25010 to use the model in your organization.

Classifying technical debt according to a quality model is among the recommendations in the Gartner article “How to Prioritize and Sell Technical Debt Remediation”.

A widely used international standard is the NIST Cybersecurity Framework:

In the Application Risk Management Use Case, we show how you can track your implementation of a framework, such as the NIST Cybersecurity Framework, and demonstrate its successful adoption. Each Framework Requirement that you intend to implement will have an Is Realized By reference to one or more Control component that represents the control or controls you plan to implement to satisfy the Requirement. The Control components will, in turn, have Deploys To references to the Applications against which they have been deployed, each with a Live Start Date to record when the Control became, or is planned to become, operational with that Application. There may also be an Initiative component linked to the Control, representing the effort to implement the Control in the organization. With this model, you can track and visualize your progress towards implementing a Standard or Framework, and record which assets in your estate comply (or will comply) with the Standard’s requirements.

This article has shown you how to represent Policies, Frameworks, Standards and Principles in Ardoq. Both internal and external documents can be represented in this way. Modeling them in Ardoq and connecting them to other architectural assets enables you to visualize and report on their impact on your organization, record your organization’s compliance with their requirements, identify any gaps and track your progress when implementing them.