Owl Technical Overview


Published on

Technical overview of OWL (Oper Workflow Light) a lightweight workflow tool.

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Owl Technical Overview

  1. 1. OWL: Open Workflow Light A technical overview
  2. 2. Workflow and business processes <ul><li>There are many processes and tasks that have the need for some kind of workflow </li></ul><ul><ul><li>E.g. Insurance claims, New customer processes, Call centres </li></ul></ul><ul><li>We contrast workflow with task management in that: </li></ul><ul><ul><li>workflow always involves more than one person, and </li></ul></ul><ul><ul><li>there are often decisions or rules as to where the work item should next go </li></ul></ul><ul><ul><li>Traditional workflow has previously worked well in industries with well-defined processes and organisational structures </li></ul></ul><ul><li>Workflow is often represented by Business Process Modelling (BPM) or Workflow applications </li></ul><ul><ul><li>Most of the major vendors and many specialist vendors have a workflow or BPM offering </li></ul></ul><ul><ul><li>These are often very expensive and always have a large footprint </li></ul></ul><ul><li>We think there is another simpler and cheaper way </li></ul><ul><ul><li>We acknowledge OWL is not suitable for all situations but believe it is applicable to a large number of cases </li></ul></ul><ul><ul><li>Read our non-technical interview at http://www.truenorth.gb.com/products/owl </li></ul></ul>Slide
  3. 3. Typical workflow design and implementation <ul><li>The workflow is usually modelled in the tool by a Business Analyst </li></ul><ul><ul><li>Involves identifying steps, roles, and conditions for moving between steps </li></ul></ul><ul><li>The IT department deploy the modelled workflow on to a server running the workflow application </li></ul><ul><ul><li>This may involve data migration from old workflow processes </li></ul></ul><ul><li>The business users interact with the workflow </li></ul><ul><li>The workflow engine </li></ul><ul><ul><li>Determines the state change of the process </li></ul></ul><ul><ul><li>Notifies users of actions </li></ul></ul>Slide
  4. 4. OWL: Open Workflow Light <ul><li>OWL was developed to meet the gap in a simple workflow tool. Its key principles are below: </li></ul><ul><li>The user knows best </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Keep a full audit trail </li></ul><ul><ul><li>It’s more important to understand what has happened to a task rather than where it will go. </li></ul></ul><ul><ul><li>Not only might this be needed for regulatory compliance but it can also aid a user in deciding what to do next </li></ul></ul><ul><li>Fit in with the users’ working methods </li></ul><ul><ul><li>The tool should integrate with the end users’ working methods not the other way around </li></ul></ul>Slide
  5. 5. Workflow Functional Architecture <ul><li>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: </li></ul><ul><li>Define </li></ul><ul><ul><li>Design and edit workflow templates. </li></ul></ul><ul><ul><li>Identify the users and roles in the process and apply to the templates </li></ul></ul><ul><li>Act </li></ul><ul><ul><li>Create and manage the state of workflow instances </li></ul></ul><ul><ul><li>Migrate processes from one definition to another </li></ul></ul><ul><li>Notify </li></ul><ul><ul><li>Let workflow participants know when they have actions to perform </li></ul></ul><ul><ul><li>Allow flows of interest (sometimes instances of interest) to be watched </li></ul></ul><ul><li>Monitor </li></ul><ul><ul><li>Examine the workflow for bottlenecks and potential improvements </li></ul></ul><ul><ul><li>Report on the metrics of process enactment </li></ul></ul>Slide
  6. 6. OWL: Functional architecture <ul><li>DEFINE </li></ul><ul><ul><li>Search and tagging seen as more important in letting users classify and find instances </li></ul></ul><ul><ul><li>NO PROCESS DEFINITION. Processes defined by users’ actions not by the application </li></ul></ul><ul><li>ACT </li></ul><ul><ul><li>Simple state management and listener-style approach to notification </li></ul></ul><ul><ul><li>Audit trail allows users to infer and understand business process </li></ul></ul>Slide <ul><li>NOTIFY </li></ul><ul><ul><li>Integrate with tools that the users has access to and understands </li></ul></ul><ul><ul><li>Don’t make the user learn the application but instead fit in with existing standards </li></ul></ul><ul><li>MONITOR </li></ul><ul><ul><li>Dashboard and metrics with simple reports are mandatory </li></ul></ul><ul><ul><li>Provide the means to hook up alerting (via API and also by integrating with microblogging & chat apps) </li></ul></ul>
  7. 7. Integrating with OWL: How and why <ul><li>All functions exposed through Java API </li></ul><ul><ul><li>Greatest cross-platform support </li></ul></ul><ul><ul><li>APIs designed for extension so advanced users can add features </li></ul></ul><ul><li>Most functions exposed through HTTP API </li></ul><ul><ul><li>Allows OWL to be accessed as a remote service – i.e. Where workflow is part of the solution not the whole solution </li></ul></ul><ul><li>Notification and alerting supported through SMS, Email, and XMPP (chat) </li></ul><ul><ul><li>Provides the greatest flexibility for the end user </li></ul></ul><ul><li>All data exportable via CSV </li></ul><ul><ul><li>For maximum portability with BI tools and custom applications </li></ul></ul>Slide Methods of integrating with OWL
  8. 8. OWL: Design principles <ul><li>Partition vertically </li></ul><ul><ul><li>Separate modules for each of the functional areas (Definition, Action, Notification, Monitoring) </li></ul></ul><ul><ul><li>Minimise dependencies between modules </li></ul></ul><ul><ul><li>Allows them to be switched out / replaced more easily </li></ul></ul><ul><li>Partition horizontally </li></ul><ul><ul><li>Code to interfaces to enable layers to be switched (e.g. Traditional relational store to be switched in) </li></ul></ul><ul><li>Hide implementation detail for “pure” consumers </li></ul><ul><ul><li>Provide full integration but hide Java implementation (through HTTP interface) </li></ul></ul><ul><li>Hide data model in API </li></ul><ul><ul><li>Data model is exposed only through its export format (CSV) and the actions that can be taken on objects </li></ul></ul><ul><ul><li>Allows data model to be changed or enhanced more easily </li></ul></ul><ul><li>Minimize data held in cookies or sessions </li></ul><ul><ul><li>Make it easier to replicate and scale by minimizing session-specific data </li></ul></ul>Slide
  9. 9. Contact us <ul><li>Please feel free to contact us if you’d like to use or extend Open Workflow Light </li></ul><ul><li>We’re also interested in any feedback you might have on this presentation or OWL </li></ul><ul><li>web: www.truenorth.gb.com/products/owl </li></ul><ul><li>email: [email_address] </li></ul><ul><li>twitter: truenorth_buzz </li></ul>Slide