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.<\/p>\n
Although DevOps has certainly garnered overwhelming momentum as a movement, it\u2019s 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:<\/p>\n
‘A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.’<\/p>\n
Meanwhile, our facilitator James defined DevOps as:<\/p>\n
\u201cThe combination of cultural philosophies, practices, and tools that increases an organization\u2019s ability to deliver applications and services at high velocity.\u201d<\/p>\n
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 \u2013 though they might change their job in the day to day.<\/p>\n
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.<\/p>\n
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.
\nThis 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.<\/p>\n
However, DevOps \u2013 or the fundamental principles at its heart – is certainly not a new idea. It merely takes Conway’s Law (1967) \u2013 that \u201cOrganizations which design systems \u2026 are constrained to produce designs which are copies of the communication structures of these organizations\u201d \u2013 to the next level, encouraging consistent iteration of team structure in line with current needs.<\/p>\n
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\u2019t have a roadmap. The goal is to give the enterprise as much agility as possible. And Devops helps engineering teams be better at agile.”<\/p>\n
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 \u2013 you learn quicker so you can change direction quicker.”
\nHow has the role of the architect changed?<\/p>\n
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.<\/p>\n
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.<\/p>\n
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\u2019re 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.<\/p>\n
Furthermore, it was raised that what the Enterprise Architect role brings to the team is the “why” \u2013 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.”<\/p>\n","protected":false},"excerpt":{"rendered":"
\u200bWhat 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<\/p>\n","protected":false},"author":1,"featured_media":2298,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[687,663],"tags":[],"class_list":["post-1820","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-attracting-and-retaining-and-developing-talent","category-hiring"],"acf":[],"yoast_head":"\n