- [Instructor] ITIL cites the accountabilities
and responsibilities of three process-related roles,
process owner, manager, and practitioner,
and the service owner role.
I don't want services and processes to be owned
to ensure somebody clearly identifiable
is making the health of their own processes or services
visible to the rest of the organization,
someone who could say quantitatively with numbers
and qualitatively with feelings
what the state of the state is for that process or service,
and how we're doing with that process or service.
This ownership does not replace shared ownership
for process and service success across teams.
It's just useful to have a concentration point
to ensure information
in the health of each thing worth managing
is accessible and transparent.
Owners own their processes and services full up.
It's the buck stops here with them.
Process owners may not in large organizations
coordinate the process day to day.
This is the responsibility of process managers.
Process practitioners,
they carry out tasks within processes.
They're the engineers for example who flatten
and rebuild servers based on a change order.
In devops, everyone is accountable and responsible
for the overall success of the product or service
and is committed to fast time to value
with quality and continuous improvement.
So is there still a role for individual accountability
and responsibility in devops?
In a word, yes.
Do you remember the story of the four people named
everybody, somebody, anybody, and nobody?
It goes like this.
There was an important job to be done.
Everybody was sure that somebody would do it.
Anybody could have done it, but nobody did.
Somebody got angry about that
because it was everybody's job.
Everybody thought anybody could do it,
but nobody realized that everybody wouldn't do it.
It ended up that everybody blamed somebody
when nobody did what anybody could have done.
Okay, you can stop laughing,
but this is precisely the situation we want to avoid
with everybody, somebody, anybody, and nobody with devops.
With devops, there's still the need to ensure
information in the health of services and processes
is transparent and widely accessible.
How that gets done may be different
than ITIL's process and service ownership,
but somebody, no not the somebody in the story,
but a named person should own full up what is done
for processes and services.
With devops, there is still a need
for day to day process facilitation,
what in ITIL is performed by the process manager.
How that gets done will differ greatly with devops.
For example, instead of presenting a locked gate
as the change manager,
you provide an unlocked gate,
lots of warning signs and install cameras.
You go to a trust and support and verify posture
versus a just say no posture.
Thanks to Delabor Sabaki for that example.
But you still need a named person
to be responsible for this.
It's just how it gets done looks different.
With devops, there's also still a need for tasks
like putting bits on boxes.
It's what in ITIL is performed by process practitioners.
And while how that gets done will differ,
especially in terms of automation with devops,
it still needs to get done.
ITIL also includes the Responsible Accountable Consulted
and Informed or RACI model as a best practice
for identifying the correct level of involvement
for roles against activities.
In addition to the accountable, the owner,
and the responsible, the manager,
there are those people or groups
that must be consulted, that's the C,
and those who must be informed about activities,
that's the I.
RACI is cited as a best practice in ITIL,
but it runs counter to many devops practices and values,
especially shared ownership and breaking down barriers.
So it seems RACI may be at odds with the devops ethos
where everyone is accountable
and responsible for everything.
Matthew Fellows in his blog goes as far as to say
that RACI destroys devops
and recommends replacing RACI with a different model SOAR
which stands for Shared Ownership and Roles
based on expertise in which he believes is more aligned
to devops values, principles, and outcomes.
So at this intersection, at least consider Matthew's advice
and tread carefully when it comes to RACI with devops.