Process

The unfinished handover

A learner has accepted an alternative course. The case owner finishes a shift and sends the details to another team. The message arrives, but nobody accepts the work. The outgoing owner still holds the case, with nobody agreed to take the next action.

Business architecture connects the intended outcome to the capabilities, people and information needed to achieve it. The Process aspect develops how the work happens: activities, rules, decisions and handovers. Structure develops the organisation, roles and authority behind that work. Read the two together when a process change affects responsibilities or staffing.

The business example requires continuous case ownership. The data example defines the agreement and assignment history. Here we examine how people use those records and what happens when the expected handover fails.

The useful questions

Roles and authority

Describe a role separately from the person or team currently filling it. Several people can perform a role; one person can hold several roles. Record any decisions that require separate review, and make cover arrangements explicit.

Where work is delegated to a tool, specify the actions it may perform and who handles exceptions. An assistant using artificial intelligence (AI) might prepare a handover summary for the receiving person to check. That allocation should say who checks the summary and who accepts responsibility for the case.

Levels of detail

A conceptual view identifies work, responsibilities and relationships. A logical view describes triggers, decisions, handovers and exception rules. A physical view assigns actual teams, people, rosters, channels and tools.

For example, the service needs someone to own each active case. The logical handover rule requires a receiving person to accept responsibility. The implementation might initially use a shared register and a conversation, then later a task service. Both arrangements need a reliable acceptance record.

Process and cycles

A business process describes how work reaches an outcome. An architecture cycle examines and changes the design of that work. Handling a cancellation uses the process; revising its cover rules is architecture work. A slow handover may trigger either a local correction or a wider review of staffing, responsibilities and service expectations.

The cycles page connects those decisions to delivery and learning. Keep the case history and the design history linked. Where a procedure is expressed as an executable workflow or rule, the service owner approves its meaning and a maintainer versions, checks and supports it.

Handover and support

Agree how work is offered, accepted and covered in each working arrangement. A shared team queue, a supplier response and an action saved on an offline mobile device each need a clear status and a person responsible for the next step. Local capture does not establish that another person has accepted the work.

Supporting services need the same clarity. Where a cloud service routes work, identify who handles an outage, contacts the supplier, reconciles waiting work and keeps the learner informed. Agree working hours, access and response expectations across the teams involved.

The worked example applies these questions to the cancellation service and links them to its supporting systems.

Speed and quality

Observe waiting time as well as task time. Record unaccepted handovers, repeated contacts, unresolved exceptions, correction effort and workload. Compare these with the cost of staffing, training and support. A quicker task may still leave the learner waiting elsewhere.

For architecture work, observe time to settle responsibilities and effort to revise them. Over a longer period, examine whether the service remains usable through staff changes, supplier replacement and new channels. Its useful life requires a history of actual use.

The wider organisation view develops responsibility across services. Security connects access, role changes and incident responsibilities to their controls.