Overview
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 Pages
Page | 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. 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 | |
| ||
| 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? |
|