Laura Merling is senior vice president of the application enablement business unit at Alcatel-Lucent. She leads strategy and execution for Alcatel-Lucent’s company-wide push to transform the network into a software platform. Merling’s most recent experience has been as a strategist in transforming companies to API and cloud-driven businesses. Her more than 20-year career spans leadership roles in executive management, business development, and product management in the software and corporate IT sectors.
John Musser is the founder of ProgrammableWeb, the online resource for mashups, APIs, and the web as platform. He is a Seattle-based technology consultant, writer, and teacher. During his 20-year career in software development, he has shipped five award-winning software products in three industries, working with companies that include Electronic Arts, Credit Suisse, MTV, and Bell Labs.
Laura Merling and John Musser of Alcatel-Lucent share how enterprises can use APIs to create platforms from existing assets to unlock new value.
Interview conducted by Vinod Baya, Bo Parker, and Christopher Isaac
PwC: Laura, can you talk about your organization and the efforts that you are leading at Alcatel-Lucent?
LM: Sure. I lead the application enablement organization. The function of this organization is to drive the adoption of the network as a platform. If you could turn the network into a Facebook-like platform, how would you do that? This goal has a couple of dimensions: the API [application programming interface] dimension and the cloud dimension.
My group does all the software and technology development to expose capabilities of the network as APIs. The capabilities could range from the ability to select what cell you run on, to functionality to route calls or access information such as call history. We also provide mechanisms to manage the use of these APIs; we put controls and rate limits on these APIs, normalize the data, establish business rules—including related business models—on the data or service, and analyze the data related to the API itself. We are also tightly integrated with our cloud offering, CloudBand, to provide API management as an embedded service. CloudBand combines dynamic network availability with cross-cloud access.
PwC: Why is creating and offering APIs to others important now?
LM: In many ways, APIs are the building blocks of the digital economy. They make existing capabilities fungible, so that it is possible to use them in new ways, quickly and easily, thereby spurring innovation and new value creation. All carriers have extremely valuable assets that are effectively locked up in their own networks. Such assets include network capabilities, data about QoS [quality of service], subscriber profile information, and call control. These assets can be used to make existing services better or build completely new offerings, to drive incremental revenues, and to enhance a third party or an enterprise brand.
Leading telecom service providers are aggressively using these assets to build deep, broad value chains across previously unconnected market segments. For instance, Facebook recently announced a relationship with AT&T, Softbank, Mobile Corp., Telefonica, and others to provide in- application purchases using carrier payment services. We already have customers around the globe who have demanded that in the next two years, all of our products should have web-based services or RESTful [representational state transfer] APIs in and out of them. That request is not just for our software solutions but for the hardware solutions as well.
PwC: John, you have tracked the growth of APIs for years. APIs have been a part of computing as long as people have been connecting one piece of software with another. Why the new interest now?
JM: There are a couple of primary differentiators with APIs now. First, they are available and accessible over the public Internet. One of the previous methods, SOA [service-oriented architecture], generally was behind-the-firewall web services within a corporation—or sometimes across partners, but classic SOA is interdepartmental and within a single enterprise. The phenomena growing for the last few years is really about APIs being open and accessible to all over the public Internet as the Twitter, Facebook, or Google Maps APIs are.
Another differentiator is that an API is not an SDK [software development kit], which typically is at either an operating system level or a platform level, such as an ERP [enterprise resource planning] system or database. SDKs used a very traditional behind-the-firewall programmer interface into a layer of the software. The difference now is that the layer of software is a website. Typically over HTTP, you access a web service endpoint that belongs to another company. This is a lot easier to do.
RESTful interfaces create a level of simplicity that didn’t exist previously, and simplicity always speeds things up, making integrations cost-effective. One of the challenges with SOA was that it was over-engineered for the complex case, which was only about 20 percent of the use cases. Owing to the complexity, it cannot adapt easily to 80 percent of the simpler cases. APIs today, using RESTful interfaces, make it possible to easily serve 80 percent of the most common use cases. At the same time, the goals of modularity, reuse, ease of integration, and flexibility apply to both approaches.
PwC: Is this largely a change about how you deliver the service or does it influence the business models in the industry?
LM: I see this as a disruptive change. You can view APIs as a toolkit to co-create value, so they have an impact on how value is distributed in an industry ecosystem. All providers need new ways of thinking about their businesses. Now it is possible to see network capabilities digitized and modularized, and therefore open to access and manipulation by programming code. The network becomes a platform for development. It becomes capable of serving exponentially more use cases. In emerging markets where greenfield LTE [Long Term Evolution] infrastructure is being installed, we see providers wanting their entire network to be API enabled out the door for a nationwide broadband network and differentiated value to the ecosystem.
PwC: Are these messages relevant to industries other than telecom providers?
LM: Absolutely. Broadly speaking, all major enterprises have underutilized assets; that is, the existing business models are not tapping into the full inherent value. For telecom service providers, networks are such assets that can create a lot more value if the providers open them up with APIs. Similarly, to fully capitalize on existing assets, other businesses must shift to platform-oriented business models that allow others to extend their capabilities in innovative ways by enabling new applications. This cannot be possible if tapping into the capabilities is expensive, time-consuming, or complex.
PwC: What should enterprises know about using APIs?
LM: One common misconception I see in how enterprises define ecosystems is targeting the long tail developers only. However, platforms that have used APIs successfully, such as Twitter or Facebook, have a small number of API users in the ecosystem that drive the bulk of their traffic. Twitter actually acquired the four top companies that were driving all its traffic. Businesses need to also look for B2B2C [business-to-business-to-consumer] opportunities that are real and can scale quickly.
JM: Indeed, the long tail of developers is an option but not a requirement. The requirement is that your audience for APIs could be anything from your own department by transforming your prior SOA efforts to something more systematic, cost-effective, and flexible. You don’t need to bend over backward just to have an API; you need to think about that strategically. One of my favorite examples is eBay. Back in 1999 or 2000, eBay opened what really was the first API in this class of APIs. Of all the things eBay could have an API for, what do you think it did first? Most people think eBay had an API to search the auction marketplace. Not so. The company’s first API was to add listings to the marketplace, because that was what was strategic. The winner in the auction universe would be the provider with the biggest marketplace, so to eBay, success meant the ability to grow that catalog as quickly as possible.
PwC: What should organizations know to start on this journey?
LM: Organizations need to establish a vision of the ecosystem that they will create or be a part of and what role they would play. This vision is dependent on the existing business model and the assets that organizations can tap to create new value. They also should look for opportunities where they can digitize existing processes, because those processes create the opportunities to expose APIs. Also, any organization that succeeds with an API has a vibrant developer ecosystem. There are many best practices on how to attract and foster a developer ecosystem, and organizations need to learn and adopt some of the best practices. It is important to understand that a developer isn’t always the guy in the garage building the next Angry Birds.
We have done studies and learned a great deal about what makes a developer ecosystem—one that spans casual hobbyists to professionals in other large firms—tick. APIs have been with us for a long time, but in the past they always took a lot of time to use and make work. Now, thanks to emerging practices with RESTful interfaces, developers expect to use their time efficiently. The easier it is for them to tap into your assets, the more they focus on creating value-added capability and bringing it to market quickly.
PwC: Are there any guidelines for where CIOs can focus first?
JM: One easy way is to look at your existing portfolio: what’s on the plate now, and how can any of those high-priority projects that are either in development or about to get under way benefit from an API? In today’s marketplace, anything to do with mobile is a natural candidate. Who doesn’t have a mobile strategy right now? Nobody. CIOs should take anything to do with mobile and make sure it is integrated with a platform strategy, because they’re such a perfect and natural fit.
Also, CIOs should understand that using APIs is an architectural choice and not a technology choice. Organizations can build a platform using whatever their core technologies are. If they are a Java or Microsoft shop or something else, there’s no need to change the core. The concepts are neutral regarding language and implementation platform. Organizations can use whatever stack the enterprise prefers and may have a mix of them as well.
PwC: Are there any risks to be aware of?
JM: For CIOs right now, it’s more important to be API literate than to be API ignorant. In the future, you’re not just going to produce APIs, you’re going to consume them. If you use a single cloud service, just one, your team needs API literacy, period. API ignorance is a risk that no CIO wants to be accused of a couple of years from now.
CIOs are going to need to know how to integrate services in the cloud. They’ll need to understand how to deploy using APIs, because there will be some project that they must run on the VPN [virtual private network] version of AWS [Amazon Web Services]. If the CIO’s team doesn’t understand this market and it’s waiting for things to settle down, good luck in your new job because it’s not going to be here. Your competitors are going to eat your lunch by being more nimble and agile and not necessarily waiting for things to mature or standards to emerge.
PwC: Where do things stand with respect to the use of APIs internally or externally?
JM: Most of the action today is in external use, but I think it’s going to be bigger inside the enterprise. I feel there’s a much larger universe of private APIs and their usage than there is of public API usage. The two flavors of private API—for internal companies or for a company’s partners—constitute the part of the iceberg that’s under the water and the tip of the iceberg represents the public APIs. The real body and meat of the API universe is hidden. This is where a lot of the value is, because you can be more adept and agile and get better ROI [return on investment].