Larry Tesler’s famous insight — which subsequently became Tesler’s Law — becomes glaringly obvious with each passing day.
Complexity escalates with each layer of human-to-tech and tech-to-tech interaction, resulting in a networked world where ramifications run both wide and deep.
At additiv, we spent a great deal of time wrestling with this challenge of how to manage complexity so we don’t slow the pace of innovation. And our response (at least in part) has been to become truly API-first because, in line with Tesler’s Law, we don’t just reduce complexity and increase agility, but we also instill into our culture higher levels of precision and alignment, which lets us move faster.
Here’s what implementing an API-first strategy looks like — for us, at least — and why it is a cornerstone to digitally upgrading the finance industry and coping with an accelerating pace of change.
Public APIs, like diamonds, are forever (well, almost)
It’s obvious that we’re moving from a world of vertically-integrated hierarchies to one of looser, horizontal networks — in every sphere of life from communication to finance.
Consequently, being API-first is about building a system whose benefits can be consumed by multiple other systems — including B2C / B2B front-ends, core enterprise systems, other APIs.
When products and services rely on each other like this, you have to make sure what you’re providing is reliable, consistent, and reusable. Just like diamonds, once they are out there, public APIs are (almost) forever. Changing them is an intricate — and delicate — process.
Good ones create long-term customers and strengthen the ecosystem.
Bad ones create long-term support nightmares and a range of issues that permeate the business.
Our strategy makes the public API the backbone of the system. Therefore, we follow established best practices on How to design a Good API and employ the applicable principles to our public RESTful APIs to ensure long term stability as well as agility.
Being API-first is a strategy that ripples throughout the company. That’s why developing a public API that both the business and the products rely on involves long-term thinking. It also requires us to look at how we can build it to serve businesses’ and customers’ needs years from now.
This is not just an engineering challenge but also a massive business challenge.
From platform and architecture to product, pre-sales, and sales, our API-first strategy guides our decision-making. As a result, the process involves extra planning and business analysis, more time spent thinking about the API design, more refinement, a faster feedback loop, and broader risk evaluation.
Another key part of this process entails orchestrating lasting value through systems of networked intelligence. This entails exposing siloed, unstructured data in a more consolidated manner, so B2B solution providers can continue to add value when everything is a service.
To achieve this ambitious feat, it takes successive layers of improvement.
Polished to shine
Any API involves establishing a contract for how it communicates with other programs. To make this contract flexible, future-proof, and reliable, additional planning and collaboration lay the groundwork, followed by strong design. And that’s before anyone writes a line of code.
With this workflow in place, specialists throughout the company pool their know-how and expertise, making the entire organization more connected, more aware of its own strengths (and deficiencies).
This coordinated operation for building value is a learning process itself. There are still many unknowns, so we borrow from the principle of protected variation.
Wealth management is a dynamic, heterogeneous domain with a variety of use cases. To manage the inherent complexity of the sector, we aim to identify the points of predicted variation and create a stable, public RESTful API around them.
Pinpointing instances of predicted variation is difficult in general. In the fast-moving world of digital wealth management, it’s even harder. That’s why creating a stable interface, which is neither too constrictive for implementations, nor too vague for clients, is paramount.
Our approach to solving this challenge is to create fine grained public APIs that serve as fundamental “Lego bricks”.
A strategic game of Lego
In the API-first mindset, we embrace collaboration and our role in the broader ecosystem.
Specifically, at additiv we assemble streams of data, providers, core banking systems, and custodians in a single B2B SaaS cloud platform. Always striving to do our best work, we orchestrate financial services that span traditional and digital channels and meet the challenges current-day wealth managers have.
The building blocks are the same for everyone. It’s how you put the pieces together that makes the difference. Team know-how and experience are the key drives for success here.
Just like a Lego game, an API can benefit an entire vertical or it can fail to be adopted in an impactful manner.
What we did is go a step further than providing a RESTful API.
Attaching the locomotive
Anyone who lacks direction can start using our public APIs to build services on top of it and get them to market really fast. Just like with Lego, additiv is the locomotive you attach to your train to gain traction in the market and be quick about it.
However, APIs alone can sometimes restrict usage for business decision-makers who crave more tangible experiences. That’s why we took it a step further.
To accommodate business leaders’ need for flexibility means inevitably adding complexity to the ecosystem. Just like elaborate Lego sets, it’s not enough to just hand a large set of bricks to the consumer. They need a set of instructions and pictures that enable them to turn and use the offering as an attractive, real-life, off-the-shelf product.
Our goal is to offer flexibility but keep the product nimble and highly usable. But how?
We grappled with this challenge ourselves, so our customers and partners don’t have to. That’s why we built API Cookbooks and Front-end blueprints designed for specific user journeys — all articulated in simple omni-channel products.
Our process involves a disciplined, deliberate development workflow to facilitate a rapid feedback loop for early APIs drafts. This prevents the wrong ‘diamonds’ from being released.
Eating our own dog food
To make sure our customers and partners have the best experience, we routinely eat our own dog food (or wear our own diamond ring, if you will).
Have no doubt, we make mistakes. Consuming our APIs as a habit maintains our focus on fixing and learning from them, ensuring their reliability, stability, and consistency in terms of design and implementation. It also keeps us innovative.
Whenever we decide to update an API or branch off to support new wealth management needs, our fine-tuned process covers everything from risk management to ensuring proper updates, release notes, documentation, and support.
Financial organizations who work with us can add entire blocks of functionality and ship products and services really fast. Whether they’re looking to ensure smooth user experiences or add eye-catching charts that help consumers visualize data and insights, we strive to build APIs that can address these specific needs.
Unlocking the innovation straitjacket
Bit by bit, closed systems are falling out of favor not just with consumers but also with business decision-makers. Their obvious limitations are amplified each time customers voice out their compelling needs.
And here’s the thing:
You don’t have to force a monolith to behave in ways for which it wasn’t built.
You don’t have to stop the world to build another system from the ground up.
There’s another way, a much more cost-effective and much faster route to innovation.
Partnering up with an API-first business, such as additiv, frees your organization to grow and adapt. You can respond to new consumer demands by launching new channels, new customer propositions or new business models — all without writing a single line of code or replacing a single existing application. Our platform is additiv by name, additive by nature.
The payoffs can be exponential. We’ve seen it happen.