Ardoq Discover compared to core Ardoq

Elements of a Viewpoint

Understanding the Viewpoint Model

Viewpoint Models as ‘Chains’

Understanding Triples

Multidirectional Viewpoints

Understanding Direction in Triples

Grouping Steps

Putting Theory into Practice

Viewpoints are predefined view ‘templates’ designed to answer a specific question or address a concern of a particular user or role. They provide the foundation for all data visualizations in Ardoq Discover.

Suppose you’ve used Visio or other similar diagramming tools. In that case, you may already be familiar with the idea of a ‘stencil’ or ‘template.’ They’re a way of defining which concepts you want to represent in your diagram, along with their visual notation or representation. Once that stencil is defined, you can draw thousands of possible diagrams of that type.

Viewpoints serve the same function as those stencils or templates for Ardoq Discover’s data visualizations. They define:

In the same way, 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 need 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.

The Ardoq administrator can use Ardoq Discover to take the complexity out of these interactions. Admins can pre-define a set of standardized viewpoints for external users 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. The Ardoq administrator still has control over which data to visualize and how to visualize it.

However, the job of understanding the data’s structure falls on the Ardoq administrator, not the Ardoq Discover user. When the Ardoq Discover user requires a new viewpoint, they can request it from the Ardoq administrator. While they can self-serve their own insights, they cannot create their own viewpoints. The admin can quickly add new viewpoints to satisfy new requirements and modify existing ones.

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 which 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.

👉 Check out this Step-by-Step Guide on How to Build a Viewpoint Model.

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?

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, 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 need 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 our 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.