As a seasoned developer who has spent years building distributed systems and various types of APIs, I’ve grown passionate about APIs. Ironically, the most significant lesson I’ve learned is that individual APIs don’t really matter. Let me explain.
While individual APIs provide small pieces of functionality, they are often incomplete when it comes to delivering real business value. The true power lies in building API platforms—a collection of logically interconnected APIs that deliver holistic business solutions. For example, an accounting API platform serves as a single destination for applications and systems needing to perform accounting-related tasks. Similarly, an enterprise customer platform centralizes all customer data interactions within a large organization.
In modern enterprises, especially financial institutions, technology ecosystems should consist of well-designed API platforms working in unison to power both digital and analog business needs. This should be our destination. However, the reality is far from this ideal.
A recent Gartner report revealed that 73% of tech acquisitions ended in regret before the projects even started, and only 13% led to satisfaction upon completion. While this statistic focuses on purchased solutions, homegrown technologies often fare no better. There’s a pervasive sense of regret in technology today.
To reduce this regret and build platforms that stand the test of time, we need to shift our focus. We’ve become adept at building things the right way—mastering agile methodologies, data governance, and other practices. But we must ask ourselves: Are we building the right thing?
I want to share three key lessons learned from working with large financial institutions and organizations over the years.
Lesson 1: Understand Customer Needs, Not Just Wants
When building platforms or enterprise systems, we often fail to pay enough attention to customer needs, taking their stated requirements at face value. Consider the famous (though possibly apocryphal) quote attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” Customers might articulate their wants, but it’s our job to uncover their underlying needs.
Imagine speaking with a farmer in the early 20th century who delivers milk to market by horse-drawn cart. The journey takes a day, causing some milk to spoil. The farmer might ask for a faster horse, but their real need is to transport milk more quickly to prevent spoilage. Understanding this, Ford could have designed a truck to deliver milk in an hour instead of a day.
This principle applies to building API platforms. It’s crucial to engage with customers to comprehend their needs fully. However, there’s an added layer: adopting a platform mindset. We must ensure we’re not just solving the needs of one customer but addressing the needs of all our customers collectively.
For example, if one customer wants strawberry ice cream, another wants banana, and a third desires frozen yogurt, we shouldn’t make each individually by hand. Instead, we should build an ice cream machine—a platform that efficiently produces various flavors to meet diverse needs. This approach scales better and provides economies of scale.
Moreover, we need to focus on implementing needs that are timeless rather than temporary. This leads us to the second lesson.
Lesson 2: Avoid Centralizing Functionality Prone to Change
When considering the return on investment and cost of a platform, we must think long-term. Often, enterprises centralize the implementation of functionalities that are likely to change over time. Initially, centralizing shared capabilities across applications seems efficient and cost-effective. There’s a significant cost saving, and everyone celebrates.
However, fast forward six months, and a customer may need to change how a specific capability works—a change that could mean millions in revenue. Since this functionality is centralized, the customer can’t implement the change independently. They must coordinate with the platform team, who may have their own roadmap and priorities, potentially delaying the change by months.
This scenario is common in large organizations. What starts as a cost-saving solution becomes a bottleneck, causing frustration and regret. To prevent this, we should avoid embedding functionalities into the platform that are likely to change frequently, even if they are widely used today.
If centralizing such functionality is unavoidable, design it to be extensible. Separate the long-term, reusable components from those likely to change. Make the platform extensible through APIs and self-service mechanisms, allowing customers to customize functionality without relying on the platform team. This approach enhances the platform’s longevity and avoids coordination nightmares.
Lesson 3: Invest in Stakeholder Emotion
Building successful API platforms isn’t just a technical endeavor; it involves understanding and nurturing the emotional investment of stakeholders and customers. APIs are backend systems without user interfaces, which can make them abstract and inaccessible to non-technical stakeholders.
To bridge this gap, create user interfaces for your API platforms. For instance, an accounting API platform could offer a UI that allows accountants and CPAs—who may not be software engineers—to interact with the APIs. They can run calculations, verify interest computations, and see debugging information. This interface won’t be deployed to end customers but serves as a tool for stakeholders to engage with the platform meaningfully.
By making interactions easy and tangible, you give key business stakeholders an early opportunity to provide feedback, understand the platform’s capabilities, and become emotionally attached to the project. They become champions of your platform, advocating for its adoption and success within the organization.
Investing in stakeholder emotion is often overlooked but is vital for the long-term success of API platforms.
Conclusion: Building the Right Thing
As we move forward, the era of disjointed, ad-hoc APIs in large companies is ending. The future belongs to well-designed API platforms that deliver holistic business value. To build platforms that last, we must shift our focus from merely building things the right way to ensuring we’re building the right thing.
By deeply understanding customer needs, designing platforms that are extensible and resilient to change, and investing in stakeholder engagement, we can create API platforms that stand the test of time and drive our businesses forward.
