April 26, 2023 • 39 mins
Welcome to this episode of Breaking Changes, where Postman's Chief Evangelist Kin Lane sits down with Olga Podolyako, Principal API Architect at Microsoft, to discuss API governance and its importance in driving business success.
In this video, Olga will share Microsoft's advanced vision of API governance and how they are leveraging it to enable teams and streamline API operations. Through a human-centered approach, Microsoft is not only able to ensure compliance with industry standards, but also drive innovation and collaboration across the organization.
Whether you're a developer or an executive, this conversation is a must-watch for anyone interested in learning more about API governance and its impact on modern businesses. So sit back, relax, and join us for this insightful discussion with one of the leading minds in API architecture.
To get more details, make sure to watch the full episode of Breaking Changes on Postman's website, YouTube, or your preferred streaming platform.
Don't forget to comment below and share your thoughts with us. Follow Kin Lane on Mastodon at https://mastodon.kinlane.com/@kin and learn more about Microsoft at https://www.microsoft.com/. Thank you for tuning in!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Thank you for tuning into today's full episode of the Breaking Changes podcast.
(00:10):
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 walkthrough of what I'd consider to be the most robust approach
(00:30):
to enterprise scale API governance that I've seen to date.
All right.
I always, 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.
(00:50):
My main responsibility is to drive Microsoft Graph API governance and standards.
Originally, I am from Russia, but I live in Michigan for more than 25 years and I have
extensive experience in development, architecture, and also I led cloud adoption in my previous
(01:11):
roles.
I have multiple certifications in these areas.
Currently, I am focusing on mostly on architecture and governance specifically.
And at Microsoft Graph, we have extensive governance process to achieve our organizational
(01:31):
roles and make our API, Graph API 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.
(01:52):
So what set this in motion?
How did, how did this governance effort at Microsoft come to be?
Honestly, I haven't started this effort.
It had, it started almost five years ago and you understand that it takes time.
(02:13):
To make sure that all our API surfaces consistent and has similar shapes, similar behavior.
We have more than thirty two hundreds of different APIs.
So what we realized that without governance, we cannot achieve consistency and usability.
(02:35):
And we also cannot deliver great quality APIs.
And what we think about quality, it's not only a good design, it's also performance.
It's also predictable releases.
It's also predictable support response.
It's also consistent consistency in the performance, latency and availability.
(03:01):
All these aspects need to be more or less the same across all thirty two hundreds of
our resources at Graph.
And it's how we started the governance.
Wow, yeah, that's 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
(03:26):
in other areas because of the things that you mentioned, you know, 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 is automation, education, workshops, training?
How much of it is is technology versus people, I guess?
(03:50):
Yes, you hit the right point because we have more than hundred twenty 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
(04:14):
Azure Active Directory products.
Right. 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 we're doing it in the federated manner.
(04:37):
So it's not only me, for example, even if I am responsible for standards for API Graph,
it's not only me writing the standards.
We also have a governance body.
Responsibilities of the governance body of the API Council is review all the standards
(04:58):
and basically manage process changes as well.
In addition, as well, as soon as we know what our our standards were, we're moving.
We try to maximize automation because for three to two hundred API and hundred twenty teams,
(05:20):
just writing a standard is not enough.
We put a lot of effort in creating leading tools, creating tools for automate automated
test testing of API capabilities like you must implement crowd operations or you must
implement filtering, sorting and other query capabilities.
(05:45):
So linking 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 crosscutting concerns like permissions,
for example, we also have additional testing practically before deploying it.
(06:11):
And all these tools together create 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
(06:31):
linking tools, validation tools, testing tools and obviously deployment into different
environments. And also at the end of the hour 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 is is the enforcement of governance.
(06:56):
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 are working on it earlier on?
Yes, it's a very interesting question.
So in my previous experience, in my previous experience, I observed that people understand
(07:22):
governance as mostly verification of some 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 verify them.
(07:44):
Depends on what kind of standards and requirements you're setting.
For example, we are setting requirements like planning, like design requirements,
consistent shape, consistent consistent capabilities of APIs.
These specific requirements can be verified before deployment.
(08:06):
And it's what I mean, shifting left.
It means that during design, as soon as the shape of API is more or less known and
specifications are written down, we can start doing linting processes.
You can start doing validation processes like mocking, mocking, for example, API.
(08:31):
We have a mock service.
We have additional environment where we can, where developers can verify their design
just in the local environment.
And it's what I call shifting left.
(08:51):
Yeah, it's really about, it sounds like it's about enabling developers to do governance
rather than enforcing and being more care at teaching them how to do things well,
rather than just pushing on them to get it into production.
They have to do it right.
(09:11):
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?
(09:38):
I truly believe in these 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 doing it in multiple channels, multiple avenues.
For example, from the standards documentation perspective, our baseline
(10:05):
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 industry.
On top of it, we have a variation specific for Microsoft graph guidelines.
(10:29):
It's a short summary document describing our approach.
For example, we need to start with the main model to create a user-friendly API.
This short document is augmented with a library of patterns and we borrowed
(10:49):
an 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 are short documents describing pattern solution and
(11:12):
providing multiple examples on how to use this pattern.
This is very actionable documents.
In addition, we have a new avenue for helping our developers to
implement these patterns in the API design.
(11:33):
We are working on a new language schedule, 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.
(12:03):
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
(12:27):
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 really good concept, but which is kind of difficult to implement,
(12:50):
especially in the environment when you already have a lot of legacy products
and legacy services, but still when it's very helpful when you try to bring to
market a new product or a new service.
What it means for us, it's when we talk about API-first, we talk about starting
(13:18):
product design or service design with use cases and thinking about interactions
between users, clients with your product.
This conversation drives us to creating a user-friendly interfaces, which reflects
main information flows, main use cases, as I already said, for the product design
(13:47):
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
(14:11):
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 programmability surface.
We start with users, we start with developers.
(14:33):
It should be understandable by developers who will use our APIs.
So it's why we pay so much attention to user, for example, to naming conventions,
to consistency of shape and behavior, to consistency of patterns.
We also exposed our design guidelines are public, so everybody can see them.
(14:57):
And we truly think about API design from usability perspective a lot.
That's so important.
So how much of this work is centralized versus federated across teams?
(15:18):
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
(15:42):
standards, but overall the work itself is done in different organizations.
We also, because of this ability of shifting left and reusing building blocks,
we also delegate a lot of decisions back to implementation teams and we have API
(16:04):
champions in some of our teams who overview consistency of APIs across large
products, for example, teams or let's say Azure Active Directory.
So from this perspective, we try to figure it as much as possible and enable
(16:28):
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 very interesting question and it's very difficult question because results of
(16:55):
governance is working are long-term results.
It's a strategic question.
And for us right now, this strategic question can be defined as very simple.
Based on our organizational objectives, we are building, we are building basically
(17:16):
graph ecosystem for developers.
So 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 APIs.
(17:36):
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, our success, success of API governance is success of our APIs.
(18:06):
And it means that good software product, we need to deliver good software product,
but it's not only software product.
There are a lot of specific specifics, right?
It's an API first of all.
So API needs to have a great design.
It's a cloud product.
(18:27):
So it needs to have a reliability and performance and operational excellence
according to the cloud standards.
So we designed, we designed a quality framework for our APIs, which is based on
our success definition.
(18:48):
And this quality framework consists right now from eight quality attributes.
This quality attributes include planning and roadmap, monetization, and design
(19:08):
considerations, security.
Security is essential for our APIs.
It has, 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 create, we created a dashboard to reflect
(19:34):
all this quality criteria.
We defined 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 long winded answer, but the point was that we designed, we
(19:57):
created the criteria, quality criteria to describe our success and we created
visibility, traceability for these criteria using a dashboard and the 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.
(20:19):
I've talked to a lot of enterprise groups.
It's pretty sophisticated.
How much of this, I mean, 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, is your
governance ever changing and kind of living and evolving alongside this?
(20:41):
Oh, God, I think it's a good question.
Our governance definitely to your point, definitely evolving because we started,
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 API, they expect that it will be consistent across all these
(21:05):
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 realize that design is not enough, that we need to provide
predictability, that we need to provide reliability, that we need to provide
(21:30):
operational support and all these characteristics basically are triggered
the next phase of API governance, I would say governance, evolution of the governance.
But again, governance is a strategic process and it takes long time because we
(21:54):
should think about not only external API developers, we also think about all
these hundred twenty 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.
(22:17):
Obviously they know what does it mean to deliver great technology products, but
we're talking specifically about graph APIs, for example.
This evolution goes continuously as we learning from experience as well.
And it also reflects our evolving organizational roles as we're moving
(22:40):
forward, we build new goals for organization and impact our governance
and the development of our new products.
So we need to think about how we can deliver the best API software.
Impact our governance evolution as well.
Do you feel like this gives you the strength and kind of the muscle to be
(23:02):
able to respond to whatever is going to come next business-wise for Microsoft?
Definitely, definitely.
We are very, we are very agile and what I see our strengths is in ability to
delegate to teams, important design decisions, ability to support
(23:27):
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, our
governance is not a rigid process.
(23:47):
Our governance is more, more a system with a feedback loop, which
reflects what organization needs.
But it's a little bit, it's a little bit conservative to be fair to our
developers and our API producers so that they will be, would be able to adjust.
(24:12):
Yeah.
Interesting.
Yeah.
I, I was impressed.
I've been impressed with Microsoft's ability to adapt to the cloud and respond
to, to changing market forces.
And I have worked on Microsoft technology since early nineties.
And I honestly have to say, I didn't expect Microsoft to be able to respond
(24:34):
and adjust and I'm actually, actually feel like they're leading when it comes
to APIs now and cloud infrastructure and, and across all the Microsoft products.
I'm really impressed with, with the way that the companies responded to an API
first landscape, but I want to, I want to understand more about you and cause I'm,
(24:55):
it's really hard to find people get governance at the level that you do.
So why, why does this stuff interest you?
Why, why does governance and, and this role interest you and, and as part of your career?
Sure.
Let, let me a little bit to add to your previous comment about Microsoft.
(25:15):
I want to mention, I want to mention that a lot of our API effort efforts
are actually open sourced, right?
Our guidelines, documentation are public documentation.
Our SDK generation automation is a public public open source,
(25:36):
open source project.
Cattle new language we are working on to implement patterns is also open source,
open source product project.
So we truly believe in the community involvement and I think that it gives us
strengths and flexibility for future.
(26:02):
Now answering your question, why I'm interested in the governance.
My, my passion is more about architecture and governance is just one part of the
architecture and why I'm thinking about so much about governance and architecture
because I'm seeing, I think about API ecosystem, Microsoft graphic API ecosystem
(26:29):
as a complex system with feedback loops.
And I'm trying to understand what, what you'll make this, what, what are the main
components of the system, how to model the system effectively and how to move this
system in the right direction.
(26:50):
And it, what leads me to, for example, defining criteria for success for our
governance, it's all based on software architecture practices.
And, uh, we basically applied software architecture to API as a software product
to derive, to derive, uh, qualities based on cloud well-architected frameworks,
(27:18):
like such as AWS and Azure, and augmented with our organizational,
organization specific and API specific qualities.
So this complexity of the, uh, system, system, uh, component interactions drives
(27:39):
me to the space and, um, gives me excitement every day.
So it's why I'm working on it.
Very interesting.
And I mean, we need so many more people just like you to, to fill the space
because governance is, and I don't want to say just governance, governance, the
way that you're doing this flexible feedback loops with the business outcomes
(28:01):
focused is so needed in, in a lot of the technology or IT driven API operations
that I see, but there's one piece of that.
You're what you're doing that I noticed that's really interesting.
And I would like to know a little bit more is why are you, why are you
so vocal and telling your story?
I just saw your talk at API specifications conference.
(28:22):
You're here on the podcast.
Why is it important for you to tell your story?
I, I think that, uh, importance of telling 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.
(28:43):
I really looking forward to hear feedback from your podcast because
it's what helps us evolve, right?
Also not so positive responses.
I guess, I guess it's a system approach, which I am applied consistently
to all of my activities.
(29:05):
And, uh, this is the main purpose of sharing it and bringing more people,
more, bringing more people to this conversation.
Um, I think it's important to share experience.
OK, OK.
I think the important thing, so what really
helped me, actually to talk with Pfitil and other autres,
(29:29):
for this, improve the pattern of customer experiences.
It helped a lot inرب trucking setup.
It made it easier for us to be the seasoners for customer experiences.
Um, and um, and if label
t's, I imagine is theumbled version of API Garden API's.
Specifics of protocols, specifics of design.
(29:54):
And we never thought it's not, it's not true.
Never, never say never, but we did not think about, uh, API as a holistic
product, uh, as a holistic software product and by product.
What is another interesting, another interesting thing I found for myself
(30:16):
is that when I, when we say about, when we talk about API as a product,
uh, it's not necessarily about, uh, how much money we will earn on this API,
how much money it will bring for organization.
It's about how much customer value it will deliver and how much business
(30:37):
value it will deliver, right?
And customer and business value may be, uh, accounted in different units.
It's not only in dollars.
It, it's really, uh, we really want to expand this, uh, definition.
So it's, I guess, I guess, yes, we are publicly talking about our
(31:00):
effort at Microsoft to involve community, to encourage feedback and, um,
bring more people to the API space.
This is just another one of your feedback loops, right?
Yes, exactly.
Uh, so is, is what you just described about treating API as products.
(31:23):
Do you feel like this is what's different than what we had during
the service oriented architecture days?
Do you feel like that, why, uh, APIs are working now and, and services
didn't work so well or, or failed us back then?
Um, yes, I did spend a lot of time on integration and service boss, working
(31:43):
with service, uh, enterprise service boss 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, uh, it's an evolution of service oriented architecture.
And again, uh, using our lessons learned, like, for example, uh,
(32:07):
soap XML was really heavy, was difficult to process, became very complicated.
And we deviated from it.
We moved to Jason, which is more user friendly, human readable and machine
readable.
We added some specifications like Jason schema, which is more user friendly.
We added some features like, uh, we added some features like, uh,
(32:31):
Jason schema on top of it.
Uh, but what definitely we are evolving from the, um, service oriented
architecture, another huge shift in my opinion is shift to distributed
systems, to cloud, to cloud systems, SAS systems, right.
(32:53):
And, um, shift to the hybrid, uh, business solutions, which require
distributed systems to support the business.
Just distributed systems communicate via API's.
Will it be REST API, JRPG?
Will it be some kind of low level interface?
(33:16):
It's still an interface, right?
So I API, when I think about it, it's a really generic term and it's
obviously it's application program or programming interface.
But, um, point being that with cloud, uh, with evolution of distributed
(33:40):
systems, API's, uh, API's are new focus for service oriented architecture.
Just different evolution, evolution cycle.
So do you think this will just keep going forward?
This, uh, API's will just keep reinventing and, and, and evolving
(34:01):
into the future and what we're building now will, will prepare us for that.
Yes.
I think that you provided answers to your question.
Yes.
I, yes, I think, I think that it's an evolution.
It's, it's an evolution of software.
It's an evolution of our ability with internet to communicate across different
(34:27):
systems, different regions, different countries, and, um, it's definitely,
it definitely will evolve.
Uh, I don't, I don't know how yet, uh, we are, we are learning even with, uh,
even with, uh, with API's we always see, uh, new flavors, new, uh, new languages
(34:54):
and coming up and being more popular.
And again, uh, what I'm thinking that API is a big term, right?
Uh, it's a, it's a lot because for different use cases, you may use
different type of API's for some use cases, rest API's is a perfect choice.
(35:15):
For another use cases, you may need to have a JRPG, for example, or JRPG API's.
And, uh, maybe we will have some additional unknown yet use cases when we
will need to have a new type of interfaces, which also will be API's because
(35:38):
it's system to system communication.
Yeah.
Well, I, I love your, your view of things.
You really, uh, have one of the, the more sophisticated views of governance
that I've seen out there talking to folks.
More, most people are, I would say API early or becoming to be API aware.
(35:59):
You definitely, the, the governance, the feedback loops, the product mindset,
um, is, is very progressive and very interesting to learn about.
And I think 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 cattle and why cattle exists and, and, uh, and,
and how it's going to help us kind of address the next generation of, of API's.
(36:24):
So, um, I appreciate you coming by today though.
Thank you so much, uh, for your attention for inviting me and late
letting me speak my mind.
And, uh, so if, uh, if you don't mind, I would like just to articulate
my main ideas, main points, uh, if you don't mind, uh, I, so the main point
(36:52):
I discovered for myself and we are trying to implement it that we need to
treat API as a software product, as a cloud software product.
Then we need to have, uh, we need to define API qualities based on, uh,
organizational needs, basically qualities of your software product is
(37:18):
driven by your organizational goals.
Then another thing is that you, we need to have standard building blocks to
promote best practices and we need to have this building blocks and patterns
for API's as well for API design and API implementation and automation for the
(37:40):
large scale API surfaces is essential.
Otherwise it's not, we won't be able to, uh, uh, to enable compliance
with quality requirements for API's.
And another thing for a successful API governance product, we need to have
(38:01):
observability and traceability.
And it means that we need to have a dashboard, dashboard or some kind of
metrics, which reflects how our API APIs perform in real life.
So that's not my part.
Thank you so much.
I love that.
Thank you for that definition.
(38:22):
That's very succinct and very helpful for help helpful for folks.
So, um, I look forward to feedback from, 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, uh, about some of this and see where we can go next.
Looking forward for the feedback.
(38:43):
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
slash events slash breaking dash changes.
(39:05):
I'm your host kin lane.
And until next time, cheers.
Thank you for tuning into today's full episode of the Breaking Changes podcast.
(00:10):
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 walkthrough of what I'd consider to be the most robust approach
(00:30):
to enterprise scale API governance that I've seen to date.
All right.
I always, 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.
(00:50):
My main responsibility is to drive Microsoft Graph API governance and standards.
Originally, I am from Russia, but I live in Michigan for more than 25 years and I have
extensive experience in development, architecture, and also I led cloud adoption in my previous
(01:11):
roles.
I have multiple certifications in these areas.
Currently, I am focusing on mostly on architecture and governance specifically.
And at Microsoft Graph, we have extensive governance process to achieve our organizational
(01:31):
roles and make our API, Graph API 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.
(01:52):
So what set this in motion?
How did, how did this governance effort at Microsoft come to be?
Honestly, I haven't started this effort.
It had, it started almost five years ago and you understand that it takes time.
(02:13):
To make sure that all our API surfaces consistent and has similar shapes, similar behavior.
We have more than thirty two hundreds of different APIs.
So what we realized that without governance, we cannot achieve consistency and usability.
(02:35):
And we also cannot deliver great quality APIs.
And what we think about quality, it's not only a good design, it's also performance.
It's also predictable releases.
It's also predictable support response.
It's also consistent consistency in the performance, latency and availability.
(03:01):
All these aspects need to be more or less the same across all thirty two hundreds of
our resources at Graph.
And it's how we started the governance.
Wow, yeah, that's 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
(03:26):
in other areas because of the things that you mentioned, you know, 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 is automation, education, workshops, training?
How much of it is is technology versus people, I guess?
(03:50):
Yes, you hit the right point because we have more than hundred twenty 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
(04:14):
Azure Active Directory products.
Right. 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 we're doing it in the federated manner.
(04:37):
So it's not only me, for example, even if I am responsible for standards for API Graph,
it's not only me writing the standards.
We also have a governance body.
Responsibilities of the governance body of the API Council is review all the standards
(04:58):
and basically manage process changes as well.
In addition, as well, as soon as we know what our our standards were, we're moving.
We try to maximize automation because for three to two hundred API and hundred twenty teams,
(05:20):
just writing a standard is not enough.
We put a lot of effort in creating leading tools, creating tools for automate automated
test testing of API capabilities like you must implement crowd operations or you must
implement filtering, sorting and other query capabilities.
(05:45):
So linking 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 crosscutting concerns like permissions,
for example, we also have additional testing practically before deploying it.
(06:11):
And all these tools together create 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
(06:31):
linking tools, validation tools, testing tools and obviously deployment into different
environments. And also at the end of the hour 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 is is the enforcement of governance.
(06:56):
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 are working on it earlier on?
Yes, it's a very interesting question.
So in my previous experience, in my previous experience, I observed that people understand
(07:22):
governance as mostly verification of some 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 verify them.
(07:44):
Depends on what kind of standards and requirements you're setting.
For example, we are setting requirements like planning, like design requirements,
consistent shape, consistent consistent capabilities of APIs.
These specific requirements can be verified before deployment.
(08:06):
And it's what I mean, shifting left.
It means that during design, as soon as the shape of API is more or less known and
specifications are written down, we can start doing linting processes.
You can start doing validation processes like mocking, mocking, for example, API.
(08:31):
We have a mock service.
We have additional environment where we can, where developers can verify their design
just in the local environment.
And it's what I call shifting left.
(08:51):
Yeah, it's really about, it sounds like it's about enabling developers to do governance
rather than enforcing and being more care at teaching them how to do things well,
rather than just pushing on them to get it into production.
They have to do it right.
(09:11):
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?
(09:38):
I truly believe in these 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 doing it in multiple channels, multiple avenues.
For example, from the standards documentation perspective, our baseline
(10:05):
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 industry.
On top of it, we have a variation specific for Microsoft graph guidelines.
(10:29):
It's a short summary document describing our approach.
For example, we need to start with the main model to create a user-friendly API.
This short document is augmented with a library of patterns and we borrowed
(10:49):
an 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 are short documents describing pattern solution and
(11:12):
providing multiple examples on how to use this pattern.
This is very actionable documents.
In addition, we have a new avenue for helping our developers to
implement these patterns in the API design.
(11:33):
We are working on a new language schedule, 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.
(12:03):
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
(12:27):
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 really good concept, but which is kind of difficult to implement,
(12:50):
especially in the environment when you already have a lot of legacy products
and legacy services, but still when it's very helpful when you try to bring to
market a new product or a new service.
What it means for us, it's when we talk about API-first, we talk about starting
(13:18):
product design or service design with use cases and thinking about interactions
between users, clients with your product.
This conversation drives us to creating a user-friendly interfaces, which reflects
main information flows, main use cases, as I already said, for the product design
(13:47):
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
(14:11):
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 programmability surface.
We start with users, we start with developers.
(14:33):
It should be understandable by developers who will use our APIs.
So it's why we pay so much attention to user, for example, to naming conventions,
to consistency of shape and behavior, to consistency of patterns.
We also exposed our design guidelines are public, so everybody can see them.
(14:57):
And we truly think about API design from usability perspective a lot.
That's so important.
So how much of this work is centralized versus federated across teams?
(15:18):
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
(15:42):
standards, but overall the work itself is done in different organizations.
We also, because of this ability of shifting left and reusing building blocks,
we also delegate a lot of decisions back to implementation teams and we have API
(16:04):
champions in some of our teams who overview consistency of APIs across large
products, for example, teams or let's say Azure Active Directory.
So from this perspective, we try to figure it as much as possible and enable
(16:28):
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 very interesting question and it's very difficult question because results of
(16:55):
governance is working are long-term results.
It's a strategic question.
And for us right now, this strategic question can be defined as very simple.
Based on our organizational objectives, we are building, we are building basically
(17:16):
graph ecosystem for developers.
So 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 APIs.
(17:36):
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, our success, success of API governance is success of our APIs.
(18:06):
And it means that good software product, we need to deliver good software product,
but it's not only software product.
There are a lot of specific specifics, right?
It's an API first of all.
So API needs to have a great design.
It's a cloud product.
(18:27):
So it needs to have a reliability and performance and operational excellence
according to the cloud standards.
So we designed, we designed a quality framework for our APIs, which is based on
our success definition.
(18:48):
And this quality framework consists right now from eight quality attributes.
This quality attributes include planning and roadmap, monetization, and design
(19:08):
considerations, security.
Security is essential for our APIs.
It has, 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 create, we created a dashboard to reflect
(19:34):
all this quality criteria.
We defined 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 long winded answer, but the point was that we designed, we
(19:57):
created the criteria, quality criteria to describe our success and we created
visibility, traceability for these criteria using a dashboard and the 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.
(20:19):
I've talked to a lot of enterprise groups.
It's pretty sophisticated.
How much of this, I mean, 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, is your
governance ever changing and kind of living and evolving alongside this?
(20:41):
Oh, God, I think it's a good question.
Our governance definitely to your point, definitely evolving because we started,
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 API, they expect that it will be consistent across all these
(21:05):
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 realize that design is not enough, that we need to provide
predictability, that we need to provide reliability, that we need to provide
(21:30):
operational support and all these characteristics basically are triggered
the next phase of API governance, I would say governance, evolution of the governance.
But again, governance is a strategic process and it takes long time because we
(21:54):
should think about not only external API developers, we also think about all
these hundred twenty 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.
(22:17):
Obviously they know what does it mean to deliver great technology products, but
we're talking specifically about graph APIs, for example.
This evolution goes continuously as we learning from experience as well.
And it also reflects our evolving organizational roles as we're moving
(22:40):
forward, we build new goals for organization and impact our governance
and the development of our new products.
So we need to think about how we can deliver the best API software.
Impact our governance evolution as well.
Do you feel like this gives you the strength and kind of the muscle to be
(23:02):
able to respond to whatever is going to come next business-wise for Microsoft?
Definitely, definitely.
We are very, we are very agile and what I see our strengths is in ability to
delegate to teams, important design decisions, ability to support
(23:27):
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, our
governance is not a rigid process.
(23:47):
Our governance is more, more a system with a feedback loop, which
reflects what organization needs.
But it's a little bit, it's a little bit conservative to be fair to our
developers and our API producers so that they will be, would be able to adjust.
(24:12):
Yeah.
Interesting.
Yeah.
I, I was impressed.
I've been impressed with Microsoft's ability to adapt to the cloud and respond
to, to changing market forces.
And I have worked on Microsoft technology since early nineties.
And I honestly have to say, I didn't expect Microsoft to be able to respond
(24:34):
and adjust and I'm actually, actually feel like they're leading when it comes
to APIs now and cloud infrastructure and, and across all the Microsoft products.
I'm really impressed with, with the way that the companies responded to an API
first landscape, but I want to, I want to understand more about you and cause I'm,
(24:55):
it's really hard to find people get governance at the level that you do.
So why, why does this stuff interest you?
Why, why does governance and, and this role interest you and, and as part of your career?
Sure.
Let, let me a little bit to add to your previous comment about Microsoft.
(25:15):
I want to mention, I want to mention that a lot of our API effort efforts
are actually open sourced, right?
Our guidelines, documentation are public documentation.
Our SDK generation automation is a public public open source,
(25:36):
open source project.
Cattle new language we are working on to implement patterns is also open source,
open source product project.
So we truly believe in the community involvement and I think that it gives us
strengths and flexibility for future.
(26:02):
Now answering your question, why I'm interested in the governance.
My, my passion is more about architecture and governance is just one part of the
architecture and why I'm thinking about so much about governance and architecture
because I'm seeing, I think about API ecosystem, Microsoft graphic API ecosystem
(26:29):
as a complex system with feedback loops.
And I'm trying to understand what, what you'll make this, what, what are the main
components of the system, how to model the system effectively and how to move this
system in the right direction.
(26:50):
And it, what leads me to, for example, defining criteria for success for our
governance, it's all based on software architecture practices.
And, uh, we basically applied software architecture to API as a software product
to derive, to derive, uh, qualities based on cloud well-architected frameworks,
(27:18):
like such as AWS and Azure, and augmented with our organizational,
organization specific and API specific qualities.
So this complexity of the, uh, system, system, uh, component interactions drives
(27:39):
me to the space and, um, gives me excitement every day.
So it's why I'm working on it.
Very interesting.
And I mean, we need so many more people just like you to, to fill the space
because governance is, and I don't want to say just governance, governance, the
way that you're doing this flexible feedback loops with the business outcomes
(28:01):
focused is so needed in, in a lot of the technology or IT driven API operations
that I see, but there's one piece of that.
You're what you're doing that I noticed that's really interesting.
And I would like to know a little bit more is why are you, why are you
so vocal and telling your story?
I just saw your talk at API specifications conference.
(28:22):
You're here on the podcast.
Why is it important for you to tell your story?
I, I think that, uh, importance of telling 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.
(28:43):
I really looking forward to hear feedback from your podcast because
it's what helps us evolve, right?
Also not so positive responses.
I guess, I guess it's a system approach, which I am applied consistently
to all of my activities.
(29:05):
And, uh, this is the main purpose of sharing it and bringing more people,
more, bringing more people to this conversation.
Um, I think it's important to share experience.
OK, OK.
I think the important thing, so what really
helped me, actually to talk with Pfitil and other autres,
(29:29):
for this, improve the pattern of customer experiences.
It helped a lot inرب trucking setup.
It made it easier for us to be the seasoners for customer experiences.
Um, and um, and if label
t's, I imagine is theumbled version of API Garden API's.
Specifics of protocols, specifics of design.
(29:54):
And we never thought it's not, it's not true.
Never, never say never, but we did not think about, uh, API as a holistic
product, uh, as a holistic software product and by product.
What is another interesting, another interesting thing I found for myself
(30:16):
is that when I, when we say about, when we talk about API as a product,
uh, it's not necessarily about, uh, how much money we will earn on this API,
how much money it will bring for organization.
It's about how much customer value it will deliver and how much business
(30:37):
value it will deliver, right?
And customer and business value may be, uh, accounted in different units.
It's not only in dollars.
It, it's really, uh, we really want to expand this, uh, definition.
So it's, I guess, I guess, yes, we are publicly talking about our
(31:00):
effort at Microsoft to involve community, to encourage feedback and, um,
bring more people to the API space.
This is just another one of your feedback loops, right?
Yes, exactly.
Uh, so is, is what you just described about treating API as products.
(31:23):
Do you feel like this is what's different than what we had during
the service oriented architecture days?
Do you feel like that, why, uh, APIs are working now and, and services
didn't work so well or, or failed us back then?
Um, yes, I did spend a lot of time on integration and service boss, working
(31:43):
with service, uh, enterprise service boss 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, uh, it's an evolution of service oriented architecture.
And again, uh, using our lessons learned, like, for example, uh,
(32:07):
soap XML was really heavy, was difficult to process, became very complicated.
And we deviated from it.
We moved to Jason, which is more user friendly, human readable and machine
readable.
We added some specifications like Jason schema, which is more user friendly.
We added some features like, uh, we added some features like, uh,
(32:31):
Jason schema on top of it.
Uh, but what definitely we are evolving from the, um, service oriented
architecture, another huge shift in my opinion is shift to distributed
systems, to cloud, to cloud systems, SAS systems, right.
(32:53):
And, um, shift to the hybrid, uh, business solutions, which require
distributed systems to support the business.
Just distributed systems communicate via API's.
Will it be REST API, JRPG?
Will it be some kind of low level interface?
(33:16):
It's still an interface, right?
So I API, when I think about it, it's a really generic term and it's
obviously it's application program or programming interface.
But, um, point being that with cloud, uh, with evolution of distributed
(33:40):
systems, API's, uh, API's are new focus for service oriented architecture.
Just different evolution, evolution cycle.
So do you think this will just keep going forward?
This, uh, API's will just keep reinventing and, and, and evolving
(34:01):
into the future and what we're building now will, will prepare us for that.
Yes.
I think that you provided answers to your question.
Yes.
I, yes, I think, I think that it's an evolution.
It's, it's an evolution of software.
It's an evolution of our ability with internet to communicate across different
(34:27):
systems, different regions, different countries, and, um, it's definitely,
it definitely will evolve.
Uh, I don't, I don't know how yet, uh, we are, we are learning even with, uh,
even with, uh, with API's we always see, uh, new flavors, new, uh, new languages
(34:54):
and coming up and being more popular.
And again, uh, what I'm thinking that API is a big term, right?
Uh, it's a, it's a lot because for different use cases, you may use
different type of API's for some use cases, rest API's is a perfect choice.
(35:15):
For another use cases, you may need to have a JRPG, for example, or JRPG API's.
And, uh, maybe we will have some additional unknown yet use cases when we
will need to have a new type of interfaces, which also will be API's because
(35:38):
it's system to system communication.
Yeah.
Well, I, I love your, your view of things.
You really, uh, have one of the, the more sophisticated views of governance
that I've seen out there talking to folks.
More, most people are, I would say API early or becoming to be API aware.
(35:59):
You definitely, the, the governance, the feedback loops, the product mindset,
um, is, is very progressive and very interesting to learn about.
And I think 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 cattle and why cattle exists and, and, uh, and,
and how it's going to help us kind of address the next generation of, of API's.
(36:24):
So, um, I appreciate you coming by today though.
Thank you so much, uh, for your attention for inviting me and late
letting me speak my mind.
And, uh, so if, uh, if you don't mind, I would like just to articulate
my main ideas, main points, uh, if you don't mind, uh, I, so the main point
(36:52):
I discovered for myself and we are trying to implement it that we need to
treat API as a software product, as a cloud software product.
Then we need to have, uh, we need to define API qualities based on, uh,
organizational needs, basically qualities of your software product is
(37:18):
driven by your organizational goals.
Then another thing is that you, we need to have standard building blocks to
promote best practices and we need to have this building blocks and patterns
for API's as well for API design and API implementation and automation for the
(37:40):
large scale API surfaces is essential.
Otherwise it's not, we won't be able to, uh, uh, to enable compliance
with quality requirements for API's.
And another thing for a successful API governance product, we need to have
(38:01):
observability and traceability.
And it means that we need to have a dashboard, dashboard or some kind of
metrics, which reflects how our API APIs perform in real life.
So that's not my part.
Thank you so much.
I love that.
Thank you for that definition.
(38:22):
That's very succinct and very helpful for help helpful for folks.
So, um, I look forward to feedback from, 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, uh, about some of this and see where we can go next.
Looking forward for the feedback.
(38:43):
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
slash events slash breaking dash changes.
(39:05):
I'm your host kin lane.
And until next time, cheers.
Popular Podcasts
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
True Crime Tonight
If you eat, sleep, and breathe true crime, TRUE CRIME TONIGHT is serving up your nightly fix. Five nights a week, KT STUDIOS & iHEART RADIO invite listeners to pull up a seat for an unfiltered look at the biggest cases making headlines, celebrity scandals, and the trials everyone is watching. With a mix of expert analysis, hot takes, and listener call-ins, TRUE CRIME TONIGHT goes beyond the headlines to uncover the twists, turns, and unanswered questions that keep us all obsessed—because, at TRUE CRIME TONIGHT, there’s a seat for everyone. Whether breaking down crime scene forensics, scrutinizing serial killers, or debating the most binge-worthy true crime docs, True Crime Tonight is the fresh, fast-paced, and slightly addictive home for true crime lovers.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com