Whichever domain of your architecture you’re modeling - from business processes to applications to cloud services - sooner or later you’re going to want to capture data about people and the relationships they have with those things.

It’s common, for example, to want to model responsibility, like the ownership of an application. Or to model skills by capturing the expert in a business process. Or even to capture the direct relationship between two people, like the fact that one person reports to another.

Maybe you already do that by capturing email addresses in your application lists, or by building RACI matrices or stakeholder maps

So how do you model that information in Ardoq?

Let’s start with some good practice. In Ardoq, we strongly recommend you model people as distinct components in themselves, not just as a field - for example a name or email address - on another component type.

Why? There are a couple of reasons.

Firstly, it’s efficient modeling: You end up storing the same data once and only once.

For example, let’s say Johan Steinmann (email address johan.steinmann@myorg.com) is the owner of three applications and six business processes. We might record his name and possibly his email as properties (i.e. fields) of those applications and processes.

But then Johan leaves - he gets a better-paid job elsewhere. Now we have to update fourteen components with the name and email address of the new owner or owners.

But it’s quite likely we miss updating the data in one or more places - for example, we update the applications but not the processes.

Now our process data is out of date because we have to manage the lifecycle of people data in many different places.

But there’s another related reason why we want to model people as components: Because it enables us to get a 360-degree view of each person, their responsibilities and expertise.

This isn’t just useful so we can easily see everything a person is connected to - for example, all the things Johan owned so we can reallocate his responsibilities.

It also enables us to create value for each person by creating personalized user experiences. For example, we can create views that combine all the elements they have a relationship with - like Johan’s applications and processes - in a single place. Or we can route messages to them based on their direct interests.

So we strongly recommend that you set up a People workspace with Component Types of Person as the basis for modeling stakeholders.

See the latest information on Modeling Roles

It’s not always the case that you want to model named individuals. Sometimes you want to abstract responsibilities, skills and behaviours to make models re-usable. In this case you can model Roles as a distinct component type.

A role represents the set of skills, competencies, behaviors or responsibilities a person or organization needs to demonstrate in the course of fulfilling their duties.

Crucially, like any logical component, a role specifies that the characteristics of that role are without specifying how they are realized - or in this case, who fulfills them.

Role modeling enables architects and analysts to allocate activities, responsibilities or behaviours at design time, to what people are required to do, or to analyze issues with current activities, responsibilities or behaviours.

For example, it’s common in business process modeling to map roles to process steps or tasks and, for example, to use swimlanes to show the hand-off between different roles.

To understand the who, people components can be mapped to role components to show how those roles are realized or fulfilled.

It’s important to distinguish between modeling roles and modeling responsibility and expertise.

In many cases you don’t need to model a Role to understand who is responsible for what, or who is an expert in what.

Instead, here we use References to show the specific relationship a person has with another thing - for example:

Johan Steinmann (Person Component) - Owns (Reference) > CNC Production Setup (Business Process)

Zhen Chang (Person Component) - Is Expert In (Reference) > Data Loss Prevention (Technical Capability Component)

In these cases we don’t need to specify that Johan has the Role of Business Process Owner or that Zhen has the Role of Security Analyst in order to describe their relationships with those other components.

But we might want to model that as well, for example:

Johan Steinmann (Person Component) - Owns (Reference) > CNC Production Setup (Business Process)

Johan Steinmann (Person Component) - Assigned To (Reference) > Process Manager (Role Component)

That’s absolutely fine. But what we don’t want to do is to model a role component between Johan and CNC Production Setup, i.e.

Johan Steinman (Person Component) < Assigned To (Reference) - Process Manager (Role Component) - Owns (Reference) > CNC Production Setup (Business Process Component)

Why not? Well, look at what happens when we add another Process Manager

Philipp Sorg (Person Component) < Assigned To (Reference) - Process Manager (Role Component) - Owns (Reference) > Inventory Audit (Business Process Component)

Both Johan and Philipp are connected to the Role Component Process Manager, and Process Manager owns both CNC Production Setup and Inventory Audit.

But now we can’t tell whether Johan is the CNC Production Setup owner or whether Philipp is, because we’ve lost the direct connection.

For that reason, we model responsibility or expertise as a direct reference between a person and the components they are responsible for or expert in.

The first step in modeling people, roles and responsibilities is to create a People Workspace in Ardoq.

This can be manually populated, for example, by uploading a spreadsheet.

But given how fast your people data can change, we recommend you consider integrating with a master source of people data in your organisation, such as your Human Resources or Single Sign On applications.

Ardoq offers our own Active Directory Microsoft Entra ID Integration to enable you to automatically populate and update your People Workspace.

However you choose to start, getting your people modeled as objects in themselves in Ardoq is the first step in making your architecture highly relevant to your stakeholders, and grounding your insights and the decisions they drive in your organization.