This contributed piece on the importance of APIs is from Brian Koles, Head of Business Development at ChallengePost.

If I told you that I had a computer with the fastest processor and best display ever, but that it would never connect to the internet, you would likely consider it obsolete. That same label will soon be applied to companies without APIs that connect them with the rest of the digital world.

As software continues its march to transform all industries, lack of connectivity increasingly equates to being broken. Application Programming Interfaces are the conduits through which data, platforms and goals come together, so the best apps are increasingly becoming collections of elegantly woven APIs. If software developers are the new rock stars, then APIs are the instruments with which they make their music.

This may all seem a bit dramatic, but truly it’s not. I don’t want my technology siloed. I want it to play nicely with others, increase efficiencies and make life easier. That’s what APIs do. They enable convenience through integration.

If your company doesn’t seek new channels for integration, then it will stand alone on a digital island, which is no place to be in the connected future. I’m not just talking about enterprise ERPs aligning myriad business processes either. APIs are on Main Street, enabling merchants to connect with new customers, more easily accept payments and hire help on the fly. They’re capturing memories at home, and enabling photos and prescriptions to be ordered from the corner pharmacy

Of course, APIs are big business too. Whether it’s trading foreign equities, managing large software projects or creating the future of consumer electronics, it’s all evolving communally through APIs (and their cousins, Software Development Kits). Developer communities are consequently becoming organic business development and R&D teams, taking companies and their technologies in new and exciting directions, all on their own.

Navigating the path from being a traditionally closed-off company to one with an API program may not be easy. Change is scary, especially when it entails inviting third parties to run wild in what’s previously been a private sandbox. Here is a broad outline of next steps for those willing to champion the cause:

Uncover Needs to Gain Early Support

Request meetings with executives whose departments could benefit from increased interconnectivity. Use the pretense of something like “wanting feedback on a potential project that would make our [content, systems, data] more accessible to various departments, and possibly strategic partners”.

During the meeting, ask what new efficiencies or revenue streams they could imagine taking shape if their {content, systems, data} was liberated. Note these suggestions, and ask to be looped in if more come to mind. Getting stakeholders accustomed to thinking about the possibilities that APIs can generate will be crucial. 

Define the End-User And Plan Accordingly

Will the developers using this API be internal, external or both? And in what order? The painful process you want to avoid goes something like this: 

  • Most larger corporations launch APIs designed only for internal needs, integrating systems and workflows from various departments. 
  • Then an opportunity pops up where a partner wants to use this API for mutual benefit, but it isn’t engineered to allow for secure third party access ... or bill for it. 
  • A few custom arrangements limp along for several months until the API can be re-engineered to accommodate a third party ecosystem. 
  • Everybody involved wonders why the API wasn’t built for the possibility of being external-facing in the first place. 

Unless there is absolutely no circumstance where it makes sense for the API to be accessible to third parties, avoid this hassle by designing the API as if it may some day be external-facing, even if there’s no immediate need. 

Get Buy-In

Exposing assets is a scary proposition. Dirty laundry could be aired, and loopholes will assuredly be abused before patched. You’ll need some champions to help you endure the bumpy road. Constantly remind stakeholders about the long-term value proposition, and brace them for the turbulence that accompanies any product release. You are thinking of your API as a product, right?

Set Up A Management Portal

Like most software-related projects, you can make a strong argument either for building it in-house or outsourcing development to somebody with more niche expertise. There are a slew of fantastic, relatively mature API management services already optimized to handle onboarding, billing and reporting for every API use case imaginable. This probably isn’t the time to re-invent the wheel.

Plus, these partners provide a variety of white label web portals for setting up your public developer program (likely at developer.COMPANYNAME.com). 

Provide Documentation And Code Samples

It’s essential that developers be provided with accurate and thorough documentation for using your API. They should not need to speak with anybody to navigate and implement your tools for accomplishing reasonable use cases. It’s also advisable to provide code samples for executing typical functionality, which enable developers to focus on coding the more difficult or unique elements of their applications.

Dedicate Staff

API programs are not ‘set it and forget it’ arrangements. Documentation needs to be constantly improved while answering support questions, coaching partners through implementations and evangelizing the platform to target developer communities. Make this somebody’s job. It will not get done effectively as a side project.

Establish Communication Channels

Even if the API is just for internal use, you should still have a discussion forum for addressing developer’s questions. Then update the documentation to reflect common issues. Public APIs should have their own blog to celebrate major updates and partner achievements, and dedicated social media accounts (or at least a Twitter handle) to tie it all together. 

Activities

Just because you built it does not mean that developers will come. Engaging developers requires a mixed bag of attending conferences, holding workshops, and sponsoring in-person hackathons and online challenges. Internal APIs will get an adoption boost from running an internal hackathon, where employees are challenged with using the API in new and exciting ways that serve the company’s interest.

Create A Gallery/Marketplace

People want their work to get noticed. Use a gallery to show off all the awesome software built on your platform, and maybe even offer a rev-share agreement through an app marketplace. It will drive downloads and inspire others to do even better. Internal APIs can have a private gallery. 

Share The Credit

Now that your API has generated some wins, the initially hesitant managers from engineering, marketing and product teams will start glomming onto your success. Let them. You’ll need their support for the next evolution of your API program.

So which will it be? Will your company remain relevant by knocking down institutionalized walls and becoming an open platform through APIs? Or will it be a computer without the Internet?