2 Changes that will Transform your Business into a Platform for Growth Travis Spencer July 24, 2014 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: [table-wrap bordered=”true” striped=”true”] Organization Industry Size Market Amazon E-commerce Large Global Fyndiq E-commerce Small Sweden Pearson Education Large Global PlanMill Technology Small Europe Salesforce Technology Large Global SoundCloud Entertainment Small Global Spotify Entertainment Medium Global Twilio Telecommunications Medium Global [/table-wrap] 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: Initial Mail Mail about Security Mail about Growth Initial Mail Hi All, I have been reading and thinking a lot about how our company needs to become more of a platform on which others can conduct their business. By focusing on our core and exposing our key capabilities and data, others will be enabled to create higher-level value than we alone can provide. I have talked with some of you about this in the past, but thought it would be great to send out an email every month or so to keep the conversation going. As mobile, cloud, and social make way for the Internet of Things (IoT), wearables, quantified self, and other new tech-centric possibilities, our company has an immense opportunity. By extending our use of APIs, we can become the basis on which partners and even the general public can create new innovations that we cannot dream of. This will give us a central position within a growing ecosystem which will ensure on-going growth. To achieve this, I believe we must: Follow the example of early adopters like Twilio Learn more about APIs Form a working group that can discuss this topic on a regular basis Attend the upcoming Nordic APIs Platform Summit What else should we do? Please reply with your thoughts. Next month, I will address the security issues that a platform move could impose, and talk about how we can overcome those. Till then. Mail about Security Hi Again All, Last month, I emailed you about the importance in growing our API program and transforming our organization into a platform. Nordic APIs has a helpful blog post with more on that topic, and we had some great internal conversations as well. This month though, I wanted to write about one of the hardest parts of building an API platform: security. There are a few very important security aspects of any API platform. In general, we must ensure that our platform is secured: With open standards that have broad industry adoption Using common algorithms that have been scrutinized by expert cryptographers Using pure-play products rather than home-grown software or heavyweight alternatives It is important as we grow our API platform that we leverage existing systems to implement the desired functionality. This will require us to broker the security of our API to the models used by our existing systems. I have read that this should be done in the API Security Service. This gateway will stand in front of our existing (and new) APIs, and will transform the incoming security model to our legacy ones. The model we expose outwardly should be OAuth 2 and OpenID Connect, suggest API security specialists. To get this setup, we should talk this month about: What security models do our existing services use? How can we transform OAuth into that? What are the requirements of any API Security Service software that we may need to procure? Do we have any software already that does this or something like it? Do we need change the network topography to allow for secure access to our APIs? How will the API Security Service fit into our deployment? Do we have expertise in OAuth 2 and OpenID Connect? Will we need help from outside experts? If so, who? To lean more about this before we meet, check out these resources: Nordic APIs security positings How security gateways help protect APIs API Security Services in context of a broader solution Next month, I will share some thoughts on how becoming an API platform will grow our company at a tremendous rate. Till then. Mail about Growth Hi All, Over the last few months, we have been talking about the need to transform our company into a platform. I touched on the security challenges of this in my last mail, and we have discussed others in our meetings. As more and more people have joined the discussion, I wanted to write this month about how a platform can enable hyper growth of our organization, and get all of your feedback. What is the difference between providing an API and being an API platform? One distinction that occurs to me is that a platform enables others within the value chain to create higher-value products and services using the base capabilities of the API provider. We are already doing this in other aspects of our business and with our APIs (to a degree), but we must become a platform to scale this way up. If we expose our core capabilities and data through our API platform, others will combine our unique value proposition with their own. If we allow them to do this in an automated fashion, the resulting combination will be more valuable to a larger market than we are able to service on our own. Self-service capabilities will ensure that our costs for this remain low as consumption increases. By providing a critical component of these higher-level offerings, we will position ourselves at the center of numerous other organizations’ product strategies. This will give us a larger and larger market reach, resulting in more and more growth for us. If we can achieve a critical mass, our API will provide us with tremendous growth. How we scale our API into a platform is a question that we need to explore more as a group. Please reply with your thoughts, and let’s find some time this month to meet and discuss. In the meantime, have a look at these resources: Transforming your Business into a Platform for Growth The Dangers of Ignoring the API Revolution An OAuth-protected API Platform for Private, Partner & Public Use The story of Fyndiq’s API Till next month. 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 Neo-security stack #nordicapis @travisspencer pic.twitter.com/4fBcbuWULr — 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+.