Enterprise API Strategy

API as a Product, a strategy for successful consumption and avoiding catastrophe

API as a Product strategy

Fail, fast, forward. This is a mindset that everyone who is tackling a digital transformation or digital initiative is tasked with executing. Modernize, Transform, Go Agile, Scale!

API as a Product strategy

Sounds good, looks cool on a t-shirt, but how do you translate this into a way to roll-out new products? How do you truly evolve the portfolio of your company and sustain this change such that it impacts the core of your enterprise solution set?

Over the past decade, the concept of Scaled Agile Framework(SAFe) has been employed extensively development and product teams to harmonize the building and release of software products. The folks at Spotify tweaked this concept and strategy to support greater team autonomy and product innovation with the goal of releasing products and features faster.

Today many organizations are stating they want to “Spotify our team” to benefit from this team structure, but what’s missing from the equation when it comes to the product and more specifically, API as a Product? Learn why you should treat your API as a product.

The 4Cs framework for API as a Product strategy. Whether you’re a Product Owner, Squad member, or Chapter lead, leveraging and employing a mindset that accounts for the 4Cs will help deliver success to your program.

C1: API Creation — Enabling Customer Experience

All products and services are brought to life when an inspired soul chooses to chase a new idea or tweak an existing one to address customer needs in a new way. Though APIs are an inherently technical concept, the creation of them is not isolated to being technical. API Creation is something that starts with the digital team or digital studio in the enterprise envisioning a new customer experience and wanting to launch it quickly by streamlining certain processes, enabling a new interface, or accessing new or existing business logic to address a customer pain point.

In evaluating these types of problems, capturing the idea and documenting the general strategy is a core goal of the product owner, however creating the actual API lives with the developer.

To truly harmonize this relationship and power the best and brightest Product and Engineering teams to work together, the role and focus of picking API Creation tools is critical to your success and cannot be overlooked.

In making this selection, it’s not only speed, automation, and continuous development and integration, it’s also designed. Yep, Design Thinking and mocking before building. Product owners this is wireframing and lightweight testing, all in one. A way to define quickly and explore a user experience before it takes shape. API creation and microservices going mainstream.

C2: API Consumption — Driving Success

Following the concept of C1: API Creation, an equally important area to address and continuously evaluate is API Consumption and the consumer experience. Delivering results in this area requires a full-time product role that someone needs to own and be analytics-driven.

It’s not okay for the dev team or DevOps team to look simply at what APIs are failing, used most, and are buggy. Someone with a Product mindset must trend the APIs, profile how are they being used, in what combinations, for what purpose, and to what result? Even more so, who is accessing these APIs and why?

Can these APIs be furthered simplified to underlying logic that may be obscured in its current form? Can the resulting simplification thus result in new products and services that the company can monetize? If you’re on this wavelength, your path to API Zen is well underway, but you may not be there yet…

Remember, a high number of transactions ≠ success and total # of APIs ≠ Digital Success. It’s all about the value that’s being unlocked, harnessed, and packaged in new offerings that expand your potential and support your growth and self-disruption.

Figure 1: With only Creation and Consumption, APIs in the wild are of little value

C3: API Codification — Establishing the Rules of the Road

Alright, the simple concepts of API Creation and API Consumption are well known. Is there really anything else to care about? Well, if you want your current project or program to not end up in a ditch, yes, there’s more to consider, starting with API Codification. So, what are we trying to communicate here, codifying sounds all official and legal? Yes, that’s exactly right. To achieve a successful API Strategy and have your API Creation and API Consumption truly scale and impact the business positively, you need to create some rules for your API adoption.

In this case, API Codification is all about leveraging your architects, team leads, product owners, and business stakeholders to come together and outline how are your APIs to be used, what’s good and allowed, what’s breaking the rules and will be unallowed, how will we track and enforce the rules and how will we explore rule-breaking from an external standpoint to see if we’re missing something?

This activity and ownership can be triggered in the design phase and blessed by your Center of Excellence, but as a process, it must take life and continue to evolve.

Rules of the Road and codifying them is key to provide structure and guardrails to development and product teams but should not be a one-time effort, rather it must avoid becoming stale and hence requires continuous attention.

API Codification is something that should be done in your traditional Continuous Development/Continuous Integration mindset, i.e. Do it Continuously and constantly apply your learnings to keep your APIs flexible and well-suited to maximizing their value.

Figure 2: Addressing Creation, Consumption & Codification limits liability and provides order but doesn’t drive adoption.

C4: API Curation – Packaging Value

Nice, you’ve made it this far. Not many people have, nor will, so stay strong, there’s yet one last point to consider, API Curation. This concept is where the money is made and lost. The difference between launching and flaming out, or launching, sustaining, and growing.

In this scenario, now that you’ve defined a strategy to roll our API as a Product that involves building/creating, identifying your target personae/consumers, and writing some rules/codification, you must also think about evolving the API as a Product based on your market findings.

This is where curation is critical and is often missed. Curating your APIs is incredibly important because you’ve launched your initial vision and APIs into the wild, but now you’re about to learn what’s good, what’s lousy, and need to make changes to stay ahead of the competition.

Additionally, you’ll want to likely stage your API products, release them in bundles, but reserve the right to catalog them, combine them with other assets, and likely make them easy to discover, access, and use in places well beyond a website or internal code repository. Your APIs need to be set free and made available to your partner ecosystem, enable and drive your new SaaS platform, and henceforth become core to the success of your business.

Figure 3: Employing Creation, Consumption, Codification, and Curation make the magic happen. Innovation and Customer-centric strategies can be employed continuously across Lines of Business.

Tracking metrics to show value for our API product strategy

In the following video, Axway Catalyst Brian Otten discusses the kinds of metrics you should track to demonstrate the value of your API product strategy.

 

 

Live by the 4Cs and it’s Miller time

Congratulations, you’ve endured breezing through this article to revisit a few thoughts that will help drive the success of your API strategy and digital initiatives. Though I wanted to make this a lighthearted overview of some key elements that contribute to API success, take these concepts to heart.

Over the past few years, I’ve seen both in the development and product worlds the omission of a comprehensive view of API strategy. This lack of vision, execution, and continuity has led to millions of dollars wasted on launching, relaunching, and parking efforts that could have truly differentiated an organization.

Instead, money is spent, release happens to hit a timeline, and the results are underwhelming because the roles and strategy required to not only launch but sustain were missing. I look forward to your success and best wishes.

Understanding the API lifecycle is not enough to truly get a business “running on APIs.” Download our three-part guide to creating an enterprise-wide API program to drive your transformation into an “API-first” organization.