Re-Architecture Feedback responses

How do we align other development priorities (such as a mobile app) during the re-architecture project? Does everything have to go on hold while we wait for the new version?

Everything doesn’t have to go on hold. Any projects that are going on at the same time can coordinate with the OpenLMIS roadmap and projects that are prioritized or have a high likelihood of funding, we’ll coordinate and work it into the scope of the re-architecture.

ThoughtWorks and CHAI participate in our design sessions that we’ll be holding in April? How would it work? Get agreement on this. They would be the ones to develop this mobile app. If we want to keep CHAI happy, we need to draw them in. If we decide this is something we want to do, then we reach out to Gaurav and pull them in. 

How do we manage dependencies during the re-architecture?

Same as above.

Is any part of the VIMS code base being incorporated into the 2.0 OpenLMIS base? Is any part (vaccine functionality) being incorporated?

The VIMS code as of Dec. 15 is included in 2.0. If there’s a demonstrated need of another customer for the VIMS functionality then we could look at incorporating that. 

What core features do we expect will be part of OpenLMIS 3.0.? What features (country-specific or otherwise) that are part of OpenLMIS 2.0. will not be part of 3.0.? How and what stage will this feature set be decided on?

We have undertaken completing a full review of features across all implementations in order to assess the scope for 3.0. The current draft of the feature analysis is here.  Based on this document, the product committee will be assessing the scope prioritized for a 3.0 core. This may include a menu of options, and a larger scope would likely increase the project cost.

What will happen to countries that have implemented OpenLMIS or earlier (ie. eLMIS in Tanzania and Zambia)? How do they stay on board moving forward?

Compelling message: You’ve invested an LMIS that was deployed at scale in TZ and Zambia – you got what you invested in. You can continue to support this as a country based system. No need for you to invest further. If there is an active interest in upgrading these systems, and interest in migrating them to the 3.0, it can be considered as part of the suite of menu options. Not part of the initial scope – but need feedback. If they want us to scope it, we can.

In our ask for additional funds, this could  be a subheading as partial investigation. We need the new architecture design first. 

How do current implementations take advantage of new modules or features? 

If a country upgrades to the new version, they will be able to take advantage of those new modules or features.

What kind of support (Tier 3, etc.) can the OpenLMIS community provide to existing implementations, and how long with this be provided?

Through the OpenLMIS Community, bugs and additional issues may be presented to the community, which then may respond with assistance in managing the issue. Any member of the Community is welcome to present their issues for assistance. *Provide links to the governance/product/technical groups. (when we do 3.0 we can craft a warranty).

The community was not sufficiently included in the creation of re-architecture alternatives (incremental approach vs. rewrite). They were presented as the only decisions/options

This feedback has been duly noted. In the next phase of the project, the OpenLMIS Core team has reached out to implementers and partners to get the full scope of the feature list for the next phase, incorporating community review of re-architecture deliverables, and including community participants in design sessions for the product.

Lowering migration burden should be a priority of the re-architecture

Yes, this is a priority and this objective will be included as part of the 3.0 design. The re-architecture project will provide an upgrade path from countries that implement on 2.0 to upgrade to 3.0, provide migration scripts for core system data, and provide samples of how to use extension points to extend OpenLMIS using modules.

Upgrading software, particularly software that has been customized, is a significant undertaking that will require funding. Countries that have already deployed earlier version of OpenLMIS will need to decide whether to stay on their current version of OpenLMIS, or upgrade. Countries wishing to upgrade can coordinate with the OpenLMIS community to plan a migration project.

Key message: Migration is a top concern and we will make our best effort to include as much in scope for 3.0 as possible, and for those items that may fall out of scope we will work with partners to develop a plan. In scope for 3.0 are data migration scripts for the core pieces. Customizations will be handled on a case-by-case basis. We are responsible for providing the extension point as well as a number of modules - partners would be responsible for providing modules for their own, highly-specific features.

Why is the OpenLMIS core team turning off features USAID paid to build? USAID's investment is OpenLMIS is being lost***

At this time for 2.0 the OpenLMIS core team has chosen to toggle off certain features that were part of the original USAID-funded implementations in the interest of developing core code that is more globally applicable, and which may be utilized by a greater number of potential implementations. The features that have been toggled off are those which are not completed, will not work for a new country as currently developed, or were developed primarily for that country's context. It is important to note, however, that any features that have been toggled off are managed through an administrative permission screen, and may be toggled back on with the appropriate permissions. If partners feel that a feature has been toggled off inappropriately, they may schedule time with the product committee to address this concern.

USAID doesn't have more money to invest in a new version of OpenLMIS***

At this time, USAID is not being asked for more money to invest in a new version of OpenLMIS. We are asking for funders to continue their backing of the OpenLMIS project via recommending that countries consider OpenLMIS when evaluating OpenLMIS solutions.

----------------------------------HAVE NOT ADDRESSED BELOW--------------------------------------

USAID doesn't know what to tell countries that are evaluating LMIS implementation now – wary of implementing on OpenLMIS 2.0 when they will need to upgrade to a new version to retain support later***

See memo: OpenLMIS Critical Mass / Communications / Memos / Country Implementation Recommendations

Investment by USAID is not being lost, it's being leveraged. Many pieces of software that have been re-written several times. In the case of a new version of OpenLMIS, whether it's an incremental re-architecture, or a full re-write, there will be a cost for a migration. Main decisions countries would have to make is whether the migration cost is traded off against the new features and extensibility.

Agreed.

What is the return on investment (ROI) for a country to upgrade?

ROI will vary on a case by case basis, and specific analysis would need to be done for each country that has already implemented OpenLMIS. In general, the most the system has been customized to meet a countries need, the higher the cost to upgrade (and thus the lower the ROI). Presumably, this would mean that ROI would be the lowest for Tanzania, as extensive customization has been added to that Tanzania implementation via the VIMS project. Countries like Cote D'Ivore, Benin, or Mozambique that use the "standard" OpenLMIS implementation with minimal customization would have a higher ROI. Despite the one-time cost of upgrading, benefits to countries that upgrade include access to the newest features, modules, bug fixes. Whether this benefit outweighs the cost of upgrade will vary by country.

What is the total 5 year cost for the re-architecture?

Right now our priority is calculating the one-time cost of completing the re-architecture – costing is being done for a baseline rewrite (including just the scope of the "toggle on" features for v. 2.0), as well as including additional items in scope (such as supporting migrations, adding in stock management, availability of APIs for interfaces with mobile tools, etc). If calculating 5 year cost is a priority, the community needs to work together to further define the ask (what is included in a 5 year cost?) and contributing to the analysis.

Rewrite sounds like a good plan, but the schedule could end up going significantly beyond initial estimates. Original OpenLMIS project was slated for 6 months, and took 18.
This is a good point, as software provides do often exceed initial estimates. That said, reworking a project with known requirements and current working software removes many unknowns that have to be handled during an initial build. The requirements are clear, and detailed database design and domain modeling has already taken place. This removed significant uncertainty. We will use standard practices to manage schedule risk, including using an agile development approach, producing working code at the end of each sprint, and focusing on an MVP that replicates current product functionality first. All of this said, we believe that the benefits of producing a product that can grow and accept contributions over time outweighs the short-term pain of a software development project, and it's associated risks.

Is a streamlined strategy for development being considered? More devs can mean more time and complexity***
A streamlined strategy is certainly being considered, and the OpenLMIS global team is weighing the costs and benefits of the various dev approaches and software teams that are being evaluated for this project. We expect the OpenLMIS global team (currently housed at VillageReach) to be the basis of the project team and architectural vision, with additional resources being added to expedite the rewrite and provide specific tech expertise where needed.

Is there a way to go faster and further by going together with another project or new underlying tech?***

This process is very disruptive to the community, ongoing software development, and potential new country implementations. Is there a way to make this less disruptive?
Almost, if not all, open source products have gone through a similar re-architecture process, often several times, to develop the best and most widely applicable, product possible. While the process is disruptive,in the long term it will produce a product more appealing to countries and donors, particularly due to the ability to leverage contributions from multiple partners. Any ideas on how to lessen the burden of the process, or improve its outcomes, are welcome.

A more generic open source logistics solution in the public/private sphere, but mobile first and aimed at developing country environments (low bandwidth, high latency, etc),  would be quite useful and could provide a way to be more than LMIS for public health : is this being taken into account when considering the re-architecture or re-write of the "core" code? ***
I don't think this question needs to be answered publicly

Where will countries find the funding to upgrade to the new version?

As mentioned previously, the ROI on upgrading will vary by country. Each country will need to first decide if they want to upgrade, and then assess funding options. I The OpenLMIS Community is committed to providing both a forum, and guidance, for sharing initiatives, funding, and implementation opportunities for OpenLMIS, including upgrades to the newer versions of OpenLMIS.

We have been presented with information, but not really included in the re-architecture decision making process. The webinar did not have the opportunity to have open discussion. How can we be more included in the project?

-- committee meeting

-- we hear you, are now putting in extra effort to coordinating with community. That said, can't make everyone happy

-- planning design week in Seattle open to the community