This page details our shared vision for product planning, prioritized features, and raw notes from brainstorming sessions

Shared Vision

Our Our Message now has it's own little home on the wiki. Please visit it!

Specific Product Priorities for 2011

Anticipated Next release - Currently in Elsie F

This release contains several important features and is close to feature complete. The majority of the product roadmap for 2011 will focus on releases after Elsie F.

• KEEF MPESA Disbursal Plugin - Q1? (Sol develo)
• Enda Variable Loans, Permissions - Feature complete January (TW)
• Declining Balance
• Some Improvements to Tally Accounting
• Small Localization Improvements
• Bug Fixing
• FTL Spike
• OSGI Spike (during F, not essential for release)
• Spring Transaction Spike (during F, not essential for release)
• Automated Regression Tests (during Q1)

Currently in BI 1.0

• India Standard Reports - some in January,
• KEEF Collection Sheet Report- February at the latest (John W)
• KEEF Transaction Report - February at the latest (Udai)
• PPI data dump - January

2011 Commitments - signed or have been communicated to our customers

• KEEF MPESA Disbursal Plugin - Q1? (Sol develo)
• KEEF Collection Sheet Report- February at the latest (John W)
• KEEF Transaction Report - February at the latest (Udai)
• Enda Variable Loans, Permissions - Feature complete January (TW)
• India Standard Reports - some in January, some in March (Sol develo)
• PPI data dump - January

Other Priorities in 2011

• Localization improvements immediate
• Improvements to Tally Accounting
• PPI Analytic Reports
• Moving clients and groups / Removing meeting requirements
• Reports with Financial Data
• Auto-calculation of penalties
• Data Migration work

Current scheduled spikes

• OSGI spikes - MIFOS-3235  
• Convert Struts/JSP to Spring/FTL spike - MIFOS-4409    (Stanley, Adam M)
• API and API test spike - MIFOS-4174   (Kojo)
• Spring transactions - MIFOS-4402    - (KeithW, Udai)

Technical Commitments

• service facades - MIFOS-4385    (KeithW)
• deliver services/application code with jar so its reusable - MIFOS-4305   (KeithW)
  • enables API based Data Migration
  • enables API use for testing - MIFOS-4174  
• removing BIRT
  • converting all standard reports
  • converting admin docs
• removing Check list functionality?? (KeithW)
• removing 'view additional fields' functionality - MIFOS-4439   (KeithW)
• remove legacy surveys
• completely remove Struts/JSP implementation to spring/ftl (Stanley?, KeithW, Others?)
  • fixes localisation issues
  • fixes broswer back button/refresh issues
  • removes all struts integration tests
  • removes all tag libraries
  • removes need for 'label' functionality in admin
  • removes menu builder functionality from ui
• database migration move to Liquibase (TW?)

Ideas

• Understanding our customers (Personas, Map Value Stream)
  • Value the domain more highly.
• Idea Page

Brainstorming notes

Session 2

Session 1:

Brainstorming ideas for product roadmap - Session 1

Uncategorized

• PPI cloud application

Tighter/cleaner integration with Pentaho

• Pentaho appears embedded in mifos (users don't even know they're using Pentaho) - aka OEM Pentaho
• single signon for reporting, dashboards....
• Admin Docs
  • how do our customers use admin docs now?
  • Can this be replaced with printable HTML (preview page or create receipt page)
• Get rid of BIRT

Language support

• allow language switching on the fly
• allow per-user locales
• remove .po files
• localization per module/plugin?

Search

1. Improve search to allow for realtime suggested search list. e.g. if user enters "my" suggested search dropdown appears with groups, clients, centers that start with "my"
2. tree view of hierarchy so organization is more visible

Mifos as a service

• allow access to Mifos outside of the web UI
• provide public API that mobile, integrators, etc. can access

Bulk Operations like Collection-sheet

• are there other operations where many operations could be done at once to improve MFI efficiency?

User Data Collection from Cloud

• A separate app, log analysis
• Compile results for help understanding usage of Mifos

Custom Login screen/dashboard

• provide a better/cooler login screen
• allow users to customize what they see on the first screen
  • include the ability to display BI dashboards/reports on login screen
• AJAX/Portlet?

Speeding up development

• Multiple stage builds
• Automated Deployments
• Automate everything which is repeated in process
• Follow best practices (continuous delivery)
  • every change in the code (even a single line change) should be releasable

Pluggable modules

• Integrating with other apps like accounting and HR, be able to plug them in and out
• Complete MFI solution?

Roles and Permissions

• Improve this area
• Get rid of custom Mifos code, use libraries instead

Flexible System?

• One feature now meets different use cases / different needs that we "hack" in
• Figure out a way to rebuild the system so we can meet different use cases effectively
  • One example is how we have fees right now
• but without complexity

Mobile client for realtime collections entry

• Are there Hardware specific to MFI Loan officer (Biometric, receipt printer)?

www access for particular clients (to check their accounts' balance, repayment schedule, etc.)

• let the client access their own account
• or checking using mobile phone access?

Reduce cost of switching to mifos

Value the Domain more highly

We need to be sure we are building the right thing.

Lean Principles: Eliminate Waste

Building the Wrong Thing
"There is nothing so useless as doing efficiently that which should not be done at all." -Peter Drucker
Some extracts from foreword by Martin Fowler to 'Domain Driven Design'.

There are many things that make software development complex. But at the heart of this complexity is the essential intricacy of the problem domain itself. If you're trying to add automation to complicated human enterprise, then your software cannot dodge this complexity - all it can do is control it.

The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need. A good domain model can be incredibly valuable, buts its not something that's easy to make....

... Eric also cements many of the things that we've learned over the years. First, in domain modeling, you shouldn't separate the concepts from the implementation. An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer. Partly this is true because you cannot build a useful conceptual model without considering implementation issues. But the primary reason why concepts and implementation belong together is this: The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together...

... domain models aren't first modeled and then implemented... really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.
So in summary I think we can achieve a better product and imagine better things to provide by:

1. Understanding the domain of microfinance better
2. Understanding our customers better and how they deliver value to their customers.
   • what happens on the ground at all levels? How can the MIS help their day to day job?
   • What is MFIs biggest problems (at all levels of staff)
3. Understanding Grameen better and how its delivers value to our customers.
   **how the various departments work together to reach organizational goals.

• Can we set up a new list or environment where us 'technologists' can meet up with domain experts? or some other form of communicating with each other, meetings, wiki etc

• Can we understand how MFIs work and how they use the application?
  • http://www.agilemodeling.com/artifacts/personas.htm 

Mifos playground for domain and technology modeling

In our upcoming roadmap, we have alot of tech debt work and changing features 'removal of meeting requirements etc' to try and get us into a 'half reasonable state'. This can be quiet soul destroying; Imagine that all 'tech debt' is done and some of the features have being completed. We still remain with an architecture/design/model that is still not suitable to what we currently understand about the domain and where we need to go (think multi-tenancy, multi-currency, auditing, village-banking model/grameen model, teller-model etc)

I personally will probably want to create a 'mifos playground' completely off mifos where I can use knowledge gained from 'domain discussions' and model this knowledge whilst also taking into account 'technologies' that we want to move towards.

The benefits is we will gain deeper insight into the model we will need and also learn about benefits from 'technologies' we want to be on (OSGI, Spring, JPA etc) (sort of like what you did with cheetah but want to take an even more extreme approach, a kind of 'future-spective look at mifos')

We can't achieve this in a reasonable time line on 'current mifos codebase' for a multitude of reasons.