Overview

Date: 08.09.2022

Follow-up-Meeting: https://openimis.atlassian.net/wiki/spaces/OP/pages/3412131841

Objective: Weekly space for deep dive topics

Participants: (kindly only add your own names, not those of other participants)

• @Patrick Delcroix

• @Dragos Dobre

• @Marco Kalin

• @Alex Motoc

Topic Proposals:

• Modular Architecture

Presentations / Attachments

Setting the Stage for Today

What is a module in the openIMIS context?

No strict definition of what a module is, but everybody talks about it:

• Implementers: “A thingy that does what I need to support the work of my users.”

  • https://openimis.atlassian.net/wiki/spaces/OP/pages/942637087

• Developers: “All the code that fits into one github repository (not more than 5.000 LOC per module)”

  • https://openimis.atlassian.net/wiki/spaces/OP/pages/3399614465

• Anybody else: whenever I need a techy sounding word for group, bunch, pile, collection, cluster, piece, lego …

Obviously we have a problem here …

What do we need for our documentation & communication?

A link between the business view and the technical view.

In practical terms: a consolidating wiki page that :

• bundles source components (What do I need?)

• assigns them to business processes (What can I do with it?)

• explains the supported functionality (How does it work?)

What’s it good for?

• We need to be able to communicate a common understanding of or features on a high level.

• If done according to standards (e.g. JLN), it is easier to compare openIMIS to other products.

  • these standards may vary according to the domain / sector - we might need more than one

• In the long run this modularisation can also serve a stricter separation of system components e.g. towards a service oriented architecture.

What has been done so far?

• Basic Module documentation in wiki pages:

• Mapping of modules to JLN Business Processes:

• Toumai study (French language version only):

• BlueSquare has come up with a very useful graphic as a result of the migration:

• We have started to structure essential information items per module page for an automated overview table:

• Extensive resource page:

Limited Target for today

1. Identify our modules

   1. Start with BlueSquare's graphic (one box = one module? one group = on module?)

   2. Group at least FE & BE into one module, maybe even more

2. Cluster the modules according to JLN Process Groups (colors)

   1. some modules will serve multiple Process Groups, let’s try to still find the primary process group

   2. some modules will just have technical purposes

3. Assign our sources to modules

4. Homework: rearrange module pages accordingly and update them with property boxes

Minutes

Remarks:

• JLN are business activities will use several modules BUT many processes will use the same modules

• A module is an element that is included in the assembly (backend/fronEnd) recipe (openimis.json) if this definition changes then will need to replace module terms we are using today → I fear that will bring a lot of confusion (Patrick)

Additional Resources