OWL: Open Workflow Light

A technical overview

Workflow and business processes

• There are many processes and tasks that have the need for some kind of workflow

– E.g. Insurance claims, New customer processes, Call centres

• We contrast workflow with task management in that:– workflow always involves more than one person, and – there are often decisions or rules as to where the work item should next go– Traditional workflow has previously worked well in industries with well-defined processes

and organisational structures

• Workflow is often represented by Business Process Modelling (BPM) or Workflow applications

– Most of the major vendors and many specialist vendors have a workflow or BPM offering– These are often very expensive and always have a large footprint

• We think there is another simpler and cheaper way – We acknowledge OWL is not suitable for all situations but believe it is applicable to a large

number of cases– Read our non-technical interview at http://www.truenorth.gb.com/products/owl

Slide 2

Typical workflow design and implementation

• The workflow is usually modelled in the tool by a Business Analyst

– Involves identifying steps, roles, and conditions for moving between steps

• The IT department deploy the modelled workflow on to a server running the workflow application

– This may involve data migration from old workflow processes

• The business users interact with the workflow

• The workflow engine– Determines the state change of the

process– Notifies users of actions

Slide 3

OWL: Open Workflow Light

• OWL was developed to meet the gap in a simple workflow tool. Its key principles are below:

• The user knows best– The user best knows how and where to route items in the process and they not

the workflow tool should not dictate where the task goes

• Keep a full audit trail– It’s more important to understand what has happened to a task rather than where

it will go.– Not only might this be needed for regulatory compliance but it can also aid a user

in deciding what to do next

• Fit in with the users’ working methods– The tool should integrate with the end users’ working methods not the other way

around

Slide 4

Workflow Functional Architecture

• Most workflow solutions support the following as a minimum set of functions. The sub-bullets are examples of features in those functions rather than an exhaustive list:

• Define– Design and edit workflow templates. – Identify the users and roles in the process and apply to the templates

• Act– Create and manage the state of workflow instances– Migrate processes from one definition to another

• Notify– Let workflow participants know when they have actions to perform– Allow flows of interest (sometimes instances of interest) to be watched

• Monitor– Examine the workflow for bottlenecks and potential improvements– Report on the metrics of process enactment

Slide 5

OWL: Functional architecture

• DEFINE– Search and tagging seen as more important in letting users classify and

find instances– NO PROCESS DEFINITION. Processes defined by users’ actions not

by the application• ACT

– Simple state management and listener-style approach to notification– Audit trail allows users to infer and understand business process

Slide 6

• NOTIFY– Integrate with tools that the users has access to

and understands– Don’t make the user learn the application but

instead fit in with existing standards• MONITOR

– Dashboard and metrics with simple reports are mandatory

– Provide the means to hook up alerting (via API and also by integrating with microblogging & chat apps)

Integrating with OWL: How and why

• All functions exposed through Java API

– Greatest cross-platform support– APIs designed for extension so advanced

users can add features

• Most functions exposed through HTTP API

– Allows OWL to be accessed as a remote service – i.e. Where workflow is part of the solution not the whole solution

• Notification and alerting supported through SMS, Email, and XMPP (chat)

– Provides the greatest flexibility for the end user

• All data exportable via CSV – For maximum portability with BI tools and

custom applications

Slide 7

Methods of integrating with OWL

OWL: Design principles

• Partition vertically– Separate modules for each of the functional areas (Definition, Action, Notification,

Monitoring)– Minimise dependencies between modules– Allows them to be switched out / replaced more easily

• Partition horizontally– Code to interfaces to enable layers to be switched (e.g. Traditional relational store to be

switched in)

• Hide implementation detail for “pure” consumers– Provide full integration but hide Java implementation (through HTTP interface)

• Hide data model in API– Data model is exposed only through its export format (CSV) and the actions that can be

taken on objects– Allows data model to be changed or enhanced more easily

• Minimize data held in cookies or sessions– Make it easier to replicate and scale by minimizing session-specific data

Slide 8

Contact us

• Please feel free to contact us if you’d like to use or extend Open Workflow Light

• We’re also interested in any feedback you might have on this presentation or OWL

• web: www.truenorth.gb.com/products/owl • email: sid@truenorth.gb.com• twitter: truenorth_buzz

Slide 9