Coming to you LIVE from APIStrat 2017 in Portland, Oregon where over 300 API enthusiasts, ranging from seasoned veterans to first-timer's, have gathered to hear about emerging trends in the API Industry. This morning’s keynotes aligned around a common theme: APIs matter. Developer experience matters. For some of us, customer passion is often better stated as customer obsession. And it is critical that you build your API strategy around this obsession.

Yina Arenas, Principle Program Manager at Microsoft shared a behind the scenes story of how her and her team transformed Microsoft’s APIs. The grassroots, scrappy journey led to evolving the entire API Strategy across Microsoft, creating a unified Microsoft Graph API. Similar to Daenerys Targaryen is the Mother of Dragons, Yina Arenas is the Mother of Microsoft Graph.

The Problem: Dozens of siloed projects across Microsoft had no guidance, governance or agreed upon styles to align around -- some were built on REST, or SOAP, RPC, even Powershell. Then, there were a plethora of ways to authenticate to the data and to connect to it. There were no canonical IDs to access the resources. For instance, one user resource might have looked like one of these 3 variations:

• /users/john
• /users(john@123) or
• i:member:john_123

Even just inconsistency around the multiple user IDs led to issues and issues piling up across the products, consider that issue multiplied by the 8 TRILLION RESOURCES (emails, users, etc) on Microsoft, and you can start to really grasp the issue at hand. And Yina reminds us, “customers don’t care about product lines and organizational boundaries” they only care about their data.

This monster led Yina to create a customer-obsessed team, with cross-functional members from all across Microsoft. They aligned around a common goal: reduce customer pain and allow for data to be easily accessible. Their goal was to translate that customer obsession to customer value with three initiatives:

1. Standardization: agreeing to be consistent. Agreed to do REST, to have canonical ids across resources, and establish a council for API governance. Published the Microsoft API Guidelines.
2. Breaking silos: Consistency for the sake of consistency is not enough. The team as Microsoft needed to break siloed products, both technically and culturally. They started by focusing on how customers access common resources and they were able to dynamically stitch their model schemas together.
3. Developer experience: A great API on its own does not lead to a great experience. You must focus on defining the the developer experience and then drive it relentlessly. Documentation, for example, should be simple, easy to read and exactly what developers expect. As you put relentless focus behind your developer experience, gradually the tone of the feedback from your community will change, and start to prove that you are creating a developer experience that developers LOVE.

The effort started a movement within the company that aligns with its recent cultural transformation, shifting from old silos towards a new “One Microsoft” vision.

This project showed that the sum can be larger than its parts and that a scrappy team with heart and passion can influence from the bottom up. Yina will share her challenges and successes on the graph project, and how this effort transformed the API strategy across Microsoft.