What does the Architect of the future look like? Is DevOps as a methodology reducing the importance of the Architecture function?
It was great to host this event for senior leaders in the Architecture space, facilitated by Director of Technology at Publicis Sapient, James Betteley. We discussed the broader context that DevOps brings as a methodology and culture and how this affects traditional Architecture functions across the industry. We also examined how best to integrate the two.
What is DevOps?
Although DevOps has certainly garnered overwhelming momentum as a movement, it’s likely that if you ask ten people, you’ll get ten different definitions of what it actually is. Technology advocate Ken Mugrage described it as:
‘A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.’
Meanwhile, our facilitator James defined DevOps as:
“The combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”
These two definitions aren’t oxymoronic. In fact, they summarise the evening’s discussion pretty well. DevOps facilitates collaboration in order to function at speed. Neither of these things threaten the role of the architect, who aims for both – though they might change their job in the day to day.
Culture Clash
DevOps is a means to an end rather than an end itself, and should be treated as such. Being able to move at pace is essential to survival in the current tech climate, and DevOps is a way of facilitating this.
Where there are often problems is where there’s a clash between “the agility versus stability paradox.” Many attendees cited the difficulty of integrating DevOps architecture with the more traditional ERP world: in particular deciding which parts of this might be worth migrating vs consolidating, and where there is capacity for co-existence.
This is not least a culture question. DevOps inspires an almost religious zeal in its proponents, particularly young software developers, which sometimes can be difficult to integrate with other factions of the business.
Stop trying to make DevOps happen, it’s already happened
However, DevOps – or the fundamental principles at its heart – is certainly not a new idea. It merely takes Conway’s Law (1967) – that “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” – to the next level, encouraging consistent iteration of team structure in line with current needs.
Indeed, it was suggested that it was less of a movement, and more of a “catch-all term for best practice,” with one attendee citing “I don’t have a roadmap. The goal is to give the enterprise as much agility as possible. And Devops helps engineering teams be better at agile.”
Since the role of the architect is to help businesses survive, and the law of the animal kingdom is currently adapt or die, then DevOps isn’t incompatible with Architecture at all. As another attendee described: “DevOps is about is learning – you learn quicker so you can change direction quicker.”
How has the role of the architect changed?
However, this isn’t to say that DevOps hasn’t affected the role of the architect. A particular difficulty with “doing” architecture for DevOps, is what a culture of innovation looks like structurally. While many organisations owe their early successes to being able to get a good idea out quickly, this becomes more of a challenge as they progress to economies of scale.
Increasingly, centralised architecture functions are being split up into more specialised functions within individual teams, with fewer enterprise architect roles, often imitating the Google SRE Model or the Spotify ‘Chapters & Guilds’ model. Many of the attendees were appreciative of this outcome-based approach, which is focused on cross-functional collaboration, outcomes and shared responsibility, in an effort to prevent the silos and dependency which can inhibit innovation.
Death of the enterprise architect?
However, as one attendee pointed out, part of the reason Google and Spotify can explore such structural freedom is because their product is entirely online, and therefore they have few physical constraints to contend with. They’re also not restricted by a strict regulatory environment. For many businesses, this is not the case, and they need an architecture function which reflects their own context.
Furthermore, it was raised that what the Enterprise Architect role brings to the team is the “why” – the qualification for what you’re trying to solve in the wider picture, something which can get lost in the evangelistic excitement of DevOps. As one attendee put it: “The enterprise architect role doesn’t intend to stop ideas. It’s how to deal with the amount of ideas, and the order they’re prioritised in.”