Apigee Blog

Why APIs? Anatomy of an Internal API Initiative

2012-05-29T16:55:46+00:00

In a recent post, I made the argument that the key to bridging the gulf between IT requirements and those of the new app economy is an API.

We categorize the API initiatives that support the app economy in four flavors - Internal, Partner, Customer, or Open - according to the different roles that app developers can play.

So what does each of these API initiatives look like? What are common scenarios in which you see them employed and how do you align your business goals with a particular strategy? Let’s start from inside a business with an Internal initiative and work outwards to the Open initiative.

We've observed that many successful API initiatives are done in stages. With each stage, businesses can build on previous projects, and assume more risk and larger investment more easily.

Anatomy of an Internal API Initiative

Loners: One of my favorite use cases for the internal scenario is what I call “Loners”. There are many organizations within a company in which there are no developers – that is, no technology people to make an app. But these organizations often have budget to hire developers to build apps. For example, a marketing department can often take the budget they may have applied to creating Web pages in the past and redirect it to building apps based on APIs. This can give quick wins, but can also leverage the marketing expertise to help gain acceptance for a new strategy and your API initiative.

Cross Departments: APIs solve the problems of keeping things secure and providing easy access. These are common concerns even internally - when departments are trying to work together to create new value for an organization. Today, cross-departmental initiatives often involve big program management apparatus and onerous processes.

If businesses followed the archetypes of open APIs within departments, they could do a lot less planning, a lot more doing. (We’ll look at the Open initiative in detail later, but for now think Twitter, Foursquare, or Facebook at the archetype.) It would be as if businesses thought of the Twitter ecosystem as one company with developers building Twitter apps in different departments. What level of reuse or value could developers take from existing internal systems to their new initiatives? The answer is 100%.

Making IT more productive

Systems of record have both vices and virtues. The most important virtue is that they make money. If you’re in the hotel business, it’s your reservation system; if in finance, it’s your stock trading system; in the automobile business, it’s your system to sell vehicles and predict economic cycles.

Systems of record are also stable. Because they’re stable, they are also often slow moving and don’t allow for core systems to keep up with market evolution. By thinking as a platform – by putting APIs between the systems of record and the apps – you can achieve agility and flexibility and take advantage of the stability of those systems.

IT has tried to do this several times through history - most recently with Service Oriented Architecture (SOA) and with mixed success. With APIs we have strong archetypes and businesses are proving success with API-based platforms.

Next time, we’ll look at the anatomy of a partner API initiative.

Why APIs? Bridging the Gulf between IT and the App Economy

2012-05-24T15:08:12+00:00

In my previous post, I talked about the challenges of ubiquity and an explosion in consumption driven by the threesome of cloud, social, and mobile apps. Businesses need to effectively target and support their customers and partners in these new contexts.

This time, what do the forces of cloud, social, and mobile apps mean for the way businesses create, evolve and offer apps, data, and services? What does it mean for IT? How to bridge the gap between IT requirements and those of the new app economy?

The big bet of yesterday; the many bets of today

The traditional axiom is that IT resources are scarce and expensive. This resulted in the creation of big budget IT projects and many high-risk projects – some of them long-term, measured in years. There were obviously big successes but there were also many over-time and over-budget project failures.

There’s a new way of viewing all of this, which was pioneered by Amazon and Google and expanded upon by companies like Facebook. The core principle is opposite to the one we saw previously. In this world, IT is increasingly cheap and ubiquitous. Budgets are iteratively assigned and success criteria define whether projects moved forward.

In this “fail fast” philosophy as defined by former Google CEO Eric Schmid, “it’s better to launch and iterate; to fail fast and learn from your mistakes, than to spend years in planning and end up miles off the pace.” Getting to failure more quickly means that you can move on and assign budgets to other projects more quickly. The result is smaller, more focused projects.

From a direct to an indirect model

How do companies accomplish the “fail fast” strategy shift? In essence, it’s a shift from a direct model to an indirect model. It’s about a technology shift to APIs that allows you to create a platform.

Fundamentals of the app economy and the role of APIs

In the past, a business was in good shape if it provided a Web site. Today a company’s data or services need to be consumable by a wide array of application clients – from the 2 ton client – the car which is increasingly more connected - to internet TVs, gaming consoles, and handheld mobile devices. APIs power it all.

People are demanding apps because other people are using them and because companies are providing functionality through apps. Given the hundreds of apps available on app stores for every platform, the app store is a competitive place. App developers are the key people behind the supply side of the app economy. Their creativity, technical know-how, understanding of the marketplace and customers is what makes apps successful.

Companies who want their brand and value proposition leveraged through apps to consumers understand that there’s value in their internal systems and that they can and must participate in the app economy in the same way as they participated in the Web economy in the last decade.

However, an app developer cannot simply access a typical internal system at a Fortune 500 company. Providing such access is a very deliberate and thoughtful proposition on the part of the business.

While social, mobile, and cloud services empower businesses by allowing developers to access corporate data and interact easily, IT departments still need to be concerned with security, compliance, rapid changes, and a myriad of other things.

The key to bridging the gulf between IT requirements and those of the new app economy is an API.

Just as the app store is competitive, the world of APIs is competitive. There’s much value to be created if app developers can leverage a business’ internal systems, meaning that many APIs compete for the attention of the app developer.

Several flavors of API strategies support the app economy. We categorize them as Internal, Partner, Customer, or Open and according to the different roles that app developers can play.

Essentially we ask whether the app developer is internal to your business, in a partner’s business, at a customer’s company, or an independent developer in the wild.

Next time, we’ll delve into the anatomy of each of these API strategies, starting with an Internal Initiative.

New Consoles & V2 Console To-Go

2012-05-23T16:39:00+00:00

Time for a quick recap of what's new and improved with Apigee Consoles. First, there are five new Consoles, bringing the total to 75 Consoles!

Heroku Pinboard MailChimp Weather Bug Flickr

We've refreshed the API definitions for 12 consoles including: Delicious, Fitbit, Google AdSense, MySpace, NYTimes, Reddit, Ruby Gems, Salesforce, SendGrid, Spotify, Twitter, and Yahoo Weather.

We've also fixed some problems and restored full support for Internet Explorer 8 and 9.

Google-style queries
In addition to being able to easily search an API’s methods in the v2 Console, you can now search filters for resources using a Google-style query. For example, verb:pu filters all the PUT operations and category:comp shows just the methods within the Company category. See the example below from the LinkedIn Console.

v2 Console To-Go
We are well on the way to enabling our v2 Consoles To-Go! You can include any existing console in v2 with the following code:

<iframe src="https://apigee.com/embed/console/bitly?v=2" height="100%" width="100%" scroll="no">

Here's the Bitly Console

Write a WADL for your Apigee Console

We are still working on updating the to-go console configurator for v2 but you don’t have to wait to switch a console to v2. To help, we have created a new guide to writing WADLs for Apigee Consoles.

If there’s an API that you would like to see added, or if you have a To-Go Console of your own, let us know. We would love to feature it on our providers page.

Why APIs? On doing Business in the Full Context of Customers

2012-05-22T21:50:28+00:00

We received some strong interest in our recent webcast Why APIs in which we explored why APIs are important to successful businesses and the different API strategies (Internal, Partners, Customers or Open) we see employed. So I thought we'd drill down into the core ideas in a few blog posts.

What challenges are businesses facing in 2012?

The three major trends of social, mobile, and cloud in the market today are driving huge changes in how individuals connect, how businesses connect, how businesses engage with their customers and employees, and therefore how Information Technology (IT) works.

According to analysts at Canalys, at the end of 2011, smart phone shipments outpaced PCs (including iPads) for the first time - smart phone units shipped was up 63% from 2010. Gartner estimated that 18 billion apps were downloaded in 2011, up 114.5% from 2010 and will rise to 31 billion in 2012.

According to this IDC study in 2011, the use of consumer-inspired social media such as Facebook and Twitter is also growing fast: almost twice as many information workers said they were using these technologies in the workplace in 2011 as the previous year. IDC also predicts that the market for Big Data technology and services will reach $16.9 billion by 2015, up from $3.2 billion in 2010. That’s a 40% growth rate year-over-year.

The “consumerization” of IT is happening fast thanks to each of these trends individually but even more because of how these trends are playing out in concert in the marketplace. The effects multiply to drive ubiquity and an explosion in consumption.

A strategy for the explosion of consumption

Think about a person sitting watching TV, while using his iPad to keep up with friends on Facebook, while browsing coupons on his Groupon email alias. Or consider the businessperson waiting for a flight using her Android tablet to check her social network on LinkedIn while accessing salesforce.com to forecast her sales pipeline.

These scenarios, and dozens of others like them, represent a fundamental shift in how customers are interacting with businesses. It’s no longer interaction through a Web site but through apps on numerous devices and platforms, social media, and cloud services.

The question on the provider side becomes whether businesses have a strategy for the explosion of consumption and whether they are doing business in the full context of customers and consumers. It’s always an imperative that businesses align investments with their customers.

Doing business in the full context of customers

How does a business effectively target and support the consumers in our scenarios? Let’s look at how apps are built in a typical enterprise. It’s common for the initial requirement for an iPad app to come from the executive office or from a marketing team. A business might start by developing an app with one of their products, a partner, a social network (say, Facebook), and a cloud service (say PayPal). The app is built and all is well.

Then they realize that there’s also a user base on Android so they build it again on the Android platform. Then they realize that they should target another social network. So they build again. And again and again to target more social networks, products, partners, and cloud services. Quickly, there’s a plethora of apps targeting different platforms, different services, different partners, and different products.

The order of magnitude increase in resources to support different browser types in the mid 1990s (to facilitate exposing internal systems via the Web) is happening again. Today, support is needed for different app platforms – different versions of Android and iOS, and so on.

Clearly, important changes need to happen in how we build our apps so that we can effectively and efficiently do business in the full context of customers.

Introducing APIs

The cloud, social, and mobile app phenomenon is stimulating an explosion in the API economy. Frequently when a mobile app user clicks a button to do a transaction (send messages, make trades, get credit information, and so on) or sends or retrieves data, an API – either transactional or data - is called. My colleague Anant describes transactional and data APIs as the Ying and Yang of APIs. He posits that while the API conversation is dominated by transactional APIs today, a revolution is underway in the world of Data APIs because of the requirements for easy consumption, flow, and interaction of data in a world of big data.

Next time, we’ll dig deeper into how APIs are the answer to handling mobile and social ubiquity and how they bridge the gap between IT requirements and those of the new app economy.

Innovator Spotlight: TradeKing - Using APIs to Deliver Next-Generation Trading Experiences

2012-05-22T16:09:31+00:00

TradeKing is a nationally licensed online broker/dealer dedicated to empowering the independent, self-directed investor. The TradeKing platform features powerful online equity, options, ETF, mutual fund and fixed-income trading tools, along with a rich set of news, research and analysis capabilities.

Dan Raju, TradeKing's CIO, talked to us about how the TradeKing API is serving as a core element of the firm's strategy for delivering the next-generation trading experience for traders and fueling the company's growth.

How are you using APIs today?

When we launched our API last year, we were one of the first brokerage firms to offer a simple REST-based API. Our API is an absolutely critical piece of our infrastructure now, promoting efficiencies and innovation across every channel: from our website and other internal systems development to our external partners and the broader app developer community.

We've made our API available so that the development community can do any possible mash-up of our services– and they are. This level of integration and innovation we are seeing is something we could never have accomplished by ourselves this quickly.

What kind of business benefits have you experienced as a result of your APIs?

We get a million plus calls every day on our API, and a growing number of partners have built their platforms on our API. We also have individual traders who write apps or trading algorithms for their own personal use.

Everyone has his or her own personal way of trading, and the API opens up endless possibilities for traders to define their own experience. In a couple of months, we'll be launching our own app gallery to showcase the apps developed by business partners and developers with our APIs. We are just scratching the surface now. We think in the next 12 months, we'll have a much larger set of partners on top of the API. All this is benefiting our customers by offering them a greater set of choices they never had before.

What has helped you promote developer adoption?

To attract a wide array of developers, it is crucial to offer a simple yet rich API, so that’s what we have done. We couple that with good developer engagement - extremely good and continuous engagement. Developers then grow into partners and traders or create trading experiences that benefit our customers. We believe TradeKing offers the most secure yet simple API in the marketplace. We've also conducted incentivized virtual hackathons and crowdsourcing initiatives, which have been very successful. This past fall, we conducted an extremely successful API Campus Challenge program, in which we encouraged undergraduate students to create platforms on our API. Young brains from colleges and universities all across the nation participated to create amazing apps.

As a part of our overall API growth strategy, we also provide special pricing discounts for our API Partners.

How do you work with Apigee?

We built our API platform on Apigee Enterprise, and then we customized it to meet our requirements. Initially, we considered developing the entire API ourselves, but we decided to keep our primary focus on the core of our business, delivering a great brokerage experience for our customers, and draw on Apigee’s expertise to help develop our API platform.

Because we are in the financial sector, security is of the utmost importance. Apigee's platform delivers excellent security features and is very customizable. In addition, Apigee's staff worked with us in many, many ways, helping us think through APIs as a technology platform and helping us build the delivery platform itself.

In our view, it comes down to three things: response, understanding customer needs, and relationship. Apigee delivered on these and has been a very valuable partner.

What is your vision for your API program?

We are one of the top-ranked online brokerages in the country, growing very rapidly. We manage people's assets, give them a set of capabilities to trade, and offer an extremely transparent pricing structure. However, we recognized that our customers’ demands for next-generation interfaces are rapidly changing, and our API helps us stay in front of that.

We anticipate that in the next phase, the API will be a meaningful revenue driver for us. It is already opening us up to new markets.

We will continue to develop our own platforms on the API and incentivize and engage our development partners. At the end of the day, it’s all about delivering value to our customers, and the API will continue to help us drive increased value at an accelerated pace.

Apigee on the Road - update for NYC Fashion Hack Day

2012-05-18T15:49:54+00:00

Time for a quick recap of when and where you'll find us in the coming months.

We will be in full force at GlueCon near Denver next week, with two presentations. Ed Anuff, creator of Usergrid, will talk about the perils of designing a massively multiuser app platform (Breakout 2, 1:45pm on Tuesday May 22).
Sam Ramji, our VP of Strategy will talk about the balancing act of control & performance in the face of mobile devices and API-powered ecosystems (Breakout 3, 4:50pm on Tuesday May 22).
We will also have a booth and we’ll be using it to help people create their first mobile app. Come say hi and walk away with your first app on your device, in under 10 minutes.

In June, you can find us participating & sponsoring the AT&T Mobile App Hackathon (Education Edition) in Palo Alto. The event will focus on creating apps & mobile apps that benefit our education system. Apigee will be rewarding the best Usergrid use case with $1,000 in Best Buy gift cards, as well as accelerator prizes if you open source your app or release it for free on the app store. The event page has all the details you need to get involved.

The following week (on June 16), we will be co-hosting the NYC Fashion Hack Day with Gilt & Tumblr. The event will take place at Gilt’s beautiful headquarters in New York and will focus on fashion app & use-cases. We will offer another $1,000 prize for the best Usergrid app, and give participants access to a wide array of iOS, Android and Windows Phone 7 devices (and an NFC devkit) so they can test their apps against the latest & greatest platforms. Sign up now while there are still seats left!

I will be at the Community Leadership Summit in Portland Oregon on July 14–15, rubbing elbows with Community Managers, Evangelists and Developer Advocates from around the world.

Finally, our own Nate McCall, Sr. Software Developer, will be at OSCON in July, talking about Test-Driven Development with Apache Cassandra , the database that powers Usergrid.

As always, we will post links to video recordings of our road appearances here or on our twitter account when they become available.

APIs and Copyrights: Monopolizing Ideas or Affording Protection? (video & slides)

2012-05-17T01:30:29+00:00

Thanks to all who participated in last week's Webcast, APIs and Copyrights: Monopolizing Ideas or Affording Protection?

The video, slides and a summary of the panel members' closing statements are below. Thanks to our moderator @brianpagano and the entire team for a lively and informative discussion. We'd love to continue the discussion on the api-craft forum.

APIs & Copyrights

View more presentations from Apigee

Panel Closing Statements

Here's the essence of the panel members' closing statements. Going 'round the table -

@landlessness When you provide an API , be explicit about the license terms you want to apply.

@jhingran Respect the ownership of whatever you're exposing with the API - for example, the data. What you are exposing is as important as the APIs.

@edenuff As API provider, state your intentions clearly as part of your license. As a consumer of the API (a developer), pay attention to the license. If openness is important to you, choose the APIs you use based on openness.

@earth2marsh We tell people to copy patterns all the time when we talk about Web API Design. I don't think we will change that practice. For example, /me is a pattern I use all the time. I think Facebook invented it. I'm going to continue using it because it's very effective.
You need a certain amount of copying for it to be a violation… How much partial use matters? How far do we take this?

@gbrail Be aware of what you're using and what you've implemented.
Check the license. Know what licenses are in the software you build, and in the APIs you consume and produce.

@samramji We might not like the expansion of IP law, but we can only blame ourselves if we are harmed by ignorance.
The expansion of these laws will depend on community practice; on expert witnesses saying what they think. Talk to other developers, discuss, debate, blog etc. Be in the conversation so we have some common sense to fall back on if needed.

Innovator Spotlight: Innotas

2012-05-16T00:54:53+00:00

Innotas is a leading provider of cloud solutions for IT Management. The company helps IT managers align their resources, budgets, and time with strategic business objectives through the Innotas Project Portfolio Management and Application Portfolio Management solutions, both delivered as software-as-a-service (SaaS). Since it was founded in 2006, Innotas has been committed to helping CIOs and IT management gain visibility across initiatives and sustain existing operations.

Tim Madewell, Innotas senior vice president of services, spoke with Apigee about the Innotas API and how they use Apigee to gain critical visibility and make better business decisions.

What is Innotas' API strategy?

We offer an API that is different than many APIs today. Instead of using an API to expose our back-end data or Web services, the Innotas API was built to enable our customers to easily integrate the Innotas IT governance solutions with their back-end CRM, HR and billing systems. Providing an API where customers can ‘come and get it’ has worked especially well for our large customers, who often have the resources to take the API and run with it to make the integrations happen. We also now offer a turnkey platform in which we build and maintain the integrations for our customers.

What opportunity were you addressing with this API?

We had a compelling event – a customer needed it. In the early days of our company, our average customer size was 25-30 users. But as we started to grow and the SaaS market became more mature, we started working with larger enterprise customers that required a level of integration with their back-end CRM, HR, and billing systems.

So we published our API to meet the needs of a large division of a F1000 customer. In hindsight, offering an API for integration was a great decision early on - it gave our customers a lot more flexibility, including writing the process orchestration around our API to meet the specific requirements of their organization.

How has the Innotas API evolved?

We offered a SOAP API as the first version, but now we’re evolving. In August of 2011, we launched our integration platform where we will build, deploy and manage the integrations for our customers. Our new platform will be powered by REST APIs.

How do you work with Apigee?

Apigee is our API cockpit, where we can view and manage details about our APIs, and use this information to make informed business decisions. We started working with Apigee Enterprise shortly after we published our API to give us visibility and control over our API usage and provide a consistent level of service to thousands of clients on a single SaaS platform.

Initially, we were primarily using Apigee Gateway as a solution to help us understand who is making API calls, what entity they are hitting, how often, etc. This detailed visibility into our API usage helps us quickly triage and troubleshoot as required. Over time, we extended our use of Apigee to include load balancing and analytics.

How do you Use Apigee Analytics?

Apigee's real-time analytics is my executive dashboard for operations. I use the analytics all the time see what's happening – it's the first place I go to see integration traffic, even before I look at my real-time monitors. Just yesterday an outage triggered, and with Apigee's analytics, I could identify the root cause in about a minute.

One of our key requirements has always been visibility…you can’t govern what you can’t see. Before we started using Apigee's analytics, all of our customers' activity was intermingled in the system logs with all the other system-generated events. Figuring out who is doing what was almost impossible and it was difficult to track back the events that were related off of just a user ID – which is the wrong key. We needed the visibility to be able to relate calls together and construct what happened with meaningful data.

Once we had this, our second evolution was around maintenance and support. Before, when a customer called and said “it’s not working right” all we could say was “go look at your code.” But with API analytics we can capture the payload – trap the data for the customer – and use our API debugging tools to help them ID the problem message.

We also use API trend reporting at a macro level over time - common calls, common integration. This gets fed into product management, sales, and performance tuning to make the product better.

What benefits have you gained from Apigee?

Apigee is our eyes and ears for our APIs. The visibility we get into customer usage has definitely enabled us to better manage costs and efficiencies. The daily Apigee data help us understand customer stickiness and retention – which has helped us maintain a consistent 90 percent renewal rate. And understanding customer usage trends and patterns has absolutely helped us make more informed business decisions.

Big Broad Data: The role of Data APIs

2012-05-08T21:43:08+00:00

In previous posts on this topic of Big Broad Data, we looked at some of the reasons for and implications of enterprises shifting their focus from the “bigness” and technology hype of “Big Data” to breadth and diversity, signal extraction, analytics and deep insights.

The future is around the easy consumption, the flow and interaction of data, which drives a revolution in the world of Data APIs. The structure of the Data APIs becomes increasingly important.

Building an Information Halo around APIs

Let’s consider enterprises as one of two types from a data perspective: those for whom data is the core business and those who give data away to attract increased transactions to the core of their business.

In the latter case, the data (information) itself is not necessarily monetizable, but it attracts people to the business.

For a great discussion about the notion of information halos around your core business, see Sam Ramji’s talk: Amundsen’s Dogs, Information Halos and APIs: The epic story of your API Strategy.

In both scenarios, data is a fundamental and critical part of an API strategy

Enterprises who are monetizing around data are beginning to plant flags in different domains. Weather, finance, real estate, Internet traffic and dozens or hundreds of other domains are forming.

The people building the data in any domain are doing so by collecting from disparate data sources. To build out any one domain, they’ve probably stitched together data from a large number of data sources, cleansed and standardized it before finally exposing it as an API.

What are companies using to collect and stitch the data?

A natural and familiar stitching technique is the linked data model (linkeddata.org). While linked data techniques are excellent at accessing individual data elements, I argue that this is not the model that these data providers need. Instead they need to crawl, bulk load, and access data in large quantities, before cleansing, standardizing, and delivering it.

If linked data is not the most effective method to stitch data together to create the domains (at the bottom of the stack), can linked data become the de-facto standard to express data out of the information halo (at the top of the stack and as the Data API for domains)?

The answer is probably yes – eventually. I think it is an unlikely scenario just yet. Today, the challenge is how to cleanse, standardize, unify and use the data in individual domains. Linked data techniques have the right characteristics to bring together data that have already been cleansed, standardized, and stitched but is not a great model to do the initial stitching. It will most likely become useful and common in the future when the inter-linking of domains becomes more important than it is today.

If linked data is not the approach to expose data as APIs, what is?

The school of thought to which I subscribe is one of schema-based access to data APIs patterned after relational models. Here are a few examples of data APIs, which highlight three common kinds of data access patterns.

* Primary key lookup - to get to a specific data element.
* Imposed hierarchy-based lookup - in which you have classes with hierarchy and in effect traverse the hierarchy to get to the data elements.
* Rectangular lookups - defined by typical relational lookups of rows and columns.

All of these techniques are being built around single data sources as opposed to massively linked data sources.

The structure and “RESTification” of Data APIs

There are several approaches to Data APIs. In addition to the perspective that is Pragmatic REST for SQL Developers, there’s Microsoft’s OData approach. As I asserted in a recent talk at an OData Meetup event at Microsoft, OData is a step in the right direction but there are certain things OData needs to do to become the de-facto standard.

The “RESTification” of the Data APIs is a fundamental imperative and both the Pragmatic REST for SQL and the OData approaches are good starting points.

Whatever the solution is, it cannot be vendor specific. Data is too important, and the data revolution too fundamental for it to be associated with any one vendor.

OData technologies need to be available in all ecosystems, not just in the Windows Foundation Classes (WFC) library and the .NET Framework. Similarly pragmatic REST and other techniques cannot be available in Apigee or any other single vendor offering only.

Let the call to action be to come together as a community; get the best of the linked data and OData ideas and techniques together and transform the world with Data APIs.

The conversation has already started and we’d love to hear more of your perspectives and arguments over on api-craft.

Innovator Spotlight: Pearson Plug & Play Platform

2012-05-08T20:52:38+00:00

Today we are proud to publish our first "Apigee Innovator Spotlight" featuring Diana Stepner, Head of Future Technologies at publishing giant Pearson. Apigee Innovator Spotlights will be a regular series of interviews with API experts sharing their experiences, strategies and best practices for innovating through APIs. Look for more soon!

Pearson is the world’s leading learning company. Pearson delivers content in a range of forms and through a variety of channels, including online services, ebooks, books and newspapers. It provides consumer publishing through the Penguin brand, educational materials and services, and business information through the Financial Times Group.

Diana Stepner, Head of Future Technologies at Pearson, discusses how Pearson, through the developer platform Plug & Play, has opened up some of the company’s award-winning content via APIs to foster the development of innovative new applications.

How are you using APIs today?

We're using APIs at Pearson to connect with developers, whether internally within our companies or externally. APIs are used in many different ways throughout Pearson. Some Pearson APIs are for internal development and others are for working with our partners. The Plug & Play platform is focused on delivering APIs that are available to third-party developers as well as internal teams.

The Plug & Play platform makes Pearson data available for developers to build new, innovative products that incorporate novel ways of using, displaying and blending Pearson content with other material and data.

The goal of the Plug & Play API program is to spawn innovation, connect with new audiences, and make it easier to create apps with Pearson content. Also via Plug & Play, we hope to explore new revenue opportunities.

What need were you addressing with your API strategy?

The world is changing -- becoming more open. There has been an important shift in the ecosystem around us, and APIs are becoming the norm. Companies are using them as the foundation of their development. We saw this as a big opportunity for Pearson.

How have your APIs evolved over time?

Initially, we offered three APIs: the DK Eyewitness Guide API, which provides access to information about the top sites and attractions in nine cities (London, Barcelona, Berlin, New York City, Berlin, Paris, Prague, Rome, Venice and Washington); The Longman Dictionary of Contemporary English API, which provides access to the flagship Longman dictionary; and The FT Press API, which delivers insights from high caliber business books and original writings by leading business thinkers. Later, we added the The Pearson Kitchen Manager as a resource for food enthusiasts and chefs. Developers can go to the Pearson Plug & Play portal to explore and use all our APIs. We’re also expecting to add more APIs shortly.

In terms of the technology evolution of Pearson's APIs, we've been listening to feedback from developers, and they've been asking for more flexibility. In response, we've made changes like moving from a traditional relationship environment to a solution NoSQL based solution based on MongoDB. Also, sometimes the content we get is not as rich as it should be, so our developers are working with the businesses to augment the content we use to build APIs.

What kind of business benefits have you experienced as a result of your APIs ?

One of the key benefits we've seen by offering our APIs is a change in the perception of Pearson. We have been looked upon as a traditional publisher. Our goal is to be seen as an innovator in the digital world and part of the developer ecosystem. We participate in developer-centric events and are hearing the awareness around Pearson’s activities changing – to be more thought of as a forward-thinking company.

Our API initiative has driven some important benefits internally too. Now, there is more focus on making content available. At the end of a production cycle, we want to make sure there's an asset – an API. Or better yet, we want to start with an API! But there's definitely an increased focus within Pearson on making our content more available for developer access, internally and externally.

And of course, we are excited about the applications being built with Pearson’s content.

How do you work with Apigee?

We use the Apigee Enterprise platform -- specifically the Apigee Gateway, Key Management and Analytics products. Apigee Enterprise provides management and control of traffic flow, analysis and control of API usage, data security and protection, and support for scaling and performance with caching.

Pearson also uses Apigee Developer Connect for developer lifecycle management. This allows Pearson to engage and enable the developer community, and developer tools make it easy to explore and use Pearson APIs.

In the beginning, Apigee also gave us a lot of guidance to get our APIs up and running. Apigee's expertise was invaluable in helping us identify and establish API best practices, and we worked very collaboratively with them.

What is your vision for your API program?

For us, the ideal scenario would be that as soon as someone starts working on a project in Pearson, they think about how to offer a supporting API. We want to ensure a constant flow of content into the Pearson developer platform so it can remain a valuable resource for developers to tap into and get inspiration to build things we never would have thought of.