Most companies are still tiptoeing into APIs. Pearson has taken a much more aggressive approach, making big strides on API management under the leadership of Allen Rodgers, the Director of Pearson’s API Program for Higher Education.
At Apigee‘s “I Love APIs” show, I got the Pearson API story from Rodgers firsthand.
In the late 90s, Pearson could see that their industry was about to undergo an upheaval that would leave them behind if action wasn’t taken. Pearson’s leadership decided that being a print-based learning company was a losing proposition.
Converting to digital publishing and e-learning was the new imperative. Digital business has been a guiding theme in Pearson’s corporate strategy ever since.
Digital acquisitions added to IT complexity
But the push to digital has also brought complexity in the form of new acquisitions, each with their own software systems. One such acquisition was Pearson’s acquisition of eCollege in 2007. Rodgers was an eCollege employee at the time; he became part of Pearson due to the eCollege purchase:
Buying eCollege allowed Pearson to acquire a Learning Management System that had a good install base. But it was purchased for tech expertise – eCollege grew up as a software company with development capabilities, whereas Pearson grew up as a publishing company.
In 2011, the challenge of deriving insights from disparate systems came to the fore. Acquisitions such as eCollege had complicated the IT landscape:
We were turning into a publishing giant – a company of acquisitions. But at first, there was never a thought of connecting these systems together. Most of the acquisitions were profitable in their own right. But in terms of the software systems, there was the thought, “If it ain’t broke, don’t fix it.”
But it wasn’t that simple. As of 2011, Pearson had 17 different Learning Management Systems:
I could give you a narrow slice of information, but I couldn’t give you a broad view of the data. For example, the company had 27 ERP systems – we had redundancy in almost every area.
Why Pearson pursued an API strategy
After internal debate, Pearson decided not to attempt the massive job of integrating all these systems together. Instead, Rodgers and his team focused on an API bolt-on strategy. Two different API initiatives were launched.
One API project involved content-based “Plug and Play” APIs, which meant exposing a range of content APIs to external developers. With API access, the developers could “remix” content from assets such as Eyewitness Guides (travel) and the Longman Dictionary for iPhone users.
The only challenge with these early content APIs? There wasn’t the immediate developer adoption Pearson was hoping for:
We just kind of threw the APIs out there. We learned a lot from that – we kind of did everything backwards, rather than starting from what our customers wanted.
But the other 2011 API project got a quick result. Rodgers’ team opened up Pearson’s Learning Studio application with bolt-on APIs. One big difference between the two API projects? This one came directly from Pearson’s own customer base:
Our customers wanted new functionality faster than we could build it. They made it clear to us: without faster functionality rollouts, they would have to re-evaluate the relationship with Pearson.
Rodger’s team decided that APIs could solve the problem by providing Pearson’s customers with the access to build out features quickly:
We have a relatively large client base. With the Learning Studio app alone, we serve 150 institutes of higher eduction and process 26 million transactions a day. If your internal system are closed, you can’t develop functionality fast enough. But by exposing our APIs, customers could move ahead with new apps as needed.
With Learning Studio, developer adoption was not an issue:
Customers were knocking on the door. We’ve literally seen an explosion of apps that our clients have developed. This has brought us – and them – a much faster speed to market.
As of this writing, Rodgers counts 2,000 developers in Pearson’s network. 200 apps have been developed, including a CODiE award winner.
More APIs, more developers – managing growth
To manage their proliferating APIs, Pearson decided on Apigee’s API management functionality:
There are two aspects of the relationship. Apigee’s value to Pearson is the knowledge base and the people from Apigee we work with – they taught us a lot of things we didn’t know about exposing APIs. Apigee’s product helps us with a number of things, including spike arrest – one of our clients did some testing which brought down our Learning Studio system. With Apigee, we can manage those issues. Apigee can also present our old SOAP APIs as RESTful services.
Looking ahead, Pearson is in the process of finalizing a global contract with Apigee that will allow Pearson to consolidate their API programs and have uniformity across systems.
Uniformity of access fits into Rodgers’ goal of easy developer ramp-up. When Pearson first rolled out APIs, it took three weeks to for developers to get up to speed: “Now it takes approximately six hours,” says Rodgers.
Pearson calls it “Time to ‘Hello World,'” or TTHW. “We want to get to ‘Hello World’ as soon as possible,” says Rodgers. When I asked Rodgers how they improved the developer experience, he cited factors such as:
- Creating a community of developers to share know-how
- Comprehensive and up-to-date documentation libraries
- Spending more time on the developer portal educating developers on the applications
Developers can bring their own language – the only learning curve is knowing how to work with RESTful APIs (Pearson is looking at creating an API course to educate less experienced developers on working with APIs).
Looking ahead – solving the insight problem
Bolting APIs onto disparate systems has solved many issues. Customers can build the apps they want; developers are free to build enhancements. But there is still the challenge of deriving insight across systems. An internal debate on the best way to solve that problem continues.
One part of the answer is agreed upon: put all new products on the same API-friendly platform. “That’s basically what we are doing at Pearson – building a product platform,” says Rodgers.
But what do you do about your disconnected older systems from an analytics standpoint? Rodgers is looking at a migration strategy which would gradually move these older systems to the new platform. As for getting more out of older systems immediately, that’s where bolt-on APIs may provide the best interim solution. The future is platform:
The future is about the internal platform as a service we’re building. We can quickly build products on that platform and expose a suite of APIs around those products. That’s a big gain for speed to development, and we will understand data across applications. Also – a third party would only need to integrate with the underlying platform once, and they will have integrated with all the products on the platform. That solves a huge problem.
For companies moving into API projects, Rodgers has another tip – don’t forget about internal education:
At Pearson, I still spend 90 percent of my time explaining the value of APIs and what they can do. If we had rolled out an educational strategy on APIs in parallel with our developer program, we’d be further down the path.
In closing, Rodgers recommends learning from the early API adopters:
Mimic a company that’s been down this road – it doesn’t have to be in your domain. There are recipes for how you build APIs, and how you build out a developer community. All the info is out there, you just need to take advantage of it.
Image credit: photo of Allen Rodgers by Jon Reed
Disclosure: Apigee helped to cover my travel and expenses to attend “I Love APIs” in San Francisco.