Have you ever tried to implement a new process in a big company? Believe us when we tell you that it’s not an easy (or fun) task. From obtaining initial approval all the way through to disseminating information, it takes time and there are often bumps along the road.

This is something that Josh Wang, project manager at Bosch Automotive Aftermarket, knows all about. Recently tasked with implementing an API management solution at Bosch, he talks about the incredible amount of data associated with Bosch’s products, which range from mobility solution and industrial technology through to consumer goods and building technology.

The aim of the project – to implement an API management platform that would allow them to use their APIs more effectively and make more useful products for customers – was a slam dunk for Bosch. With billions of data points being generated via end user usage of their products, it made perfect sense for them to want to streamline and solidify their API management practices.

This post will cover some of the lessons learned from enterprise API management implementation — though that’s not to say that there’s nothing to garner if you’re working at a much smaller company — many of these best practices apply whether you’re managing a very large number of different APIs or creating and maintaining just a couple.

Is building everything yourself always the answer?

For developer consumers, there’s a certain stigma associated with building your property on someone else’s land – What happens if they shutter the API? How will downtime affect our app? The question posed above is an important one to ask.

When beginning a developer program, you must consider whether or not there’s already an API out there that can do the type of thing that you’re looking for. For example, there’s no need for a website looking to give personal recommendations for movies to build their own API when they can just use IMDB’s data instead.

That’s a basic example, but the idea holds true even in large enterprises – it’s much easier to convince your team to use an existing product than it is to get C-level execs, developers, marketing and operations on board with building one of your own.

There are certain parallels here between using a third party API management platform and trying to build your own API in that making use of what’s already out there can save a lot of time. In the case of Bosch, however, one thing was for sure – whatever the solution was, it needed to be extremely robust. As Wang says, “we’re building stuff that can potentially burn your house down, crush you or do harm to you if it’s not done 100% correctly.”

In this context, it’s clear that relying on many different developers to maintain APIs that need to work seamlessly together wasn’t the best idea for Bosch. They settled on using a third party API management solution and, while that might sound like a luxury for smaller organizations, it makes good sense when planning for scalability. We’ll talk more below about cases in which that might be particularly important.

Have an effective strategy

Regardless of what you’re doing with APIs, it’s best to start with a list of requirements – what do you need to be able to do with your API(s)? How will existing infrastructure impact what you can do? Can your current setup handle the extra load?

In Wang’s case, this list comprised more than 200 requirements. Large enterprises have to deal with multiple security zones, each with clearances, manual registration processes AND different users required to complete those processes. “This is far, far away from continuous delivery,” Wang jokes.

Smaller companies are lucky in that they’re generally better equipped to develop in a more agile fashion, but security, data protection, and uptime of existing services are still things that need to be taken into account when you’re planning your next API move.

And, as much as we hate to bring it back to this, organizational complexity will always be a huge factor in API deployment and management. “Within Bosch, for example,” says Wang, “there are so many divisions, business units and people with authority, that you need a platform that is flexible enough to facilitate the entire API lifecycle workflow.”

Without that buy-in from others in the company, you’re going to be spinning your wheels every step of the way during any API-related activity.

Be ready for that strategy to fall apart

“Life is what happens to you while you’re busy making other plans”, said Allen Saunders, and he might as well have been talking about software development when he did so.

Wang admits that he was naive in coming up with a timeframe for the execution of his project to implement a third party API management system from Axway that could handle the many APIs used by Bosch. “The team we were working with said it would take two days, maybe five. Ok, let’s say ten days.” Just to be on the safe side!

The reality was that implementing a management system, designed to simplify the maintenance of and interaction between existing APIs, took far longer than this: management nodes couldn’t communicate properly with the current security setup, necessitating a design of exception, firewall issues, etc. The infrastructure for the new domain needed to be changed four or five times. Even tiny problems like Bosch’s existing system not allowing the execution of scripts in the temp folder, which was required by Axway, seemed to snowball.

“And those are just the small problems!” says Wang.

Taken from Josh Wang’s presentation at the Nordic APIs 2016 Platform Summit. See full slide deck here or at the bottom of this post.

Whether we’re talking about API management or implementing a new API, flexibility is key. On the former, Wang prompts enterprises to ask big questions like “how can you define your API management architecture in a way that supports on-premise hosting and cloud solutions?” and to “think about the different use cases with security.”

But he’s eager to point out that platform providers have plenty of work to do as well, saying that there are “challenges that providers of API management solutions and gateways need to address if they want to offer their solutions to large enterprises.” It’s important to note here that this doesn’t mean that management providers like Axway are necessarily doing anything wrong, only that the relationship between them and large organizations are so new (relatively speaking) that it’s common for unpredictable issues to arise.

For example, Wang talks about some of the legal requirements associated with API management, joking that this is something most developers don’t like to think about:

“In Germany, you need to record the version and date of when somebody has agreed with the terms and conditions in the privacy statement. If the system does not support a dedicated database that can store this kind of information, it’s very difficult to convince the legal department that you can go live with the platform.”

That’s just one example, but it’s a compelling one that highlights the difficulty creators of API management platforms face: they don’t only need to measure up to the technical requirements proposed by developers, but must address a number of other issues as well.

Think big, even when you’re small

Some of the content in this post might seem like overkill for startups and smaller businesses, but APIs are like Pringles – once you pop, you just can’t stop. At the time of this writing, Salesforce, for example, has 10 APIs and Microsoft Cognitive Services has 23. Google has such a large suite of APIs that they have an API explorer to navigate them. And, with companies increasingly using freemium or paid API models, the trend of multiple APIs and microservices will only become more prevalent.

Wang highlights the way in which the size of a company doesn’t always correlate with the complexity of an organization anyway: “Even small companies have very complex authorization structures in roles sometimes, depending on what kind of domain they’re working in, and it’s really important to have a platform that supports different roles, additive roles etc.” Even smaller companies need to think about all of this, sooner rather than later, if they’re thinking about building a suite of APIs.

There’s a certain element of future proofing inherent in the idea of building or implementing an API management platform: the insinuation is that APIs will become, or at least have the potential to become, a key part of the business. That can be a smart move since lots of companies develop a single API then, before they know it, they’re hosting multiple APIs that probably aren’t synchronized as well as they could be.

To go one step further, API Evangelist suggests that “personal APIs” are not only on their way, but already here. As employees bring their own APIs to the table, potentially using them in their own individual workflow, an approach that’s very open to API management platforms makes sense.

It might seem far-fetched for some companies to start thinking about API management, and the problems associated with it in large enterprises before they’ve even built their first API, but it could just end up being one of the smartest business moves they ever make.