The transformation from current architecture to the modular architecture will be iterative and incremental.
Iterative
At the end of each iteration, a production-ready version of openIMIS will be delivered.
To be production-ready implies that, at each iteration:
- a migration of (re)implemented features is prepared (with dry run,...)
- tests (integration , load and acceptance) are formally organised
- documentations (from user guides to deployment procedures) are delivered
Each project will have the choice to join the new openIMIS platform at that iteration or not.
Incremental
The aim is to cover all current openIMIS features (of each implementation) with plugins in the (new) openIMIS.
However, not everything will be ready at first iteration. To ensure a production-ready delivery, openIMIS will, as a consequence, be built upon proxy plugins to (legacy) implementation.
Proxy plugins will be developed in the various layers and will be replaced once the new implementation is ready.
Transformation
...
The very first iteration of openIMIS will thus be a "all proxy" implementation where every (functional) feature is a proxy in the (web) frontend layer to existing openIMIS implementation:
Next iterations will be planned to replace chosen proxy(ies) to their target implementation.
The core components (FE, BE,...) of openIMIS will be built (enhanced) along the proxy replacements.
The choice (order of) proxy replacement will thus be based on:
- what is needed from the core components, and its availability
- what has the most value (business wise)
Proxy replacement by own implementation
Proxy may be replaced by the target implementation, moving horizontally (in a layer) or vertically (cross layers).
Example, should we identify the Payers-related features as interesting to migrate first.
An iteration may target the Payers FE proxy replacement by implementing a BE proxy, targeting current openIMIS API (WebServices):
Depending on the identified workload, the iteration may even skip the BE proxy and connect the actual Payers BE plugins (Online and Batch) implementation:
Proxy replacement by delegation
Proxy replacement does not necessary mean full features re-implementation of existing features.
openIMIS will indeed rely on other Software components out of OpenHIE, a proxy may be replaced by a delegated implementation.
Example, should HFR target an interface to DHIS2 (Organisation Units).
Not all HFR features (like manage facilities hierarchy,...) must be re-implemented in the openIMIS while openIMIS will need search capability for facilities, reference them in the services (price lists,...), the actual hierarchy management, facility description, grouping,... can be delegated to DHIS2:
...
Phases
- Pré-database migration
- Database migration
- Post-database migration
Proxy replacement with standardisation
Replacing a proxy (by own implementation or delegation) is one opportunity to adopt existing standards.
The relevance of the various standards (FIHR,...) will be analysed prior to (re)implementation of the concerned plugins.
The migration feasibility (and cost) is probably the major concern for this transformation. One alternative is to have several implementations of specific modules, to be chosen according to each project's needs.