APIs Inside vs. Outside the Enterprise

The boundary between internal and external IT functionality in an enterprise is a false distinction. Nobody can predict how data will be used or where information will flow. Even if you know where your company’s interior/exterior lines are drawn today — those lines will almost certainly be moving targets in the future.

Take Pitney Bowes, a company I’ve worked with in my role in the Apigee team at Google. While much of its near-century history has been rooted in physical mailing solutions such as postage meters, the company also developed payments and ecommerce capabilities over the years and acquired vast amounts of logistics, shipping, and geolocation data. As Pitney Bowes evolved from analog services to today’s world of connected commerce, it derived value from these assets and competencies within the organization — but it recognized the assets and competencies could be valuable outside the company as well, to developers and partners who could use them to build new apps and services.

To seize this opportunity, Pitney Bowes offers over 160 public APIs via the cloud, opening millions in potential new revenue and helping the company’s digital commerce efforts become a $1 billion-plus annual business. Data and functionality that was once solely internal is now external as well.

There’s a lesson here: thinking of business solutions and strategies in terms of “internal” and “external” or in terms of “integrate System A and System B” is outdated. The issue isn’t how you are going to connect your internal systems and users — that connection can be made a number of ways. Rather, the issue is what you can do with the connection once it has been made.

The answer depends on the type of connection — static versus dynamic. In the old world of point solutions, for example, the focus was often just static integration, getting information from system A to system B. The monolithic mechanisms employed were often brittle and complex, focused only on the current A→B trajectory, as though future routes to C, D or E would never be ventured.

But of course that’s not the case. As the Pitney Bowes example demonstrates, today’s data pathways might look nothing like tomorrow’s. In the long run, all connections need to be dynamic, ready to be scaled up or down as needed, and ready to interface with whatever is required. To stay competitive, you can’t just use the same technologies and keep bolting on, and you can’t rely on crumbling frameworks such as “inside” and “outside.”

More specifically, here are the minimum requirements for internal access to a system:

• Security
• Audit trail
• Visibility
• Runtime performance (uptime, latency)
• Cost (cost avoidance, cost savings)

Traditionally, many businesses have stopped here. But there are additional points that must be considered in today’s fast-moving world:

• Insights/analytics
• Ease of Use
• Extensibility
• Deployment options (e.g., containers, clouds, scale)
• Monetization
• Fine-grained control

As the new requirements demonstrate, if you don’t build your systems with the expectation that they’ll have to interact with systems that haven’t yet been invented, you’re risking locking yourself in. Too many people are still mistakenly thinking that the challenge is shuttling large chunks of data through coarse-grained security to thick client apps.

But going forward, applications and architectures will need to be incredibly granular and scalable. To get there, businesses must evolve from an integration mentality to more modern approaches that make systems available granularly, reliably, and scalably while supplying visibility, insights, control, and security. The foundation for most of these atomic, agile architectures will be productized APIs — that is, APIs that aren’t just used to expose assets but that are designed and managed as products that empower developers, whether internal or external, to create new apps, extend brand reach, and open new revenue possibilities.

This distinction is important: APIs are used today in many integration scenarios, so the point isn’t to have APIs — it’s to have APIs designed and managed for consumption, reuse, and continual improvement. Put another way, with an integration mindset, APIs can solve short-term problems — but once one sees that the internal/external division has collapsed and that integration use cases are no longer sufficient, API management becomes the most reasonable solution.

[Interested in more tips for managing APIs and driving digital business? See Apigee’s new ebook, “The API Product Mindset.”]