Description: Steps to move from current code base to proposed design

Leads: Karl

Rapporteur/Notetaker: Rich

Notes from Session:

Intro

(Short discussion on how to use this session's time. Karl: should define timeline and funding for architecture work)

Ashraf describes a few pain points, and asked the group for potential design solutions:

Facility Edition in Zambia: Offline Java swing app that needs to sync monthly to OpenLIS via REST.
- Be more sustainable (in terms of cost) to transition this to a tablet, but needs to work offline.
- Josh mentions concern that current REST "lookup" APIs expose entire objects, concern the data may change overtime and break consumers
- Mused on OpenLMIS versions running on tablets, disconnected desktops, etc.
ILS Gateway. This solution required SSO. What is a preferred/good way to implement SSO?
- Does HIE recommend anything?.
- This is a feature request, but ideally something defined by a larger "community of communities" (i.e. OpenHIE), otherwise go with standard mechanism like OAuth. This is a good question for Dykkie.

What are steps to take?

What are migration/upgrade paths, even if we completely rewrote the application?

Or, look at each pain point and come up with solution? E.g. for database migrations, we could modularize this much better to support migrations, extensions, etc.
Incremental approach rearchitecture: Could take a stable module, not under development, and apply new architecture to it as a case study.
Discussion, what module or feature can we rearchitect as a vertical slice?
- Notifications (existing email and SMS) is a candidate, may be lacking in "domain".
- Reporting module: a rewrite could be advantageous (but does that hit problems like defining a domain model?)
  - Much longer discussion on reporting commences…what can we provide to help projects get the reports they need?
  - Was Jasper not enough? (a decent third party BI suite could provide dashboards for OpenLMIS, and maybe lose the 12k lines of code for existing reports)

Reset: what is the problem/problems we're trying to solve

TW proposes taking a TW pair to create a slice of new architecture functionality, then share it, in person, with JSI and TW.

Point on "plugins" - popular systems like OpenERP have a large number of implementers, deployments, etc. and sustains a vibrant plugin marketplace. This is not the case for OpenLMIS - we don't anticipate that many deployments, not enough for a "full" plugin architecture.