...
- 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
...
- 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
- Different 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 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
| |
| |
| |
|
...