Mike, thank you for pulling this all together into a single presentation. Having it all in one place, should make it easier for everyone to gain a common understanding of what workflow (or BPM) is (and is not) and what it will mean to engage on this project.
I added a whole bunch of comments to the presentation, which I do not want to repeat here.
Also, I wanted to make sure it is understood that there are two major components to a workflow system: design-time and run-time, each with a different target audience and each with requirements for a separate set of tools and SKILLSET for development and maintenance.
Finally, when talking about a complete solution for a workflow system (also referred to BPMS ☺), they may refer to the following set of functional components/pieces. The list is incomplete… I just jotted it down based on my prior experience with implementing workflow systems. We may not need any of them but it might be helpful to know what capabilities are provided by a 3rd party solution if we were to build a business case.
- Process Orchestration Engine with support for standards: BPEL, BPMN, XPDL
- Graphical workflow (process) Design Environment, may include User Interface/Forms composition
- Content Interaction Environment: integration with Document Management systems, e.g. for email messaging and more complex notifications or for collaboration on a document
- Human Interactions (forms on any device, access rights, roles)
- On-Demand Analytics (simulations, predictive analytics)
- Process Intelligence and Business Activity Monitoring (BAM)
- Business Rule Processing (forward chaining/deductive reasoning, forms validations)
- Connectivity (HTTP, REST, SOAP)
- Management and Administration (start, stop, deploy, monitor)
- Registry/Repository (versioning)
Thanks!
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
one additional point added below -tod
My take in-line.
Some questions that don't fit neatly on slides so will ask group here. Let me know if there is a better place to discuss this?
* Who is the intended audience to program the flows in the workflow engine? Is it safe to say for now that this is the Folio dev community that does this so apps are integrated out of the box, and we are not expecting Libraries who run Folio to have to do that? I think it's worth clarifying and stating this, if not for Thursday then at least once the further investigation is complete.
From reviewing some of the mockups and requirements, the expectation is that librarians/library staff would setup workflows. In looking briefly at the Camunda UI for their modeler, I think a systems librarian wouldn’t have trouble creating workflows. Note that I wouldn’t call if “Program the flows”, but its interesting that you used that terminology. I have been thinking that it will require knowledge of endpoints, etc.. so it is “code-like”. Note that there’s a desire for the ability to script/create workflow without using the UI (UXPROD-734).
I think there are two aspects, and back-end service and a front-end app. As a base the WFE as a back-end service is immediately an enabling service available to other modules. A user-facing app for ToDos and/or configurable Workflows would be a way of exposing the back-end WFE more directly to the libraries. One could do the back end WFE work as one step, and then take on the user-facing configuration as a second step, prioritized separately.
* Can Folio release a 1.0 without WFE? I would imply from this discussion that we cannot release until WFE is available because we are not investing in any of the other app integrations (i.e. workflows coded by hand). This should be stated in PC presentation (my opinion) because what that says is it is putting an unstaffed and scope-not-fully-understood component on the critical path for release. Or do I misunderstand, is there a path to releasing a 1.0 that doesn't have to wait for WFE? This would be my own preference the way I see it now, just giving my opinion, like to hear that of others. I am worried WFE could drag on longer than we think to integrate it and thus delay a release in Spring, whereas we might at least hard code a few simple workflows to get ourselves off the dock for now.
I tried to state that FOLIO COULD release a 1.0 without a formal externalized workflow system on slide 5:
I am under the impression that we’re still working through Go-Live requirements with PO’s and so we not sure what fits and what’s the highest of high priorities. IMO Workflow is one of many highly desirable features that aren’t staffed and have uncertain scope.
* The deeper analysis that is proposed - who would be proposed to do that, the TC members in their spare time, or a specific team assigned, and for how long will that investigation go? Like to know thinking for who would do that and a milestone date at least for how long the investigation takes before we have additional scope data.
This is TBD, although I would lobby for Ian Ibbotson to be part of that since he’s on ERM (lots of workflow-related requirements) and he was the one to do the PoC for Camunda.
To unsubscribe from this list please go to http://archives.simplelists.com