[MUSIC PLAYING]
SPEAKER: Hello.
Let's talk about API program governance.
What is governance, and more importantly,
how would that apply to your API program?
Governance is defined as to rule and control.
But in our fast paced environment
where innovation is key to attaining
that competitive edge, heavy ruling
can control or slow down things.
And slowing things down, progress can be impeded.
Governance when applied to the API first model
is a balancing act.
We need to manage risk while enabling
speed and agility in order to meet the consumer's needs.
We don't want heavyweight authority, control,
or regulation, and this is why we call it a little g.
Finding the balance depends on your organization:
startup versus traditional enterprise, risk appetite
versus speed requirement.
Let's talk about the keys to managing risk
while still maintaining the ability to meet market needs.
The balance comes from an intersection of 4 components.
First are the key roles within an API team.
Second is the structure of the team focused
on the digital initiative.
Third is the ownership of the API products,
and the fourth and final component
are the simple guidelines and structures around the platform
for ease of adoption.
As mentioned in the previous video around API team
composition, it is essential to have an API team
leader who is aligned with both the business and IT.
This role is called the API product owner,
and it is a key component to ensuring
that the APIs built target a priority business outcome.
Central team defines API development standards
and developed APIs based on the requirements from product,
project, and business unit teams.
This model allows for consistency and development,
approach, and adherence.
However, this model lacks the agility
that some of the other models have.
A decentralized operating model has the agility and the speed,
but lacks the standards and common development
best practices.
This combined with a lack of clear ownership
after the APIs are released showcases
how different this model is compared to that
of the centralized model.
So now we arrive at the hybrid model.
This model possesses the speed and agility
of the decentralized model while also maintaining
a close adherence to standards.
The downside is that a lot of coordination
is needed when it comes to the requirements
across multiple teams.
So who owns which APIs?
Ownership of the APIs, or the components
that make up those APIs, is dependent upon the operating
model.
For example, in a hybrid model, the platform team
is responsible for setting guidelines, standards,
and the reusable assets.
Reusable assets are in the form of shared flows or shared
services that adhere to a common practice such as security,
traffic management, or air handling.
This frees up the specific product, project,
and business unit teams to focus on API supporting
their business objectives.
Delivery can be much faster when the teams don't
have to worry about the standards for common assets.
Reusable assets can be selected from an a la carte
menu to include in the delivery team's API product.
Big G Governance is what most companies end up with.
This assumes that the teams are not
trusted to do the right thing, and result in heavy gating.
Committees like change approval boards
are formed to manually audit any change that
are pushed to deployed systems.
Policies and procedures are written into heavyweight Word
documents, and teams are split by function, as they are not
trusted to work together.
Little g governance is harder for an organization to swallow,
as responsibility and accountability
is pushed down to where the decision needs to be made.
It provides enough governance to keep
the teams on the right path, but doesn't seek to slow delivery.
Now let's run through an analogy of a freeway.
While you're on a freeway, the direction
is set, but can be changed at junctions.
Guard rails helped keep cars on the right side of the road
and traveling safely in the right direction.
Lanes are painted to suggest the right way to drive,
but can be crossed if needed.
The emphasis here is on keeping the flow.
Now imagine if big government was in control.
Every time you needed to accelerate, slow down, change
lanes, or even change direction, someone else
would need to have to review that decision
and approve it for you.
Now imagine what that would do to traffic.
Little g governance provide standards principles
and best practices.
Teams are trusted and empowered through tooling and automation.
Information and documentation is shared collaboratively.
Teams are cross-functional to minimize handoff
and communication issues.
Going back to the freeway analogy,
little g governance operates how we think of freeways today.
Organizations have hierarchy.
What tends to happen is that we push information to authority.
The people at the bottom have the information,
but they don't have the authority to make the decision.
This results in bottlenecks and delays.
We create systems that channel information up,
where decision is then taken, and then
that information comes back down again.
As you can imagine, this tends to take a lot of time.
And alternative is pushing authority to the information.
The foundation for this model is making sure
that the people that are closest to the information
are both technically competent and have
organizational clarity.
They understand the priorities and know
what the right thing to do.
They are empowered to make the decisions, and as a result,
they are happier for it.
If your organization is truly undergoing
a digital transformation, it is deeper
than building a mobile app or putting some APIs
on a developer portal.
Think about why your company started this initiative
in the first place.
If the benefits include reducing costs and accelerating time
to market, then the initiative has
to go well beyond that of just building APIs.
To achieve those aims, imposing a heavy weight process
that encourages blind compliance with no room
to accelerate delivery will at best slow, or at worst,
stop the benefits of the program.
To achieve those aims, imposing a heavy weight process
that encourages blind compliance with no room
to accelerate delivery will at best slow, or at worst,
stop the benefits of the program.
Much of the time governance, processes
are imposed top down, and borne out of quick resolutions
to problems encountered.
The gates imposed often have documentation
required at each stage, which are
slow to produce, and discourage effective communication
between teams.
Ultimately, the focus is on the process protecting
the organization from the IT teams, who they don't
trust to do the right thing.
This is done so rather than accelerating business outcomes
in a safe manner.
So how do we apply this to the API governance model?
If a centralized team have all the authority,
then we can't scale, and agility is inhibited.
We must give developers, publishing or consuming APIs,
the information and knowledge they
need to publish and use those APIs thank you.