How many have you heard that you need APIs for digital transformation? How about that this also requires cultural transformation? Let me guess: too many! Businesses are struggling when it comes to knowing what to look for, what actions to take, and how to make digital transformation work.

Digital transformation is more than just technology. Digital transformation prepares organizations to leverage the benefits of new technology to create business value. It applies to APIs, as well as any other technologies.

From this article series, you’ll learn the common road blockers and catalysts that make or break an organization’s digital transformation journey. It helped me to assess an organization’s situation and conclude what actions to take.

In part one, I’ll discuss how we digitalized the traditional assisted transport service of an NGO, as well as the reasons why we did it. It demonstrates the transitional change from digitization to digitalization.

Then, I’ll show how we evolved it into an API product that enables new digital business. It demonstrates the transformative change from digitalization to digital transformation. This transformational change is the most challenging as it requires businesses to evolve.

In part two, I’ll present the blockers and catalysts that make or break digital transformation. It’s based on our first-hand experience at the NGO and at many other organizations across industries (e.g. telecommunications, financial services, manufacturing, and healthcare).

What’s at stake

Our NGO is a non-profit organization. Its purpose is to protect the lives, health, and dignity of people in need. It’s organized as one agency and multiple regional associations. Associations provide services in one region while the agency provides them with infrastructure and common services (e.g., assisted transport application and fundraising service).

But why are they trying to become digital? I’ll present the two primary reasons why this NGO started their digital transformation journey.

Customer base is not sustainable

Our NGO has three main customer segments who donate or provide volunteering: seniors, young people, and adults.

Many seniors pass on their fortune to this NGO. They grew up in the post-war period and saw firsthand the significant impact it had on their community. As a result, they have a high emotional bond with this NGO and want to support it with their last will.

Young people have different priorities. According to a survey conducted by the World Economic Forum (WEF), young people’s priority is climate change. Unlike seniors, adults don’t have the same emotional bond with this NGO. Parents care about the future of their kids and therefore care about other causes (e.g., climate change and the future of humanity).

In summary, our NGO is facing a shrinking, unsustainable customer base. Furthermore, volunteers want to make an impact on people’s lives. However, volunteering often involves cumbersome paperwork, especially reporting. Digitalization shows great promise for increasing volunteering experience.

NGOs never get disrupted!?

Well, welcome to reality! Every industry gets disrupted, NGOs are no exception. For instance, Uber started offering two products that compete with the assisted transport service: Uber WAV and Uber Health.

With Uber WAV, people tied to wheelchairs can order a ride in a wheelchair-accessible vehicle (WAV) with all the comfort of the Uber experience. The drivers are certified to assist people with disabilities.

With Uber Health, Uber helps healthcare organizations getting fewer no-shows and more on-time appointments, which reduces idle times for specialists. With this goal, they provide a specialized product to order and manage rides for clients.

In summary, the NGO is facing new competitors disrupting the market. Also, new NGOs compete for donations. Our NGO needed to rethink how it generates funds to help people, what problems to solve, and how.

Traditional assisted transport service

Regional associations provide assisted transport services to people with disabilities or unable to use public transportation. The agency provides associations an assisted transport application. With this application, associations manage transports, coordinate volunteers, and charge customers.

Revenue model of traditional assisted transport service

The revenue model consists of four main parties: end-customer, volunteer, association, and agency. The following image illustrates the revenue model:

In the following, I’ll explain the value and revenue stream for each party.

• End-customer: The customer orders a ride to his medical appointment from the association. The customer gets a ride. In return, he pays a fee to the association.
• Association: The association coordinates volunteers and assigns volunteers to driving jobs. It charges the customer a fee for the ride. From this fee, it reimburses the volunteer’s expenses and pays the agency for using the assisted transport application.
• Volunteer: The volunteer drives the customer to the destination and back again. He fills the report form, sends it to the association, and waits for the reimbursement of his expenses (e.g. gas and parking tickets).
• Agency: The agency provides the assisted transport application to the association. In return, it receives a usage fee from the association.

Assisted transport service as API solution

We run a design sprint. The design sprint is a human-centric approach to identifying problems and validate feasible solutions in just one week. We invited people from associations and experienced volunteers.

As a result, we identified one big pain point: reporting. After every ride, volunteers file a report form to provide the driving distance and the duration. They have to fill the yellow report form when the end-customer pays cash or a green one when the end-customer pays on the account. At the end of the month, they have to send report piles to the association to get compensated for expenses.

The association collects all report forms and enters its details into the assisted transport application to start the charging process.

API solution: reporting

We created a reporting mobile app that provides volunteers their driving assignments and automatizes reporting of driving distance and duration. To this goal, we designed the Reporting API that feeds the reporting mobile app with driving assignments and receives report information. The reporting mobile app replaces report forms (digitization) and automates the reporting process (digitalization).

Here’s a simplified specification of the Reporting API:

# REPORTING API## Gets all transports.
GET /transports
[ ... ]## Reports details for a specific transport.
POST /reports
{
 'transportId': '123',
 'distance': '4.5km',
 'duration': '2.2h'
}

Business value of an API solution

Besides digitizing the reports, this solution digitalizes and automates the reporting process to save costs and increase timely charging. The reporting process remains more efficient, faster, real-time, and automated. No structural change, no organizational change required.

Revenue model of reporting mobile app-based on API solution

The revenue model consists of four main parties: end-customer, volunteer, association, and agency. The most significant change is that the agency provides value to the volunteer and the association through the reporting mobile app and digitalized reporting process.

• End-Customer: The customer orders a ride to his medical appointment from the association. The customer gets a ride. In return, he pays a fee to the association.
• Association: The association coordinates volunteers and assigns volunteers to driving jobs. It charges the customer a fee for the ride. From this fee, it reimburses the volunteer’s expenses and pays the agency for using the assisted transport application.
• Volunteer: The volunteer drives the customer to the destination and back again. He uses the reporting mobile app, which automatically sends reports to the assisted transport application. Afterward, he receives reimbursement for his expenses.
• Agency: The agency provides the assisted transport application and digitalized reporting process. Further, it gives volunteers the reporting mobile app, which automatizes the reporting process. In return, it receives a usage fee from the association.

Currently, twelve associations are using the agency’s assisted transport application. The pricing of the Reporting app is $600 per month and $6 per active driver and month. Let’s assume they all have 1,600 active drivers in total. Based on the current pricing model, it creates approximately a revenue of $200k per year for the agency to operate and extend it with more features.

Assisted transport service as API product

According to Uber, over 3.6 million Americans miss their medical appointments due to a lack of reliable transportation. If we scale it down to the population of Switzerland, that’s 85K people. A doctor in Zurich, Switzerland, charges $135 per 15min. Making the math, that’s $11.5M loss for healthcare organizations in Switzerland.

What if we can offer healthcare organizations reliable transportation for their clients. Healthcare organizations will have fewer no-shows and more on-time appointments to reduce idle time of specialists. What if we can provide an interface to this value proposition?

API product: Transport Care

We designed the API product Transport Care. It allows healthcare organizations to order and manage assisted transports for their clients. The Transports API is similar to the Reporting API. Further, the reporting mobile app uses the Transports API instead of the Reporting API with minor modifications. The API product, Transport Care, empowers health organizations to order rides for their clients to get fewer no-shows. That’s a digital business (digital transformation).

Here’s a simplified specification of the Transports API:

# TRANSPORTS API## Gets all transports.
GET /transports
[ ... ]## Creates a new driving assignment.
POST /transports
{ ... }## Updates the driving assignment with info that are reporting relevant.
PUT /transports/123
{
 'distance': '4.5km'
 'duration': '2.2h'
}

Business value of API product

This API product enables a new digital business model. Healthcare organizations pay for the API product because they lose less money from no-shows. It may even generate enough revenue such that associations would get the assisted transport application and reporting mobile app for free. Plus, all the prior benefits of digitalization: automated, more efficient, and faster.

Revenue model of Transport Care

The revenue model consists of five parties: healthcare organization, end-customer, volunteer, association, and agency. The following image illustrates the revenue model. The most significant change is that the healthcare organization pays the NGO for the assisted transport service. That’s an entirely new revenue stream and complements the income from fundraising and donations.

• Healthcare organization: The healthcare organization uses Transport Care APIs to order rides. Its motivation is to lower no-shows and increase on-time appointments. It pays the agency a fee for ordering rides via an API.
• End-customer: The customer gets a ride to his medical appointment.
• Association: The association coordinates volunteers and assigns volunteers to driving jobs. It receives compensation from the agency. From this compensation, it reimburses the volunteer’s expenses.
• Volunteer: The volunteer drives the customer to the destination and back again. He uses the reporting mobile app, which automatically sends reports to the assisted transport application. Afterward, he receives reimbursement for those expenses (e.g., gas and parking tickets).
• Agency: The agency provides the API to healthcare organizations. It provides the assisted transport application and digitalized reporting process to the association. It offers volunteers the reporting mobile, which automatizes the reporting process.

Healthcare organizations in Switzerland may save approx. $11.5M per year. If we charge friction of it, e.g. $1M per year, which is five times more than the income from the API solution with approx. $0.2M per year. That’s the significant difference between the two breeds of API: API products and API solutions. API solutions digitalize a business process while API products create digital business opportunities.

API Product Never Made It

This API product remains on-hold even though it promises business value. The reasons for this were that it lacked IT governance, accountability, and a digital and entrepreneurial mindset to manage and grow into a digital product. Therefore, this an API that was just another project. These reasons represent some of the blockers and catalysts of digital transformation that I discuss in more detail in part two.

The good news: this API product demonstrated the value of what could be. That’s one of the reasons why today, the NGO is working on IT governance and evangelizing a digital mindset.

Social Context Makes or Breaks Digital Transformation

New technologies provide new capabilities and promise some benefits that create business value. At an NGO, we used API technology to create a new digital business model based on the API product Transport Care.

However, we haven’t succeeded yet due to a lack of consideration for one aspect: the social context or organization. The social context blocks or boosts the impact of technological capabilities on creating business value.

The affordances model covers these three aspects and puts them into relation: technological capabilities, business value, and social context. I was inspired by my colleague, Marc Jost who identified the social context as a critical differentiator for when a platform-as-a-service product creates value.

Digital transformation is not another software project. It’s more than technology. Digital transformation is about making an organization ready to leverage the benefits promised by technological capabilities.

Blockers and Catalysts of Digital Transformation

The social context consists of two types that make or break digital transformation: blockers and catalysts. Use them to assess your organization, identify your blockers and catalysts, and what actions to take.

Blockers of digital transformation

Blockers are elements that lower or even stop how technological capabilities affect business value. Eliminating blockers must be your priority.

• Doing APIs as projects: Many times, people build APIs as part of a project, however, projects are about execution. An API-as-a-project is good for digitalization, increasing efficiency, and saving money. However, projects lack adaptability in that learnings are not taken away, setting and adapting a vision, and creating and maintaining a roadmap. In other words, API-as-a-project is not good enough to create a digital business or build a digital ecosystem. Do API-as-a-product instead of API-as-a-project.
• No API strategy and no corporate strategy alignment: No strategy means no focus and no KPIs. If you don’t set a course and measure the progress, you don’t know if, how, and when to adapt the course. Further, if the API product doesn’t support the corporate strategy, then it won’t gain support from management. Develop your API strategy and align it with your IT and corporate strategy. Identify the opportunities and benefits of API inside and outside your organization.
• No accountability and no responsibility: Someone has to make decisions and being answerable for the actions if the decision-maker doesn’t understand the product they will not make a decision. Make sure that the team who ideates, designs, and builds the API is accountable and responsible. It needs to be someone who cares and follows a vision. Get an API product manager who is accountable and a team of engineers who are responsible.
• Insufficient IT governance: Do you know how to bring an API product to production and who maintains it? There are vital roles and responsibilities, e.g., API product manager, API designer, engineers for development, security, and operations, etc. Make sure to define roles and responsibilities clearly. Distribute the roles to the right people; only someone who knows the customer’s needs and pains should design the API.

Catalysts for digital transformation

Catalysts boost the effect of technological capabilities on the business value. Establishing catalysts is your second priority to gain speed and maximum impact.

• Hire API product managers: The API product manager defines the why and what of that API product. It is this person’s job to research the market and identify opportunities, validate customer needs and pains, and get the digital product to full production. They understand how to navigate within an organization to make the next step happen based on new or existing corporate assets as well as stakeholder management. They connect customers, business, and technology.
• BizDevOps: Form API product teams that consist of business, development, and operations (i.e., API product manager, and DevOps engineers). This group communicates and collaborates on effectiveness, speed, and innovative outcomes.
• Get out of the building: Building products without talking with and understanding customers are destined to fail. Start talking to customers to understand their pains and jobs-to-get-done. Then, you’ll find problems worth solving.
• Do analytics-first: Calculating the number of API calls is useless, instead identify and monitor relevant KPIs. Relevant KPIs provide you insights on how to improve API products and organize the API ecosystem. Analytics provide you the data and insights, which support your decision making.
• Limit budgets: Yes, you read correctly! Too much budget creates comfort and allows for maintaining the status quo. When you limit resources, teams become value-driven and start innovating. It supports the meaning of accountability and responsibility. Allow them to participate in the value they create.
• Leverage the organization: Involve account managers and sales to help you getting customer attention. Provide both the materials to advertise API products with prospects successfully. They help to get customer feedback, especially from business partners.

Conclusion

Digital technologies like API promise great business benefits. We’ve seen in this article how to use APIs to digitalize business processes and save costs. Digitalization is not a transformation; it’s a translation from an old approach to a new, digital approach.

Furthermore, I’ve demonstrated how API products enable new digital business models. However, the social context or organization sets the limits on what technological benefits transform into business value.

Digital Transformation is not yet another software project. Digital transformation is also not just about digital products. Digital Transformation is about making an organization ready to leverage the benefits promised by technological capabilities.

Recommendations

Digital technologies, like APIs, promise great business benefits. Digitalization is not a transformation; it’s a translation from an old approach to a new, digital approach.

Furthermore, I’ve demonstrated how API products enable new digital business models. However, the social context or organization sets limits on what technological benefits transform into business value.

Digital transformation is not yet another software project. Digital transformation is also not just about digital products. Digital transformation is about making an organization ready to leverage the benefits promised by technological capabilities.

Eliminate blockers to make technologies effective and create business value. For instance, stop thinking of API-as-a-project, align API products with corporate strategy, and make teams accountable and responsible for creating business value.

Establish catalysts to boost the effect of technological capabilities and benefits on the business value. For instance, hire API product managers, form BizDevOps teams who develop API products, and create a startup mindset among your teams. Then, organizations become genuinely digital and leverage the significant benefits promised by technology.