Task Architecture: Defining the Work Before Assigning It

A supplier has been selected and someone sends an email: “Please get them set up.” Procurement collects documents, finance checks payment details and an operational team waits to place its first order. Everyone recognises the request, but they may have different ideas about when it is complete. A supplier record can exist while the organisation is still unable, or unwilling, to do business with that supplier.

In our previous article, we considered who or what should execute work. That decision depends on another: where does one responsibility end and the next begin? “Onboard a supplier” describes a useful business outcome, but it may be too broad to assign as a single task. At the other extreme, treating every field entry as a task creates a detailed account of activity without necessarily explaining what has been achieved.

Task Architecture addresses this question of boundaries. It gives work a structure that people can understand, take responsibility for and change.

Start with a result someone else can use

Consider verifying a supplier’s identity. Opening a document, reading a registration number and comparing it with a record may all contribute to that work. Individually, they do not establish that the organisation knows who it is dealing with. A useful result would identify the supplier, record the supporting evidence and make any unresolved uncertainty visible.

That result gives the task a meaningful boundary. The person making the next decision can understand what has been established without repeating the investigation. It also prevents a misleading definition of completion. A document being uploaded proves that a file arrived. It does not prove that its contents were checked or that they support the claimed identity.

The task should also distinguish a completed check from a successful verification. Conflicting records may lead to a documented finding that identity could not be established. That can be a valid result of the investigation, while still preventing the wider onboarding process from proceeding. Defining work only around successful cases leaves the difficult ones to informal judgement.

Existing process models and operating procedures may already describe much of this. The practical starting point is to examine whether their activities have clear results and conditions of completion. There is no benefit in creating a second description merely to give familiar work a new architectural label.

Boundaries should follow responsibility

Supplier identity verification and permission to trade with that supplier are related, but they answer different questions. A supplier can be genuine and still unsuitable for a particular purchase. Separating these responsibilities allows the organisation to improve how it checks identity without silently changing who can approve a commercial relationship.

This offers a useful test for a boundary: could the method of performing this work change while the people relying on its result still understand what they can trust? If a new verification service provides different evidence or weaker assurances, the change is not confined to the executor. The task’s requirements and the decisions depending on it need attention too.

There is a helpful parallel with microservices. James Lewis and Martin Fowler describe software services organised around business capabilities, with explicit interfaces and the ability to deploy them independently. The relevant lesson here is to group related responsibilities behind a clear boundary. Simply making everything smaller is not the objective.

The comparison has limits. A business task is not a software deployment unit. It may involve conversation, judgement and several applications, while one software service may support many tasks. Describing work separately does not remove its dependencies or make every change independent.

Nor does every distinction require a separate handoff. Reading a supplier’s documents and resolving an inconsistency may be best kept together because both depend on the same context. Splitting them across queues could make each activity appear efficient while increasing the total time needed to reach a reliable conclusion.

A separate boundary becomes more useful where the required authority changes, where a result can be assessed in its own right, or where different circumstances justify a different approach. Those are reasons to examine the design, rather than rules that produce one correct task size.

Keep the whole outcome in view

Suppose identity checks are completed within minutes, but suppliers still wait weeks before receiving an order. Improving that task has not necessarily improved onboarding. The delay may sit in commercial approval, or several teams may be asking the supplier for the same information. Someone must remain responsible for the overall outcome, including the gaps between tasks.

The people performing the work are essential to finding those gaps. Procedures rarely capture every clarification that an experienced colleague makes before proceeding. Examining real cases can reveal which activities belong together and where an apparently simple handoff relies on knowledge that has never been recorded.

Task boundaries should not automatically become job boundaries either. One person may sensibly carry several responsibilities through to completion. Making those responsibilities visible can support their judgement without turning their working day into a queue of disconnected instructions.

Within NativeWork, Task Architecture provides a basis for deciding what work can be reassigned and what should remain together. An organisation might improve supplier verification using existing software, introduce AI assistance for reviewing documents, or remove a duplicated check. Each proposal can be assessed against a defined result and its contribution to the wider service.

The design itself must remain open to revision. Repeated clarification between two tasks may suggest a poor boundary. Different approval requirements may justify separating work that was previously handled together. Continuous Enterprise Evolution includes changing how work is divided, not only replacing the resources performing it.

For the supplier waiting to begin, the number of completed tasks matters very little. What matters is knowing what is still required and being able to start work once the necessary decisions are made. A useful Task Architecture should help the organisation deliver that result, with fewer hidden assumptions about what “set up” actually means.

About NativeWork

NativeWork™ is an AI-native Enterprise Architecture standard and method developed by Centipod. It places work at the centre of enterprise design and provides an architectural foundation for Continuous Enterprise Evolution.

WorkML™ is the accompanying language for expressing NativeWork architectures in a form designed for both people and intelligent systems.

Learn more at nativework.org.

NativeWork™ and WorkML™ are trademarks of Centipod. Trademark applications are pending.

This article was created by people. We have used artificial intelligence (AI) to help articulate our message and refine the text. AI was employed as a tool to assist with structuring, identifying grammatical and spelling errors, and improving readability. The final document has been carefully reviewed and approved by our team.

© Centipod B.V., 2026