Let’s be real—no one in today’s hyper-fast business landscape has the time to wait on others. In order to meet the needs of rapid software releases, true developer independence is needed. And productized APIs, which deliver simple, flexible, intuitive, and secure experiences, can do just that.
Of course, implementing a successful enterprise API practice is easier said than done. To illustrate how different API success factors can lead to better business results, we talked to Chase Fryer, SVP of API Strategy and Enablement at Concentrix, about the organizational changes and shift in thinking required for API success.
Q: What is the biggest misconception clients have about APIs?
Our clients think that APIs solve a technical problem. APIs have historically been viewed as technical solutions in that they connect systems, serve other needs, and help other apps, platforms, and products work. It gets interesting when we start thinking about APIs as solving business problems—creating business value and serving as products on their own to bring to market, positioning data for consumption at the edge, and self-serving for internal teams. Our goal is to intentionally build a set of digital business capabilities as its own portfolio to solve for and create new opportunities, as opposed to just solving a project’s technical challenges.
Q: What are some cultural changes organizations should make to succeed at their API programs?
We need to think more about product ownership and less about project execution. APIs should be built as products, not as the components of functional project execution that they have been historically. A big part of this is changing how we incentivize teams. Today, teams are typically measured on velocity of production. Instead, we should incentivize teams on how effectively they can build a product that can be independently consumed. We should think about how we scale consumption and adoption of that API, not about how many APIs can we pump out. So, we switched the construct to “fewer is better” and we’re measuring the qualitative outcomes of what we’re producing. We want to create something that has three or four or five different points of consumption.
Q: In your opinion, why is API governance so important?
APIs are proliferating at an unprecedented scale, and systems are becoming more distributed. At the same time, the world economy is becoming increasingly connected. There are a lot more points of connection—between, around, through, and even within systems. We need APIs for those points of connection. This tends to drive companies into a state of API chaos—the number of APIs grows faster than the company’s ability to manage them. Ultimately there’s duplication and waste in companies’ overall portfolios because of the speed of production and multiple teams unknowingly building similar things.
It goes beyond the API success factors themselves, though, with the attacks growing: every API is a point of potential entry, or risk. Governance is required to reel some of this in. However, we cannot use in a one-size-fits-all model. We need to incorporate a risk-based model to keep ourselves moving at the right speed, based on modern standards and patterns that promote consumption. If we’re implementing anything that is going to negatively impact consumption of the API we need, then we’re creating a problem for ourselves. Lastly, we need governance to be able to produce a cohesive API portfolio of products that span the various capabilities of the business, represented in a developer portal, that allows a customer to see everything the business does. To have that one cohesive experience is not easy to pull off in a large and complex enterprise. We have all these different business team that exist, each with a sense of ownership over what they produce. If we don’t have standards from a design perspective, we don’t have standards from an authentication perspective.
Q: What’s the most essential change organizations can make to improve API security?
API breaches are on the rise, costing millions of dollars and brand damage. The majority of these breaches occur as a result of improperly designed authentication and authorization mechanisms. This is a space that is really difficult to systematically deter, which we’ve seen in our own experience running API assessment programs where we evaluate over 180 points around security and design. And yet, the small handful that check for these appropriate authentication and authorization aspects are violated more than any other set in that entire bit. This is why we need to educate and enable architects and developers, because those patterns are created, designed, and executed in their hands. We’ve found all too often that the modern patterns around API authentication and security aren’t well understood by much of the market today.
Q: In your opinion, what do clients get from working with Concentrix’ API Enablement team that they don’t get from other technology vendors?
They get a 10-year API strategy practice with industry-leading thought leadership that has an informed an enterprise-level API practice blueprint. Also, we have a wealth of IP, including frameworks, templates, best practices, and standards that accelerate our clients’ journeys to API maturity, and deep expertise with industry-leading API management platforms such as Apigee and Mulesoft. We’re bringing content and best practices to the table with 90 percent of that defined and prescribed. And, we work with our clients to integrate that into their organization. We bring API product owners, API designers, and build teams that know how to create API for scaled adoption. What also sets us apart is a deep understanding of the cultural challenges organizations must overcome to build a winning API program. And finally, we’ll provide both strategy and execution with a proven ability to connect the two for impactful outcomes in the API space.
Chase Fryer
SVP, API Strategy & Enablement