Re-Architecture Objectives

A number of challenges have been identified with the current OpenLMIS architecture that we hope to address with the re-architecture. The key challenges are:

• Country-level implementation can not modify the look and feel of the UI without forking the code base
• Country-level implementations can not add additional features to OpenLMIS needed for their implementation (such as Tanzania adding the ILS Gateway integration) without forking the code base
• There is not a clear demarcation between code that is central to the system (requires a high level of reliability, high test coverage, should be modified only with the agreement of the community), versus code that is implementation specific and is managed by specific development teams without the need for community involvement. As a result, the current code base is impossible to maintain at a high-level of quality and reliability. 
• Creating reports that meet user needs (i.e. beyond the basic capabilities available in Jasper Reports) requires writing code and forking the code base
• Managing merges between the increasing number of implementation project, to try to maintain a single version of OpenLMIS, is time consuming and will become harder/impossible over time

Note that there are many other pain points with the current version of OpenLMIS that will not necessarily prioritized to be addressed by the initial re-architecture. 

Based on the challenges noted above, we envision the following end-state after the re-architecture. At this point, this is a suggested proposal. The end-state described here will be validated by the governance committee during the OpenLMIS conference.

• To improve reliability, there is a tightly controlled OpenLMIS code set that has high test-coverage, high reliability, and changes relatively infrequently
• There is a straightforward way for developers to extend OpenLMIS without forking the code base
• Developing extensions to OpenLMIS is possible for junior developers with little formal software development training (low barrier to entry, minimize complexity where possible)
• The OpenLMIS user interface can be customized for specific implementations without forking the code base
• Extensions to the OpenLMIS code base can be made available to others that may want to use it
• Some extensions to the OpenLMIS code base can be deemed "community supported" (see below), with specific standards for code that the community will agree to support having been defined
• Implementors or System Admins can design reports (ideally) without writing code (possible?)
• The OpenLMIS "default" user interface continues to contain configurability features, such as the configurable R&R (or in the future a configurable stock card), such that implementors can set-up standard OpenLMIS features to match their countries forms and business process using configuration alone  (note: we could set a threshold here such as "60% of customization needs can be met by configuration" if that would be useful)
• OpenLMIS continues to include a user interface, or a reference user interface that can be used as a starting point for customization
• Current OpenLMIS implementations have a migration path to the new version (it is not impossible), however it's understood that this will be costly and may not be pursued by every implementation
• Legacy code created for existing implementations can, over time, be migrated out of the core code based into community modules
  • In the interim, legacy code created for existing implementations that is not desired for inclusion in core, is "turned off" such that new implementation do not have to use it (i.e. Dashboard home screen)