Leads: Karl

Rapporteur/Notetaker:  Rich

Audio recording:  Architecture Discussions d2s2.mp3

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.

Architecture:  steps to the future

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

• Is it, "What does the next implementation do?"

More Path-Forward Proposals

• TW proposes taking a TW pair to create a slice of new architecture functionality, then share it, in person, with JSI and TW.
• TW needs to secure funding
• Would need some level of doc
• Group should have some review/input before spike happens
• Ashraf:  should review other extension services/techniques
• E.g. OpenMRS or OpenERP.  These offer additional benefits
• Can work on 2.0 stabilization in parallel, a way to establish a master branch
• Work off the Code State list of items
• 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.
• Should focus on establishing domain model first