DevOps

Understanding DevOps personas and perspectives

Recognizing the different DevOps personas and understanding their unique perspectives will help to improve collaboration and drive alignment across teams and initiatives. 

 

Despite good intentions, many traditional IT organizations struggle to show successful outcomes from DevOps initiatives quickly enough to generate and maintain momentum. Early attempts can be hampered by a steep operational learning curve, resistance to change (“we can’t because…”), and poorly aligned expectations. To avoid these pitfalls and accelerate these DevOps initiatives, teams should identify the different roles that participate in the application lifecycle and work to understand what drives them.

 

Dev and Ops – Ships passing in the night?

Infrastructure and operations teams and their developer peers have a long history of working together, separately. Separate priorities (agility vs stability), separate processes (automated vs manual), and often separate and unaligned leadership. How can organizations help these passing ships navigate choppy waters together without causing a maritime disaster?

 

The “Ops” Challenge

Many customers have shared the difficulties encountered trying to transition traditional “Ops” into application DevOps teams. This is understandable. In some cases, organizations have simply re-shuffled – taken their best operational resources and moved them into application teams. Often times these resources are ill prepared – an infrastructure resource landing in an application team without the necessary tools, processes, knowledge, or organizational support to succeed can be left feeling frustrated and isolated.

 

The “Dev” Challenge

In other cases, organizations will simply assign the management of an applications infrastructure components directly to the developers. Many application developers are not thrilled by this. Firstly, they are motivated by building new features, not messing with “unexciting infrastructure”. Secondly, once the developer discovers that the shared infrastructure teams cannot provide the capabilities that they need to be effective (for example, infrastructure as code) they do what developers do; find an innovative way to get what they need. This is often in the form of procuring public cloud services, circumventing the internal infrastructure teams all together.

 

Stalemate?

Neither of these approaches is ideal or result in outcomes that are in the best interest of the organization. What is needed is to empower traditional infrastructure teams with the concepts, capabilities, and process changes that enable them to be valuable contributors to the software development lifecycle (and to benefit from these automation and integration best practices across other operational functions).

 

DevOps Personas

The Provider / Consumer Continuum

To help bring clarity to how the journey affects different parts of the technology organization, we map DevOps personas to two perspectives – the provider and the consumer. This can be in the context of infrastructure services, cloud services, or any other service typically provided by the IT organization.

These perspectives are not unique to any one role, instead each role will lean more towards one side of the spectrum than the other. DevOps personas that fall towards the middle of the continuum suggest an organization or team that is farther along in their journey. Some roles may be considered providers of one service and consumers of another.

Consumers

Towards the Dev side of the continuum are the consumers of services – lines of business (LOBs) and developers, roles that can reside within or outside of the application DevOps team. They are consumers of infrastructure runtimes for their applications, and their priorities include:

  • Developer productivity & application agility
  • Everything as code and robust APIs
  • Shorter release cycles
  • The inclusion of infrastructure runtimes in their testing and deployment pipelines

 

Providers

Towards the Ops side of the continuum are the providers of services – traditional infrastructure teams (outside of the application DevOps team) and SREs (within the application teams). They are providers of the infrastructure runtime and services for the application, and their priorities include:

  • Visibility and governance
  • Delivering services quickly and reliably
  • Operating consistently across clouds

 

The DevOps Lifecycle

Different roles will approach the phases of an application lifecycle with different expectations, priorities, and requirements. Understanding what drives each other leads to more collaborative, empathetic engagements. And knowing what to listen for can help teams realize that they are actually prioritizing the same outcomes, but from different angles. Here are some examples of concerns that you may hear from different DevOps personas at different phases of the DevOps application lifecycle:

Plan What are my options for curated platform services? How do I curate a set of consistent services across hybrid & public clouds?
Code How can I experiment with new features confidently and securely? How do I manage infrastructure and policy as code?
Build How do I build my application with embedded security and monitoring? How do I detect and remediate misconfigurations and vulnerabilities?
Test How do I include infrastructure components in my CI/CD pipeline? How do I ensure that infrastructure components are included in testing?
Release How do I continuously update my environments images, config & code? How do I keep up with developer demands without sacrificing quality?
Deploy How can I seamlessly provide resiliency for my application? How can I ensure infrastructure always meets application demands?
Operate How do I manage costs across a complex multi-cloud environment? How do I avoid configuration drift and continuously enforce policies?
Monitor How do I ensure my services are always up and running? How do I correlate data sources to troubleshoot more quickly?

 

Closing the DevOps gap

When an organization has a clear understanding of the personas on both sides of the DevOps spectrum, the chances of successfully meeting requirements for both sets of priorities increases. Aligning DevOps personas to a consumer or provider perspective can help accelerate efficient prioritization, as well as driving a holistic approach to setting achievable objectives.

Selecting solutions that both assure developer productivity and support operational requirements (like embedding security, testing, and monitoring into the release pipeline), will drive further alignment.

VMware Cloud Management solutions deliver the capabilities to support each stage of the DevOps lifecycle, from both the provider and the consumer perspective.

Other posts in this series

 

 

 

 

 

 

Learn More!

Recommended Reading

Other posts in this series

Mandy Storbakken

An early adopter of Cloud technologies, Mandy Storbakken has lived through the good, the bad, and the ugly of driving transformation through technology. She draws on these experiences to shape…

Related Articles