Overview
In this step, the identified organized processes are detailed to provide a comprehensive understanding of their sub-activities. This level of detail helps to capture the intricacies of each process and its associated activities.
As for all dependency mapping steps of the methodology, the Service Owner is accountable for this activity
and relies on business and IT SMEs. It is thus mandatory for architects to first get in touch with the
Service Owner and the Operational Resilience Manager prior organizing any workshop.
Activities and Business Functions
The processes are broken down into activities, which are modeled as ArchiMate Business Functions[1].
These activities represent the specific tasks and actions required to execute the processes effectively.
The identification and documentation of activities involve a collaborative effort between process owners,
and SMEs such as Enterprise/Functional Architects, Business Analysts and Product Owners. It requires a
deep understanding of the organized processes and their associated activities to ensure accuracy and completeness.
8-Step Workshop Approach
Here is a simplified approach to process modeling[2]:
- Define scope. Make sure the scope of the Vital Service and the goal of the workshop are clear for all people involved in the modeling workshops.
- Identify the starting event. Identify the starting point of the process. It is usually described as an (external or internal) event.
- Identify ending events. Identify the ending point(s) of the process, also modeled as events.
- Identify activities. Identify the different activities. Usually, an activity is performed by one actor, is related to one key information, and pursues one single goal. Make sure to document these activities.
- Assign actors. Clarify which actor performs each activity. In some contexts where activities are fully automated, the actor is not a human but an application.
- Map applications. Clarify which applications are used by actors for each activity.
- Group into sub-processes. If the number of activities is higher than ~10, it usually makes sense to group them into sub-processes. This makes it easier for people to analyze the process at different levels of detail. It also makes it easy to create a simplified version of the process description that can be used on top of the end-to-end application flow diagram.
- Define process flow. Define the "process flow" (i.e., in which order activities are performed) and potential related decisions (i.e., splits in the process where the flow of the process is decided by some qualifier).
- Each activity should be well named (the name should clearly indicate a well-defined behavior, use action-verb and also describe the main business object impacted by the behavior) and documented (short description that non-SMEs can understand).
- Events name should use a verb in the perfect tense and should describe the main business object related to the event.
- Use triggers between activities to denote the "process flow". Triggers don't have to be named, except when several triggers enter or exit an activity, in which case the name of the triggers reflects the conditions/decisions related to the splits.
- Business Actors are usually best labeled using generic names reflecting the role that people play in the process, and not the actual name of the team doing the job.
Manual vs. Automated Activities
The organized process description should not be limited to activities performed with the assistance of an application and should thus also include important activities which are performed manually.
- Each activity should contain a property named
Operation (nominal) set as either Manual (i.e. fully manual) or Automated (i.e. supported by one or more applications).
Architecture Viewpoints
For simple processes (or as a first step in an iterative approach), use a business process diagram[3] to depict the simplified process flow.
For complex processes, organized process diagrams[4] can be created to visually represent the sequence of activities and the roles involved. These diagrams provide a clear and concise overview of the process flow.
Example: Process Flow Diagram
The following diagram illustrates the process flow for the Cash Payments - Outgoing process, showing activities, decisions, and sub-process groupings.
3. Cash Payments - Outgoing (Process Description)
Example of a BPMN-style process flow diagram
Payment
Instruction Sent
→
→
Receive Instruction
Assignment / Manual input of payment information
Signature check / Call back check
(if SSI issue) ↓
Check Electronic Payment Order
→
Coherence Checks
4 eyes check and validation
Check details / Request authorization
Credit Risk Check
6 eyes check and validation
Treasury Announcements
Compliance Check
→
Change
→
Repair of Instruction
/ Release of alert
←
Payment release
→
(compliance alert)
Compliance Alerts
Handling
Level A checks
Twist B1 checks
Compliance B2 checks
Compliance C checks (Group)
(reconciliation issue)
Regulatory Reporting
Emission
→
Financial / Accounting
Positions Update
Activity / Sub-process
Coherence / Update step
◇ Decision / Branch
Footnotes
- ArchiMate Business Functions represent a collection of business behavior based on a set of criteria such as required business resources, competencies, or location.
- This approach is based on industry best practices for business process modeling and can be adapted based on the complexity of the process.
- Business process diagram — a simplified view focusing on the sequence of activities without swimlanes.
- Organized process diagram — a detailed view showing the sequence of activities along with the roles/actors that perform them.