DevOps, like other technology fields, is gathering a rich lexicon of technical terms, often with murky meanings. One such term, used interchangeably with software architect, is ‘DevOps architect’. I’ll try to clarify how we use this role at New Relic.
Let’s start with a mildly controversial statement: DevOps is not a goal. You shouldn’t want DevOps, you should want the outcomes that DevOps delivers, namely empowered teams rapidly delivering value to their customers. A DevOps team’s success arises directly from how well development and operations work together in that team. The role of the DevOps architect, therefore, is to work with teams in creating processes and tools to ensure the software release pipeline flows smoothly, safely, and efficiently.
The ultimate guide to DevOps: everything an enterprise needs to know
The scenario facing a DevOps architect today is that their DevOps teams are moving fast, keeping pace with the imperatives of their organisation to release software that continually improves customer experience or grows revenues profitably, for example.
The responsibility of the architect in this environment is to work with the team to create a continuous development environment that both enables speedy development and deployment and protects the future of the organisation. Critical for the architect is the choice of tools that can help automate and streamline processes. To be successful, you must identify those tasks that are holding back DevOps teams and deliver on embedding comprehensive best practices.
However, while they may have several teams constantly changing software, part of their value as a DevOps architect is to take the long view. This is about guiding those teams to do the right thing for their organisation, while also realising the software needs to be released.
There might appear to be an obvious tension here. Sometimes an architect may have to allow a team to release software that is, maybe, 80% “good” because of that imperative to ship out a crucial update on time. This doesn’t mean the architect relinquishes their responsibility to ensure the software teams are moving fast safely. Once the release is out there, the architect needs to lead the team on working on a fix for next time.
How to build a DevOps team — 6 principles for success
To enjoy the trust of the DevOps team, an architect needs to have considerable, hands-on experience of building software and familiarity with the tools and processes facing their DevOps engineers. At the same time, the architect should also exhibit empathy with the team. Teams are often put in positions with competing objectives and need support and guidance in choosing the one that is best for both them and the organisation. The architect may have to run interference with management to allow the team to get their good work done.
A natural source of good DevOps architects is the pool of DevOps engineers within an organisation, as they possess the intimate knowledge and insights into how to make the team perform more effectively. A solid understanding of the concepts of how to build, in this case, better software faster are key attributes; as is a willingness to accept the need for continuous learning to keep abreast of important changes in tools and best practices.
Although, a strong DevOps architect also needs to have broader leadership and communication qualities. As the overall team leader, they must be inspirational to the team as well as being able to counsel on problems and other issues.
DevOps vs Agile: pulling in the same direction in the enterprise
In this respect, the architect can play a crucial role in how a DevOps culture is fostered. Simply reorganising the software organisation to combine development and operational team members isn’t going to close the cultural gap between those who prize software code innovation and those who worry about operational performance. The architect can be the practical visionary who works to narrow the distance. This means more than just investing in tools but also conducting daily product or project stand-up meetings with both groups. Periodic breakfast meetings or brown-bag lunches can encourage the teams to share their points of view about the development process and ways that everyone could benefit from working together.
As a leader, sometimes the role is about shielding the DevOps teams from the rest of the organisation and preserving the right of the team to be left alone to focus on their work.
DevOps is about significant cultural change, and experience has shown that its promise isn’t realised unless someone leads from the front. A DevOps architect can be that leader who defines the architecture for delivering DevOps for the entire organisation, and then ensuring the teams deliver what is needed. It is unsurprising that high performing DevOps teams are associated with successful DevOps architectures of tools, processes and best practices – assembled and maintained by someone who acts like, and is increasingly titled, an architect.
How DevOps works in the enterprise
As an architect of head-turning physical buildings including Paris’s Pompidou Centre and London’s Shard, Renzo Piano once said: “Architects spend an entire life with this unreasonable idea that you can fight against gravity.” And similarly, DevOps architects seek to defeat the physical laws that conspire against organisations delivering superior software at breakneck pace set by market forces. It is a young and emerging role that will be of increasing importance as DevOps teams grow and proliferate.
With the increasing desire for a “bigger picture” view cross functionally, DevOps technology has become more of a strategic function for organisations today. The success of DevOps comes from how well the development and operations work together. This can be achieved through a mix of technologies, tools, and processes. The role of the DevOps architect is to oversee all those processes and teams to ensure the pipeline of software releases flows smoothly, safely, and efficiently.
