Having governance as part of your architecture process is critical to ensuring data integrity and continuity. As more data is created and stored within Ardoq, it is critical to maintain the quality of that data. Having accurate and current data ensures the credibility of your insights with stakeholders.
One challenge to overcome this is through the crowdsourcing of data. As contribution opens up to people potentially outside of the core architecture teams this can lead to undesired changes to data within the organization. To help mitigate this issue and maintain data quality and integrity, Ardoq has established some best practices to ensure the right people are keeping the right data up to date.
In addition to what we outline below, having regular meetings with the Admins and super users of Ardoq is crucial to make sure everyone is aligned and knowledgeable about deliverables and responsibilities.
Dynamic and Static Workspaces
The first thing that we need to define is the terminology we use in this best practice document.
Ardoq segments your data for performance and organizational reasons into what we call workspaces. Workspaces can be categorized into two different types:
1. Static Workspace
A static workspace is a workspace that goes relatively unchanged over time. Some examples of this could be:
Business capability model
These are considered static because after the information is created and stored in Ardoq only minor changes are typically made to them.
2. Dynamic Workspace
A dynamic workspace is a workspace that is constantly changing. These changes could be driven through integration, crowdsourcing, or the core team itself. Some examples of a dynamic workspace:
Business Process Inventory
Data Object Inventory
As you implement Ardoq in your organization, it is important to decide what roles should have access to and rights to what data. Below you can see some of the common roles that we see interact with Ardoq:
As you can see, there are core Ardoq users, contributors, and consumers. Each one of these roles will use and consume Ardoq differently. A CIO may never log into Ardoq but may consume the data through a presentation or a dashboard. An application owner may only update their application information through a survey and check on the applications they own through a report. The architecture team may manage the relationship between the application, capability, and process. Once the roles are defined, this will help guide you are you determine how people will interact with Ardoq through a number of permissions.
Governance Before Implementation
It is critical to establish how you will handle the governance of Ardoq before it is implemented. Things like a governance process, the meta-model, roles, and responsibilities should all be defined before onboarding takes place so that the onboarding process can cover governance.
Governance Through Process
Now that you have established roles, it is important to define access and ownership. You wouldn’t want a procurement person defining the capabilities of an application both of which they might not know anything about. We can do this by segmenting the roles we have previously defined.
Segmentation of Roles
Any contributors that aren’t part of the core team should not have access to the full workspace, they should only have access to the data that they are responsible for (ex. An application owner should only have access to change and update their applications, this can be handled through the survey module). Core team members should have access to the workspace with edit privileges but only to workspaces that are dynamic.
It is recommended that with static workspaces that only select users should have edit access to these workspaces and that other core team members should only have read access. A change process should be established for static workspaces that handle the addition, removal, and changes to components and references as well as updates to the meta-model. Identify and assign reviewers that handle requests to changes to static workspaces (business capabilities, location, business structure, etc) and limit write access to those reviewers. This will help control the data and ensure quality.
Governance Through Functionality
Permissions: Governance can be established through Ardoq workspace permissions. Access and modification can be defined at the workspace level. Users can have read access to a capability workspace but have write access to an application workspace. This allows for more granular access controls without reducing the visibility of content.
Fields: Another way to apply governance is by leveraging component metadata. Create a list field called 'Approved' with 'Yes/No' values to flag newly created components that have been or have yet to be approved. You can then use Perspectives to filter out components with 'No' as a value from views, reports or dashboards. Alternatively, review components based on the last time they were updated. Create a 'Review Date' date field and set the date in which the component was updated. Next, create a report or dashboard using the 'Review Date' field and review the components that were last updated since a particular date.
It is important to note that while the default field “Last updated” might seem relevant, it won’t help as much as data may still be incomplete even though an update has been made. A validation date ('Approved' or 'Reviewed Date') ensures that the data is 100% accurate at that date.
Surveys: Another way to provide governance over your Enterprise Architecture is through the Surveys functionality. Surveys allow you to define the specific components to include, and can limit and restrict responses and changes to predefined components and references. This is good when you need to get information from employees without having to grant them access to the tool itself. You can also set up an Approval Workflow using Broadcasts that will help you route for review each new application submitted via a survey to a domain expert who either approves it to be added to the repository or sends it back to the submitter with comments.
Meta Model generator: You can keep an eye on your main workspaces components, fields, and references and how they connect across using this function. It also shows you how complete the field values are across your dataset.
Dashboards: Use searches and queries to build governance dashboards according to your needs. Examples to look for are the use of implicit references, Applications not connected to Capabilities (if that is what you are working on in Ardoq), any component not updated in the last X amount of days.
Scenarios: With Scenarios, users can select any part of their architecture and make a copy of it. Scenarios creates a safe space to make changes and design potential futures without affecting the mainline data. Thus, contributing to strong corporate governance.
As always, please reach out to us if you need help with anything or want to discuss different solutions to this.