Menu
▾
▴
Re: [Mifos-users] Data Migration Approach-- a question
|
From: <Par...@su...> - 2010-04-14 11:47:26
|
Hi Krishnan, You are right, building a domain ontology will surely help in many areas - not just migration. The lofty goal is to model the microfinance domain using one of the modeling languages (EMF in this instance) - data becomes instances of this model, and transforming these data to some platform/product specific model is a case model to model transformation. While this is the idea with which we started this project, given the toolset available in the market to achieve this and their efficiency (and our mastery/lack of it in them :) ), we want to do whatever that is possible through modelling and allied tools, and achieve the rest through some traditional methods. We are happy to know that you are keen on participating and there are quite a few areas in which you can help. We can have a detailed discussion over call sometime this week - let us know a time. One of the things we are also to keen to see is the xl templates used by MOSTFIT to gather data. Thanks and Regards, Parthasarathy T * Technical Lead * SunGard * Technology Services * Embassy Icon, #3, 6th Floor, Infantry Road, Bangalore - 560 001, Karnataka, India * Tel +91 80 3091 3183 * Mobile +91 99450 00394 * Main +91 80 3091 3000 * Fax +91 80 2222 0511 * www.sungard.com/sts <http://www.sungard.com/sts> P Think before you print CONFIDENTIALITY: This e-mail (including any attachments) may contain confidential, proprietary and privileged information, and unauthorized disclosure or use is prohibited. If you receive this e-mail in error, please notify the sender and delete this e-mail from your system. ________________________________ From: Krishnan M [mailto:km...@ya...] Sent: Friday, April 09, 2010 10:39 AM To: A good place to start for users or folks new to Mifos. Subject: Re: [Mifos-users] Data Migration Approach-- a question Hello Emily, my 2 cents on your specific questions (and then some other thoughts, requests...): Firstly, i am presuming migration using the approach is significantly faster, as well as 'iterative' (that is, one can re-load all or part of the data at will as issues are discovered and fixed after each run) a) About changes at the MFI during the data migration process. i am not sure why the system should be unavailable for 'direct' usage and data entry during the time that a data migration using the 'interim' database is in progress. Except for changes to configuration, etc. that affect a lot of things, i am sure the migration team can setup a dashboard, for example, that lists (for example) branches and a RED/AMBER/GREEN flag against each (a highly simplified view...) that lets people go about their work as migration completes for data against branches, or whatever other "node" is suitable. In such case, it is not necessary that all changes must be applied through the migration team alone, though it is advisable that the migration team is "subscribed" to or even advises about all such changes, though it may or may not apply those changes to their "own copy of data", unless the same are relevant. i don't anticipate a lot of churn, unless the governance is setup wrong, which is usually the case with most system adoption efforts. b) The approach suggested also takes care of a staged roll-out, in fact, it pre-supposes one... Now, for some other thoughts: i have been advocating a common industry standard format for data that (ultimately) reduces vendor dependence for microfinance organizations. The simplified data model is pretty much the first step in this direction, and i am hoping we could: 1) Come up with a simple model and publish the same, and 2) Provide "reference implementations" that establish the value of the data model for migrating to Mifos, and even, between Mifos and a few other MIS systems (in one, and preferably, both directions) i am keenly interested in participating in this effort. In fact, with MOSTFIT (the other open-source MIS for microfinance i am a part of), we provide a simple spreadsheet that users can put data into, that we simply upload. Admittedly, this is at an early stage, where we don't have a very sophisticated data model, but its a start...(more details available on request) regards, krishnan --- On Tue, 6/4/10, Emily Tucker <ET...@gr...> wrote: From: Emily Tucker <ET...@gr...> Subject: [Mifos-users] Data Migration Approach-- a question To: "A good place to start for users or folks new to Mifos." <mif...@li...> Date: Tuesday, 6 April, 2010, 8:59 PM Hi Folks, Partha and Chandan, at SunGard, are working with us to develop a data migration tool for Mifos. Below is a quick high level overview on their approach, and then a question. High level overview (I'm not technical, so apologies to SunGard if I miss some technical nuances): SunGard is developing a simplified data model into which data from other systems (legacy systems, excel spreadsheets, etc) can be migrated. They will then build migration scripts that will port data from this interim database into Mifos (these scripts will be replaced by APIs once Mifos has those available). The idea is that the work to migrate data from the interim database into Mifos only has to be done once. The work from the MFIs data sources into the interim database will need to happen every time (unless we're doing multiple migrations from the same legacy system)-but it will be a much easier task since the interim database will be much simpler than the Mifos database. Approach: SunGard is assuming that they will do a *complete* migration of all data from the interim database into Mifos-including things that would be quite easy to manually type into Mifos-ie, offices, users, products, etc. Basically all configuration items would be stored in the interim database and migrated over. My Question: What do people think of this approach? I had always assumed that we (the deployment team working at the customer site) would first configure Mifos and manually enter entities like offices and that the migration would be limited only to the entities that can't be handled by manual entry (ie, centers, groups, clients and accounts). Not sure why I assumed that-I suppose because I didn't see the need to build migration scripts for items that can easily be manually entered. Besides the general concern, I have two specific questions: (*) Will this approach make it difficult to accommodate changes at the MFI during the data migration process. Ie, if the MFI adds a new user during the migration process-they can't add it directly into Mifos-they need to communicate back to the data migration team to make a new entry, right? Will this cause a lot of churn? (*) How will this approach handle doing a staged roll-out, where they're migrating a few branches at a time? Partha: Any comments on this? Ryan: especially interested in your take. J Emily -----Inline Attachment Follows----- ------------------------------------------------------------------------ ------ Download Intel(r) Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -----Inline Attachment Follows----- _______________________________________________ Mifos-users mailing list Mif...@li... https://lists.sourceforge.net/lists/listinfo/mifos-users Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php |
