Ardoq’s Business Process Management (BPM) Solution enables organizations to document the business processes and the activities (the “how”) within an organization and then connect them to the EA graph.
By capturing and analyzing your processes across the organization, you can realize several benefits associated with clearly understanding your processes and how they connect to the rest of the Enterprise Architecture.
This metamodel article discusses the components, references, and fields of the Business Process Management solution.
To learn more and better understand the foundation for the method, please refer to the Business Process Management: Purpose, Scope, and Rationale document.
Content
Business Process Management - Metamodel Overview
Business Process Management Metamodel
Business Process Management
At its core, the Business Process Management Solution focuses on:
Documenting Processes and how they fit into a Process Framework
Determining if detailed Process Activities are necessary
Establishing the connection between processes, process activities, and the rest of the Enterprise Architecture
Maintaining process information
Process Library Workspace
Process Category
The Process Category component is adapted from the generic Category Component, which is used to organize components into a categorized hierarchy. As covered in the BPM Purpose Scope and Rationale it is similar to the Category and Process Group in the APQC framework and allows for a clear distinction between the process and the grouping structure.
Process Category Fields
Field | Field Type | Description |
Name & Description
|
|
|
Component Level | Calculated Number Field
| Used to create a simple number level used for filtering. An example when this is valuable is when you would like to create a view that only shows Level 3 or higher process categories. |
Process Component
The Process component is used to represent a series of interconnected activities or tasks that transform inputs into outputs, following a defined sequence and set of rules. It represents the operational flow of activities within an organization. It is like a recipe, with a series of steps and instructions that -lead to a desired outcome.
Processes are typically expressed in verb-noun format e.g., Receive Order or Ship Product, and they focus on the sequence of activities required to complete a particular task or deliver a specific output. They provide a detailed, operational view of how work is performed within an organization and are often assessed to improve performance, automation, and compliance purposes.
Process Fields
Several metadata fields are used to capture process attributes to help better classify and understand what the process is and how it is functioning in the organization.
Field | Field Type | Description | Definition |
Process Description |
|
|
|
Process Diagram | URL Field |
|
|
Percent Automated
(on Process component) | Calculated Number Field | A measure of how effective the process is based on a 1-100% scale | Calculated by assessing the automated and manual steps of the underlying process activities and returning that in percentage scale out of 100 |
Maturity | Number Field | A measure of how complete and optimized a process is | ( 1 ) Initial ( 2 ) Under Development ( 3 ) Defined ( 4 ) Managed ( 5 ) Measured
Scoring follows the ACM Model from TOGAF |
PII | Calculated Checkbox | Identifies if a process has any activities that process Personally Identifiable Information | Calculated by checking if any referenced process or process activities have a reference to a data entity that has a Confidentiality field value of Confidential or Restricted |
Total Duration (Min) | Calculated Number Field | Used to represent the Total Duration of the process based on the aggregated duration of the referenced process activities | Calculated by aggregating the duration field of all child process components or by the duration field on the process if there aren’t any child process activities |
Duration (Min)
(only needed if not capturing process activities) | Number Field | Used to capture the duration of the activity in minutes |
|
Cost (Optional) | Number Field | General cost field that can be used to understand cost associated with the process |
|
Total Duration & Duration Fields
To capture the duration of a process or a set of activities, we use the Duration number fields. If processes are mapped to underlying process activities we recommend using the Total Duration calculated number field on the process component. This field will aggregate the duration of the process or all children process activities. If you are not mapping process activities to your processes then the Duration number field should be sufficient.
Process Governance Fields
Field | Field Type | Description | Definition |
Approved | Checkbox | Used to indicate whether a component has been reviewed and acknowledged as being accurate and complete |
|
Review Date | Date Field | Used to indicate the date at which a component was reviewed and acknowledged as being accurate and complete |
|
Process References
Outgoing References | Description |
Is Supported by (Process → Is Supported By→ Process) | Provides the linkage between Processes that depend on other processes or sub-processes |
Is Supported by (Process → Is Supported By→ Application) | Used to illustrate the relationship between the process and the technology that supports it. |
Accesses (Process → Accesses → Data Entity | Used to illustrate which data is leveraged during a process. Can be mapped at the process activity level for granular detail. |
Sub-Processes
Sub-processes are like activities, but ones that themselves are further broken down into constituent activities. We use the Process component type to represent them, but in all other respects, they can be considered similar to Process Activities. We model these sub-processes as Processes that support self-reference with the Is Supported By reference, allowing these processes to support multiple Processes.
Incoming References | Description |
Consumes (Organizational Unit → Consumes → Process) | Used to connect the process to the departments, teams, or groups within the organization that rely on the process |
Owns (Person / OU → Owns→ Process) | Used to show ownership/responsibility of the process. This should be from a Person. It can also be to an Org Unit, Team, Department etc. |
Is Realized By (Business Capability → Is Realized By → Process) | Used to connect the Business Capability to other components in your architecture that help realize it, such as; Process, Technology, Organization, etc. |
If there is a need for greater fidelity in your process ownership, check out the Process Playbook: Application Ownership for a more detailed ownership assignment process.
Process Activity Components
As articulated in the Business Process Management: Purpose, Scope and Rationale, our recommendation is to capture and document connections at the Process level. However, sometimes, there is a need for greater fidelity. Based on the needs of the organization, those connections can be made at the Process Activity level instead of the Process level.
Process Activities are the operational tasks that support the Process. Because Process Activities are often unique to the process itself, they are represented as children components of the Process.
Process Activity Fields
Field | Field Type | Description | Definition |
Process Activity Description |
|
|
|
Activity Type | List Field | Identifies what type of process activity it is following the BPMN task types
| Automated
Manual
|
PII | Calculated Checkbox | Identifies if the activity accesses any Personally Identifiable Information | Calculated by checking if this process activity has any reference to a data entity that has a Confidentiality field value of Confidential or Restricted |
Duration (Min) | Number Field | Used to capture the duration of the activity in minutes |
|
Cost (Optional) | Number Field | General cost field that can be used to understand cost associated with the process |
|
Process Activity References
Outgoing References | Description |
Is Supported by (Process Activity → Is Supported By→ Application) | Used to illustrate the relationship between the process activity and the technology that supports it. Mapped at the activity level for granular detail. |
Flows To (Process Activity → Flows to → Process Activity | Used to represent the flow or sequence of various activities in the process |
Accesses (Process Activity → Accesses → Data Entity | Used to illustrate which data is leveraged during the activity. Mapped at the activity level for granular detail. |
Roles
Roles Workspace
The roles domain workspace classifies the capabilities, competencies, and behaviors required from people, teams, or organizational units without specifying who will fulfill them. The main component type in this workspace is Role.
Role Component
A role represents the set of skills, competencies, behaviors, or responsibilities a person or organization needs to demonstrate while fulfilling their duties. Roles are used within the Business Process Management solution to illustrate who participates in the processes or the activities. This information is captured via the RACI field on the assigned reference.
Outgoing References |
|
Assigned To (Role → Assigned To → Process / Process Activity) | Used to connect the key roles that perform various parts of the process(es) |
Incoming References |
|
Assigned To (Person → Assigned To → Role) | Used to connect the people who are fulfilling the role |
Assigned To Reference Field
To better understand how a role engages with a process or activity, the Assigned To references carry a field to capture that classification.
Field | Field Type | Description | Definition |
RACI (Role → Assigned To → Process / Process Activity) | List Field | Uses the RACI classification to identify what type of engagement is needed with roles associated with the process or process activities |
|
Gremlin Queries
Below are the gremlin queries needed to support the calculated fields for business process management.
PII
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
choose(
repeat(
timeLimit(50).
union(
__.in('ardoq_parent'),
out('Accesses')
).
simplePath()).until(hasLabel('Field' , 'Data Entity').has('confidentiality', within('Restricted', 'Confidential', 'Internal')),
),
constant(true),
constant(false)
)
)
Percent Automated
g.V(ids).where(__.in('ardoq_parent').has('activity_type')).
project('id', 'name', 'value').
by(id).
by('name').
by(
choose(
__.in('ardoq_parent').has('Process Activity', 'activity_type', within('Service', 'Script', 'Business Rule', 'Send', 'Receive', 'User', 'Manual')),
project('automatedCount', 'manualCount').
by(
coalesce(
__.in('ardoq_parent').has('Process Activity', 'activity_type', within('Service', 'Script', 'Business Rule','Send', 'Receive')).count(),
constant(0))).
by(
coalesce(
__.in('ardoq_parent').has('Process Activity', 'activity_type', within('User', 'Manual')).count(),
constant(0))).
math('automatedCount / ( automatedCount + manualCount) * 100').
map{it -> it.get().round()},
constant(0)))
Total Duration
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(choose(__.in('ardoq_parent'), __.in('ardoq_parent').values('duration_min').sum(),
choose(__.not(__.in('ardoq_parent')), values('duration_min').sum(),
constant(0))))
Document Version
Version | Date | Responsible | Rationale |
1.0 | 7/26/24 | Jon Scott | Published |
1.1 | 12/17/24 | Leart Kollqaku | Updated metamodel diagram |