[Instructor] At the intersection of DevOps values
and disparate, siloed teams,
focus on the C in CAMS,
the value of culture breaking down barriers.
There are many dimensions along which
you can break down barriers,
even if you can't combine disparate siloed teams.
The first thing to do is to ensure that,
regardless of where they sit, Legacy or Cloud,
your teams have one shared objective:
fast time to value, with quality and continuous improvement.
This North Star goal must be recognized universally
as the end in mind,
with the understanding that the means
and level of achievement
may differ by platform due to constraints.
Then, work to reduce barriers among teams,
starting where they payoff is biggest.
You may not be able to break down all barriers,
but chipping away, you can approach the DevOps ideal.
And while we're discussing breaking down barriers,
note that in some cases
there's still utility in putting up barriers.
It's just that they may be in different places.
For example, identity management is often set apart
from the rest of the organization
to avoid conflicts that occur when combined.
At the intersection of DevOps principles,
the three ways, and disparate siloed teams,
focus on the third DevOps principle:
establishing a culture
of continual experimentation and learning.
One thing you can experiment with
to help orchestrate disparate siloed teams,
is to try devising a standard partnership approach
to how we work with other teams, establishing patterns,
and then working to drive all teams
to that aligned approach.
Start with essential partnerships like QA, Build and Deploy.
They may be siloed, but work to make sure the teams
are small enough to have a conversation.
The DevOps method that stands out
for use with disparate siloed teams
is the lean practice of value stream mapping.
A method used to document, analyze and improve
value flow from a product or service to a customer.
Value stream mapping can highlight
breakdowns and bottlenecks that can be worked on
to improve orchestration across disparate siloed teams.
And if you can't break silos,
think about how you can reduce or remove dependencies
so as to lower conflict and the need for orchestration.
For example, if you move to Containers,
your server team will no longer be custom-building servers,
and the need to orchestrate with them goes away.
If you move to versioned APIs and the use of data contracts,
you remove two dependencies
that often cause breaking changes
and reduce the cross-team orchestration
required to sort out those dependencies.
So the advice here is simple.
Take a key product or service and do value stream mapping.
Have a hard look at the "why" of orchestration,
and root out any unnecessary dependencies.
Three DevOps practices are essential
for bringing together disparate siloed teams.
Devs on call, embedded teams, and blameless postmortems.
The DevOps practice of embedded teams
can help bring down barriers between disparate siloed teams.
An embedded product team
consists of all the people and skills needed
to independently take products all the way
from requirements to delivery.
In DevOps, which is Dev + Ops,
the place to start is by embedding Dev representatives
in Ops teams and vice versa.
Devs on call is simply taking a,
"you dealt it, you deal with it" approach to systems,
with the idea that more attention will be paid
to both functional and non-functional requirements
if the Dev who developed the system
must deal with supporting issues with it
later downstream in ops.
Lastly, look to adopt the practice of blameless postmortems
after major incidents, failed changes and releases,
and disasters.
That can help bring down the barriers
between disparate siloed teams as well,
driving more of a
"It's just us" versus "Them and us" culture.
At the intersection of DevOps tools
and disparate siloed teams,
it's important to get the teams interested in the tools,
to get them exposed, for example,
on how we can bring code into a common repository
and to get scripting going, get everybody writing code
for on-prem and cloud-based systems.