It has been seven years since Marc Andreesen’s famous article “Why Software is Eating the World” was published in the Wall Street Journal, and given the slow pace of change in many companies, some executives still may not be taking the threat of being “eaten” seriously enough. 

Software, and platform business models based on software, have the potential to deliver powerful economic forces into virtually any company or industry. Every company has valuable assets—such as data, expertise or access to certain services or user bases—and most of these assets can be delivered via software. Once an asset is expressed as software in a modern way—that is, as an application programming interface (API)—it can be combined with other software to create new applications and digital experiences.

Benefits of this approach, just to name a few, include near-zero marginal cost to scale up APIs for new users or use cases; global reach for both partners using APIs and end users consuming the digital experiences those APIs power; and network effects triggered as more partners use a given company’s digital assets and spread its services into new markets and use cases.

Disruption by software-powered business models

In the last two decades we’ve seen individual companies and entire industries upended by these kinds of software-powered business models. Examples abound: Amazon and the retail industry, Netflix and movie rentals, Uber and ride hailing, Airbnb and hotels, etc. We’ve reached the point that these companies’ names have become verbs synonymous with being “eaten” by software (e.g., “Amazoned” or “Netflixed”).

The most famous examples of digital disruption involve digital natives, of course, but legacy businesses are leveraging software to evolve too. Brazilian retailer Magazine Luiza—a company I’ve worked with through my employer, Google Cloud’s Apigee team—has enjoyed enormous revenue growth and seen its stock soar, for example, as it has built out its digital platform capabilities and transitioned from a primarily brick-and-mortar model to an omnichannel one. The point is, whether a company has been in business five decades, five years or five months, software remains ravenous and is always looking for new companies and industries to “eat.”

Change in the face of serious threats

Facing this threat, how should corporate leadership respond? There are some excellent examples of CEOs who have galvanized their companies and led them through the massive, gut-wrenching change required to pivot in the face of a serious threat. A few of the biggest examples include: 

• In 1995, it became apparent to Microsoft co-founder and then-CEO Bill Gates that the internet was “the most important single development to come along since the IBM PC,” and, if not embraced in haste, a threat to many of Microsoft’s businesses. In May of that year he published the “The Internet Tidal Wave” memo and focused all of Microsoft on adopting and building for the internet. Almost 20 years later, current Microsoft CEO Satya Nadella similarly made the bold decision to redirect the company for a cloud-first world. 

• Facebook went public at $38 per share in May of 2012 but within months, stocks could be had for a little over half that. The concern? Facebook was a desktop-optimized website without a polished mobile presence, and by 2012, consumer attention had begun to accelerate towards mobile at a much higher rate than many initially predicted.  Facebook CEO Mark Zuckerberg reacted by not only proclaiming Facebook a mobile-first company, but also backing up that proclamation with action.  

• Turning to another company I’ve worked with via Apigee, T-Mobile launched its highly visible “Uncarrier” campaign—which offers streamlined, customer-friendly plans and services—while also investing in and executing a new IT vision dedicated to ongoing digital transformation. T-Mobile execs have credited the technology effort, spearheaded by CEO John Legere, with helping the company to introduce new services and better service customers. T-Mobile’s market cap has more than doubled since Legere took over in 2012.  

Keeping pace with changing customer needs

In the face of an existential threat, strong executive leadership is required to pivot the company to safety, as these examples attest. Digital transformationisn’t about deploying new technologies just to make an existing approach more efficient or to add a few new apps or features to the status quo; digital transformation is about keeping pace with changing customer needs by leveraging software platforms to continuously evolve how the business operates. This can be akin to turning an enormous ship—and a ship can’t turn very well without her captain, first mate, and other leaders showing the way.  

Research supports this. A recent Deloitte survey, for example, found that over “80 percent of respondents from digitally maturing organizations say their leaders have sufficient knowledge and ability to lead the company’s digital strategy,” compared to only “22 percent of early-stage business respondents [who] have the same belief.” Similarly, Gartner research finds that CEOs are seeking a “deeper understanding of digital business” as they shift their focus from growth in general to how technology helps them attain it.  

More recently, the onslaught of software devouring the world has been further accelerated by machine learning making everything smarter, voice interfaces changing how people interact with devices, and more. To keep pace, corporate leaders need to galvanize their companies to build and deploy software faster, make systems and data easily accessible inside and outside their companies, and improve digital experiences through not only machine learning but also constant data-driven iteration. 

Seven years after Andreesen’s editorial, the pace of digital disruption is still increasing, and so is the need for strong leadership to pivot fully into digital. Over half of the Fortune 500 has been acquired, merged or declared bankruptcy since 2000—and the companies that survive in coming years won’t be those whose leaders treat technology as an IT concern rather than a core part of the business.  

When banks and other financial institutions make their products available via non-banks, we call that Embedded Finance. Think, for example, of a retailer offering financing for people buying goods; or a budgeting app gathering bank transactions to help you categorize and understand your spending patterns. The finance – the money management – has been embedded into the retailer or the budgeting experience.

This last example falls under the Data Exchange category of Embedded Finance , and it’s often also called Open Banking. In many countries this active data exchange is actually mandated by law, with specific Open Banking standards encoded into law for all financial institutions. As of this blog post, there are approximately 37 countries with such laws already in place or currently being worked on.

In an Embedded Finance scheme there are three main players: The financial institution offering their products and services, a third party provider (TPP) making use of those products or services, and an end user who is a customer of the financial institution and is interacting with the TPP.

The most important ingredient for these schemes is consumer trust. If a consumer does not trust that their data will be safely shared with a third party, and that they can easily understand the terms they have agreed to and stop sharing their data whenever they want to, consumers will simply not participate. When a consumer agrees for their data to be shared, this is called consent.

What components do I need for a successful Embedded Finance solution?

Banks’ products and services are made available to other parties via APIs, thus a fundamental component is an API Management platform. An API Management Platform lets you design, secure, analyze, and scale APIs anywhere with visibility and control.

Also, we need a component to manage consents given by end users. Consent Management refers not only to the capability of checking whether a certain action by a third party (eg: access an end user’s account balance) is valid according to the consent granted by the end user to that TPP,  but also the availability of tools for end users to check existing consents, modify them or revoke them, as well as tools for financial institutions to perform similar actions on behalf of their customers.

Finally, we need an Identity Platform capable of authenticating an end user and establishing their identity.

A Google Cloud based embedded finance solution uses Apigee as the API management platform, Identity Platform or your own identity platform of choice, and a consent management service (CMS).  Google Cloud has partnered with two leading providers in the consent management space: Clarip and CloudEntity.

How do these components work together?

The main roles and responsibilities of each of the three components are quite clear, but there is a certain degree of flexibility on how to orchestrate the interactions between the components, and which component performs which function when there is an overlap of functionality between them.

Google Cloud has tested the following interaction patterns:

• Interaction Pattern #1: Apigee as the main orchestrator

In this interaction pattern, Apigee interacts with both the consent management service and the identity platform, coordinating end user authentication with the identity platform, and authorization and consent with the consent management service. Apigee acts as the “broker” between users, their identity, and their consent.

• Interaction Pattern #2: The consent management service abstracts the identity platform.

In this case, the consent management service manages all the interactions with the identity management platform, and the identity platform acts as the “broker”. Apigee only interacts with the consent service.

The three components share a common pool of client apps and end users. One of the components is typically designated as the source of truth for these entities, while the other components that need to know about these entities synchronize that information from the source of truth. 

The identity platform is typically the source of truth for end user identities and the consent management component will synchronize that information by pulling it from the identity platform. 

The consent management service is the source of truth for user opt-in and current consent status. Apigee will either check with the service the validity of a consent every time a request comes through, or to make it more efficient, it will validate the main attributes of the consent based on information stored in Apigee. To maintain consistency, the consent management service should tell Apigee to invalidate any tokens associated with a consent when it is revoked via other means (for example, if an end user revoked consent from a consent dashboard).

For client apps, either Apigee or the consent management component can act as the source of truth, with the other component synchronizing the information. In the context of Open Banking in particular, standards often mandate that financial institutions support Dynamic Client Registration. This means having endpoints that new clients can use to register themselves as clients for the Open Banking APIs. In this case, the synchronization of clients can easily be incorporated into Dynamic Client Registration.

Let’s look now into more detail about how the three components interact. There are two user journeys that are particularly relevant:

Authentication/Authorization/Consent

This is the beginning of the typical consumer client journey, when an end user starts using a third party app that requires access to that user’s data. The third party app needs to authenticate itself, and request authorization to access the user’s data. This will trigger the authentication of the end user and consent granting: Consent granting being the process of, the user authorizing the operations the app will execute on their behalf, and establishing the list of accounts on which these operations will be performed. The authorization is represented by an access token, which the app will need to include in all subsequent requests.

This is quite a complex journey with many steps involved in order to make this as secure as possible. To make it easier to understand, we will simplify some of the steps (apologies in advance to you OIDC/FAPI experts out there!).

At a high level, these are the steps involved in this user journey:

1. End user starts using an app
2. The app requests permission to access user’s data
3. The identity platform (IdP) authenticates the end user
4. The consent management service obtains consent from end user
5. An access token is issued for the app, encapsulating the authorized permissions, accounts, etc. A refresh token is also issued – the access token normally has a short life (measured in minutes), but the app can use the refresh token, which typically lasts much longer (days or months), in order to obtain a new access token without the need of going through the end user authentication/authorization/consent process again.

The way these steps are orchestrated varies depending on the interaction pattern among the components.

Pattern #1: Apigee orchestrates all interactions
When the client requests permission, Apigee will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback URL that Apigee registered in the IdP configuration.

Apigee will then redirect the client app to the Consent Management service, so that the consent form is displayed. Once the user grants consent, selects the desired permissions, and selects the accounts it will apply to, the Consent Management Service will update Apigee with the status of the consent, via a callback Apigee registered in the consent configuration.

Now that the end user has authenticated and granted consent, Apigee can now issue an authorization code, and associate all the necessary information, for instance, details about the consent, the authorization code issued by the Identity Platform (IdP), the identification of the end user in the IdP, etc. Apigee will return this authorization code to the client app via a callback endpoint that the app provided when registering with Apigee.

The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the IdP, abd update the status of the consent before issuing an access token to the client.

Pattern #2: The Consent Management Service is the center of the Architecture
In Pattern #2, Apigee will only communicate with the Consent Management Service, which acts as an authorization server for the app and will also coordinate all interaction with the IdP.

When the client requests permission, Apigee will forward the request to the CMS. The CMS will record the request and then redirect the client app to the IdP login page. Once the end user logs in, the IdP will return an authorization code to the callback the CMS registered in the IdP configuration.

The CMS then displays the consent form. Once the user approves the consent and selects the desired permissions and accounts it will apply to, the Consent Management Service will return an authorization code to Apigee, via a callback Apigee registered in the CMS configuration.

From now on, the flow is the same as explained above. Apigee will issue an authorization code, associate all the necessary information and will return this authorization code to the client app via a callback endpoint. The app will then exchange the authorization code for an access token. Apigee will obtain an access token from the CMS, before issuing an access token to the client.

Let’s now look at the other relevant user journey:

Access shared data 

Once the third party app has been authorized, it will then start requesting that end user’s data. For instance, it may request the list of accounts or the balance of a particular account. 

When that request goes through, a series of checks need to be performed: Is this third party app still authorized? Has it been granted the right permission for the operation being requested? Is the account involved included in the list of accounts authorized by the end user? Apigee can perform all these checks by inspecting the access token presented by the third party app. 

There is, however, one other check which cannot be done simply by inspecting the token. Imagine for a moment that in-between the user granting consent and the app requesting the user’s data, the end user decided to revoke that consent. This could be done by other means than the app itself, for instance by checking all consents granted to all apps in a consent dashboard accessible via other channels such as an “Internet Banking” site. When the app requests the user data, the token is still valid, however the consent has already been revoked. Therefore, in this user journey, Apigee will check with the Consent Management service to check if the consent is still valid. This adds a bit of overhead, which can be minimized by other means. For instance, one popular optimization is to make sure that the Consent Management service asks Apigee to revoke any access or refresh tokens associated with a given consent when that consent is revoked via other channels. If that guardrail is in place, then Apigee can determine if a request should be allowed simply by validating the access token and using the consent information stored alongside the token.

The following diagram summarizes the interactions required between Apigee and the Consent Management component. The interaction is essentially the same in both interaction patterns.

What’s next?

In this article we have described how Apigee, a Consent Management service, and an Identity Platform are the fundamental ingredients of a successful and secure Embedded Finance solution. We have also looked at how these components interact with each other to keep user consent consistent and available. Both interaction patterns described are valid and have been proven to work. So which one may be right for you? The answer ultimately depends on your particular requirements, the choice of consent management service, and your choice of identity platform. As a rule of thumb, if you have multiple application experiences, identity systems, and sources of consent, an Apigee-centric architecture is a great solution. If you are looking at a Consent Management service in the context of an Open Banking implementation mandated by a centralized authority (eg: Open Banking Brazil, Consumer Data Standards in Australia), CloudEntity is a good choice for consent management, as their product is also Certified Financial-grade API (FAPI) OpenID Provider, with profiles for the various Open Banking standards. CloudEntity integrates with Apigee using Pattern #2. 

For more details on both Clarip and CloudEntity’s offerings and how their particular solution works with GCP please check:

• Clarip: Universal Consent Management Platform – GDPR
• CloudEntity: Certified OpenBanking  & Consent (UK, Brazil and Australia) at scale

For more details on Apigee API Management, see https://cloud.google.com/apigee

You can also learn about our solutions for retail banking or contact sales.

Did you know API traffic for Apigee customers increased 46% year-over-year, to 2.21 trillion calls, between 2019 and 2020? If you have more questions on APIs trends and their role in disrupting enterprises digitally, you can catch up on key take aways from the Google Cloud’s State of API Economy 2021 report and insights from Google’s experts on API-best practices.

If you build apps and services that your customers consume, two things are certain: 

1. You’re exposing APIs in some form or the other. 
2. Your apps are made by multiple functions working together to deliver products and services. 

As you scale up and grow, your enterprise architecture can benefit from a sound strategy for both API management and service management, both of which impact your customer and developer experience. In this article, we’ll explore how these two technologies fit into your application modernization strategy, including how we’re seeing our customers use Anthos Service Mesh and Apigee API Management together. 

How APIs, microservices, and a service mesh are related

APIs accelerate your modernization journey by unlocking and allowing legacy data and applications to be consumed by new cloud services. As a result, organizations can launch new mobile, web, and voice experiences for customers. 

The API layer acts as a buffer between legacy services and front-end systems and keeps the front-end systems up and running by routing requests as the legacy services are migrated or transformed into modern architectures.  In addition, an API management platform, like Apigee, manages the lifecycle of those APIs with design, publish, analyze, and governance capabilities.

Once microservices architectures become prevalent in an organization, technical complexity increases and organizations find a need for deeper and more granular visibility into their applications and services. This is where a service mesh comes into play. 

A service mesh is not only an architecture that empowers managed, observable, and secure communication across an organization’s services, but also the tool that enables it. Anthos Service Mesh lets organizations build platform-scale microservices with requirements around standardized security, policies, and controls, and it provides teams with in-depth telemetry, consistent monitoring, and policies for properly setting and adhering to SLOs. 

How API management and a service mesh compliment one another

Many organizations ask themselves, “Do I really need both an API management platform and a service mesh? How do I manage them together?” 

The answer to the first question is yes. These two technologies focus on different aspects of the technology stack and are complementary to each other. A service mesh modernizes your application networking stack by standardizing how you deal with network security, observability, and traffic management. An API management layer focuses on managing the lifecycle of APIs, including publishing, governance, and usage analytics. 

Most organizations draw a logical boundary at business units or technology groups. Sharing these microservices outside that boundary with other business units or with partners is where Apigee plays a significant role. You can drive and manage the consumption of those services through developer portals, monitoring API usage, providing authentication, and more, with Apigee. 

Google Cloud offers Anthos Service Mesh for service management and Apigee for API management. These two products work together to provide IT teams with a seamless experience throughout the application modernization journey. The Apigee Adapter for Envoy enables organizations that use Anthos Service Mesh to reap the benefits of Apigee by enforcing API management policies within a service mesh. 

Accelerate your application modernization journey

Though the journey to application modernization doesn’t always follow a clear-cut path, by adopting API management and a service mesh as part of a modernization journey, your organization can be better equipped to rapidly respond to changing markets securely and at scale. 

Wherever you are on your application modernization journey, Google Cloud can help. To learn more about how service management and API management can be part of your application modernization journey, read this whitepaper.