Organizational Patterns

The Organizational Modeling Patterns document describes and illustrates various types of common organizational structures. Depending on the structure of your organization, this document should help guide you through the best way to structure your organization in Ardoq.

Understanding the Organizational Modeling Metamodel principles will help you adapt or extend the patterns below to your own needs. If you haven’t already, we strongly recommend reading our Organizational Modeling Guide and Organizational Modeling Metamodel article to understand the building blocks of Ardoq’s metamodel as it applies to Organization. Reading the two documents is a logical starting point before modeling your organization that will help you to understand the various patterns.

Ardoq’s native flexibility allows you to use the Ardoq Organizational Modeling Metamodel to suit the needs of your organization. The Metamodel includes several patterns to get you started in mapping your organization for your stakeholders and to support future use cases.

We have tested our Metamodel with many types of organization structures and groups. If your model is different from what is shown below, you can find a similar model that will translate to match your requirements.

Stand-alone structure is for an organization that typically consists of a single root organizational node and then underlying children Organizational Unit components.

These Organizational Units can represent business units, divisions, departments, teams, and groups. It should be created in a single workspace for these reasons. If you have multiple lines of business or your organization is broken down into subsidiaries, then see the conglomerate organization pattern below.

Use this pattern to model single companies with any category of organizational structure. Whether a hierarchical, flat, or matrix style, these can easily be modeled following a stand-alone organizational pattern.

Benefits to Modeling this way:

This creates a simple and proven way to model your organization.

Limitations:

To accommodate Organizational Units that represent short-term project teams or groups, you may need to include a ‘belongs to’ reference type in the Organization workspace.

For Conglomerate Organizations or Organizations made up of multiple lines of business, Ardoq recommends modeling the holding company and each subsidiary in individual workspaces and utilizing the “owns” reference type between the organizations. This will allow the architect to model the General and Administrative functions like Group HR, Group Finance, Legal, and Executive Management in the workspace as the parent organization. This also means that you can model each child organization according to its needs and requirements.

Modeling this way allows you to leverage workspace level permissions for each organization, meaning each organization can be responsible for ensuring their organizational data is current and accurate.

Use this modeling pattern if you have multiple lines of business or your organization is broken down into subsidiaries.

Benefits of Modelling this way:

This creates a simple and efficient way to model your organization.

The Conglomerate Structure allows architects to assign relevant permissions for Company/Divisional Owners while allowing read-only permissions to the other divisional owners for visibility.

Limitations:

A ‘People’ Workspace may become too cumbersome due to the number of people in a large organization. This might also be compounded if each child company or division utilizes their own HR system making the importation task a challenge in a single workspace. The practical solution would be to create a ‘People’ workspace for company/divisional.

Project teams that stretch across organizations need to be accommodated using a ‘belongs to’ reference type. This reference type will need to be created in each of the relevant organization workspaces.

These are typically cross-functional or short-lived teams or groups of people within your organization that are brought together to deliver an initiative but are not typically a part of the organizational structure. Examples could include groups of people brought together as part of a value stream, scrum, swarm, internal or external projects, Joint venture project teams, M&A activities etc.

Note that an additional reference type “Belongs to” is required and it should be added to the People workspace.

On the topic of modeling an organization, we are often asked: "what is the best way to model applications in a conglomerate-style organization?" Our advice is to model applications in a single workspace and to use references from the relevant Organizational Unit for the applications. This will dramatically simplify the management of your organization and the applications.

We recognize that sometimes organizations have specific requirements (regulatory/security) to create additional workspaces for applications that relate to a particular subsidiary to limit the accessibility of application information. In this case, Ardoq advises you to keep the number of application workspaces to a minimum.

Hopefully, the examples above have given you a head start on building your organization 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 model your organization effectively, reach out to us via our in-app help.