After years of steady growth, the API economy has hit new highs this year. ProgrammableWeb now hosts over 22,000 public API’s as of July 2019, having grown ten-fold since 2010. Navigating the API economy has become a central tenet of the digital strategy of organizations worldwide. In one study, digital leaders API-enabled 44% of their core capabilities so that external partners can connect to them, compared to only 19% for digital laggards.

While there is little disagreement about the potential of the API economy to transform business models across all industries, the topic of API design has unfortunately lagged API development. Whereas API development deals with the implementation of individual API’s, design is concerned with coordinating a holistic set of API’s to achieve a desired business outcome.

API design is often treated as a uniform set of generic steps, regardless of the use case. Well-intentioned enterprise architecture teams compound the problem by creating and enforcing rigid API design procedures in the name of standardization that are not well-adaptable to individual circumstances. This inevitably leads to development rework and project delays.

Rather than treating API design as a uniform process, digital transformation teams should first segregate their API’s into three layers to make sure their architecture will scale, and then choose from among a set of API design approaches, which will serve the team in a variety of situations, like a set of clubs in a golf bag.

The three API layers

In API design, teams often categorize their API’s into three layers:

• The experience layer defines the interfaces that end users experience and consume, whether through apps, traditional devices, mobile devices, or any other touchpoint
• The process layer encapsulates business logic that perform specific operations on the data accessed via the system layer
• The system layer provides access to systems of record, which in turn store the firm’s master and transactional data

Many digital transformation teams struggle to decide which layer to begin with first. Some teams begin with the first layer in the list, while others attempt to tackle all three layers simultaneously, in the name of team efficiency. However, starting with the wrong layer can lead to significant rework in the development process.

Instead, a team needs a set of approaches, depending on the business domain in which the problem occurs and the business outcome they wish to achieve. This article presents three approaches, though there are no doubt more. Each approach has its strengths and weaknesses. The correct layer to begin with depends on the approach selected.

The design thinking approach

Teams looking to create a brand new application or to radically redesign a legacy application should consider the design thinking approach:

• Start with the experience layer, by developing a vision of the end-to-end customer experience, empathizing with the customer’s pain points, and coming up with creative, potentially outside-the-box solutions to those problems.
• Next, develop the process layer, by creating a set of customer journeys for each end-to-end experience. The process layer provides the connective glue between each step of the experience. Without a well-defined process layer, the customer experience becomes inconsistent and uncoordinated. However, developing the process layer first can result in significant rework upon defining the experience layer.
• Finally, define the system layer, by identifying which data elements are required at each step of the process, where those data elements reside, and how those data elements are updated throughout the process.

The design thinking approach is best suited for greenfield application development, where the team can proceed unencumbered by legacy applications, processes, and data sources. It is less well-suited in situations where the team is building upon existing, complex processes, or integrating with existing, complex and disparate data sources.       

The process reengineering approach

Teams looking to redesign a business process or to drive a continuous improvement effort should consider the process reengineering approach:

• Start with the process layer, by mapping out the business processes that will enable users to get work done. Teams often start with current-state business processes, identify bottlenecks in those processes, and redesign them into future-state processes.
• Next, create the system layer, by identifying the data elements required at each step of the new processes, and in which system they reside. Without defining the business process first, a team would not be able to identify when and where end users would need the data.
• Finally, create the wireframes or user interfaces that drive the efficient capture, manipulation, and viewing of data throughout the new business processes. In this approach, the team creates the user experiences last, because they need to redesign an existing business process and flesh out how data moves across that process beforehand.

The process reengineering approach is best suited for driving process efficiency, reducing undesired process deviations, and for improving the quality of data generated by those processes. It is less well-suited when current processes are not well defined or when process redesign is unnecessary.

Teams often adopt this approach to transform operations and modernize legacy applications simultaneously.

The data analytics approach

Teams that have high-quality data available and the discipline to make use of it should let the data guide them via the data analytics approach:

• Start with the system layer, by performing exploratory data analysis on your systems of record, to identify the insights that your data can offer. While this analysis can be performed offline through spreadsheet tools, creating access points to the systems of record can improve the quality of the analysis by reducing unintentional data errors.
• Next, create the elements of the experience layer that will enable dashboards to visualize the analytics for end users.
• Finally, define the process layer that will embed analytics into current processes, allowing managers to optimize and refine process steps based on analytics. Without the visualizations afforded by the experience layer, end users would be unable to improve their business processes.

The data analytics approach is best suited for further improving a business process that is already in steady-state, when the quality of data is known to be good. It is less well-suited in situations where data quality is poor.

The data analytics approach can also lead to a process reengineering effort, as it can provide useful benchmarking data for future-state processes. In this case, the process reengineering approach begins where the data analytics approach ends.
 
These three approaches to API design offer digital transformation teams a more robust way to think through their team objectives. With some careful thinking upfront, a team can accelerate development and avoid costly rework, by focusing on the correct set of steps to achieve their business outcome.