Many aspects of enterprise architecture work require building connections. The Organization Modeling Metamodel shows how the traditional business and application architecture concepts connect with the organizational entities that own, develop, and maintain them. We're also providing the Organizational Modeling (OM) metamodel to connect organizational components with the other use cases to capture who owns, maintains, and delivers change.

Organizational Modeling documents the relationship between the external and internal organizations and an organization’s components. To fully understand how your organization delivers on its strategy, realizes its capabilities, and measures the impact of change, it is important to connect organizational structure to the other business and application architectures components. These components primarily show what structures exist within the organization and where people are placed within that structure.

Ardoq recognizes that there may be many organizational structures, and these can be broken down into 3 main structural types. The Organization Modeling Metamodel was developed for flexibility and to cater to the three broad organizational structure approaches.

These are:

The Organizational Model also considers that organizational structures can be long-lived or temporary (Cross-Functional or Project teams) within an organization. The Organizational Modeling Metamodel considers both stand-alone (single) or conglomerate (multi org) organizations in the metamodel development.

The Organizational Modeling (OM) metamodel defines how organizations can model their enterprise. The OM can also assist in documenting the relationship between organizational entities: business units, departments, teams, groups, or value streams and business capabilities, applications, and infrastructure components.

Organizational Modeling assists organizations in addressing the following:

Additionally, Organizational Modeling is an aspect of Enterprise Architecture that enhances other use cases like Application Lifecycle Management, Application Hosting, Business Capability Modeling, and IT Lifecycle Management. Organization Modeling further enables organizations to understand and communicate where the impact of change may be realized.

Organizations are composed of many combinations of traditional or modern structures. Our metamodel allows architects to flexibly map out Divisions, Branch Offices, Departments, Business Units, Teams, Groups, Committees, External Parties, etc.

While we recognize that there may be many types of organizational structures, broadly speaking, these can be broken down into 3 main structural types, which are the focus of this Metamodel.

These are:

Organization's extensive partner networks which they rely on to deliver services to their employees and customers could also include a fourth organizational type, Networking. The network structure relies on other organizations to perform critical functions on a contractual basis. This latter type can be easily modeled in Ardoq by creating the relevant reference type between organizations or organizational units.

Ardoq can address all three of these categories through the Organizational metamodel. Further, hierarchical organizations can be broken down into more simplistic stand-alone organizations and highly complex conglomerates. Additionally, it does not matter if organizational structures are long-lived or temporary (Cross-Functional or Project teams) within an organization to be in scope for Ardoq to address.

Our metamodel approach works for all structures we've tested and is flexible enough to apply to any combination of these structures in practice today.

This Metamodel guide focuses purely on the internal structure of the organization. This allows architects to focus primarily on how the internal organization is composed and the relationship between organizational structure and how it impacts the internal business and IT ecosystems.

The scope of this Ardoq Metamodel focuses on the Organization and Organizational Unit component types. The model considers that people own (through management) Organizational Units and People and that People belong to Organizational Units. These connections allow you to focus the organizational modeling metamodel primarily on organizational structures and the relationships between organizations rather than on human resource management, a practice outside Enterprise Architecture.

Our rationale for the Organizational Modeling metamodel is to handle the broadest set of scenarios possible with the minimum number of metamodeling concepts. Learn more about this principle in our Principles of Creating a great Enterprise Architecture Metamodel.

Metamodel concepts need to be abstract in order to handle such a wide range of situations. The broader range makes the metamodel applicable in more situations. However, it may take more time to understand initially.

With these principles in mind, the metamodel which consists of three components (Organization, Organizational Unit, and Person) is similar to the Business Architecture Guild's organizational Modeling.

To reduce the complexity of modeling an organization, we advise starting with a minimal amount of components and component properties. Ardoq's metamodel is focused on two main components: Organization and Organizational Unit. The addition of the Person component type completes the Organizational Modeling metamodel.

Modeling the organization can be carried out as an implicit task or organic task which can take place alongside the modeling of other use cases like Business Capability Modeling or Application Lifecycle management. If you are an organization with an HRM solution, we would suggest re-using the organizational data through an import as an implicit task. Suppose your organization does not have this data available. In that case, you could try to utilize the excel import template or organically grow this organizational model through manual entry as you focus on other use cases.

Ardoq recommends using an Organizational Unit to simplify the Metamodel. It can represent Business Units, Divisions, Branches, Groups, Team as a single component. Organizational Units can be Structural or Functional in nature and either long lived or short lived. The Organizational Unit component simplifies the decomposition of an organization, and this approach is similar to the Business Unit component used by the Business Architecture Guild.

Understanding the Organizational Modeling Metamodel

This section will walk through the different component types, fields, and reference types that make up the metamodel for Organizational Modeling.

Organizational Modeling comprises three main component types: Organization, Organizational Unit, and Person.

Organization is the top-level node representing the main organization or external organizations. Where possible, each organization should be modeled in a separate workspace. This focuses the workspace on the relevant organization. It also allows any potential communications or data collection through broadcasts and surveys to be focused on the relevant organization. While this creates additional overhead in terms of management of workspaces it allows architects to work within Ardoq to focus the collaboration of each organization to a particular workspace.

If you need to model a conglomerate type organization check out the patterns document for details on how to model this organization structure.

All Organizations will have pre-defined fields including Name and Description. Name should be unique wherever possible. Having an accurate Description is also very valuable as it should give others some idea of what the organization does.

Organizational Units decompose into business units, departments, sub-organizations, committees, teams and groups to enable the creation of organizational hierarchies. This can often take the form of structural (hierarchical) and functional entities within an organization, which can be documented by using the Organizational Unit component.

Structural examples include: Divisions, Branch Offices, Departments, and Business Units.

Functional examples include: Cross-Functional Teams, Committees, and Workgroups.

Furthermore, the Organizational Unit component can be either structural or free-floating and they should be modeled in the same workspace as the Organization.

However, when an organizational unit is part of a project or joint venture between two or more organizations, Ardoq recommends modeling these as stand-alone components in a separate workspace where the “Belongs to” reference can be used to link the respective organizations or organizational units.

All organizational units should have a Name, and that name should be unique wherever possible. Having an accurate Description is also very valuable as it should give others some idea of what the organizational unit does.

Person is a named individual in the organization. In enterprise modeling, a person is usually represented when they have a defined relationship with one or more other component types. For example, the CFO owns the Finance Department and reports to the CEO.

All persons should have a Name and Contact Email is essential to capture as this enables a destination for Surveys and Broadcasts.

The other key points of data capture are made by connecting references between the Organization, Organizational Units, and People to represent the organization's structure.

References ensure data quality and consistency by avoiding duplicating data in your model.

Parent/Child

To model the structural hierarchy of an organization and its organizational units, we recommend using the Parent-Child reference type. This reference represents that one component is an exclusive part or sub-component of one other component, and not of any other components.

Belongs To represents that a component is part of or a member of another component for another component or components.

Owns represents that a component has overall responsibility for another component or components.

Ardoq uses this reference type to identify the person to send broadcasts to.

For example, in Organizational Modeling, the person who has decision rights and responsibility for the specific Organizational Unit might also be responsible for the underlying departments (Organizational Unit).

Reports To

Represents that a person or organization reports to or is accountable to another.

In many organizations, it’s common for an individual to have different reporting lines - for example, a structural manager (Reports To) and a functional Manager (Reports To).

The reports facilitate where resources from one department are required to assist in the delivery of a project or change initiative. A typical example of a functional manager would be a Project Manager.

In the example above, we use the reference’s display text to indicate a structural reporting line (Reports To) to Jane Smith in the Finance Organizational Unit and a functional management line (Managed By) to Sam Smith in the project management office.

As Organizational Modeling is an enabler for use cases, it is likely that the structure will have to be created from scratch. For stand-alone organizations, it is recommended to create two workspaces. One will be for your Organization, and the second workspace to contain your people.

The Organization Workspace will contain your Organization and Organizational Unit components that will use a Parent-Child reference type. The second workspace will contain the person component type.

Three references will need to be made:

For conglomerate organizations, it is recommended that you review the Organizational Modeling Patterns Knowledge Base Article here.

Ardoq recommends using the fewest number of workspaces when modeling your organization. This simplifies the administration and management of your enterprise model and allows the architect to focus their attention on other areas of value. The picture below illustrates the workspaces and their relations used to implement the Organizational Modeling.

Extending your Organizational Modeling Metamodel

What if you want to add more data points to your Organizational Modeling data capture?

If you would like to extend the fields to your organization components, you may consider adding the following fields to your data. Organization Type allows enterprise architects to capture whether or not it is the internal organization or external organization. The internal organization represents each enterprise or organization within your legal structure, including subsidiaries. External Organizations are those that sit outside your legal structure.

You may also want to extend the fields to include Organization Number (the legal Registration number associated with that organization). Still, Ardoq recommends keeping the number of fields to a minimum.

The beauty of Ardoq is its flexibility. For example, adding new fields can be done by an administrator in seconds - see this article for information on adding fields.

An administrator can also easily create a new component and reference types, although we suggest you plan this process carefully: Over-complex metamodels are more difficult to navigate and query.

Before you extend your metamodel, ask yourself:

With those considerations, you can quickly adapt your model to changing requirements. You can keep your critical data up-to-date and maintain your insights, keeping it continuously relevant as requirements evolve.

We're always happy to help. Feel free to reach out to us via the in-app chat if you have any follow-up questions about this article.