1. A Process Divorced from Responsibility Is Meaningless

Software architecture matches organizational architecture, and this shows up not only in functional boundaries but even more in the division of responsibilities.

Only clear responsibility boundaries can build good team collaboration and growth. Every team and every person should understand their own goals — what they should take on and what they should stay out of — and invest their time and energy in things that benefit the primary goal, rather than sinking into trivia. That way team members will not be so worn out, and there is a chance to accumulate some domain knowledge and to think with depth.

Clear responsibility boundaries are hard. This is not a management problem but an execution problem. A process may involve a great many people, but the professional level of those people in their respective domains is not necessarily on the same tier. Usually, the clear boundaries we see at large companies owe a great deal to the fact that they hired a bunch of outstanding people. In small and mid-sized companies the proportion of outstanding people is small, and once a weak link appears at some step, others have to fill in. That breaks the boundaries of responsibility and leads into a state of no process.

The breakdown of responsibility boundaries keeps the team permanently in firefighting mode. Every time a problem arises, people on the team do not attend to their own scope of responsibility but depend on a handful of firefighters to put out the fire. Because these firefighters know the whole process well and handle problems quickly and well, they get used more and more readily. But this is not a sustainable approach: as the business grows, problems will only multiply — yet can the firefighters grow in proportion as well? Whether at different business stages we still need a different proportion of firefighters is a question worth continuing to think about.

The following mainly discusses two collaboration processes: DevOps and SRE.

2. DevOps Goes Right

As the figure below shows, from the perspective of workflow, DevOps goes to the right.

On the pipeline, developers use the platform to complete requirement management, coding, compilation, deployment, and so on in sequence. This simplifies the whole process, and it does not form the classic loop either.

DevOps emphasizes end-to-end value delivery: one end is the requirement, the other end is the user. Only from requirement to delivery into users’ hands does it count as one complete DevOps iteration.

DevOps does not emphasize measuring and managing the delivered value, which is a marked difference from SRE.

Although delivery is completed self-service by R&D, operations and ops-development personnel support it. Ops-development personnel mainly provide automation capabilities, lowering the barrier to delivery and raising delivery efficiency. Operations personnel mainly act as experts, providing domain guidance and designing the whole process.

3. SRE Goes Left

As the figure below shows, from the perspective of workflow, SRE goes to the left.

If DevOps works somewhat like KPI, then SRE works more like OKR. DevOps starts from the requirement, makes a good plan, advances steadily, hands over one process after another, and finally goes live and delivers to the user. SRE is different: SRE has the goal first, and then considers what efforts should be made and from which aspects to start in order to reach the goal.

There is also a saying that SRE is a kind of best practice of DevOps. I think this is merely a conceptual generalization, because the objects the two discuss overlap too much. Rapidly evolving concepts always attract all kinds of interpretations and extensions. But here we can clearly see a difference between DevOps and SRE in their workflows.

Let us look at the SRE workflow together. First, operations personnel or domain experts define the core SLI metrics. The purpose of defining metrics is to make things measurable. Only when business metrics can be measured can business metrics be managed. Next, based on the manager’s OKR, the relevant SLO target — how much should be achieved — is set. Then R&D personnel improve the business in line with the SLO target.

After the SRE workflow, one more pass through the DevOps pipeline is needed before it can be released and go live.

4. Summary

This article has mainly discussed the importance of the division of responsibilities to a process, and the two workflows of DevOps and SRE. It does not set DevOps and SRE against each other. In fact, the SRE workflow also needs the support of the DevOps workflow; they do not exist in isolation.

On the other hand, the applicable scenario and the business stage matter a great deal too. Directly assigning an SLO for a brand-new business is not appropriate, because the SLI is not easy to define and measure; at that point the DevOps workflow should be adopted, iterating steadily and releasing as you go.