Irakli Nadareishvili is the Managing Director of the global Banking Platform at JPMorgan Chase and Company. Over the past 15 years, he has worked on distributed systems and various APIs. He has also authored a couple of books. In this article, he discusses building future-proof API platforms.
I’m very passionate about APIs, but ironically, one thing that I learned about APIs all the time is that APIs don’t matter. Let me explain myself. Individual APIs just provide a small part of the solution. They can be very useful, but usually they are incomplete. The real value comes from building API platforms, a collection of logically interconnected APIs that deliver holistic business value. For instance, an accounting API would be a single destination for applications and systems that want to do something related to accounting. Similarly, an enterprise customer platform is where all of the systems and applications go in a large enterprise to query any data about the customer or to modify any data about the customer.
In a modern enterprise or financial institution, the technology space should consist of a bunch of well-designed API platforms, all working in unison to power the business’s digital and analog needs.
Unfortunately, the reality is that there’s a lot of regret in technology these days. A recent report from Gartner shows that 73% of all tech acquisitions had ended in regret even before the project was started, and only 13% of these acquisitions were successful or led to no regret once the project was completed.
Suppose we want to reduce the regret in technology and build platforms that last a long time. In that case, I believe we need to focus less on how to build things the right way, maybe less on agile methodology, data governance, or other things that we have been upsized by and are starting to worry more about. Are we building the right thing? So, we have mastered all these ways to build things correctly, but at the end of the day, are we building the right thing?
I want to share three main lessons that we have learned from working for several large financial institutions and other organizations over the past many years.
Lesson one – Focus on “Needs” versus “Wants.”
Many times, when we are building large platforms of enterprise systems, we don’t pay enough attention to customer needs, and we sometimes just take the requirements, which are really what the customer wants, at face value.
To consider an analogy, if Henry Ford had asked his early customers what they wanted, nobody would say a car because nobody knew what it was, and most people would tell them they wanted faster horses. So, the customer needed a faster mode of transport, but because they did not know the solution, they said they wanted faster horses. So, it’s important to talk to your customers because if you don’t talk to your customers, you don’t understand their needs. While building a solution, we need to look at a platform that addresses multiple needs of multiple customers and not a single need. We need to build a model that can scale. Needs are timeless and wants are temporary. Last but not least, we must ensure that the needs we implement in the platform are timeless and not temporary.
Lesson Two – Watch total cost over time.
Sometimes, we centralize the implementation of the functionality that does not last over time. When we think about a platform’s return on investment and cost, we need to think about it in time. At a specific time, somebody looks at the collection of all needs and builds a platform. But, if one customer’s need changes, the entire platform is impacted. This can lead to many unhappy customers or changes to existing code and implementations. So, we must analyze things in time and avoid implementing things in the platforms that may change frequently. It is a very important criterion to evaluate when we build anything into a platform. The general rule is that don’t put in the platform the functionalities that are very likely to change in the future, even if today, they are very useful and are used by many. If you do have to implement that centrally, then make that functionality extensible, such that they can extend it through self-service APIs. This will create more longevity for the platform and avoid the dependency and coordination nightmare that usually leads to the demise of centralized platforms.
Lesson Three – Invest in Stakeholder emotion
When we build centralized platforms or API platforms, we often don’t pay enough attention to the emotional aspect of the stakeholders and customers of the platform. For most people, other than the developers, APIs are a back-end engine that does not have a user interface, and they don’t know how to play with the APIs. So, they do not know how to test APIs and give their feedback or get a feel of how things are working. To address this issue, creating specific user interfaces for the API platforms you’re building is very important. We must create experiences for people who can tell us if the business logic of the API platform is correct or not. It’s very important to make that interaction easy and share it with stakeholders early in development. This will give the stakeholders an opportunity to opine about the API platform and start admiring what we’re building, get emotionally attached, and become the champions of what we’re building. So, investing in stakeholder emotion is an often-ignored aspect of building successful API platforms, but it is very important.
To conclude, the time of wild forest of APIs at large companies is over. It will be all about well-designed API platforms that deliver holistic business value in the future. As we learn to develop these API platforms, the most important thing to remember is to worry less about building them correctly and start concentrating on building the right thing.
