Page Comparison

...

• The community has developed an OpenLMIS mobile strategy the clearly states the community would like an independent mobile reference application that can be used with OpenLMIS v3.
• There is donor interest to adapt the SIGLUS mobile app to be compatible with OpenLMIS v3. (SIGLUS is a robust Android app that integrates with a custom OpenLMIS v2 server)
• The User Interface for OpenLMIS v3 is built on Angular v1.x. The final release for Angular v1.x will be in July 2018 and it will then begin the final 3 year long term support phase. The entire user interface will need to be upgraded to another version of Angular, or another framework before July 2021. The community has begun discussions on this transition.

Key Risks

• Risk: It might be too hard of a problem or too much work for the current budget to try addressing the "orderables" concept with the OpenLMIS v3 Commodity Model (commodity types, trade items, and lots) while also addressing the "legder" concept (CQRS event model).
  • Ways to mitigate this risk:
    • Slow down and assess this more deeply before we make a choice between tech options.
    • Do more in-person with Josh or other experts on v3 model so deliverabes can understand the "orderables" model and the "ledger" model.
    • Reduce the scope to tackle the "ledger" concept first, and not try to tackle the "orderables" concept. We could break this work up into smaller parts rather than try to achieve the "whole enchilada" at once.
• If we haven't done a big enough risk assessment, then we may not be able to deliver the feature set.
• What is the UI and back-end server doing?
  • What is the difference between stock events and stockcard line items as well as the stockcards?
• Discussion:
  • The OpenSRP system already has a read-only ledger type concept.
    • Conclusion: The ledger aspect is not as big a risk, now that we have talked about it. The risk is really around the "orderables" model.
  • How do we stay "DRY" and build the business rules about conflicts and sync into offline devices.
  • Josh: Our scope could be reduced if we get rid of centralized lot management.
    • Decentralized lot management would make this project easier.
    • Josh: "Move away from synchronization". Separate the data from the business logic. Ensure the business logic is similar/aligned in both systems.
• When offline, we need to be able to follow the same business logic

Decision

With which of the following options should we proceed?

...

• This approach does not conform to the OpenLMIS v3 strategy of building an independent application
  • This functionality would only exist inside the OpenSRP app, and running it depends on having an OpenSRP server running.
• This approach would not result in a product that is as mature as adapting SIGLUS
• Components are not able to be reused outside of Android

...

• If used as a reference application for OpenLMIS, implementers would have a dependency on OpenSRP server and OpenMRS.
• This approach only partially conforms to the OpenLMIS v3 strategy of building an independent application
  • There is still a dependency for the data to all flow through OpenSRP server (the product list, all metadata, the stock events, etc).
• OpenLMIS will have to maintain both a web (JavaScript) and mobile (Android Native) codebase

...

• This approach requires a long-term dependency on the OpenLMIS v2 data model in the Android client unless there is additional funding and benefit to convert the SIGLUS Android Client to be compatible with OpenLMIS v3.
• Higher maintenance cost long-term.

Risks:

• Schedule Risk:
  • The team assumes a tool like Nifi can be used to perform this interaction, which requires much less programming than doing this in Java. Nifi is already a dependency of the OpenLMIS v3 reporting architecture so we would not be adding an architectural component.