Next Tech Council Agenda: Workflow, AES, others Mike Gorrell (10 Aug 2018 07:33 EDT)
Re: Next Tech Council Agenda: Workflow, AES, others Vince Bareau (10 Aug 2018 12:36 EDT)
Re: Next Tech Council Agenda: Workflow, AES, others Mike Gorrell (10 Aug 2018 14:35 EDT)
Re: Next Tech Council Agenda: Workflow, AES, others Tod Olson (14 Aug 2018 15:20 EDT)
Re: Next Tech Council Agenda: Workflow, AES, others Mark Veksler (14 Aug 2018 15:37 EDT)

Next Tech Council Agenda: Workflow, AES, others Mike Gorrell 10 Aug 2018 07:33 EDT

Folks,

Next week’s Tech Council (15-Aug, 11am Eastern) meeting will be full of important/timely issues, so I wanted to send an email and have us make as much progress/pre-meeting prep as possible. Additionally, I am traveling on Wednesday and my flight lands at 11:08am - I’ll join via mobile as soon as I can. Tod Olson has agreed to run the meeting in my absence.

The agenda is here: https://wiki.folio.org/display/TC/20180815+-+Aug+15%2C+2018+-+Technical+Council+Meeting+Notes

The first issue listed - Hardcoded lists - was raised at the Product Council yesterday. These two threads outline the potential issue of lists not being editable/customizable by libraries, which doesn’t seem like the way things were designed. Jakub has reached out to the teams to investigate and report back to the TC in case there are further actions that we need to take.
- https://discuss.folio.org/t/orders-material-types/1975
- https://discuss.folio.org/t/acquisitions-hardcoded-list-values/1937

The second issue is the AES Doc that Vince submitted before going on vacation: https://docs.google.com/document/d/15gWIh_iNZQvk0LzJwapofwnnyck1NM7h6BUTvWmCIDs/edit?usp=sharing
There seems to be good traction in the comments of the document and general consensus. I am hoping that by the time the meeting on Wednesday comes people are in 100% agreement.

The third issue is the one I think we’ll spend the most time on. This presentation was used to facilitate a conversation on Workflow in yesterday’s PC meeting:
https://docs.google.com/presentation/d/1vEZELmIlSC5AOusObnkMTyB0XkhWt_qNVcvLe0KilgI/edit?usp=sharing

After much discussion, the PC Asked us to validate/change the estimate I show on slide 11; how much work would it take to
1) Validate that Camunda is the right choice for use in FOLIO
2) Install Camunda and establish proper support so that the project can begin using it

When I put slide 11 together, this is what I was thinking:
A) We’d want a PO who could review the epics and features that have been identified as needing workflow, and compare those requirements to the capabilities of Camunda. This person would have to understand library workflows and the technical implementation of Camunda - likely installing and running the modeler and engine to fully validate it. They would identify gaps, and likely surplus capabilities that might feedback into what POs and librarians might want to leverage. This would all be documented. They would work with the other resources listed below to plan PoC work and generally structure/prioritize the effort.
B) We’d want a developer to understand the technical details of Camunda from its multi-tenant approach, how it fits with FOLIO’s backend architecture, etc, and identify any gotchas or troublesome ‘incompatibility’. Once past that, we’d like to understand the best ways to integrate with and leverage Camunda. Which APIs, settings, patterns, etc. In working through this I’d imagine there may be an opportunity and/or need to create some artifacts that can be used by teams who will eventually work with Camunda - a mini FOLIO-specific SDK of sorts?
C) We’d need a DevOps person for the backend plumbing setup, monitoring, and operation. There are also NFRs that need to be explored (performance, fault tolerance, upgrade process, etc.)
D) These resources would collaborate to create documentation that would permit a dev team to use Camunda as they would use STRIPES or Okapi

So the task of the TC is to review my logic and the roles and estimates that I put on slide 11.

I’ve invited Ian Ibbotson to join the meeting and to lead this discussion. He has the most experience with Camunda, having done the PoC, and he lead the dev team who is doing ERM - an application that has workflow needs.

SECONDARILY, if we could also discuss and amend the four estimates that were made on page 12, that would be great.
1) Once Camunda is up and in use throughout the community, how many resources are needed to keep it up and running? This is analogous to how many resources are needed to keep Stripes/Okapi healthy and supported for the community.
2) Assuming Camunda is ready - how long does it take a dev team to climb the curve to begin imbedding it in their app/modules?
3) Once an app/module is integrated with Camunda, it needs workflows to be authored. Each implementer of FOLIO needs to have staff that can author, run and monitor their workflows. How long and how many resources are reasonable for this training/learning curve.
4) On an operational basis, how much time does a library need to allocate to the care and feeding of their workflows. In my view this is incremental (but analogous) to the support a library would allocate to overall FOLIO. Just acknowledging that adding Camunda adds to the level of support required.

There’s one last item on the agenda - Consortia Model. I’ll spend some time early next week prepping for a discussion on that if we have time.

I’d like to ask you to think about these issues and ask questions/have discussions prior to our meeting Wednesday so that we can get through it all.

Thanks

-mdg