I am spending two days this week with the Capital One DevExchange team outside of Washington DC, and they’ve provided me with a list of questions for one of our sessions, which they will be recording for internal use. To prepare, I wanted to work through my thoughts, and make sure each of these answers was on the tip of my tongue–here is one of those questions, along with my thoughts.
In the spring of 2010, I was ready for a career shift. I was running the North American event for SAP, and had also taken up running events for Google, which included Google I/O and Developer Days. I was the VP of Technology, and made all the decisions around usage of tech, from email blasts, to registration, session scanning, and follow-up reporting. When I took over the role, I was dealing with a literal hostage colocation facility for server infrastructure, and massive hardware expenditure on servers that I didn’t need most of the year. Then, in 2007, I began using the Amazon Cloud, and got to work re-engineering systems to be more API-centric, leverage AWS APIs to orchestrate my operations.
By 2007, I had been playing around with web APIs for some time. I had incorporated payment and shipping APIs into commerce systems, and integrated Flickr, Delicious, Twitter, Facebook, and other APIs into applications. I had plenty of SOAP web service experience when it came to enterprise infrastructure, but this was the first time I was deploying global infrastructure at scale using web APIs. I realized that web APIs weren’t just hobby toys, as my SAP IT director in Germany called them, they were an actual a tool I could use to operate a business at scale. My success resulted in more work, taking on more events, and scaling operations, which didn’t always pencil out to me actually being happier, even though the events scaled more efficiently, and out-performed what had come before.
The two Google I/O events where I managed the technology were the first ones where Google gave away their new Android mobile phones. I saw first hand what was happening in the mobile market, with the growth of the iPhone, and everyone scrambling to deploy APIs to support the new applications they were developing. Now, I was also beginning to develop new APIs to support what was possible via Android devices. It was clear that web APIs were going to be the preferred way to deliver the resources needed on mobile phones, and by 2010 there was no doubt that this mobile thing was going to be around for a while. Both SAP and Google were pushing on us to deliver resources that could be used on mobile platforms across all the events we were managing, and I saw that web APIs were how we would do this at scale.
I was using web APIs to deliver compute, storage, and other essential infrastructure to support global events. I was also using web APis to deliver resources to iPhone applications, and now Android applications. I wanted to better understand how this was being done, so in 2010 I began studying the world of APIs, looking at the common approaches to delivering APIs. I quickly saw there were plenty of pundits discussing the technical details of doing APIs, and I decided that I would focus on the business of doing APIs, and specifically how I can help convince business leaders to understand the potential. By summer of 2010 I had settled in on the name of my research blog, and by October I was beginning to publish my research on the blog. Seven years later, 3,000 blog posts later, I’m still doing it, and enjoy the focus on this important layer of not just the web, cloud, and mobile, but how APIs are being used in devices, on the network, and for bots, voices, and other conversational applications.