Table of contents

Viewpoints provide the foundation for all data visualizations in Ardoq Discover. They are a group of components and references of a specific type that can be individually visualized in Ardoq Discover. They are predefined view ‘templates’ designed to answer a specific question or address a concern of a particular user or role.

Viewpoints define:

In other words, as an admin or writer user with the Create Viewpoints privilege enabled, you can make components and references of given types available in Ardoq Discover by creating a viewpoint in core Ardoq. Moreover, you can define how these components and references will be displayed by selecting a view style.

To allow team members to search for the components and references included in a viewpoint within Ardoq Discover, you must assign them the necessary permissions on each viewpoint. Additionally, verify that your team members have the 'Access Discover' privilege enabled. This privilege allows users to sign in to Ardoq Discover and open assets, such as a viewpoint, they have been granted a permission on. Learn more about granting users access to Ardoq Discover and assigning asset permissions in this KB article.

A single viewpoint can be used to generate thousands of possible visualizations. Based on what is relevant to the end-user, you can define multiple viewpoints for a single component type and create many different views of the same data.

Ardoq automatically generates such large numbers of visualizations. Viewpoints are a set of queries against Ardoq’s database.

The viewpoint defines the query rules - for example, you should start with a business process and find all the applications it uses and the rules that determine how that data will be rendered in Ardoq Discover.

But it’s left to the user to determine which applications they want to see in the business process. The user needs to only work with what they understand, i.e., business processes and avoid the technical layer of the applications. In this way, the Ardoq administrator can serve large numbers of requirements without creating separate views for each business process. Instead, the Viewpoints allow users to self-serve.

Users of the core Ardoq application already have multiple tools to give them unparalleled flexibility to build their views. For example, Ardoq includes a wide range of view (data visualization) styles, quick filters, perspectives (including conditional formatting), view modifiers, and more. Unfortunately, the flexibility comes with the cost of a complex user experience.

Thus, EAs can use Ardoq Discover to take the complexity out of these interactions. They can pre-define a set of standardized viewpoints for stakeholders who don't use core Ardoq to select from, without the user needing to set them up.

To use an analogy, if core Ardoq is a buffet, then Ardoq Discover offers an à la carte menu. For casual users who still need the flexibility to self-serve their own insight and value simpler interactions, Viewpoints in Ardoq Discover wraps most of these functions into a single feature.

Thankfully the user-friendly interface doesn’t significantly constrain the functionality in viewpoints. Admins and writer users who have the Create viewpoint privilege enabled still have control over which data to visualize and how to visualize it.

However, the job of understanding the data’s structure falls on the creator of the viewpoint, not the stakeholder consuming data from Ardoq Discover. When stakeholders requires a new viewpoint, they can request it from their admin and writer users who have Create Viewpoints privilege enabled. While stakeholders can self-serve their own insights, they cannot create their own viewpoints. The admin and writer user can quickly add new viewpoints to satisfy new requirements and modify existing ones given they have the Create Viewpoints privilege enabled.

Given that you are an admin or writer user with the Access Discover privilege enabled, you can access viewpoints from both core Ardoq and Ardoq Discover. Accessing a viewpoint within core Ardoq leads you to the Viewpoint Builder where you can configure your viewpoint. Accessing a viewpoint within Ardoq Discover enables you to visualize the selected component types and reference types in the view style you configured in your viewpoint.

You don't need to have the Create Viewpoints privilege enabled to edit viewpoints you have been granted the Administrator or Writing permissions on.

Admin and writer users who have the Access Discover privilege enabled and:

This ensures that viewpoints are defined by the users with the best understanding of the Ardoq organization’s repository structure.

Users who have the Access Discover privilege enabled have access to Ardoq Discover where they are a consumer of the viewpoint information provided by the admin or writer users who are allowed to create a viewpoint. In addition, they are a respondent of the different surveys for each component an admin user chooses to expose in Ardoq Discover.

With the “Explore viewpoint in Discover” permission, a user or group will:

Without the “Explore viewpoint in Discover” permission, the viewpoint will not appear in the Viewpoint Selector menu at all. The thinking behind this is that someone with access to a viewpoint should have read access to all the underlying workspaces otherwise they should be given access to an alternative viewpoint that excludes sensitive data.

It’s important to understand that the component and reference types a user can see depends on all the viewpoints they have access to. For instance, typically, an Ardoq Discover user has the “Contributor” role in the Ardoq core app. If the user is a Contributor in Ardoq, they will need to have the "Access Discover" privilege enabled and the "Explore viewpoint in Discover" permission to open a viewpoint in Ardoq Discover. If they do not have access to any viewpoints, the result page will be empty.

Each viewpoint consists of a set of standard elements:

Setting up new viewpoints is an administrator task in core Ardoq using the Viewpoint Builder. Upon completion, Ardoq Discover users have immediate access to a viewpoint from the viewpoint menu in Ardoq Discover.

Most of the steps above are relatively straightforward. You can read about them in detail in our separate articles on Building a Viewpoint and Viewpoint Permissions.

However, the most important task in defining a new Viewpoint is understanding how to build the Viewpoint model that specifies the component and reference types you want the viewpoint to visualize. This is a specialist task best performed by Ardoq administrators who understand the data structure.

Ardoq administrators should already be familiar with Ardoq’s graph data structure and the fact that all concepts are represented as components, references, or properties. They should also understand that those references are directed - i.e., that they have a source and a target component.

If you understand those concepts well, the following steps will build on that knowledge.

The Viewpoint Model is made up of a selection of component types and reference types. The first concept to understand is that those types must be linked.

You can’t select types if there’s no relationship between them. For example, you can’t build a viewpoint consisting only of applications and locations if there’s no relationship between them.

For this reason, you can think of a viewpoint as a chain of linked types. That chain can be of any length, but all types must be directly or indirectly linked. So a valid viewpoint might be:

In this case, you can include applications and locations because they are linked via the server component type.

Each link in that chain is called a triple. A triple consists of a source component type, a reference type, and a target component type. So each viewpoint metamodel consists of one or more triples.

Why do it this way when you could, for example, just select from a list of components and reference types you want to include, you ask.

It’s because triples give us more control over what you include and what you don’t include in our visualization.

In this example case, you want to visualize a business process flow and the applications that support it. But you might not want to include the relationships between those applications.

If you select the component types and relationship types you’re are interested in (i.e. Business Process, Application, Flows To, Supported By), then you have no way to tell Ardoq that you’d like the Flows To references between Business Processes but not the Flows To references between Applications with the result that we’ll get unwanted data in our visualization.

On the other hand with triples you can be more precise, i.e.:

Business Process - Flows To > Business Process

Business Process - Supported By > Application

A key property of viewpoints is that they can be entered from multiple angles. So even though you might define your viewpoint as a chain of triples, that doesn’t mean that you always start at one end.

In this example, your starting point can be a Project, an Application, a Server or a Location. So you can start at any point in the chain.

This is important for reuse – you won’t need to define a new viewpoint for each starting point. Multiple stakeholders with different roles can use the same viewpoint to answer their questions.

For example, a Project Planner could start with a project to understand the impacts of change, and an Application Owner might begin with their application. A Business Continuity Manager could prefer starting with a location to see the potential impact of a risk or security event.

Ardoq administrator needs only define the triples that make up the viewpoint’s model. They needn’t worry about which component type a user starts with. Ardoq will automatically calculate the route through the data based on the user’s start point.

Nor does it matter which direction the references point in. In this example, if you follow the chain from project to person, two of the references are outgoing (i.e. you start at the source end and travel to the target end) but the last is incoming (i.e. you start at the target end and travel to the source end).

This makes no difference to your ability to build this viewpoint (although it might affect exactly how the shapes are laid out in the visualization).

However, there is a situation where the administrator does need to consider direction in building their viewpoint.

Consider this example: with Applications and Databases. Both can be either the source or the target component type for a Flows To reference type.

But in this case it’s not enough to define one triple. A triple like this could be defined as:

Application - Flows To > Database

That would work regardless of whether you entered the viewpoint via an application or a database. But it might not return all the data you want.

Why not?

Because if you enter by the database, it will only look for incoming applications, while if you enter by the application, it will only look for outgoing databases.

To allow for the fact that the relationship between applications and databases is bidirectional, you need to define two triples, i.e.:

Application - Flows To > Database

Database- Flows To > Application

Regardless of which type you’ll start with, there are incoming and outgoing components.

In many cases, each link in the chain consists of a single triple. But there are cases where you want to group triples together to retrieve the data for all those triples before proceeding to the next step.

In our next example, building a viewpoint can show which data is stored or processed by the applications and databases, and show how those applications and databases integrate with each other.

To do this, you’ll need to understand the integrations between those applications and databases, and the data entities that represent the data they access. Logically, our metamodel looks something like this, with applications integrating with other applications and databases. Databases integrate with other databases as well as applications, and both applications and databases access data entities.

The data retrieval sequence can have potential problems when used without triples. Take this example without triples:

Now there’s a problem, the databases will be missing data entity information because a step is executed before you get to them.

As you can see, it’s best to group the triples to ensure that you first retrieve all the application and database information before linking them all to data entities. The result looks something like this:

Using groupings gives you more control over how you build your viewpoints, especially where you have metamodels consisting of similar types and relationships - for example, specialized component types representing different types of technology or similar process flow concepts that, although different, have similar patterns of relationships.

There’s a lot of power in the concepts above, and learning how best to use them will take some practice. The best approach is to start building some simple viewpoints that give immediate value to your stakeholders, and then build up to more complex types. If you need guidance, check out our Viewpoint Patterns knowledge base article for ideas on getting started.

If you have any questions or concerns don't hesitate to reach out to us by dropping a line via the in-app chat or at support@ardoq.com.