...
Q4 2022 | Q1 2023 | Q2 2023 | Q3 2023 | Q4 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 | 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"
...