Many of the stories we have heard at past Nordic APIs events and have recounted on our blog are ones of transformation. Organizations providing APIs are reinventing themselves as platforms that are ideally suited for modern-day business. These stories have been told by PlanMill, Bisnode, Fyndiq, and others of various sizes operating in different industries. I presented on this last year at Internetdagarna, but feel that we should talk more about it given the prevailing trend toward platformification.
Becoming a platform will require changes in two main areas of your business:
- People: The roles, personnel and processes of your organization will have to undergo major reorientation if they are to function as a platform on which third-parties can conduct their business.
- Technology: Existing technology must be bridged from the old ways of doing business to the new ones. If the gap is insurmountable or if legacy systems are unable to adjust, new technology investments will be required.
The first is the hardest, but don’t be overwhelmed. I have shared the following advice with many would-be platform companies who have followed it and achieved great results.
It’s a People Thing
Moving toward platform-based business operations is a team effort. There is no chance of doing this by yourself. Sorry, Kemosabe. You have to find friends and allies. Building a platform is as much about building relationships as anything else. This will be challenging at first because many potential allies will not grasp the concept or benefits. Platform-oriented business based on APIs is a paradigm shift. Pivoting others’ mindsets can be an uphill battle. To overcome these challenges, I suggest that you employ the following tactics:
- Demonstrate value early
- Refer to examples of API pioneers
- Strive for small, successive wins
- Be an intrapreneur
- See yourself as an internal API evangelist
- Get top-level buy-in
Your goal is the last point. Only with agreement from the C-level (and perhaps even the board) are you going to succeed. This is going to be a long and expensive process that will not be possible without upper management’s help. How you get that though will require a course of action that includes the other methods.
I will not go into all of these; it would make this post too long. (Keep sending us your thoughts though, and I will make sure they are posted on our blog.) I will dig into one that you can begin with right away at no cost.
Tell the Story of API Pioneers
APIs are not new. They are new-ish, but many people are already doing amazing things with them. To gain mindshare and win allies within your organization, tell your colleagues about what these pathfinders have done. Find cases of organizations in the same industry, of similar size, and operating in the same market. If you can find a very close match, it is likely that they are a direct competitor. If you want to motivate your company to quickly make a platform move, explain that the competition has already launched an API. Tell your coworkers that only by becoming a platform can you outflank the competition. I have seen cases where this argument was all that was needed to quickly start companies down the API platform route.
To help you with this, here are a few resources about platform-based and API-driven businesses that you can refer to:
To hear directly from SoundCloud, join us in October when Erik Michaels-Ober, the company’s Developer Evangelist, will present firsthand.
Internal Evangelism & Intrapreneurship
Entrepreneurship and API evangelism go hand in hand. The qualities of an API evangelist are very similar to a technology founder, says Brandon West, API evangelist for SendGrid. The external type of evangelism Brandon is talking about though comes at a point when the company needs to market its APIs to developers. By then, APIs are an important part of the company’s product strategy. Before that, internal API evangelism is going to be needed. The work will be somewhat similar though.
You will need to network like your life depends on it! Mingle with engineering. Attend company parties with project managers. Go jogging with salespeople. Each lunch in the canteen with the support folks. Take product managers out for sushi when you get sick of the cafeteria food. Tell them all about the massive shift the world is undergoing, and how APIs are making organizations more programmable. Use examples of other API platform companies like the ones above to explain how APIs are disrupting entire markets.
Create an Internal Newsletter & Blog
Everyone has to eat, but lunching will not scale. To reach more people, publish articles on your business’ internal blog. Compose a letter and send it to coworkers every month or so — an internal newsletter of sorts. Try something like this to get started:
Check out these useful API resources for ideas of what to include in future mailings.
In everything you do, aim to motivate, inspire, encourage, and lead.
The Technology of API Platforms
Building a platform requires new technologies to be deployed. What exactly these are will very depending on many factors unique to your organization. In general, however, the following advice should be considered:
- Reuse existing IT investments, systems, and processes
- Build on open, international standards that have broad industry adoption
- Avoid vendor lock-in
- Follow best practices and industry norms
Reuse IT Wherever Possible
The only way to become a platform is to extend and reuse the technologies that you already have. These are working and helping your company earn its precious revenue. To abandon them is folly, but they are most likely ill suited for direct usage by platform consumers. Instead, these will have to be abstracted and adapted to alternative access methods. The general pattern is to obscure them with an API Integration Service. Such integration software will orchestrate and transform existing services that were designed for another era into virtual APIs that can be consumed by modern, mobile and cloud-based consumers. By forming an integration layer that transforms incoming content, an API Integration Service pivots the data format from old world to new world, from modern to legacy.
Transforming content is only part of what must be done to repurpose legacy IT systems. The other is the identity of the consumer. You will almost certainly have to adapt the security model exposed to new third-party API consumers to the ones employed by your legacy systems. This is usually done by a different entity called an API Security Service. This gateway brokers the security mechanims exposed on your API to the methods in use by the systems you are abstracting. Practically speaking, this typically means transitioning OAuth and OpenID Connect, which are exposed to API consumers, to WS-Security, certificates, and/or symetric keys that legacy systems support.
The combination of the API Integration Service and the API Security Service form what is called the API Managment System. This is one of three core pillar of any API platform. I will cover these in a future post. Subscribe to our newsletter to be notified of new posts, and catch that as soon as it is out.
Insist on Standards
The lifetime of any successful platform will be long — 7 years minimum. It is not a short-term project. It is a stratic initiative. To make certain that it is future proof, the technologies must be standards-based. This will ensure longevity.
I cannot speak authoritatively about standards for API design; however, I can tell you with full assurance that the security of your API platform should be based on the Neo-security Stack which is comprised of these open, international specifications:
- OAuth 2 for delegated access
- OpenID Connect for federation
- JSON Identity Suite for identities and tokens
- SCIM for provisioning
- ALFA / XACML for authorization
— Lynn Greenwood (@lynngre) March 31, 2014
Avoid Vendor Lock-in
As I emphasised when I was on tour with Nordic APIs in April, it is essential that you avoid vendor lock-in. No one sells an API platform. If anyone tells you they do, they are lying to you! An API platform must be built. To protect your investment and to ensure optimal interoperabily with new and existing systems, you should select best-of-breed vendors that focus on a very narrow part of the API platform. Pure-play vendors always support standards because they have to connect with so many other software components; standards-based interfaces are the cheapest way for them to achieve this. These suppliers are also more innovative and responsive due to their smaller size, and will be quick to upgrade their offerings to meet new requirements that you introduce (if they are generally useful).
“A future-proof platform is standards-based and built from multiple vendors’ products; it does not expose proprietary interfaces, nor is it sourced from one supplier.”
Not only does no one sell an API platform, no one is going to sell you your APIs either. Perhaps that is obvious, but it does mean that you must have a strong competence in software development. If you outsource this development, you are exposing your core competence to someone else. Big outsourcing firms may then hold you hostage or begin competing with you directly. Also, be mindful about using consultants instead of employees. Both can go at any time, but the later are more loyal. You will need them as your platform ages. Incentivize them to stay, and invest in them as well as the platform itself. This may require a reversal of your sourcing strategy, so find allies in HR and management.
Continuing the Conversation
As mentioned above, your internal evangelisation will require you to connect with a lot of different people. Do this externally as well. For example, generalize your internal blog posts and share what you can on your company’s public blog or on your own personal blog. Share those and other ideas on your social networks. Present your ideas at conferences like our upcoming Platform Summit. For more on this topic in the meantime, check out my presentation on how to transform into a platform for innovation and agility. Also, be sure to share your thoughts here in a comment, on Twitter, Facebook, or Google+.