Hi Myrle - this is good information and clarity. I do have some comments
inline here and some further suggestions.

On Mar 10, 2018 12:09 AM, "Myrle Krantz" <my...@apache.org> wrote:

Hey James,

Fineract CN is a from-the-ground-up rewrite. Most important: it includes a
UI (fims). Fims is Apache-licensable and is actually part of the Fineract
project, unlike the Mifos community app. As a result we can keep
development on it onlist with no risk of splitting the community or
creating confusion about what is Mifos and what is Fineract.

Yes. Agree that this is a good thing, we want to avoid this confusion.

If you’ll look closely at the strangler pattern it assumes a gradual
synchronized rewrite of the backend *and* the front end. That is not what
has happened here.

Right. I wish we had been more conscious of how to enable a
transition/migration - the important thing is to not strand our community
of users.

If you wish to take that course yourself you’d need to do the following:
* create a translator API — this would be “shaped” the same as the current
Fineract 1.x api but implemented by calling Fineract CN where Fineract CN
has the necessary functionality.
* create an event mapper — for the bidirectional transport of data between
new and old systems that Fowler describes.
* create a data mapper — for the import of data from the old system to the
new system (and probably back again).

This would give you the ability to continue to use the Mifos community app
over Fineract CN. Because Fineract CN doesn’t support all the functionality
of Fineract 1.x, you would have to deploy both until it did. This kind of
deployment will require a sophisticated and expensive Ops team of a
dimension that not even Kuelap has. Perhaps there is some entity out there
which has this?

Perhaps... and I'd only suggest this for institutions w sufficient
requirements that can only be met w such a hybrid system. Seems unlikely.
Nonetheless thank you for outlining the approach required and how difficult
it could be.

I, personally, do not have the resources to help out in this sort of
programming effort required either. I believe it’s far more effort, with
worse results, than a simple data migration targeted at the specific use
cases which can be covered by Fineract CN today. And I feel no
responsibility for refactoring the Mifos community app which is not part of
the Fineract code base.

1.x and CN can co-exist in the Fineract project whatever migration strategy
we follow, including no migration at all.

No migration means that we will have two separate communities. I believe
that is not the way to go. Instead, the Fineract community needs to address
- over an appropriate period of time - the way to move from gen2 to gen3. I
believe the new code was accepted on the basis of one community vision and
high level roadmap.

In any case, we should focus on how to either maintain Fineract 1.x and
Fineract-CN or to enable a migration path that works for enough of the

If you do want to implement the strangler pattern though: I assume you are
already familiar with the Fineract 1.x REST API.  I suggest you start by
looking at the feign APIs of the Fineract CN services. There’s a package
called “api” in every service module which contains the REST interface,
domain objects, and event constants for that service.

I do believe still that my observation about API completeness and match w
Fineract-1.* Is important.  It's an easy way of confirming functional
completeness. Is there a reason not to use the API in that way?

Ok, I will start to look at the feign APIs and compare w existing Fineract
1.x.  I hope I can figure that out. If someone else on list has already
done so, please let me know!

Data migrations may be another way of approaching the software migration
issue, however I don't believe that will fully answer the questions about
functional match, and some migration issues will only become visible
through a regression testing involving the same APIs.  Changing all three:
front end, API layer, and data model simultaneously seems really difficult
to me to get right. Right?


Best Regards,

On Sat 10. Mar 2018 at 03:56 James Dailey <jamespdai...@gmail.com> wrote:

> Hi Ed and Devs,
> This thread deserves some comment and attention.  For many of the
> participants, the core MifosX (now Fineract 1.x) platform is all that they
> have known and a move to a different platform has all sorts of issues
> associated with it.  With Fineract-CN, a key idea was to respond to some
> the issues identified by implementers in the field - namely that the code
> was insufficiently flexible and extensible.
> It is vital for the community to determine a path from Fineract 1.x to
> Fineract-CN.
> My previous understanding, when Fineract-CN was first discussed, was that
> the code was going to be starting as a refactoring of the existing
> code. I vaguely understood it to be consistent with Martin Fowler's
> Strangler Application.
> https://www.martinfowler.com/bliki/StranglerApplication.html  In this
> article he lays out how to deal with a migration path from one monolithic
> API driven application to a microservices application.  "The fundamental
> strategy is EventInterception
> <https://www.martinfowler.com/bliki/EventInterception.html>, which can be
> used to gradually move functionality to the strangler and to enable
> AssetCapture <https://www.martinfowler.com/bliki/AssetCapture.html>."
> IBM has this later explanation on Fowler's concept:
> https://www.ibm.com/developerworks/cloud/library/cl-strangler-application-
> Why is this useful for Fineract1.x --> Fineract-CN?  Well, first it points
> to the idea that the Fineract API needs to be maintained from one
> generation to the next  As a guiding principle, this helps to define the
> "surface area" for the development effort. Once the API is able to run (or
> perhaps 95% of the API is a better target), then the effort can shift to
> versioning of the API or some other concept involving public APIs,
> APIs and composition of APIs.  It implies that existing front ends need
> be migrated initially.
> The strangler application concept also suggests that the microservices
> "creep in" and "take over gradually", implying that there should be a way
> for the Fineract-CN to relate to the existing code.  Perhaps we could look
> at certain areas of the Fineract-CN code to replace existing services in
> the Fineract1.x.
> Useful way to move forward?
> James
> On Wed, Feb 28, 2018 at 9:44 AM Ed Cable <edca...@mifos.org> wrote:
> > Now that the Fineract CN repositories are on the Apache Github,
> stabilized,
> > and proper build documentation is coming together, momentum is starting
> to
> > build.
> >
> > I wanted to raise on the mailing lists a question and concern I know is
> at
> > the back of the minds of many members of the Mifos and Fineract
> > communities.
> >
> > *What is the migration path from Fineract to Fineract CN? *
> >
> > During the genesis of Generation 3 now Fineract CN, we made the
> commitment
> > to a migration path so I want the dialogue to happen early so we can
> ensure
> > that as Fineract CN evolves and matures, we have in place the tools,
> > scripts, documentation to bridge the communities.
> >
> > Hundreds of institutions and millions of clients supported by partners
> from
> > around the world currently rely on Fineract but would greatly benefit
> form
> > this new architecture.
> >
> > I want our community to have this open discussion about what they
> envision
> > for an ideal migration path and what can be practically be implemented
> > achieve the best migration path possible.
> >
> > So let's use this thread and this wiki page at
> >
> >
> https://cwiki.apache.org/confluence/display/FINERACT/
> > to discuss:
> >
> > - Use cases for migration path
> > - Proposed solutions for a migration path along with pros/cons of each
> >
> > Some outcomes I'd like to see:
> > - Proposed Design & Approach
> > - Timeline and Placement on our Roadmap
> > - Identify Volunteers to Drive this Forward
> > - Scope out as a Potential GSOC Project
> >
> > I look forward to the discussion!
> >
> > P.S. If they're reading, this might be a chance for the folks at Apache
> > to get involved! :)
> > --
> > *Ed Cable*
> > President/CEO, Mifos Initiative
> > edca...@mifos.org | Skype: edcable | Mobile: +1.484.477.8649
> > <(484)%20477-8649>
> >
> > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org
> > <http://facebook.com/mifos>  <http://www.twitter.com/mifos>
> >

Reply via email to