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 while working on the new version. Any projects that are going on at the same time can coordinate with the OpenLMIS roadmap. For projects that are prioritized or have a high likelihood of funding, the OpenLMIS global team will coordinate and work those into the scope of the re-architecture.

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 December 2015 is included in 2.0. If another customer shows a demonstrated need for the VIMS functionality then that could be considered for incorporation.

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?

The OpenLMIS global team has undertaken 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?

Existing implementations can choose to continue on their current version without upgrading, or plan an upgrade project. Countries staying on the current version can continue to receive OpenLMIS community support, as well as implementation partner support in-country. If there is an active interest in upgrading the system to 3.0, this can be considered either as a distinct project, or as part of the suite of menu options presented in the scope of 3.0. We need input from partners and donors responsible for legacy implementation on whether they want an upgrade project scoped in concert with the 3.0 release.

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. Community members may present issues and request support via the following committee groups:

Governance

Product

Technical

With the 3.0 version, a warranty may be crafted to guarantee provision of support.

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.

Migration is a top concern and the global team will make its best effort to include as much in scope for 3.0 as possible. For those items that may fall out of scope, the global team will work with partners to develop a plan. In scope for 3.0 are data migration scripts for core pieces, and customizations will be handled on a case-by-case basis.

Why are certain features being turned off or not included?

At this time for 2.0 the OpenLMIS global team has chosen to toggle off certain features that were part of existing 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.

Partners don't necessarily have more money to invest in a new version of OpenLMIS

At this time, partners are not being asked for more money to invest in a new version of OpenLMIS. Funders are asked to continue their backing of the OpenLMIS project by recommending that countries consider OpenLMIS when evaluating eLMIS solutions.

It's unclear what to tell countries that are evaluating eLMIS implementation now – wary of implementing on OpenLMIS 2.0 when they will need to upgrade to a new version to retain support later

See the New Country Implementation Recommendation page for a full response on this issue.

Previous investment 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 more a system has been customized to meet a country's need, the higher the cost to upgrade and lower the return. 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 the 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 help contribute 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. For the current rewrite being considered, the requirements are clear and detailed database design and domain modeling has already taken place, thereby removing significant uncertainty from the process. Standard practices will be used to manage scheduled 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 said, 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 its 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.

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.

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.  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?

Anyone is free to join any of the OpenLMIS committees (please see above for links to each committee's wiki page. The three committees (Governance, Product, Technical), meet regularly to discuss key issues facing the community and provide feedback on primary issues.

Issues around community participation are being treated with the highest priority and regard. Every effort is being made to make the community as inclusive, transparent, and participatory as possible. Any feedback on community participation is welcome, and may be sent directly to the OpenLMIS Community Manager, Tenly Snow (Deactivated), or to info@openlmis.org, or to any of the committee forums.