Erin Kieffner, Director of Service Enablement, Ryan Pigford Software Developer Manager, and Chris Spinner, Software Engineering Manager, share OneMain Financial’s journey implementing MuleSoft. They recently presented with our Online Group-English to offer tips for others in the MuleSoft Community looking to either transition to using MuleSoft or build an omnichannel framework.
In the first part of our blog series, we discuss a little bit about our individual roles on the team, explain our MuleSoft journey, and dive into a few of the integration challenges we needed to solve. I am the Director of Service Enablement, also known as the “MuleSoft Team,” for OneMain Financial. My organization has four development teams with about 30 developers, and we are responsible for integrations across the enterprise’s application network, as well as with external third-party partners. I’ve been with the organization for two years.
Ryan is a Software Engineering Manager on my team, and he is one of the four development managers focused in the originations program. He’s been with OneMain Financial for three and a half years and was the only manager we had at the beginning of our MuleSoft journey. Chris is also a Software Engineering Manager on my team and has been with OneMain Financial for about two years. He’s taken part in our journey to adopt MuleSoft and an API-led design approach to integrate our systems and applications. Chris primarily works in account servicing and customer communication spaces.
So who and what is OneMain Financial?
OneMain Financial is the country’s largest lending exclusive financial company, with more than 1500 branches across 44 states. We are backed by over a hundred years of experience and we offer safe, affordable, and transparent installment loans to millions of people. Our customers turn to us to meet financial needs such as debt consolidation, medical expenses, household bills, perhaps home improvements, or even auto purchases. We consistently innovate to serve our customers when, where, and how they want.
What we offer really boils down to three main products:
- Unsecured personal loans: loans that don’t require any collateral
- Secured personal loans: loans that require collateral
- Auto loans: These are specific loans to purchase a vehicle
What sets us apart is that our customers have the opportunity to meet with us face to face or digitally, whichever they prefer.
Our MuleSoft journey: Creating a C4E
We started our MuleSoft journey in January of 2018, when we brought in MuleSoft Professional Services to help us onboard. Before MuleSoft, we had a large space of Java applications with Java web services that we had created over the years. We had 37 Java applications with a thousand point-to-point integrations and only two full-time developers. These became muddy and hard to work with, so we chose MuleSoft to monitor, effectively manage, and build a network to move forward.
Ryan was the manager of the team and they decided to pick a pilot application. We started on Mule 3.X and MuleSoft professional services helped us understand what we needed and how we were going to start. Our first challenge was how do we move this point-to-point integration to the network? One of the keys to our success really was our creation of a C4E team. We now have a separate team that manages our Center for Enablement and that really helped us understand MuleSoft as we got started on our journey.
We launched our pilot in August of 2018, so it took us a little while. Also, about five months after we started developing, Mule 4.x was released. So, instead of continuing in Mule 3.x, we made a corporate decision to move to Mule 4.x. This was a difficult decision for us, but ultimately knowing how difficult it was to move our applications, we didn’t want to migrate the entire system of APIs. We built our first Mule 4.x APIs in October of 2018, and over the course of the year we started converting the 1000 Java endpoints that we had into MuleSoft. By the end of the year, we had eight APIs in production and in December of 2018, we decided to only do new work in MuleSoft when we felt more comfortable.
Thus, 2019 was our year of growth and after we created the C4E team, they built a training program and our technology group allowed us to expand our team and focus on service enablement. We had to train many developers over the course of 2019 and by the end of the year, we had over 20 developers. The C4E was beneficial to us and prepared us to build with MuleSoft on our own in the future.
Our work after the C4E in 2019
After becoming more confident in our MuleSoft abilities, we built a CI/CD platform in a year and decided to do all project development in MuleSoft. However, we were having a difficult time completing conversions because of the project work, onboarding, and growth we were experiencing at the same time. Thus, to facilitate conversions and get ourselves off of Java, we had new work coming in that touched an old endpoint. We took that as an opportunity to re-architect the solution and move it to MuleSoft. From then on, that’s how we pushed those conversions through in 2019. We really started to understand the architecture of what it meant to create using an API-led framework of: experience to process to system and drive towards reusability.
2020 onwards
2020 was really the year of our maturity in use of MuleSoft. Our ability to monitor and report to show how our services are bringing value has really improved. Right now, we have over 200 APIs in production and that’s been a big sell for us. In August 2020, we crossed over that line where now our MuleSoft implementation is really creating more value than our Java services. Over the next year, we plan to bring our Java service count to zero and be fully on the MuleSoft platform.
Challenges faced over the last three years
Over the course of our three years, we’ve had several challenges and we’ve really had to figure things out. Our C4E team has been a huge factor in our success. Some of the biggest challenges we struggled with are:
- Technology buy-in and having our technology organization understand why we’re moving to an API-led architectural approach and the value.
- Reusability and transitioning from a point-to-point mindset to looking at each project differently to see how the APIs we build could be reused in other projects.
- Business logic and understanding how the API layers fit including what goes into each layer.
- API visibility and knowing what we have available in Anypoint Exchange for our UI teams, as well as getting consumers to see our library.
- For the legacy Java services that have been converted to MuleSoft APIs, challenged with getting attention of consuming applications to convert to the MuleSoft APIs.
In the next portion of this series, our team will describe how we overcame these challenges and built an omnichannel customer notification framework. You can find our presentation of our MuleSoft Journey below:
