Ardoq’s native flexibility allows you to tailor your EA metamodel to match your organization’s requirements. Ardoq’s new Viewpoint Builder takes this a step further now you can build numerous Viewpoints for your stakeholders and their use cases.

Currently, each implementation of Ardoq is different, making it challenging for us to propose exactly which Viewpoints you should build and how you should build them.

But there are still common patterns when modeling components in architecture data: from component hierarchies to information flows or people and ownership.

So even if your model differs from what’s shown below, you can likely find one that’s close enough to your model, making it easy to translate it to match your requirements.

If you haven’t already read them, we strongly recommend reading our guides to Understanding Viewpoints and Building a Viewpoint. The first explains the principles behind Viewpoints; the second shows you how to configure them in the Viewpoint Builder.

Understanding the principles will help you adapt or extend the patterns below to your own needs.

This straightforward but useful viewpoint maps applications to the people who own or are responsible for them.

Name: Application Ownership

Description: This viewpoint shows application ownership and responsibility.

View Style: Dependency Map

Workspaces: Applications; People

Viewpoint Model:

Step 1:

Triple: Person > Owns > Application

Grouping: None

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Using Steps in the Viewpoint Model

The Step function is an important part of the Viewpoint model builder. It enables Ardoq administrators to define dependencies between different parts of the Viewpoint Model. For example, Step 1 should be completed before Step 2 (or the other way around, depending on the entry point).

Viewpoints can run across any number of workspaces as long as the components in those workspaces are linked together. Here’s an example of a viewpoint that runs across four workspaces to link business products down to application hosting locations. In this case, we use a separate step for each workspace to workspace link.

Name: Product Hosting

Description: This viewpoint shows how business products are supported by applications and which locations host the servers they run on.

View Style: Dependency Map

Workspaces: Business Products; Applications; Servers; Locations

Viewpoint Model:

Step 1:

Triple: Business Product > Is Supported By > Application

Step 2:

Triple: Application > Is Supported By > Server

Step 3:

Triple: Server > is Located At > Location

Grouping: None

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Viewpoint model steps can either be fixed or flexible.

Fixed means they take a pre-selected number of hops through the different components and references; flexible means that the number of hops can be adjusted with the slider control.

Take the following example triple:

Application > Flows To > Database

I can go one hop:

Application 1 > Flows To > Database 1

Or multiple hops:

Application 1 > Flows To > Database 1 > Flows To > Database 2 > Flows To > Application 2

Setting a step to flexible requires the Ardoq administrator to set the max repetitions to a number higher than one and check the flexible checkbox.

However, not every step can be flexible. They must comply with one simple rule:

For all the triples in the step, the from types must match the to types.

So for example, this step consisting of three triples is valid:

Application > Flows To > Application

Application > Flows To > Database

Database > Flows To > Application

But this one is not:

Application > Flows To > Application

Application > Flows To > Database

Database > Flows To > Service

The reason is that in the second example, Service is included as a from type but not as a to type.

Here’s a simple example of using a flexible step: An application integration map where applications are connected directly to each other with references representing their integrations.

In this case, we actually have two reference types representing different types of integration (one-way and two-way).

We also need to define each of these triples twice, once for each direction, to represent that we want to capture both incoming and outgoing references for the context component.

As we want to make the viewpoint flexible, we’ll check the flexible checkbox option and set the max repetitions slider to the maximum number of steps we want to allow.

Name: Application Integrations

Description: This viewpoint shows integrations between applications.

View Style: Simple Block Diagram

Workspaces: Applications

Viewpoint Model:

Step 1:

Triple: Application > Flows To (One-way) > Application

Triple: Application < Flows To (One-way) < Application

Triple: Application > Flows To (Two-way) > Application

Triple: Application < Flows To (Two-way) < Application

Max repetitions: 4

Flexible: True

Grouping: None

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Even within a single workspace, you may need to break your viewpoint model into steps to ensure the triples are executed in a defined sequence.

To illustrate this, we’ll build two alternative viewpoints against a single workspace with identical triples, but one using the step function and one without so you can see the pros and cons of each.

In each case, we want to build an expandable component hierarchy using our Business Capability Model. From our context component, we want to be able to expand or collapse lower levels of the hierarchy while also seeing all its parent components up to the highest level.

Both methods below will work for any component hierarchy that is a strict hierarchy (i.e., one parent component has one-or-many child components, but each child component has only one parent).

Method one uses a single step with triples representing the incoming references (i.e., child components) and the outgoing references (i.e., parent components).

Name: Business Capability Hierarchy

Description: This viewpoint shows the hierarchy of Business Capabilities and their sub-Capabilities.

View Style: Simple Block Diagram

Workspaces: Business Capabilities

Viewpoint Model:

Step 1:

Triple: Business Capability < Ardoq Parent < Business Capability

Triple: Business Capability > Ardoq Parent > Business Capability

Max repetitions: 4

Flexible: True

Grouping: None

Conditional Formatting: None

Label Formatting: None

This viewpoint gives us our expandable hierarchy. We can adjust the slider and expand the levels above and below (if any) our context component.

But it also may not give us exactly the result we want. At one degree of separation, we will see a clean hierarchy; but at two or more degrees, we may get unwanted components appearing higher up the tree.

You’ll see unwanted components because when the triples execute in the same step while getting the children of our context component, you’ll also get the children of our context component’s parents.

Now, this may be useful context; but on the other hand, if you don’t want to see this, the answer is to use two parent-child steps like this:

Name: Business Capability Hierarchy

Description: This viewpoint shows the hierarchy of Business Capabilities and their sub-Capabilities.

View Style: Simple Block Diagram

Workspaces: Business Capabilities

Viewpoint Model:

Step 1:

Triple: Business Capability < Ardoq Parent < Business Capability

Max repetitions: 2

Flexible: True

Step 2:

Triple: Business Capability > Ardoq Parent > Business Capability

Max repetitions: 4

Flexible: False

The result for the same context component should look a little different:

This works because the first step travels down the hierarchy to retrieve all the children of the context component to n degrees of relationship; the second step travels up the hierarchy to retrieve all the parents of those components. Because it travels down first, then up second, it will not retrieve the children of parent components.

Although the second step is not flexible, setting the degrees of relationship to a number equal to the total depth of your tree will ensure all the parent components are retrieved no matter how far you drill down.

Once you've built your viewpoint model, you can group the components specified in your triples. The Viewpoint Builder offers a range of grouping options, including workspace, component type, and field.

However, in order to group by three of these options - by referenced component, by parent, and by parent all - you need to first retrieve their components in the Viewpoint model, meaning these referenced or parent components must be included in your triples.

To illustrate this, we’ll loop back to one of our earlier examples, but this time modify it to group the components. In this case, we’ll apply a referenced component grouping to our flexible application integration map.

In this example, you’ll learn to group the servers that Ardoq applications run on. Then, you’ll need to add an additional step to the Viewpoint model to retrieve those servers before grouping them.

Start by adding a second step to the Viewpoint model to retrieve the servers for each application picked up in the first step.

Name: Application Integrations with Servers

Description: This viewpoint shows integrations between applications and the servers they run on.

View Style: Simple Block Diagram

Workspaces: Applications, Servers

Viewpoint Model:

Step 1:

Triple: Application > Flows To (One-way) > Application

Triple: Application < Flows To (One-way) < Application

Triple: Application > Flows To (Two-way) > Application

Triple: Application < Flows To (Two-way) < Application

Max repetitions: 4

Flexible: True

Step 2:

Triple: Application > Supported By > Server

Grouping: None

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Once you have the data we need, you can use the grouping function to put those servers inside their respective applications.

Grouping: Referenced component

Workspace: Applications

Reference Type: Is Supported By

Direction: Outgoing

‘Outgoing’ in this case, will group the server inside the application (‘incoming’ would group the application inside the server).

Let’s take the previous example one step further. If you've built the last viewpoint, you may have spotted a weakness with it: If your starting point is an application, then all the applications have servers associated with them; but if your starting point is a server, then only one application does.

This is because when you start with an application, you go

But if you start with a server, you go

However, you don’t pick up the servers for that second set of applications. To do that, you’d need

In other words, depending on our starting point, you might need to go two steps or three.

For the next step, try that. Note this is the only time you’re going to exchange servers for people and build an application collaboration network based on application integrations.

In this case, you see that the first and last steps are effectively mirrors of each other.

Name: Application Integrations with Experts

Description: This viewpoint shows integrations between applications and the experts for those applications.

View Style: Relationship View

Workspaces: Applications, People

Viewpoint Model:

Step 1:

Triple: Person > Is Expert In > Application

Step 2:

Triple: Application > Flows To (One-way) > Application

Triple: Application < Flows To (One-way) < Application

Triple: Application > Flows To (Two-way) > Application

Triple: Application < Flows To (Two-way) < Application

Max repetitions: 3

Flexible: True

Step 3:

Triple: Application < Is Expert In < Person

Grouping: None

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Grouping: Referenced component

Workspace: People

Reference Type: Is Expert In

Direction: Outgoing

Finally, you’ll build a complex viewpoint with fixed and flexible steps as well as grouping.

In some cases, a single viewpoint may consist of a large number of types. Use this case for visualizations like business process diagrams where we need to allow for various types of events, steps/tasks, and decision points. This does make the viewpoint model more complex.

In this case, we divide the viewpoint model into four steps, three fixed and flexible.

The first step gets the parent business process component and the first element of the process flow - the start event. The next step maps that start event to either manual or automated tasks.

The third step is flexible. This is because as we travel between the start and end event(s), we can never be certain what the next component type will be - it may be a manual task, an automated task, or a decision point - that depends on the process.

However, we do know the end of the process will be one or more end events, so the fourth step again is fixed.

The final thing to do is group all the component types we picked up in steps 2-4 by the parent component we retrieved in step 1.

Name: Business Process

Description: This viewpoint shows a Business Process Flow.

View Style: Simple Block Diagram

Workspaces: Business Processes

Viewpoint Model:

Step 1:

Triple: Business Process < Ardoq Parent < Start Event

Step 2:

Triple: Start Event > Next Step > Manual Step

Triple: Start Event > Next Step > Automated Step

Step 3:

Triple: Manual Step > Next Step > Manual Step

Triple: Automated Step > Next Step > Automated Step

Triple: Manual Step > Next Step > Automated Step

Triple: Automated Step > Next Step > Manual Step

Triple: Manual Step > Next Step > Decision Point

Triple: Decision Point > Next Step > Manual Step

Triple: Automated Step > Next Step > Decision Point

Triple: Decision Point > Next Step > Automated Step

Max repetitions: 10

Step 4:

Triple: Manual Step > Next Step > End Event

Triple: Automated Step > Next Step > End Event

Grouping: By Parent

Conditional Formatting: None

Label Formatting:

Reference: Reference Type

Defining your Viewpoints

Hopefully, the examples above have given you a head start on building new viewpoints based on your data. Using these patterns, you should be able to translate, adapt and combine to your requirements.

However, if you are struggling to define the viewpoint you need, reach out to us via our in-app help.