Accessibility Links

Is Agile Killing the Architect?

21/10/2016 By James Lewis

Is Agile Killing the Architect?

In May 2016 we held a debate around this timely question. However, the opinions on both sides were so strongly put last time, it seemed a good idea to re-run the session with a different crowd.

So we did it all again. Interestingly, some believe that the question “Is Agile killing the Architect?” doesn’t need a debate. It’s a closed question: Agile has killed the architect. Though this felt like news to the architects who did attend. We were delighted to have Jim Stevenson and Julian Browne as our speakers and thanks to Rudi De Sousa & Kamil Haq for joining the panel.

As before, the two sides of the argument were put: Julian Browne made the case that, whilst architects are having to radically rethink their role in a world that values practical localised insight over enterprise bureaucracy, a company’s technical architecture is one of its greatest differentiators and therefore deserves specialist attention. Jim Stevenson of the Bletchley Group countered with the view that the shift in the way modern companies deliver projects has in effect removed the need for the role entirely – that is to say thinking in terms of products, rather than projects, means team coalesce around concepts that free them up from top-down thinking, allowing them to deliver in a more agile way, focusing only on their contracts with other product teams. Both sides agreed that high quality software engineering practices are the secret to agility and microservices got a few mentions as an architectural approach that seems to promise agility, but demands sophistication and maturity to achieve.

Key Takeaways

Agile is a Given

In a change from the first session, there was universal agreement that agile is the only way to deliver projects. The first time around there was some debate about agile being simply another methodology that may or may not be relevant to a team. It was also agreed that very few companies are actually doing agile properly. In general we know what good looks like, but we recognise the cultural gap between where we are and proper agility.

Some Aspects of Business do Require Centralised Thought

Another point of agreement was that there are technical features of an architecture (notably: logging, monitoring, heath checks, possibly some aspects of build & deployment) where consistency is a benefit. What was not agreed was whether it is the role of an architect to manage those standards. In fact the term Tech Lead was used a few times to indicate a senior knowledgeable person who might create consensus, but from a position of natural technical seniority, not because they had been given the title of architect.

Big Companies are in trouble

A great deal of the debate amongst the attendees focused not on agile or architecture (although both are implied) but on how large organisations are attempting to innovate their way out of a competitive crisis. With smaller (more agile) businesses coming onto the scene all the time there is a struggle to maintain market share and hold on to valuable staff who might be tempted to go and work somewhere smaller and more fulfilling. Whether this is a threat in regulated markets remains to be seen – operating in a field that comes with compliance and legal directives makes it hard to be agile whatever the role of architects might be.

The Name (Again)

The session wasn’t quite as confrontational as last time. But if there was a contentious point it was, as it was the first time around, the term “architect”. Remove the grand implications of being a master builder and there’s was surprising agreement between the attendees of both sessions. There’s very little value in architects merely drawing impractical pictures of the way the world should look, nor is there value in governing projects from the outside without the context of delivery challenges. Modern architectures rely on solid engineering practices. There is value is giving product teams technical assistance, but it has to be that: assistance that makes things go faster, not interference that slows projects down for the sake of arbitrary alignment to an idea.

*thanks to Julian Browne for his contributions to this event summary.

Tagged In: Recruitment
Add new comment
Latest articles