Re-Architecture Alternative Pro / Cons

Topic	A. Incremental	B. Rewrite
Time to Completion	Slower	Faster (because of less technical debt to manage, decreased tech risks, and lack of fast-track support)
Technical Risks	Unclear whether 'slice' approach will work and the degree of untangling that will be required.	Lack of written business requirements and user stories for OpenLMIS v1 will require reverse engineering requirements from OpenLMIS software Lack of any consistent staff from first project working on re-write – possibility things may be missed
Incremental Value	Value available with each release	None until project matches functionality of OpenLMIS 2.0 (with toggle off feature set)
Technical Quality		Likely higher due to ability to start with a clean slate, particularly in regards to test coverage.
Migration Path
Scope
Cost
New Implementations During Project	New implementations can take advantage of incremental releases, have possibility of working with community on needed extension points	New implementations before completion will use 2.0 and have to upgrade later.
Community Collaboration

Goals: Address key pain points – more flexible UI, Enable contribution. Provide modular framework. Create explicit area “core” of 100% shared benefit. Ensure high-quality, tested code throughout. Provide framework for migration.

Rewrite

Best Case: Some time from now we launch a fantastic new LMIS that the entire community buys into. Solves all the contribution and forking issues we are experiencing, and a rich community of modules develops around the active open source community.

Worst Case: We release a shiny new product – no one cares, the community has dissolved while waiting for our release and something else has entered the space.

Incremental

Best Case: We leverage the best existing features while removing those that aren’t up to par. Many new implementations come on board during the incremental re-arch, and they become active members of the community. No one really cares that it takes longer because partners and the ecosystem evolve in tandem. Partners are engaged because they have contributed to the code base and feel a sense of ownership of the end product.

Worst Case: We aren’t able to respond quickly enough to fast track requests and the community forks in order to progress. X time from now we have y+ implementations on different forks somewhere between 2.0 and 3.0. All current risks still apply and the .

Assumptions

Partners are most interested in feature set, migration path, and timeframe – don’t care about the “sausage making” of the re-architecture as long as they are satisfied with above
Community is bought in to incremental approach as of January 2016
There is strong community interest in migrating existing implementations to “3.0”
New deployments at the end of either A or B need to be excited about the product in order for current implementations to consider a migration
If we rewrite, we will recommend that new implementations in the next ~1 year will build on 2.0 release tag
The migration LOE will be higher for current implementations if we do a complete re-write than if we do an incremental re-architecture
Higher chance of failure for an incremental re-arch rather than complete rewrite – unknown by how much
An incremental approach allows us to internalize more of the knowledge into our own team whereas outsourcing a rewrite team would internalize less
In order to encourage implementers to build on 2.0, we must offer a 2.0 to 3.0 migration in the re-write scenario
In an incremental release, we may have to support n different version migration paths (i.e. for those that start on 2.0, 2.1, …, 2.n to 3.0).
All current implementations (TZ, Zam, etc.) will not merge in incremental changes because they don’t get added benefit from toggles

Re-Write

Issue	+/-	Risk	Mitigation
Better tech approach (better end product)	+
Higher LOE for migrations for existing implementations than with an incremental approach	--	Schema, logic, etc. could be significantly different	Allocate a separate project to analyze what should be migrated
Requires a larger outsourced team with all the overhead and cost associated with that	--	Additional overhead, expense, loss of internal knowledge
No incentive for partners to contribute to “2.0” over the period of the re-arch	-
We can move faster, unhindered by community requests (less churn)	++
No new implementations during rewrite b/c OpenLMIS is seen as a dead-end (why use software that is about to be obsolete?)	-

Incremental

Issue	+/-	Risk	Mitigation
Incentive for community to stay involved	+
Migration Path LOE	-
Potential to become “death march” with competing fast track and re-arch work where little progress takes place	---
Team is “bought in” to this approach	+
Implementations building on OpenLMIS in the next year	++
Must support n different migration paths (i.e. for those that start on 2.0, 2.1, …, 2.n to 3.0	-

Open Questions:

If we do a re-write, how close to we stay to the current structure and behavior of OpenLMIS?