David Mooter is a Senior Analyst at Forrester. This article by David discusses building an API platform business.
Analogy – Building a conference center.
In a typical IT approach,
- CEO – sells a premier customer a conference center.
- CIO – designs for the customer’s immediate needs using the fastest tools to build walls. Now we know the needs of this immediate customer.
- CFO – focuses on the immediate problem, budgets for fixed walls because moveable walls are cheaper, and those fixed walls will meet the customer’s needs.
The event was perfect. It perfectly met the customer’s needs, making it very easy to sell to a second customer. But, the second customer has different needs, and the walls need to be torn down. The CIO focuses on agile, DevOps, and tools to rapidly tear down and rebuild walls.
But smarter competitors who focus on moveable walls with the agility to reconfigure the business more rapidly take the market. Now, this is obviously a ridiculous way to build a conference center. Yet this is how we build software. This is because of wrong mindsets.
Incorrect mindsets
- CEOs who focus on near-term wins.
- CIOs who focus on technology enablers to build solutions. That’s your foundation, but that should not be your primary focus.
- CFOs who focus on narrow ROI measures.
Building software, APIs, and the business the right way.
Speed versus agility
Speed is going fast when we know your destination. Agility is going fast when you don’t know your destination, the ability to change direction rapidly.
That conference center was able to move towards a second customer as fast as possible to tear down walls, rebuild and fashion anybody else right. But that second customer’s needs were not what they expected. Because the first customer was very different, they couldn’t change directions. This is key.
Organizations that could rapidly change directions survived, if not thrived, in the pandemic situation, but those that could not have suffered, and many are no longer with us.
To enable year-over-year growth, organizations must be agile. That implies we need an architecture to support that business agility. APIs are key for that.
Tech silos are not a platform business.
In a standard business model, an organization decides on strategic objectives. They have business capabilities and either refactor APIs or build them from scratch.
That creates an enterprise platform these objectives can plug into to advance themselves. The mindset you have for your APIs reflects what delivers value to your customers, not the application.
So the API that you design should be built to look like business capabilities.
Start with business capabilities and find the right tools to advance those.
Events also enable modular business transformation.
As organizations create a digital business, if digital for you just means REST, then the constraints of REST become the constraints on business possibilities. Do not attempt to fit your business into REST; find the right integration pattern to fit your business scenario. Event-driven architecture seems to have the highest demand as a complement to REST.
Who should lead your API strategy?
Should it be your CIO or some other IT leader that’s delegated?
If you’re getting your feet wet with APIs and need to build IT competency, that may be a good place to start. But it’s definitely not where you want to end. It should be the CEO or someone in the business organization that reports to the CEO, CTO, product management lead, or someone like that. But ideally, your CEO has some involvement in saying we will become a digital business.
Example – Health insurance provider
A health insurance provider could do a maximum of three partner integrations a year. They had a single SOAP schema with 126 operations. Every time you touch it, you break something. So they introduced an API product manager. It is someone who reads reports for the business. Usually, they don’t have an IT background, although sometimes they have a product management background that they apply to technology and help us with this problem. This product manager found that 90% of the market needs can be met by only 10% of those operations. And so based on that, the product manager led a refactor so that the core 90% was one API, and the others were add-ons.
This resulted in 42-party integrations and hundreds of millions of dollars in new revenue the next year.
Open Business: APIs reframe business strategy
Traditional businesses start with the business, then look at the customers. Then they look up the channels to help us access those customers and the partners to access those channels. At this point, you largely have a business design for the most part. And then, you look at how we make this business design efficient. What are the processes? Where can it help automate things?
An open business strategy is an API-led business strategy. It starts by asking, What are we good at, and what are our competencies?
What are the ecosystems that can benefit from those competencies? Relationships connect to ecosystems, which becomes leverage to expand into new markets.
Business design for agility and integration happens at the end of traditional business design and at the beginning of an open business design. IT and business work together to drive business strategy. IT drives moving from an efficiency cost center to a top-line revenue generator.
Nationwide Insurance.
I came from insurance. I was the architect and domain architect for our integration department. A big part of that was APIs. And I was watching the insurance industry to find a public developer portal and for a while, nationwide was the only one I could see. There might be others. But as far as I’m aware, they were the first to market. And now several companies have them pass here too. But they are embedding insurance into Ford and Toyota as products. They embed Medicare into the National Council on Aging’s retirement planning tools. They also automate insurance verification for lenders.
Current innovation model
The current innovation model is siloed and sequential. First, you create a business idea, change the business strategy, design, and create software requirements. Then we hand it over to IT.
New innovation model
The new innovation model is interfused and evolutionary. It infuses tech possibilities into your business ideation. Create a holistic digital business strategy with technology infused into business design and operations. And then you evolve it iteratively into reality. And the key here is for business and tech teams to co-create and continuously improve.
I’ve seen API teams that do not report to IT; they report to a business product team. And some of them say that is the better design.
Funding
You need seed money to underpin an API platform. You need to invest in the API Management governance Centre and enable IT portfolio management. You have to cater to changes and look at their ROI.
Reframe design, build, financing and leadership
Design is modular business design. It has software-based building blocks.
Build is blended business technology teams working hand in hand to design new business possibilities enabled by tech.
Finance – agile finance
Leadership – CEO-driven software competency.
To conclude, the correct mindsets should be
- CEOs who think of long-term ecosystem possibilities.
- CIOs who consider architectural models to deliver flexibility for ongoing disruptive change.
- CFOs, who plan for a stream of portfolio investments in the platform and its architecture.
