nuts and bolts

The silo integration challenge has existed for decades, but the nature of the challenge and the means to address it continue to evolve to reflect the changing world around us. 

As always, the challenge is shaped by the business context — what business problem are you trying to solve? Firms today are typically aiming to achieve one or more of these objectives:

  • Deliver breakthrough customer experiences over the entire customer journey. This requires integration on both the front-end and the back-end so that customers see consistent information across smooth handoffs between distinct systems or micro-sites
  • Integrate business operations across multiple subsidiaries and/or geographies. Ranging from integrating multiple ERP systems to internationalizing the user experience, today’s global firms face this challenge on a larger scale than ever before
  • Integrate disparate data to deliver a “single view” of customers and/or products. Whether transactional data or analytics, the proliferation of massive troves of data fortunately is matched by the pace of innovation in data management technology

Of the three, customer experience is by far the biggest change driver today, thrusting the rise of APIs (Application Programming Interfaces) in the spotlight as a technical approach to integration. Were it not for this disruption, firms might rely more on earlier generations of technology, whether an ESB (Enterprise Service Bus) or ETL (Extract-Transform-Load) tool for data movement. Indeed these older technologies still have a role to play in integration across silos on the backend.

So how can you effectively leverage APIs to meet the integration challenge? Early API innovation was driven mostly by “pure digital” firms like Amazon, Netflix, Box and Google. Their APIs continue to play a central role in the way large enterprises like CapitalOne, MasterCard and GE approach the market because of the standards and design patterns the “pure digital” firms shape. But whereas a “pure digital” firm may publish a handful of APIs, enterprise players must manage hundreds or even thousands of both internal and external APIs along with a much larger and more complex landscape of data that these APIs convey.

For all their potential value in bridging silos, this flood of APIs brings its own challenges. Without the right design and management approach, enterprises may fail to realize that value.

Design Your API Portfolio Around Resources, Experiences and Capabilities

To effectively manage a portfolio of APIs, you must organize your APIs around the way they will be used — centered on the concepts and objectives of the audience for the APIs. This is in contrast to the old “point-to-point” style of integration, which sustains technology-centric silos rather than bridge across them to provide a business-oriented interface. 

Left to their own devices, many enterprise teams working in parallel to deliver APIs will deliver APIs that are more like the point-to-point interfaces of the past rather than a fully integrated, business-oriented API portfolio. Enterprises should organize their APIs around three primary categories to achieve this business orientation:

Resource-Based APIs

Netflix gives examples of this type of API including:

  • /users/<id>/ratings/title
  • /users/<id>/queues
  • /users/<id>/recommendations
  • /catalog/titles/movie
  • /catalog/people

Each resource represents a collection of information about an entity or collection of entities of a given type, organized according to the information architecture for the domain. API consumers use REST (Representational Entity State Transfer) style APIs to perform CRUD (Create, Read, Update, Delete) operations on information that represents the state of a resource (e.g. what movies are in your queue). Effectively managing information architecture for an enterprise ensures these resources mirror key business concepts rather than silos.

Experience-Based APIs

Netflix has for some years (since Daniel Jacobson’s arrival from NPR to Netflix, now VP of Edge Engineering) organized its APIs to deliver unique experiences to each endpoint device, and they are designed around the specific capabilities of each device. A Roku box delivers a different experience than a PlayStation, so Netflix provides APIs tuned to each endpoint type. For example:

  • /ps3/homescreen

Experience-based APIs represent a different design pattern than resource-centric “one size fits all” (OSFA) resource APIs. However, they are often a wrapper that invokes OSFA APIs to do the work. Because of their focus on experience, these APIs are usually optimized for use from Javascript, but at their best still mirror the business’ digital experience strategy rather than functional silos. Enterprises often provide experience-based APIs to fuel their mobile apps.

Capability-Based APIs

This pattern is more common for internal enterprise use cases but may also apply for B2B. Enterprises often undertake Business Architecture to develop strategies and roadmaps for better aligning technology with business goals and priorities. One of the most common techniques used in Business Architecture is Business Capability Modeling. Capabilities break down into lower-level capabilities. Each abstract capability represents the human, physical, process and digital resources that together are able to deliver the capability. For example, a retailer might represent some of its inventory management capabilities like this:

inventory management

APIs that deliver these capabilities are most effective at bridging silos when aligned with these business-oriented capability models. Although these models do evolve, they are stable enough to provide a structure to guide developer portal navigation to find APIs. The models are also a great way for portfolio managers to work with business stakeholders to focus API investments and improvements in the areas that the business sees as most critical to its success.

For example, in building an app that enables customers to shop from inventory in multiple stores, APIs like these would bridge the disparate inventory systems underneath:

  • /store/product (For a store, find information about products in stock.)
  • /product/store (For a product, find the quantity in stock at each area store.)

Managing the API Portfolio Requires Product Management

Pure digital firms already manage their APIs as products, and some enterprises have organized their technology teams on a product model for years. Applying product management discipline to the API portfolio means understanding the audiences for APIs, their goals, and the business goals (and model) that will sustain investment in serving those audiences through APIs. The product manager leads the business process to allocate investments across potential API development or enhancement so as to maximize the business return for the API provider, while ensuring a more business-oriented (and less siloed) outcome for the API portfolio.

Only enterprises that follow this kind of business-oriented approach can expect to succeed in the digital world via their API investments. The kind of point-to-point API chaos that results from failing to manage API-based integration in this way exacerbates the problem of silos, as each team or area becomes the source of yet another generation of siloed technology. Following this business-oriented path to bridging technology silos with APIs is the only surefire way to position your business to deliver consistent and enjoyable customer experiences throughout the customer journey.

Creative Commons Creative Commons Attribution 2.0 Generic License Title image by  Sergei Golyshev