Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Q4 2022Q1 2023Q2 2023Q3 2023Q4 2023 (more speculative) Q1 2024 and BEYOND BEYOND (most speculative) 

SprintBatch

Event Framework

SpringBatch COB

Event Framework

Upgrade to SpringBoot 3.0  

Improvements to batch 






Tenant improvements

Tenant improvements
Scalability Checks 





Self_Service out, refactor as service





Improvements to Batch processing

improvements and fixes (e.g. Data table access) 

Removing cruft , initial refactoring of loan class 

Refactoring Loan Module 

Payment Accounts (and related payment tranx) 

Revolving Line of Credit
Payment Accounts 
Improvements to Treasury Mngt

Treasury Management module 


Documentation on wiki redone to point to Ascii doc

Improvements to Swagger API auto generation

Liquibase for custom modules (doc)

Business and user documentation 









...

The above roadmap shows the high level areas of development.  Q4 work is retrospective.  

Group A: underlying libraries and infra related 

  • Spring Batch and Close of Business (COB) 
  • Upgrade to Spring Boot 3.0 [ SpringBoot now at major release 3.0 (JDK release process -like ), we are close to end of life on version 2.7 (likely on unsupported version by Q2 2023) 
  • Event framework (limited to specific modules for now ) 
  • Tenant improvements (parameterization) and security 
  • Need liquid base change script improvements for not-known liquibase change sets based on new custom modules ( in their own namespaces) , some kind of "orchestration" concept that outside groups have to... maybe better documentation 

Group B: Module refactoring  

  • Process: Fineract Improvement Proposal (FIP) under discussion on list 
  • Process: Developer documentation via ASCII docs so that patterns of "how to help use improve and add" are more clear 
  • Process: Creating high quality standards for new commits so that we avoid new code debt especially in this area (i.e. stop digging the hole) Existing work ongoing on Scalability, Batch processing, Event generation - improvement coming and also will need more attention 
  • Making progress on the Loan Module , cleaning it up, paying down "code debt", making it more maintainable and enhance performance by streamlining the code 
  • Creating high quality standards for new commits so that we avoid new code debt especially in this area (i.e. stop digging the hole)
  • Fineract Improvement Proposal (FIP) 
  • Documentation
  • Isolate "Self Service APIs"  to prevent inadvertent use 
  • Payment Accounts (scalable, avoid optimistic locking, throughput, refactor of balance calc ), essentially limited "current account" functionality, strip out interest and other features of savings component and create as a new concept).  aka "wallet accounts" 
  • Related to payment accounts, CAMPT.052 for ISO compatible batch concept, refactoring "note field" i.e. a JSON representation of the transaction set 

Group C: Documentation of the project

  • Using automated tools (ASCII doc) that exist in the git next to the code (DONE)  
  • Deprecate much of the wiki pages - highlight the ASCII docs 
  • Create flow of wiki that suites the two audiences (business vs developer) 
  • Need wiki pages for Capabilities documentation (as a kind of updated "user doc")  
  • Need API documentation auto generated 
  • Need liquid base change script improvements for not-known liquibase change sets based on new custom modules ( in their own namespaces) , some kind of "orchestration" concept that outside groups have to... maybe better documentation 
  • DSLQuery or JOOQ for enhancing security 
  • CAMPT.052 for ISO compatible batch concept, refactoring "note field" i.e. a JSON representation of the transaction set 
  • SpringBoot major release 3.0 (JDK release process -like ) / they currrently only support 2.6 and 2.7 and we are on 2.7 / so we are close to end of life 
  • Reporting module 

Group D: Areas of work we anticipate seeing as contributions 

  • Fixes for POSTGRES implementations (existing queries in code base and uncovered by tests) - coming as a fix 
  • Completing features across the board (events applied to outside of loan module) 
  • Generic revolving line of credit (as a plug in or in a new way that enhances extensibility of the architecture)  , maybe a new microservice?  

Group E:  Ideas and specific items we might be looking at further 

  • DSLQuery or JOOQ for enhancing security Payment Accounts (scalable, avoid optimistic locking, throughput, refactor of balance calc ) 
  • Command processing service - implementing retry mechanism in case of optimistic locking problems (multiple transactions on the same account/ improved implementation) 
    • Message Queues and response mechanisms 
  • Refactor and Remove all security framework and place instead with outside OpenPolicy notes / at idea stage **See notes notes Roadmap conversation 2023 


Group F: Stuff we think is needed but isn't practically on the Roadmap (no one doing the work) 

  • Reporting module
  • Completing features across the board (events applied to outside of loan module) 
  • Extension points for the Customer model, i.e. support external KYC providers and external third party systems 
  • Data export capabilities to external data lakes (might be mostly documentation) 
  • Security model enhancement by proposing a deployment architecture behind appropriate firewalls and API gateways (documentation
  • Isolate "Self Service APIs"  to prevent inadvertent use  
  • Generic revolving line of credit (as a plug in or in a new way that enhances extensibility of the architecture, maybe a new microservice?  
  • Better extension points for Full Treasury management system (APIs and new funds movement configuration)  
  • Better documentation and perhaps a micro service that performs upgrade from version A to version Z Payment Accounts (limited "current account" functionality, strip out interest and other features of savings component and create as a new concept).  aka "wallet accounts" 
  • Merchant account feature?:  Down payment on a "Purchase Event" , introducing the idea of a merchant account where full "good funds received" payment is made into account by source of funds being "purchaser" plus "financing source" 

...