Overview
Module Overview
Result of Deep Dive 2022-09-08
Rework and preparation for follow-up Deep Dive sessions
Definitions
Term | Definition |
---|---|
Module | Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality. |
(Software) Package | A collection of functions written in a single language bundled with additional content like documentation, unit test, sample data etc. Source: https://en.wikipedia.org/wiki/Package_development_process |
Component | An individual software component is a software package, a web service, a web resource, or a module that encapsulates a set of related functions (or data). Source: https://en.wikipedia.org/wiki/Component-based_software_engineering#Software_component |
Sources | Technical source code, structures and definitions of an IT solution |
(JLN) Business Process | |
Functional Unit | An interchangeable unit that provides a piece of business functionality |
(Software) Repository | A storage location for software packages & other technical sources |
Key Questions
How to find a wording which is clear and prevents misunderstanding and allows for a common language between business (implementers) and technical (developer) people?
How to achieve an up-to-date documentation of the architecture and it’s features (modules) which satisfies and links the needs of implementers and developers
Key Findings
- Many things are called a “Module”, but a clear definition is missing
- Repositories/Deployables in Sources Release 2022-10 were called modules before despite covering many aspects (FE, BE, DB, tools, core, assembly/configuration, docker)
- Towards non-IT people a module is a unit of functionality covering a business/domain aspect such as a process (Claims, Calculations) or an entity
- It is hard to understand what modules are out there and which are optional, configurable, customizable and so on
- Documentation of the modules/features is fragmented, outdated and incomplete
- Dependencies (repositories) are missing
- An overview of modules is missing
- Linkage to business processes (e.g. JLN) is missing or incomplete
- Link to the technical (code) documentation is missing
- History (change log) and linkage to Releases is missing
- The software architecture is only documented in Target (modular) Architecture out of the perspective of a future development (Modular Transformation), not as something that exists as part of the product and seemed to be not actively maintained / updated
Findings
- Module pages under openIMIS Modules do not share a common structure / content
- Use of property tables seems advisable
- Overview in openIMIS Modules uses color coding without providing an explanation (types of modules like Core, Interop, Business, ??)
- Linkage between “Modules” and Repositories unclear / Dependencies are not documented
- Definitions unclear, what is a “Module”?
- What is the bare minimum a module must provide? What are the key features? Interfaces, etc.?
- What principles are followed to define what is part of one module, but not of an other?
- Relationship to “Repositories” and other modules
- Are there different types? Which?
- Is the module configurable/customizable? On a technical level or from a business perspective?
- Is the module optional? Is there a choice of different modules (e.g. FHIR version)?
- If a (business) is an abstract bracket around repositories, does it have a version number? How to tell if the “module” is still compatible to the rest of the system?
- Sources Release 2022-04 lists repositories as “Components” (renamed from “Module”)
- Multiple modules under openIMIS Modules seem to be outdated and incomplete, are not separately documented, but mixed with other “Modules”
- Modules under openIMIS Modules are organized in a complex but incoherent structure (e.g. sometimes grouped by business process or other)
- Modules under openIMIS Modules do not follow a consistent naming format
- Modules under openIMIS Modules are not always described separately, but mixed (failed separation of concerns SoC?)
- Some modules under openIMIS Modules do not match to the diagram
- Some modules under openIMIS Modules are missing
- Some modules under openIMIS Modules contain overly technical (source code, stored procedures) details
Related topics from Developer Committee
DC #224 Testing Scenarios
DC #288 Implementer Documentation
DC #274 Default Module Configuration
DC #260 Documentation Platform
DC #105 List of modules / JLN Business Process Mapping
Related Sources
Source | Content / Findings |
---|---|
Describes “Modularity” as Modularity (and its integration counter-part) is considered at 3 distinct levels:
… Software Component and Entity levels modularity are fully in the scope (controlled by) of openIMIS. openIMIS is built modular "from the core on": even low level features (like login,...) and central features (like Insurance Scheme management,...) are built as a plugins of a core platform. The core platform provides generic components (building blocks) to be used by / particularised in the various plugins and is split in 3 layers:
Although openIMIS is an assembly of components (themselves assemblies of plugins), deployments of openIMIS doesn't impose a distributed deployment. The choice of isolating the various (server-side) components to dedicated infrastructure is taken according to each project's needs. Within a project, scaling up by distributing components as the load increases is a very standard (and easy) operation: Plugins are documented in openIMIS Modules. | |
In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle. … Plugins (can) provide several types of archetypes, dedicated to the various openIMIS layers: openIMIS Mobile FE, openIMIS Web FE, openIMIS Online BE, openIMIS Batch BE,... openIMIS can be deployed with an extra layer dedicated to implement a FHIR API, based on openIMIS core (base) modules. In openIMIS, (nearly) everything is a module: even "low level" (and mandatory) features follow this principle. In other words, even the following features are implemented as (interchangeable) modules:
Beyond these low-level modules, several modules will be dedicated to configuration/administration:
The real business needs will be implemented in dedicated modules:
In addition, the following modules are used for integrating openIMIS with external systems: Tests cases for the various modules are documented in a separate wiki page. Plugins (can) provide several types of archetypes, dedicated to the various openIMIS layers: openIMIS Mobile FE, openIMIS Web FE, openIMIS Online BE, openIMIS Batch BE,... openIMIS can be deployed with an extra layer dedicated to implement a FHIR API, based on openIMIS core (base) modules. Today the FHIR API is a unique module, but there is an open point on splitting it into separate modules (per FHIR resource?): Code (static) analysis, as well as unit tests coverage metrics of each module, is automated via travis-ci and codeclimate. You can log into these tools via your GitHub login. If you are registered in openIMIS GitHub, you'll have access to openIMIS build job and code quality metrics.
Patrick Delcroix in the comments: Here my point of view on the module list details in 4 groups (core, business...) The module with * leading are not found in JLN IT core
Business
Register
Reporting
| |
| |
| |
| |
|
List of modules under openIMIS Modules
Module | Content / Finding | “Modules” in diagram |
---|---|---|
| Claim | |
“Beneficiary Enrollment” \ Policies module scope |
| Policy |
“Beneficiary Enrollment” \ Persons & Families module scope |
| Persons - Missing in diagram Families - Missing in diagram |
“Beneficiary Enrollment” \ Contributions & Payment module scope |
| Contribution Payment |
“openIMIS Administration Modules” \ Product module pages mockup |
| Product |
“openIMIS Administration Modules” \ Locations & Health Facilities module scope |
| Location Health Facilities - Missing in diagram |
| Claim AI - Missing in diagram | |
| ||
| FHIR V3 FHIR V4 | |
| Invoice Others? (e.g. Contribution Plan ?) | |
| Calculations | |
| Contract | |
| Policy Holder | |
| Policy Holder Portal - Missing in diagram | |
| Bulk CHFID Generator- Missing in diagram | |
| Claim Batch | |
| Report | |
Missing modules from diagram |
|
|
Missing modules on the diagram? |
|