Olga Podolyako, @Microsoft

Thank you for tuning in to today’s full episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore topics from the world of APIs, but through the lens of business and engineering leadership. Joining me today, we have Olga Podolyako, principal API architect at Microsoft. Olga provided me with a walk-through of what I’d consider to be the most robust approach to enterprise-scale API governance that I’ve seen to date. All right, I always start with the basics, start real simple. Who are you and what do you do?

So my name is Olga Podolyako, and I’m a principal API architect for Microsoft Graph. My main responsibility is to drive Microsoft Graph API governance and standards. Originally I’m from Russia, but I’ve lived in Michigan for more than 25 years. And I have extensive experience in development, architecture, and also I led cloud adoption in my previous roles. I have multiple certifications in these areas. Currently I’m focusing mostly on architecture and governance specifically. And at Microsoft Graph we have extensive governance process to achieve our organizational goals and make our Graph APIs specifically surface great and very usable and useful for API developers.

Wow, exactly the type of conversations I’m looking to have. I think most enterprises I’m talking to today are trying to achieve what you just described. So what set this in motion? How did this governance effort at Microsoft come to be?

Honestly, I haven’t started this effort. It started almost five years ago, and you understand that it takes time, it takes time to make sure that all our API surface is consistent and has similar shape, similar behavior. We have more than 3,200 different APIs. So what we realized is that without governance we cannot achieve consistency and usability. And we also cannot deliver great quality APIs. And what we think about as quality, it’s not only good design, it’s also performance, it’s also predictable releases, it’s also predictable support response, it’s also consistency in the performance, latency, and availability. All these aspects need to be more or less the same across all 3,200 of our resources at Graph. And that’s how we started the governance.

Wow, yeah, that’s very important, because from what I’ve seen a lot of conversations have been focused on just design, design consistency, and they’ve hit a lot of problems in other areas because of the things that you mentioned, performance, a lot of other things matter. So that’s a lot of APIs. I’m guessing it’s a lot of people you have to deal with too. So how much of this governance is automation, education, workshops, training? How much of it is technology versus people, I guess?

Yes, you hit the right point, because we have more than 120 different teams delivering APIs, and we have three large organizations with large API review boards in Microsoft, only for Microsoft Graph, and Microsoft Graph delivers API surface for M365, Azure Active Directory products. So it’s a lot of people involved in the process. A lot of our effort goes on education, a lot of our effort goes into creating standards, writing down standards, and we’re doing it in the federated manner. So it’s not only me, for example, even if I am responsible for standards for Graph API, it’s not only me writing the standards. We also have a governance body. The responsibility of the governance body, of the API Council, is to review all the standards and basically manage process changes as well. In addition, as soon as we know what our standards are, where we’re moving, we try to maximize automation. Because for 3,200 APIs and 120 teams, just writing a standard is not enough. We put a lot of effort in creating linting tools, creating tools for automated testing of API capabilities, like you must implement CRUD operations, or you must implement filtering, sorting, and other query capabilities. So linting and testing comes first so that you can shift validation of API design left as much as possible. In addition, we have additional API concerns like cross-cutting concerns, like permissions, for example. We also have additional testing proactively before deploying it. And all these tools together create our onboarding pipeline. Our onboarding pipeline is based on Azure DevOps. And Azure DevOps coordinates the workflow, coordinates the approval, coordinates invoking of different automation tools like linting tools, validation tools, testing tools, and deployment into different environments. And also at the end of our pipeline we have extensive monitoring.

So you mentioned, I hear a lot of customers come into governance and they focus on the pipeline, as you said, with Azure DevOps, the enforcement of governance. And a lot of people start there, but you mentioned shifting it left. So what does that involve? Is it like design reviews? How do you shift governance left so that more teams are working on it earlier on?

Yes, it’s a very interesting question. So in my previous experience I observed that people understand governance as mostly verification of some quality, let’s say quality attributes, at the runtime, at the operation time. Governance effectively consists of two sides. First, you need to set up standards and requirements, and then you would verify them. Depends on what kind of standards and requirements you’re setting. For example, we are setting requirements like design requirements which are consistent shape, consistent capabilities of APIs. These specific requirements can be verified before deployment, and it would, I mean, shifting left. It means that during design, as soon as a shape of API is more or less known and specifications are written down, we can start doing linting processes, we can start doing validation processes like mocking APIs, for example. We have a mock service, we have additional environment where developers can verify their design just in their local environment. And it’s what I call shifting left.

Yeah, it’s really about, it sounds like it’s about enabling developers to do governance rather than enforcing and being more carrot, teaching them how to do things well, rather than just pushing on them, that to get it into production they have to do it right.

Definitely. It’s more about self-service, about ability to verify that your API is compliant to the standards.

What other kind of building blocks and patterns do you supply for developers? You talked about standards. How do you help make sure that they apply consistent patterns when they’re designing APIs?

I truly believe in patterns and building blocks in general for architecture. I think it’s the main responsibility of architects, and also API architects, to provide and describe these building blocks. So we’re doing it in multiple channels, multiple avenues. For example, from the standard documentation perspective, our baseline documentation was created relatively long time ago. It was Microsoft REST API guidelines who set the foundation for REST services inside Microsoft, and also provided best practices for the industry. On top of it, we have a variation specific for Microsoft Graph guidelines. It’s a short summary document describing our approach, that, for example, we need to start with the domain model to create a user-friendly API. This short document is augmented with a library of patterns. And we borrowed architectural language for describing these patterns. Specifically, our patterns consist of what is the problem we’re trying to solve, in what context, and what is the solution for this problem. These patterns have short documents describing pattern, solution, and providing multiple examples on how to use this pattern. This is a very actionable document. In addition, we have a new avenue for helping our developers to implement these patterns. In the API design, we are working on a new language, TypeSpec, which allows us to codify these patterns and make design as a Lego, actually, as combining different Lego blocks into one design, bringing design patterns easily to create API shape. And in addition to helping with design, we also have an implementation library implementing similar patterns, so that we can create a scaffold for the background service supporting the API based on the API design. All these steps significantly help us to drive API-first approach, so that we can start with design, we use building blocks for API design, and then we can create a scaffolding for the background service.

I like that. So you said in there API first. What does API first mean to you?

API first is a really good concept, but which is kind of difficult to implement, especially in the environment when you already have a lot of legacy products and legacy services. But still, it’s very helpful when you try to bring to market a new product or a new service. What it means for us, when we talk about API first, we talk about starting product design or service design with use cases and thinking about interactions between users, clients, with your product. This conversation drives us to creating user-friendly interfaces which reflect main information flows, main use cases, as I already said, for the product design and for the API design. And it’s what we basically call API-first approach, starting with use cases and starting with user interactions or client interactions for your product.

I think that’s one of the better definitions I’ve heard of API first, because most people are very technical in their response, but it sounds like you’re bringing it closer to business, that this needs to be about business outcomes rather than just the APIs themselves.

Yes, and I truly believe that APIs actually are user interfaces. Even though, yes, it’s a programmability surface, we start with users, we start with developers. It should be understandable by developers who will use our APIs. So it’s why we pay so much attention to, for example, naming conventions, to consistency of shape and behavior, to consistency of patterns. We also exposed our design guidelines, they’re public, so everybody can see them. And we truly think about API design from usability perspective a lot.

So important. So how much of this work is centralized versus federated across teams?

As I mentioned, we have three large organizations working on delivery of APIs, and we have three different review boards. So from governance perspective it’s federated. We have a centralized body to review the main principles, process changes, and standards, but overall the work itself is done in different organizations. We also, because of the ability of shifting left and reusing building blocks, we also delegate a lot of decisions back to implementation teams. And we have API champions in some of our teams who oversee consistency of APIs across large products, for example, Teams, or let’s say Azure Active Directory. So from this perspective, we try to federate as much as possible and enable consistency using automation, mostly automation, and consistent standards.

Yeah. So how do you know what’s success? How do you know governance is working?

It’s a very interesting question, and it’s a very difficult question, because results of governance working are long-term results. It’s a strategic question. And for us right now this strategic question can be defined very simply. Based on our organizational objectives, we are building a Graph ecosystem for developers, so that every developer can go to Graph APIs and easily start development using Microsoft capabilities for their business solutions, so that they can innovate on top of Graph API. So from this perspective, for us it’s extremely important to deliver API as a software product. And when we think about API as a software product, we think about what does it mean to deliver a good software product. This defines our success. So in our terms, success of API governance is success of our APIs, and it means that a good software product, we need to deliver a good software product. But it’s not only a software product, there are a lot of specifics, right? It’s an API, first of all. So API needs to have a great design. It’s a cloud product. So it needs to have reliability, and performance, and operational excellence according to the cloud standards. So we designed a quality framework for our APIs, which is based on our success definition. And this quality framework consists right now of eight quality attributes. These quality attributes include planning and road map, monetization, design considerations, security. Security is essential for our APIs. It has performance and availability, and also operational excellence. From this perspective, it’s how we define success. So we define success, now we need to measure it. And we created a dashboard to reflect all these quality criteria. We define KPIs for each of these quality areas. So we have a dashboard and we have a weighted combined score, which basically reflects success of a specific API. And I guess it’s a long-winded answer, but the point was that we created criteria, quality criteria to describe our success, and we created visibility, traceability, for these criteria using a dashboard and a weighted score, and it’s how we see if our governance is successful.

It’s impressive. It’s more than I’ve seen out of most organizations I’ve talked to. I’ve talked to a lot of enterprise groups. It’s pretty sophisticated. How much of this, I can tell you’ve put a lot of work into defining all of this and laying this foundation. How much of this is static and will always be the same, or is your governance ever changing and kind of living and evolving alongside this?

Our governance definitely, to your point, definitely evolving. Because we started five or six years ago, mostly focusing on design. And it’s extremely important for APIs, because this is the first impression for API developers. When they see Graph APIs, they expect that it will be consistent across all those different M365 products, it’s very important. As we grow and mature, as we understand how our APIs are used for critical business systems, we realized that design is not enough. That we need to provide predictability, we need to provide reliability, we need to provide operational support. And all these characteristics basically triggered the next phase of API governance, I would say evolution of the governance. But again, governance is a strategic process and it takes a long time, because we should think about not only external API developers, we also think about all these 120 teams which are in Microsoft. They need to know what are new quality requirements. We need to socialize, communicate, educate them on what does it mean to deliver a great API software product. Obviously they know what does it mean to deliver a great technology product, but we’re talking specifically about Graph APIs, for example. So yes, this evolution goes continuously, as we’re learning from experience as well. And it also reflects our evolving organizational roles. As we’re moving forward, we build new goals for the organization and they impact our governance evolution as well.

Do you feel like this gives you the strength and the muscle to be able to respond to whatever is going to come next, business-wise, for Microsoft?

Definitely, definitely. We are very agile, and what I see our strength is, is in ability to delegate to teams important design decisions, ability to support federation, ability for teams to make their own decision and automate, and we automate validation of these decisions. So from this perspective, definitely I think that our governance is not a rigid process. Our governance is more a system with a feedback loop, which reflects what organization needs, but it’s a little bit conservative, to be fair to our developers and our API producers, so that they would be able to adjust.

Yeah, interesting. I’ve been impressed with Microsoft’s ability to adapt to the cloud and respond to changing market forces, and I have worked on Microsoft technology since the early ’90s, and I honestly have to say I didn’t expect Microsoft to be able to respond and adjust, and I actually feel like they’re leading when it comes to APIs now and cloud infrastructure and across all the Microsoft products. I’m really impressed with the way that the company’s responded to an API-first landscape. But I want to understand more about you, because it’s really hard to find people who get governance at the level that you do. So why does this stuff interest you? Why does governance and this role interest you as part of your career?

Sure. Let me a little bit add to your previous comment about Microsoft. I want to mention that a lot of our API efforts are actually open sourced. Our guidelines documentation are public documentation. Our SDK generation automation is a public open source project. TypeSpec, the new language we’re working on to implement patterns, is also an open source project. So we truly believe in the community involvement, and I think that it gives us strength and flexibility for the future. Now, answering your question, why I’m interested in the governance, my passion is more about architecture, and governance is just one part of the architecture. And why am I thinking so much about governance and architecture? Because I think about the API ecosystem, Microsoft Graph API ecosystem, as a complex system with feedback loops. And I’m trying to understand what are the main components of the system, how to model this system effectively, and how to move this system in the right direction. And it leads me to, for example, defining criteria for success for our governance. It’s all based on software architecture practices. And we basically apply software architecture to APIs as software product to derive qualities based on cloud well-architected frameworks, such as AWS and Azure, and augmented with our organization-specific and API-specific qualities. So this complexity of the system, the system component interactions, drives me to the space and gives me excitement every day. So it’s why I’m working on it.

Very interesting, and we need so many more people just like you to fill the space, because governance, and I don’t want to say just governance, governance the way that you’re doing it, this flexible feedback loops with the business outcomes focused, is so needed in a lot of the technology- or IT-driven API operations that I see. But there’s one piece of what you’re doing that I noticed that’s really interesting, and I’d like to know a little bit more, is, why are you so vocal in telling your story? I just saw your talk at API Specifications Conference, you’re here on the podcast. Why is it important for you to tell your story?

I think that the importance of telling your story is to share experience, but also learn from the feedback of people. So I’m really looking forward to see feedback from the conference, I’m really looking forward to hear feedback from your podcast, because it helps us with right this feedback loop, positive and also not so positive responses. I guess it’s a system approach which I apply consistently to all of my activities, and this is the main purpose of sharing it and bringing more people to this conversation. Start talking about API governance, API management, what does it mean actually API architecture, because API architecture is relatively a new term, right? We know what is software architecture, and for a long time perception of API architect was focused on only specifics of protocols, specifics of design, and we never thought, it’s not true, never say never, but we did not think about API as a holistic product, as a holistic software product. And by product, another interesting thing I found for myself is that when we talk about API as a product, it’s not necessarily about how much money we will earn on this API, how much money it will bring for the organization. It’s about how much customer value it will deliver and how much business value it will deliver. And customer and business value may be accounted in different units, it’s not only in dollars. I really want to expand this definition. So I guess, yes, we are publicly talking about our effort at Microsoft to involve community, to encourage feedback, and bring more people to the API space.

This is just another one of your feedback loops, right?

Yes, exactly.

So is what you just described about treating APIs as products, do you feel like this is what’s different than what we had during the service-oriented architecture days? Do you feel like that’s why APIs are working now and services didn’t work so well or failed us back then?

Yes. I just spent a lot of time on integration and service bus, working with enterprise service bus and looking at the service-oriented architecture. I think that it’s just another evolution. It’s just another evolution of service-oriented architecture, honestly. And again, using our lessons learned. Like for example, SOAP XML was really heavy, was difficult to process, became very complicated, and we deviated from it. We moved to JSON, which is more user-friendly, human-readable, and machine-readable. We added some specifications like JSON Schema on top of it. But what definitely we are different from in the service-oriented architecture, another huge shift in my opinion is shift to distributed systems, to cloud systems, SaaS systems, right? And shift to the hybrid business solutions, which require distributed systems to support the business. Distributed systems communicate via APIs. Will it be REST API, gRPC, will it be some kind of low-level interface, it’s still an interface, right? So API, when I think about it, it’s a really generic term, and it’s obviously application programming interface, but the point being that with cloud, with evolution of distributed systems, APIs are the new focus for service-oriented architecture. Just a different evolution cycle.

So do you think this will just keep going forward, this, APIs will just keep reinventing and evolving into the future, and what we’re building now will prepare us for that?

Yes, I think that you provided the answer to your question. Yes, I think that it’s an evolution. It’s an evolution of software, it’s an evolution of our ability with internet to communicate across different systems, different regions, different countries, and it definitely will evolve. I don’t know how yet, we are learning. Even with APIs, we always see new flavors, new languages coming up and being more popular. And again, what I’m thinking is that API is a big term, right? It’s a lot, because for different use cases you may use different types of APIs. For some use cases, REST APIs is a perfect choice. For other use cases, you may need to have gRPC, for example, gRPC APIs. And maybe we will have some additional unknown-yet use cases when we will need to have new types of interfaces, which also will be APIs, because it’s system-to-system communication.

Yeah, well, I love your view of things. You really have one of the more sophisticated views of governance that I’ve seen out there talking to folks. Most people are, I would say, API early or becoming to be API aware. You definitely, the governance, the feedback loops, the product mindset, is very progressive and very interesting to learn about. And I would love to have you back at some point in the future. I’ll probably get some of your colleagues to come. I want to learn more about TypeSpec and why TypeSpec exists and how it’s going to help us address the next generation of APIs. So I appreciate you coming by today.

Thank you so much for your attention, for inviting me, and letting me speak my mind. And so, if you don’t mind, I would like just to articulate my main ideas, main points, if you don’t mind. So the main point I discovered for myself, and we are trying to implement it, is that we need to treat API as a software product, as a cloud software product. Then we need to define API qualities based on organizational needs. Basically, qualities of your software product is driven by your organizational goals. Then another thing is that we need to have standard building blocks to promote best practices, and we need to have these building blocks and patterns for APIs as well, for API design and API implementation. And automation for the large-scale API services is essential, otherwise we won’t be able to enable compliance with quality requirements for APIs. And another thing for a successful API governance product, we need to have observability and traceability. And it means that we need to have a dashboard, or some kind of metrics, which reflect how our APIs perform in real life. That is on my part. Thank you so much.

I love that, thank you for that definition, that’s very succinct and very helpful for folks. So I look forward to feedback from people to this show, so I’ll be in touch and share any questions that we get, and then maybe we can have a conversation again in the future about some of this and see where we can go next.

Looking forward to the feedback. Thank you so much for inviting me.

Thank you, Olga, I appreciate it. Enjoy your day.

Thank you.

Thanks again to Olga for stopping by. You can find more about Olga on LinkedIn, and Microsoft at microsoft.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host Kin Lane, and until next time, cheers.