It is “Social open source community”

As a systems developer, I pretty much agree that the idea behind the pyramid (which is a kind of a separation of concerns) is very useful. It’s not usually a good thing to put too much functionality into one system.

From a user perspective, the product used needs to have all the functionality to do the job at hand. Of course, under the bonnet, this can be a number of systems that seem connected. The basic idea behind Mifos X is to be good at ‘portfolio services’ and to expect that there are times when other systems will need to be integrated to make up a full ‘product’ e.g accounting, contact management, adhoc querying, analytics and so it goes on depending on the user needs.

Mifos X also does a ‘basic’ job at providing a reporting capability, the ability to plug-in non-core data and (soon) simple accounting so that many smaller users don’t have to worry about integration if they don’t have a huge need in those areas. However, its a point well-made that going beyond this simple scope can be counter-productive and is likely to result in much more complicated beast to take care of. Although the boundaries are somewhat subjective, any desire to incorporate fully functional accounting or contact management features within Mifos X should be avoided in favour of integrating with other systems that focus on those areas.

Most of the main article is about being able to cater for combinations of Microfinance methodologies because ‘blending’ might prove useful in business development and outreach. In the system sense this still amounts to handling transaction processing for the various types of a client’s accounts and services. So, the heavy lifting is still at the bottom of the pyramid. In Mifos X, this is equivalent to the API which dutifully does all that mind-numbing number and data crunching work – although I do love the sound of the cogs turning over . Other parts mentioned in the main article (analytic insight for example) can be done using any number of open source and commercial products. And it’s possible to make that integration appear seamless through the user interface.

At the risk of sounding like an Information Systems lecturer (or teaching grandma how to suck eggs) information systems are often depicted as a pyramid with Transaction Processing Systems (TPS) at the base, Management Information Systems (MIS) in the middle, and Decision Support Systems (DSS) at the top. The critical attributes for each kind of system differ. TPS need to be efficient to handle the volume of transactions, be accurate, and auditable – the “rock solid” foundation on which the layers above are stacked. They tend to be backward looking.

DSS on the other hand need to be flexible and support ad-hoc queries and are often more forward looking, supporting “What if?” scenarios. One doesn’t really want tellers in microfinance institutes experimenting with ideas like “What if that customer just now hadn’t actually made a payment to the bank”

MIS fall somewhere in between – standard reports that summarise the transactions in well understood ways.

In my view, Mifos’ tremendous value is as a solid TPS. The TPS constraints above will mean that it will always be a “poor dancer” – never showy and nimble on its feet, but a friend that we can rely on to clean up after the party. (hope I’m not mixing metaphors too much).

I’d welcome greater expressive capability in its database, but in my view greater complexity (and greater risk of bugs) will inevitably come with that flexibility, and that will tend to make its development somewhat slower than everyone might wish.

Hope I haven’t missed your point above.