Leads: Karl

Rapporteur/Notetaker:  Rich

Audio recording:  Architecture Discussions d2s2.mp3

Notes from Session:

(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

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

• 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