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. By having accurate and current data maintains 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.
A static workspace is a workspace that goes relatively unchanged overtime. Some examples of this could be:
- Business capability model
- Business Structure
- Geographical Location
These are considered static because after the information is created and stored in Ardoq only minor changes are typically made to them.
A dynamic workspace is a workspace that is constantly changing. These changes could be driven through an integration, crowdsourcing or the core team itself. Some examples of a dynamic workspace:
- Application Portfolio
- Infrastructure Portfolio
- Business Process Inventory
- Data Object Inventory
As you implement Ardoq in your organization it is important to decide what roles should have access 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, there are contributors and there are 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 update their application information through a survey and check on the applications they own through a report, and 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. For permissions, see this article.
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
It is recommended that 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 handles 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 visibility of content.
Fields: Another way to apply governance is by leveraging component metadata. For example, you can create a date field called “validated” and then once that component has been updated have the modifying user set the date. Then you can create a report or dashboard showing components have haven’t been updated in a time frame. 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 ensures that the data is 100% accurate at that date.
Surveys: Another way to provide governance over your Enterprise Architecture is through the Survey functionality. Surveys allows you 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.
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 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.