Financing digital transformation poses a significant problem for many enterprises we work with. It’s not because the C-suite doesn’t support it: the need to become more agile, digital, and data-driven is nearly ubiquitous in executive public pronouncements. But most large organizations look at IT investment in a way that’s ineffective for a successful digital transformation effort.  

A varied combination of  factors affect an organization’s success in the digital ecosystem, and a lack of alignment between IT and business leaders can hamper even the most digitally sophisticated organizations. Empirical research by the Apigee Institute shows clear evidence that a solid digital transformation effort, aligned across business and marketing, whose progress is carefully tied to core enterprise metrics, must be supported by an investment strategy that uses a “real options” portfolio approach.

Let’s explore ways to think about funding digital transformation.

Planning for the Unimaginable

Common IT investment strategies are focused on straight-line net present value (NPV) business case calculations, which emphasize linear solutions and impacts. These methods ignore the value of enabling a range of options and potential future use cases, which an API program, with its reusable, highly consumable digital assets, makes available for the enterprise. In addition, these methods often ignore the value of the new categories of business data generated by such programs, as well as business capabilities that were impossible to imagine before the capabilities came online.

One media company we’re working with was astounded by a project that now makes key sales provisioning available to large distribution partners within two months, when previous estimates predicted two years and many millions of dollars, each.

More importantly, that functionality will now be reused across all of their numerous current partners and sales channels, and is enabling exciting new partnerships that were too costly before. This functionality was an unexpected by-product of their original API effort—it wasn’t even the main focus of the initial project.  

There was no way that the impact of this capability or its implications on new business could have been predicted at the outset, and no way to formally model the outsized impact this functionality will have on the enterprise. Any attempts to do so would have been deemed ludicrous.

Breaking from the Status Quo

So how do you fund an API-driven digital transformation, which by nature emphasizes speed and optionality to unlock new ways of doing business, instead of the business-as-usual single-use, point-to-point integrations that perpetuate status quo thinking? For a world where the latter is the dominant paradigm and you don’t have a clear C-level mandate, here are three suggestions.

1.  Enable your web/e-commerce teams. Many such teams find their responsibilities expanded to include mobile, kiosk, and many other digital initiatives, while being trapped in the traditional web server, do-it-yourself paradigm. These teams are actually quite open to technology, and often harbour weekend hackers who love to explore the new capabilities that are expanding the digital ecosystem at light speed. Tapping this passion by funding new approaches and quickly realizing immediate projects can create first the technical, and then the business proof points that resonate with a strategy team. These capabilities must be nurtured to move out of the lab into production, where real results are created.  

2. Focus on partnerships. Opening and accelerating  your relationships with partners via APIs (read more about partner API initiatives here) is high-impact and relatively easy to model. This business area can prove out an API platform, and in our experience creates clear business value that can support future justifications for other business units. What’s best about these wins is that sales operations groups are typically very tactical and demanding, so when they see the value, these groups will send a message to the rest of the organization that APIs have business value. Further, your enterprise’s core partnerships have the focus of executive attention. Adding value here will elevate the stature of the API program in the C-suite.

3. Work on your CFO/financial organization. Using your successes in e-commerce and partnerships, you can propose a more robust investment using a real options approach that leads to treatment of APIs as products. This path is predicated on what research has proven to work: the adoption of a digital KPI target, coupled with a portfolio of programs whose net result is to achieve the target KPI.  

Building Toward the Big Vision

But what about the visions of ground-breaking business models, ubiquitous connectivity, and enablement of an ever-shifting set of opportunities on big platforms and with unlimited partnership possibilities? Yes, these are still the endpoints to work toward, and fundamentally comprise the strategic reasons to embark on a digital transformation. If your enterprise has the C-Level leadership (in the form of a CDO or CDO-like figure), supported by a well-funded, sophisticated investment approach, by all means, build that new world now.

However, should that vision be shared only within your business unit, a forward-thinking IT group, or a dedicated innovation team, the most important thing to do is to build your team’s capability—and your program’s credibility—while delivering value along the way. The approach we suggest here has been proven in many of the organizations we work with; once your organization begins working faster and at lower costs by orders of magnitude, you’ll have created enough leverage to change the way your organization invests in its API program.

I previously talked about Eventarc for choreographed (event-driven) Cloud Run services and introduced Workflows for orchestrated services.

Eventarc and Workflows are very useful in strictly choreographed or orchestrated architectures. However, you sometimes need a hybrid architecture that combines choreography and orchestration. 

For example, imagine a use case where a message to a Pub/Sub topic triggers an automated infrastructure workflow or where a file upload to a Cloud Storage bucket triggers an image processing workflow. In these use cases, the trigger is an event but the actual work is done as an orchestrated workflow.

How do you implement these hybrid architectures in Google Cloud? The answer lies in Eventarc and Workflows integration. 

Eventarc triggers

To recap, an Eventarc trigger enables you to read events from Google Cloud sources via Audit Logs and custom sources via Pub/Sub and direct them to Cloud Run services:

One limitation of Eventarc is that it currently only supports Cloud Run as targets. This will change in the future with more supported event targets. It’d be nice to have a future Eventarc trigger to route events from different sources to Workflows directly. 

In absence of such a Workflows enabled trigger today, you need to do a little bit of work to connect Eventarc to Workflows. Specifically, you need to use a Cloud Run service as a proxy in the middle to execute the workflow. 

Let’s take a look at a couple of concrete examples.

Eventarc Pub/Sub + Workflows integration

In the first example, imagine you want a Pub/Sub message to trigger a workflow. 

Define and deploy a workflow

First, define a workflow that you want to execute. Here’s a sample workflows.yaml that simply decodes and logs the Pub/Sub message body:

  main:
  params: [args]
  steps:
    - init:
        assign:
          - headers: ${args.headers}
          - body: ${args.body}
...
    - pubSubMessageStep:
        call: sys.log
        args:
            text: ${"Decoded Pub/Sub message data is " + text.decode(base64.decode(args.body.message.data))}
            severity: INFO
Deploy the workflow with a single command:
gcloud workflows deploy ${WORKFLOW_NAME} --source=workflow.yaml --location=${REGION}

Deploy a Cloud Run service to execute the workflow

Next, you need a Cloud Run service to execute this workflow. Workflows has an execution API and client libraries that you can use for your favorite language. Here’s an example of the execution code from a Node app.js file. It simply passes the received HTTP request headers and body to the workflow and executes it:

  const execResponse = await client.createExecution({
      parent: client.workflowPath(GOOGLE_CLOUD_PROJECT, WORKFLOW_REGION, WORKFLOW_NAME),
      execution: {
        argument: JSON.stringify({headers: req.headers, body: req.body})
      }
    });

Deploy the Cloud Run service with the Workflows name and region passed as environment variables:

  gcloud run deploy ${SERVICE_NAME} \
  --image gcr.io/${PROJECT_ID}/${SERVICE_NAME} \
  --region=${REGION} \
  --allow-unauthenticated \
  --update-env-vars GOOGLE_CLOUD_PROJECT=${PROJECT_ID},WORKFLOW_REGION=${REGION},WORKFLOW_NAME=${WORKFLOW_NAME}

Connect a Pub/Sub topic to the Cloud Run service

With Cloud Run and Workflows connected, the next step is to connect a Pub/Sub topic to the Cloud Run service by creating an Eventarc Pub/Sub trigger:

  gcloud eventarc triggers create ${SERVICE_NAME} \
  --destination-run-service=${SERVICE_NAME} \
  --destination-run-region=${REGION} \
  --location=${REGION} \
  --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"

This creates a Pub/Sub topic under the covers that you can access with:

  export TOPIC_ID=$(basename $(gcloud eventarc triggers describe ${SERVICE_NAME} --format='value(transport.pubsub.topic)'))

Trigger the workflow

Now that all the wiring is done, you can trigger the workflow by simply sending a Pub/Sub message to the topic created by Eventarc:

gcloud pubsub topics publish ${TOPIC_ID} --message="Hello there"

In a few seconds, you should see the message in Workflows logs, confirming that the Pub/Sub message triggered the execution of the workflow:

Eventarc Audit Log-Storage + Workflows integration

In the second example, imagine you want a file creation event in a Cloud Storage bucket to trigger a workflow. The steps are similar to the Pub/Sub example with a few differences.

Define and deploy a workflow

As an example, you can use this workflow.yaml that logs the bucket and file names:

  main:
  params: [args]
  steps:
...
    - log:
        call: sys.log
        args:
            text: ${"Workflows received event from bucket " + bucket + " for file " + file}
            severity: INFO

Deploy a Cloud Run service to execute the workflow

In the Cloud Run service, you read the CloudEvent from Eventarc and extract the bucket and file name in app.js using the CloudEvent SDK and the Google Event library:

  const cloudEvent = HTTP.toEvent({ headers: req.headers, body: req.body });
  //"protoPayload" : {"resourceName":"projects/_/buckets/events-atamel-images-input/objects/atamel.jpg}";
  const logEntryData = toLogEntryData(cloudEvent.data);
  const tokens = logEntryData.protoPayload.resourceName.split('/');
  const bucket = tokens[3]

Executing the workflow is similar to the Pub/Sub example, except you don’t pass in the whole HTTP request but rather just the bucket and file name to the workflow:

  const execResponse = await client.createExecution({
      parent: client.workflowPath(GOOGLE_CLOUD_PROJECT, WORKFLOW_REGION, WORKFLOW_NAME),
      execution: {
        argument: JSON.stringify({bucket: bucket, file: file})
      }
    });

Connect Cloud Storage events to the Cloud Run service

To connect Cloud Storage events to the Cloud Run service, create an Eventarc Audit Logs trigger with the service and method names for Cloud Storage:

  gcloud eventarc triggers create ${SERVICE_NAME} \
  --destination-run-service=${SERVICE_NAME} \
  --destination-run-region=${REGION} \
  --location=${REGION} \
  --event-filters="type=google.cloud.audit.log.v1.written" \
  --event-filters="serviceName=storage.googleapis.com" \
  --event-filters="methodName=storage.objects.create" \
  --service-account=${PROJECT_NUMBER}-compute@developer.gserviceaccount.com

Trigger the workflow

Finally, you can trigger the workflow by creating and uploading a file to the bucket:

  echo "Hello World" > random.txt
gsutil cp random.txt gs://${BUCKET}/random.txt

In a few seconds, you should see the workflow log the bucket and object name.

Conclusion

In this blog post, I showed you how to trigger a workflow with two different event types from Eventarc. It’s certainly possible to do the opposite, namely, trigger a Cloud Run service via Eventarc with a Pub/Sub message (see connector_publish_pubsub.workflows.yaml) from Workflows or a file upload to a bucket from Workflows. 
All the code mentioned in this blog post is in eventarc-workflows-integration. Feel free to reach out to me on Twitter @meteatamel for any questions or feedback.

About Bank BRI

Bank Rakyat Indonesia is one of the largest banks in Indonesia and is committed to increasing financial inclusions among un-banked Indonesians. Bank BRI specializes in using modern digital banking to facilitate microfinance lending across its network of over 10,000 branches and thousands of branchless agents.

Google Cloud Results

• Contributes $50M in revenue through the Apigee monetization feature
• Wins recognition for best digital bank in Indonesia from The Asian Banker in 2019
• Achieves ISO 27001 information security for open APIs, earning distinction as the only bank in ASEAN to receive certification to date
• Reduces partner onboarding from 6 months to under 1 hour with Apigee developer portal

Bank Rakyat Indonesia is making waves in Asia with its award-winning digital strategy. As a government-owned bank, Bank BRI is dedicated to changing the lives of its customers through accelerating financial inclusion across Indonesia. With an aggressive target of 84 percent of Indonesians participating in the banking system by 2022, Bank BRI is leapfrogging fintech competition thanks to its innovative digital strategy that has APIs at its core. By the end of 2019, Bank BRI expects to have reached a 70 percent financial inclusion rate among the country’s population, in part due to the adoption of the Cloud Apigee API Management Platform as the bank’s digital nucleus.

Transforming a legacy into a digital future

In the banking business, trust is essential, not only between the bank and its customers, but also between the bank and its partners. Recognizing that gaining and maintaining this trust would be key to customer and partner adoption of the new Bank BRI products and services, the bank decided to pursue ISO 27001 certification in 2018, becoming the first bank in ASEAN (the Association of Southeast Asian Nations) to become certified as information security compliant. Now the international community of partners and customers who use the bank’s APIs have yet another reason to place their trust Bank BRI.

“Apigee has become the central nervous system for all communications between the digital core banking, the microservices, the frontend, and the apps. Apigee has become our sun. Everything rotates around Apigee.”—Kaspar Situmorang, Executive Vice President, Bank Rakyat Indonesia

Kaspar Situmorang, Executive Vice President of Bank BRI, had the original vision for how the bank could transform itself into a fintech with digital technology and APIs. His team got started by implementing a web-native frontend over a new technology stack with Apigee as a second layer. This was a big change from the legacy technologies that existed when Situmorang joined the bank in 2017. Previously all of the bank’s products had their own public APIs, which were very difficult to manage, secure, and monetize.

Since deploying Apigee, it’s become much easier to manage the entire API lifecycle. Situmorang’s digital bank team of 15 uses the Apigee monetization and developer portal features while managing and securing APIs and conducting big data integrations. Apigee has become Bank BRI’s center of communications, handling all transactions between the bank and third parties.

Whereas previously it could take up to six months to onboard a new partner using host-to-host and VPN technology, now it takes less than an hour for partners to self-onboard using the Bank BRI Apigee developer portal. On the portal, partners can register, browse APIs, test in the sandbox, and go into production — all in less than an hour.

“Apigee has become the central nervous system for all communications between the digital core banking, the microservices, the frontend, and the apps. Apigee has become our sun. Everything rotates around Apigee,” says Situmorang.

Increasing financial inclusions

With more than 10,000 offices across Indonesia, Bank BRI has the largest network of any bank in ASEAN. The bank is also the biggest microfinance lender in the region. Though already present in even the most far-flung corners of Indonesia, Bank BRI is still working on increasing financial inclusion among un-banked Indonesians. With 56 million people that haven’t accessed banking services, Indonesia is in the bottom four countries for financial literacy in the world, along with Bangladesh, India, and China. It’s estimated that there is up to $8.3 billion in currency being held outside the banking system.

In order to reach this mostly rural, subset of the population, the bank launched Agent BRILink, a nationwide network of branchless agents. These agents can open new accounts, take deposits, pay out withdrawals, and process and disburse loans in under two minutes with the Pinang microfinance mobile app. To date, over 30,000 customers have received loans through Pinang. Handling its own risk-scoring and automatic payroll deductions for payments has translated into less risky and more profitable loans for Bank BRI.

“Customers download the app and scan their ID, capturing their credit score in just a few seconds. The digital offer letter says how much they’re approved for. They can then accept it, go to the approval screen, and do facial recognition. The money is disbursed immediately. GCP has transformed us into a fintech.”—Kaspar Situmorang, Executive Vice President, Bank Rakyat Indonesia

BRILink agents are bank customers who have been scored highly for reliability by the bank’s big data analyses and who maintain a minimum balance of around $800. Combining this data with the Google Maps API, Bank BRI is able to score all 75.5 million of its customers and identify which of them should be recruited as agents for underbanked areas. Since 2018, the bank has been able to appoint more than 200,000 branchless agents using the Agent BRILink app, eliminating the need for logistically challenging face-to-face meetings. This has resulted in an increase in loan volume from branchless business from $15 billion in 2017 to $26 billion in 2018.

To enable branchless agents to sign up new customers and provide banking services, all they need is a mobile phone and internet service. With many parts of rural Indonesia not covered by commercial 3G, Bank BRI has overcome this hurdle by operating its own satellite. With the connectivity the satellite guarantees, branchless agents can help customers obtain microfinancing and open new shops and businesses in all parts of the country. The satellite also provides internet service across the APAC region wherever the bank operates, from Sri Lanka to New Zealand. While it might seem unusual for a bank to operate a satellite, it’s reflective of Bank BRI’s commitment to reaching its financial inclusion targets and meeting its customers wherever they are.

“Pinang was created to win against fintechs trying to compete against us on speed, cost, and security,” says Situmorang. “The truth is that Indonesian regulators closed about 650 fintechs, mainly in the peer-to-peer lending space, because they were unsafe, too expensive, and very slow.”

Using APIs to create and monetize new products

Another way that Bank BRI is leveraging Google Cloud Platform solutions is through an innovative use of the Cloud Vision API, which enables the bank to integrate with the Indonesian government ID database. Identities of new customers — whether they’re coming in via a branch, a BRI Link Agent, or a mobile app — are automatically verified in seconds through facial recognition. With instant credit scoring and identity fraud concerns essentially eliminated, the bank can make more confident lending decisions.

“Monetization is very important to us. It enables us to define our pricing based on API calls and bill automatically based on usage. We’ve already recognized $50 million through the Apigee monetization feature.”—Kaspar Situmorang, Executive Vice President, Bank Rakyat Indonesia

“Customers download the app and scan their ID, capturing their credit score in just a few seconds,” explains Situmorang “The digital offer letter says how much they’re approved for. They can then accept it, go to the approval screen, and do facial recognition. The money is disbursed immediately. GCP has transformed us into a fintech.”

Bank BRI sees a bright digital future, in part thanks to the API product marketplace it’s creating to serve fintechs. With its digital technologies and massive customer base, the bank is sitting on a treasure trove of big data. Bank BRI already packages this data through more than 50 monetized open APIs for more than 70 ecosystem partners wanting to do credit scoring, business assessments, and risk management. Fintechs, insurance companies, and financial institutions don’t have the talent or the financial resources to do quality credit scoring and fraud detection on their own, so they are turning to Bank BRI.

“Monetization is very important to us. It enables us to define our pricing based on API calls and bill automatically based on usage. We’ve already recognized $50 million through the Apigee monetization feature,” says Situmorang.

Bank BRI is meeting and surpassing the goals it has set for itself for digitalization, increasing financial inclusion, and creating new revenue streams with APIs.

Founded in 2015, Rapido operates a mobile app-based two-wheeler taxi service across more than 40 cities in India. More than 100,000 drivers provide Rapido two-wheeler taxi services, while more than 400,000 current or prospective drivers have downloaded the company’s app. Consumers have downloaded the app more than 5 million times, and the business receives about 5 million orders per month for taxi services.

“If a consumer wants to travel from point A to point B, they simply open up the app on their smartphone, select pickup and dropoff locations, and tap ‘request,'” explains Rishikesh SR, Co-Founder, Rapido. “We can track that request to the nearest available two-wheeler taxi and allocate the job to the right driver.”

Google a compelling opportunity

The business started operations on a cloud service. However, Google presented a compelling opportunity to Rapido to improve its location-based intelligence through a wide range of cloud-based map APIs, infrastructure, and mobile app development services. “Google Maps Platform was particularly interesting to our business and we saw enormous potential to use it to improve our service and gain a competitive edge,” says Rishikesh.

Rapido elected to use Geocoding API to enable its app to convert addresses to geographic coordinates, and the reverse, allowing consumers to identify point A and point B on their journey. The company also uses Directions API to identify the fastest route between pickup and dropoff locations, which enables Rapido to provide users with approximate prices for trips. Distance Matrix API is used to calculate the travel times and distances between locations, and Maps SDKs for Android and iOS to add interactive maps to the app.

Google Cloud Results

• Enables the business to optimize use of Maps Platform APIs
• Takes 5 million orders per month
• Establishes a robust platform for expansion

“Google Maps Platform is particularly useful for us as it identifies optimum routes for two-wheel services,” says Rishikesh. “This saves us time and money, while helping us deliver a better consumer experience.”

In addition, Rapido uses the Snap to Roads service to deliver best-fit geometry for sets of GPS coordinates within the Roads API, which identifies and provides metadata about the roads on which drivers travel. “Snap to Roads in Roads API allows us to optimize the path drivers take and helps ensure the fare charged is accurate,” says Rishikesh.

Improving user experiences

As Rapido matured, Rishikesh considered how to improve the user experience of the app while reducing the business’ costs. In 2017, Rapido asked Google Cloud Premier Partner and Google Maps Platform Partner Searce to help meet these objectives. Searce provided the technical and business advice that prompted Rapido to take advantage of the unlimited API calls, 24-hours-a-day, 7-days-a-week support, and strict SLAs available through the Google Maps APIs Premium Plan for Asset Tracking.

Searce also helped Rapido optimize its API calls and integrate directions and distance calls with the Roads API to smooth out variations in GPS readings received from the handsets of two-wheeler taxi owners. Finally, Searce helped Rapido deploy the Firebase mobile and web development platform to automate the mode configuration of the API keys, rather than maintain a time-consuming manual process. This move also minimized the likelihood of any issues arising if Rapido decided to start multiple projects or add more licenses, or combine Google Maps APIs Premium Plan for Asset Tracking with an external license.

Technical skill and experience

Searce finalized its initial engagement with Rapido last year and provides ongoing support and advice. “Searce’s technical skill with Google Maps Platform put us on the right path to provide a better, more relevant user experience,” says Rishikesh.

Rapido also now uses a range of Firebase services for app development, testing, and modification. The business employs Google Analytics for Firebase to measure customer use of and engagement with its app, enabling the business to make informed decisions about where to direct its resources. In addition, the business is using the Firebase Test Lab app-testing infrastructure to test its Android and iOS apps across a range of device configurations, view the outcomes, and make changes as needed.

Rapido uses Firebase Remote Config to change the app’s behavior and appearance on the fly in response to the results of A/B testing across sections of its user base. Furthermore, Rapido uses Firebase Crashlytics to provide app crash reports to its Firebase console.

Firebase Dynamic Links allows Rapido to direct users to linked content in the iOS or Android version of the app, while Firebase Cloud Messaging enables Rapido to deliver notifications and other messages to users. Cloud Firestore provides a NoSQL cloud database to store and sync data for the Rapido app.

Rapido has also started using the Firebase Realtime Database to store and sync information about customers that can be used to provide a more informed, personalized service.

At the same time, Rapido uses a BigQuery data warehouse to process about 10TB of data every month for analysis and reporting that supports decision-making across the business. The organization is also using application containerization through Google Kubernetes Engine on Google Cloud Platform.

“We are moving our apps from dedicated virtual machines to a scalable containerized environment that consumes fewer resources,” says Rishikesh. “It makes sense to work with Google – the business that designed the Kubernetes container-orchestration system.”

Rapido has also started using the Cloud Functions event-driven serverless compute platform to process smaller jobs. “This is ideal for small use cases in particular as we do not have to spin up virtual machine instances,” says Rishikesh.

Finally, Rapido is using image classification through the Vision AI service to analyze riders’ documentation, such as driving licenses. This allows the business to verify details such as names, addresses, and expiry dates with more than 90 percent accuracy – a high rate in a country where each state has its own license template.

Expanding rapidly to new cities

The Rapido app enables drivers to pick up customers quickly – in most cases, between 2 and 5 minutes.

Overall, the high-quality experience for consumers and drivers delivered by Google Maps Platform, combined with Firebase, has helped power Rapido to robust growth. The business now takes more than 5 million orders per month.

“With Google, we are delivering the right experience to users through Google Maps Platform, Firebase, and Google Cloud Platform services,” concludes Rishikesh. “We have realized our vision faster and now have a robust platform to grow in the future.”

Chances are, when you think of Experian you think of a traditional credit bureau that provides credit reports. But Experian has transformed into a true technology and software provider. We gather, analyze, and process data in ways that other companies just can’t. Businesses use this data to make smarter decisions about credit and lending, as well as to prevent identity fraud and crime. We’re also able to use this data to help individuals take financial control of their own lives and access all kinds of financial services with products like Experian Boost.

Transforming data delivery, transforming the enterprise
A big part of our digital transformation has been based on our API program. We approached APIs with a concrete goal in mind. We knew exactly how we wanted to transform the business, and we had a set plan to achieve that. For us, this meant establishing an API center of excellence as a first step. It’s sole purpose was to enable the business units to create their APIs quickly and correctly, then apply them properly. We then went out to the business units one by one so that we could train them to build their APIs in a customer-friendly way. We taught them the entire API process of building, giving access to developers internally and externally.

This approach is fundamentally different from previous ones. As far back as the 1990s, our customers connected to us via software applications installed on their systems. As technologies evolved, our services to customers evolved, and we began supporting XML-based transactions and custom integrations with our partners. Some of these integrations actually included VPNs rather than going through HTTP connections. We did custom database schemas, one-off processes, and all kinds of custom development. 

This meant that we had a team just for our IT system processes. This team kept growing as Experian continued to acquire new companies. Each acquisition brought a new way of doing integrations and business. We had a real challenge in standardizing development practices, which led to a lot of isolated environments inside the company. We had disparate data repositories and non-standard client conductivity, which hampered innovation.

Responding to customer demand for APIs
When we first started, we had some concrete goals. We wanted to grow our ecosystem, develop a massive reach for transaction and content distribution, power a new business model, and drive innovation. Basically, we wanted to use APIs to transform our business into a platform, and we wanted to build an ecosystem that leveraged this API platform to develop new solutions. 

Our leadership also understood the importance of delivering information to our customers in the way they wanted to consume it. Our customers had told us that they didn’t want software, they just wanted access to the data—and APIs are the easiest, most secure way to grant that access. 

The Apigee API management platform as an enterprise solution
We knew we needed an API management platform to enable this step forward. In addition to the documentation and discoverability, we also wanted a place to create APIs fast, and where we could get visibility into usage and other metrics. The Apigee API management platform from Google Cloud offered all of this, and more. From the robust feature set to advanced security to the developer portal to analytics – Apigee provides us everything we need to run an enterprise-class API program.

Now that we have our API program up and running, integrations no longer take months. In some cases, it’s just a matter of minutes or seconds. Customers can simply look at our documentation on how to invoke APIs and begin consuming data in seconds. We started with this new model in our three largest markets: North America, the United Kingdom and Brazil. Later, we rolled it out to Singapore and Australia, while deploying an on-premises platform for some of our North American business units that needed to provide their APIs internally only. Next, we went to EMEA. At this point, we’ve deployed Apigee company-wide, giving us a flexible deployment model that maintains a centralized platform and processes.

We continue to evangelize the program today, and we recently conducted a workshop with the Apigee team to train our EMEA business unit and get them onboarded to the platform. They were able to start developing API proxies right away, and they’re set to go into production with as many as nine of them. We also went live with three developer portals, which we call API hubs, in North America, the United Kingdom, and Brazil. 

As we expand, we don’t want to keep building up different developer portals for each region because then we’re going to have too many. Alternatively, we plan to combine them into a single global developer portal that will allow users to select geographies of interest where they’ll be presented with relevant information.

Experian continues to evolve the types of products and services we offer. Thanks to Apigee, we have the flexibility, security, and technology to keep innovating and providing value to our business and our customers.