What does Lenvi know about it?
We have a rebuilt lending platform. This has been grown from decades of pedigree, capability, and experience from our core lending systems and then made into a cloud-native solution with extensible UI and API. It is a solution that scales, is resilient and is highly configurable.
What advantages does LenviPF1 have over other Loan Management Platforms? To answer that I need to explain a bit about the thinking behind LenviPF1 and how we made the decisions that have led to its inception.
What, why, and where to start?
Digital transformation isn’t just a better website for your business or a new app.
It means building services for the online era, this means services for and of the web. User expectation is now that digital services are simple to use and well-integrated. Look at the examples from the Government Digital Service, your bank, and nearly every retailer.
Where to start? In my previous role, there were multiple crises at the beginning: failed security test results, a system outage, overrunning back-ups affecting the business day, a weekly recurring performance issue, and a host of persistent bugs that were preventing users from doing their day jobs and having to find workarounds.
You may have legacy systems, our loan management platform was considered a legacy product by its suppliers at that time; it had issues with stability, scalability, and resilience and was so difficult to change that a whole cottage industry of shadow IT solutions had grown up around it to support the day-to-day running of the business.
You may have little visibility of the cause of the issues and limited scope to alter the systems, we could only change our lending system through configuration; although we knew it was immensely capable, it wasn’t being used effectively and it was very hard to administer.
We needed to find effective ways of enhancing the platform and building on those changes iteratively. You need reliable foundations to begin the digital transformation journey so you can begin to deliver small and frequent change.
The right team
The first steps were to build a team that thought differently and understood agility, was open to collaboration, and understood digital transformation.
I’ve found that agile is misunderstood in most businesses. Being agile is defined by what teams find most valuable. Agile teams value personal interactions, and therefore the success of agile teams is heavily influenced by how well people work together and are willing to listen to the ideas of others. I’ve found that multi-disciplinary teams where people can put aside their roles and job title and just listen to the person with the expertise are successful. The people in our teams are empowered to try things and not be daunted by failure.
With empowerment comes accountability, the approach of those teams was always to put production systems first. This is something else our teams' value, working software. They document what is necessary, including the things that didn’t work, build, test and deploy, demo, get feedback, and iterate. But they are also there when it goes live, working with the end users and getting their feedback, looking at monitoring and diagnostics, and being on hand if it goes wrong.
The team needs to win the trust of the business people, their peers and senior stakeholders by demonstrating their ability to deliver.
Foundations
With the team in place, we set about building foundations that would make the core platform reliable, scalable, and cheaper to host. And most importantly, would give ourselves a platform to build upon. We did this by taking all the legacy software and packaging it in Docker containers, then orchestrating the platform with Kubernetes. We used CI/CD tools to build and deploy the packages and made the whole process automated so we could create or update dev, test, and production environments in a repeatable way. We wired in APM tools such as NewRelic (other APM tools are available) at the container level to monitor each platform component. We ran performance tests and could scale the environments up and down by adding more instances of individual components.
Infrastructure-as-code was a key component of making our strategy achievable. If someone had to manually log on to a server as part of a deployment we considered it a failure. With a cloud-native solution, we should codify a desired end state and then test that deployment configuration in pre-production environments like any other code. The advantages of this are repeatability, version control, peer review, and an approval chain that is very audit friendly.
Credibility, Consistency, and failure
The next steps were to find out what the business wanted from its system, other than reliability. Most of the shadow IT had grown up because of small missing features from the legacy LMS or a lack of integration. We built an augmentation layer using modern and ubiquitous tools and frameworks. No one wants to learn a 17-year-old Java web framework when they can be working with .net core, react, etc. We used client-side development and APIs with backend services in Azure functions to begin with because it was so easy to get deployed.
Once, we had a pipeline for injecting change through Azure DevOps and had embraced infrastructure-as-code we went further and used docker containers for all components and extended production monitoring so that we had full control of scale, resilience, and observability.
Managing change and getting buy-in from business colleagues from the board level down is key. Our collaborative teams sat with end users and produced fast prototypes and proof-of-concept software. We introduced new features behind toggles so that they could be switched on and off without full releases and had pilot groups of users trying out new functionality and giving us fast feedback.
Showing key stakeholders that we could quickly make changes but also quickly go back or fix forward if there was a problem was incredibly important. This mitigated much of the risk around releasing and we could begin to release changes every week or more if we wished. This consistency built our credibility. We already had the support of the senior management team but this also gained us the support of our end users.
But sometimes we failed, either to get the functionality right or we hit an issue in production. If it was a change to functionality we toggled that feature off until we could fix it. We created monitors and alerts to check the system was healthy and jump on any performance issues if and when they occurred. Our monitoring allowed us to find and alleviate bottlenecks in our system and scale up and down accordingly. It also enabled us to see when our integrations were failing and check on the third-party interfaces, missed payments, failing DD files, CRA outages, etc. We stopped worrying about failure as we could get back to a place of safety quickly and could easily see what was occurring in production.
Open platforms, standards & succession
What did we achieve? We integrated with SSO platforms, two different telephony systems, email and SMS gateways, open banking providers, CRAs, multiple payment providers, document generation, and fulfilment providers, all by creating an augmentation layer around the original legacy system.
But, making this augmentation layer was hard work, I don't believe many businesses could achieve it in the time we did. Our team gained specialist knowledge of how to run this platform and then made simple well-documented open tools to allow future extensions to be done with modern well-understood tools and frameworks.
If our platform was designed to be open to extension we could have achieved this so much quicker. If we'd had a standardised well-documented API and UI from the beginning we could have developed new functionality rapidly to suit our business needs. If the system had been hosted in a cloud-native way, we would have been able to scale up and down with the demands of the business and probably have greater reliability.
We had built the open platform and API we needed and that we wished we'd had from the beginning. We created a well-documented and standardized pathway for delivering new change. It allowed us to leave a better system and make recruitment and the onboarding of new people so much easier.
LenviPF1
This is the digital transformation journey that has led to LenviPF1. It is Cloud Native, scalable, resilient, and has cheaper hosting options. We have user interfaces and APIs that are open to extension and you can even take the source for some of the components to build on for yourself. You can host it yourself; we can provide the system in containers, or we can host it for you in the cloud. We support integration partners and have consumption-based pricing models.
We can grow with you.
Book a real-time demo to see how PF1 can help you
