FISPAN Blog

“Don’t try this at home”. Why you shouldn’t develop your own ERP Adaptors

Posted by Clayton Weir on Jul 8, 2020 9:00:00 AM
Clayton Weir
Find me on:

During a panel at AFP New England, the moderator posited that most Fintech ideas evolve from something too niche for banks to tackle themselves. My response was indignant; while that may be true in some cases, truly powerful ideas are just the opposite. These ideas and tools are almost too big for a single bank to take on themselves - even for Tier 1 Global banks. I strongly believe that FISPAN is built on an idea that requires “utility-scale” in order to get right.

 

FISPAN’s value proposition of embedding your bank’s products deeply into your client’s domains is becoming mission-critical, but the challenge is you still need to decide whether using the FISPAN platform is the right solution to the problem versus building your own solution (either internally, or contracting some outsourced solution developer). We fully realize that there are cultural (certainly in some banks) and strategic (hopefully in all banks) reasons to do that analysis. My flippant sales answer is something like, “As a friend, I can tell you that you might regret building, owning, and operating your own suite of ERPconnectors, because most days I do.” Below is a slightly more thoughtful version of things you should be considering to help you navigate through this decision.

 

How quickly, cheaply and impactfully can you get to market (if at all)?

 

We all know the horror stories about enterprise software projects going over budget (45% of projects) and failing to deliver the intended value (only about 56%)  according to McKinsey. The stories get worse if you focus on projects involving digital banking experiences.  Forrester and Avoka published a great study on how many large IT projects at enterprise banking and financial services firms get delayed, overrun, and even more disappointingly fail to deliver all of the business value promised.

 

Their survey shows that most projects take longer than expected and that a miss on speed is usually coupled with a blown budget. A low 12% of projects were recorded to be on or under budget, 45% of projects were over budget by at least a staggreing 25%. Coupled with speed, only 3% that went over their delivery date were on or under budget. If you choose to develop internally, odds are you will be over-budget and miss your initial targeted delivery date. 

 

In addition, projects that take longer than expected are less likely to be updated frequently, on average ⅓ of software releases are updated once a year or less, closer to half (42%) if the project took longer than expected. Instead of updating software, teams are focused on fixing defects and managing dependencies. Without the much needed updates to your software, the value of your project diminishes. 



We have all seen this movie before when it comes to software projects. Now four years into the FISPAN journey, I have started to see some of those early build vs. buy decisions from our early prospects come to fruition. Let’s just say the results are quite consistent with what Forrester and Mckinsey might have predicted. 



When you look at the biggest drivers of a failed software project, a disproportionate amount of blame tends to fall on some failure to properly scope the mission in terms of vision, customer needs and potential constraints. 

 

In addition to the inability to properly staff the program with the right skill mix, I believe those risks become heightened in a domain area like embedded/ERP banking. A team has to understand the nuances of client ERP Systems, Bank legacy systems Treasury Banking, Accounting Workflows, Banking Workflows and deliver a program that can exist and add value within all of those different constraints. Not only will most banks and contracted build partners be unlikely to have some of those perspectives sitting on the bench, it will be hard to deploy the right mix of people to the initiative concurrently. 

 

Our platform is OOB SaaS and we have invested heavily in tooling that allows us to connect to your payments and data systems, leveraging everyday connectivity paradigms you have available. We can get into the market and learn from your bank's clients within weeks as opposed to years (if ever). Because FISPAN is not an IT project, you are relying on our hundreds of sprints and investment in user analysis and development. You can keep your powder dry for additional initiatives to take your ERP banking initiative over the top. 

 

Nuance, Idiosyncrasies and Headaches

 

Business applications such as ERPs create quite a complicated landscape. There are hundreds of applications in the market, each with their own issues on versioning, customizations and nuances in language and workflows. Below is an example of such differences from our ERP webinar

 

Sometimes the language is similar, but the underlying architecture of each system is always unique. Banks require a platform-type solution to normalize this complexity to enable scale with legacy bank platforms.

If gathering requirements and constraints analysis is the biggest driver of cost and failure in software delivery, then navigating a project that adds many destination applications with their own complexity massively increases the opportunities for failure.  A project team requires some familiarity with these systems, with accounting and treasury works flows in addition to the bank’s side of the program. Generally not the resources you have sitting on the bench at a bank. Not to mention that in addition to whatever application development framework you use, our ERPadapter team has had to deploy an ever growing list of languages and frameworks used by the applications. These are sometimes proprietary, not the horizontal skills you already have in the team. In many cases the ERP will require your developers to be certified to build extensions to their application.

ERP Adapter Team: List of ever-growing languages and frameworks.


When working with FISPAN you are benefiting from hundreds of sprints worth of customer (Finance Departments) discovery, business analysis and hard-earned scars. It has forced us to staff our whole organization with the right mix of technologists and business people to solve the different challenges in the stack.   



Tooling, Agility and Cadence. 

 

You may have become scared of developing for a wide range of legacy ERPs and want to run a focused program against a few of the modern applications that tend to be more single tenanted, single versioned and cloud-based. That type of focus solves a lot of problems, but it exacerbates other realities of a bank’s IT delivery program.

Modernization of the ERP. Legacy Applications vs. Modern Applications

A more modern application takes advantage of those same factors in order to release products more often and more efficiently than legacy ERPs anywhere from twice a year to monthly. Just preparing for these planned releases would challenge the delivery cadence of most internal development shops, but that’s only part of the story. What about unplanned changes in front hose vendors and how do you even detect them? What about bank side changes and new functionality? What about the fear that creeps into an organization on touching anything in your code not knowing if it will accidentally break QBO while adhering to a change?  

 

Maintaining a functioning and valuable portfolio of these adapters will really put additional pressure on a bank to modernize its DevOps tooling and delivery cadence. When banks ask what our secret sauce is, I always point bank to the CI/CD Pipeline and the expansive automated testing infrastructure we have invested in. Not only are we shipping weekly at a minimum, but we are also testing each ERP application E2E across all the banking systems on each code commit, often picking up unpublished changes or errors on both sides. FISPAN partner banks are taking advantage of our infrastructure testing and monitoring, developer environments and other tooling for free.


FISPAN Technical Build and Functionality Complexity

This tooling is the required cost of offering a product such as fispan and is something you as a bank need to consider when deciding between build vs. buy.

 

Non Functional Requirements

 

Even if your business analysis nails the customer experience and the business objectives of offering, you must recognize this is a mission-critical application that will have massive Nonfunctional requirements. While we know that your development and deployment environment is completely compliant, an outsourced build may not be out of the gate, and building your own application will uncut infrastructure costs. 

 

With FISPAN you’re not just buying the functional outcomes but you are getting the whole NFR platform as a package including multi-data center hosting, a robust operational and compliance program overseeing development in a SOC II, ISO 27002 and GDPR compliant manner. No headaches, no marginal costs which makes the TCO profile more palatable and knowable over time. 

 

Building is Forever

 

The excitement of building fades long before the bills quit rolling in for the obligation. These ERP adapter applications have a long lifecycle as all banking software does but it introduces a long term exposure to the variability of multiple other software with the developer’s vendors of these ERPs. This creates a profile of long term costs and makes it difficult to get off the ride once you want to.  We have developed a platform where banks can take our OOB offering, with light touch bank connectivity and get to market quickly.

 

Contact us today to learn more about FISPAN and partnering with us.