Follow one work item from request to completion
A work item should retain its purpose, responsible role, deadline and history as people offer, claim, release, complete or escalate it.
Open BPM
Keep work moving without losing who did what
Open BPM is developing a reference component for creating, assigning, completing and recovering human work. It will provide public interactions and a usable interface; neither has been built yet.
Open BPM
Follow one work item from need to completion
A reference component with an API and a usable interface
The proposed component should own work state and history while exchanging defined information with domain, identity and rule components.
Commands ask for change; events report accepted facts
Public interactions should say who is asking, what they want, which work they mean and how later changes relate to the original request.
Support work that can take hours, days or weeks
Support staff need to find stuck or overdue work, distinguish business refusal from software failure and recover without erasing history.
Open BPM glossary
Plain explanations of the work-management and interface terms used on this site.
Start with a rebooking work item
A service cancels an appointment. A scheduling team needs to offer a new date within five working days unless the person has asked to close the case.
A future Open BPM component could create a rebooking work item, place it in the scheduling queue and let an eligible person claim it. The component would record the offer date, escalate overdue work and retain the request, actor, time and result for every accepted change.
Manage processes, cases and individual work
Business-process management (BPM) is the practice of organising, carrying out and improving work across people and systems. A process follows a route known well enough to define in advance. A case changes route as facts and human decisions emerge. A single work item may still need an owner, deadline and recorded result even when it is not part of a larger process.
Open BPM is intended to support all three without making every kind of work use the same model.
Provide an interface as well as an API
Other software needs defined requests so it can ask Open BPM to create work, and events reporting accepted changes so it can respond. People need a clear interface showing available work, responsibility, deadlines, history and the next action. Support staff need to find work that is stuck and recover it without silently rewriting the past.
The first reference component should test these surfaces together. A technically correct service with no usable participant or support view would not satisfy the proposed role.
What exists now
Open BPM is the reactivated reference implementation programme for the work, case, workflow and decision component family described by Architecture Portal. Historical architecture and design material provide useful questions for this new direction. The new reference component, API, service and interface have not yet been implemented, and no deployable Open BPM component exists. Open BPM makes no current standards-conformance claim. No Open BPM integration with cREXX or CoreLang exists. Earlier middleware and enterprise-platform examples belong to the project’s history and are not current recommendations. Public Purpose Lab may supply a synthetic scenario for the first reference implementation; it has not yet done so.
Related work
What other projects contribute
- Architecture Portal defines the logical component role that Open BPM proposes to implement.
- Public Purpose Lab may supply a synthetic situation for the first demonstration.