The last few years have seen the phrase "Shift Left" become popular. It started with testing, and moved rapidly on to infrastructure and security.
For me, this has been a very natural progression for teams that are working in an agile, cross functional team. Once you are focussed on rapid releases and highly automated deployment pipelines, the idea of sending code off to a separate testing team seems painful and anachronistic. DevOps and Infrastructure concepts were much more dramatic and challenging, but can be seen as a natural response to the opportunities presented by cloud technologies. Once you can provision servers with just a few lines of code, why maintain the inefficiencies of a completely separate infrastructure team?
So what about Architecture? They key to this lies in the changes brought about by cloud capabilities, but first I'm going to take a step back and look at what it means to be an Architect in 2024.
There are lots of different types of Architects - certainly lots of different Architect job titles!
Quick thought : The job title "Architect does seem to be much more common in the UK than the US. "Principle Engineer" is a more popular term in the US, and the name itself insinuates that this shift left is already happening/has happened. It might be that this article isn't particularly exciting for teams that have already moved forward, but hopefully it can add some value for teams at the start of the journey.
So what exactly does an Architect do anyway?
The work of an Architect typically falls into the following categories:
Technical Leadership
Explaining key technical concepts and technologies to senior stakeholders, communicating key business strategies to technical teams, assessing capabilities, and (most important of all) drawing lots of beautiful pictures.
Technical Co-ordination
This is especially prevalent in project that require the co-ordination of multiple tech teams. Brokering compromise and agreeing integration points. Ensuring that the key non-functional requirements are fully understood by the technical teams.
It's this second capability that seems the most ripe for shifting and updating. Bluntly, Engineers really don't like the idea of a separate team designing systems and then asking them to deliver them. It's not an engaging or collaborative approach, and hopefully it's not too common these days (Note: It definitely still happens , I have seen it first hand).
How Cloud changed the way I work
I was naturally extremely excited when I was asked to lead Company X's migration to the cloud. There were some clear and obvious wins for our project - it was going to bring some immediate performance and scalability benefits, but also open the door to new technologies that simply weren't available on our on=premise estate.
My initial thoughts were that I would be producing a set of beautiful "template architectures". These would look like the diagrams that Microsoft make available at the Azure Architecture Center. I would ensure that my "blueprints" met our companies stringent security standards, the Cloud Platform team could create Infrastructure as Code templates, and we would happily wander off to a world of harmony and technical efficiency.
There were some immediate problems with this.
It was overly simplistic. The engineers didn't need a diagram showing an Azure Web App connecting to a database - they already knew thats what they needed. The issue was with the implementation details. How were we going to make a decision about the web app configuration? How were we going to implement a secure connection to the database? This was also exacerbated by the fact that, in my experience, absolutely nothing in the cloud works exactly as advertised (at least not without a bit of nudging and tweaking).
That last statement might feel a little harsh, but it was certainly true that nearly everything we tried to do required us to compromise or deviate slightly from standard patterns. This was often because the applications we were migrating had technical debt, or our desired end-state wasn't possible because of other organizational or technical restrictions.
For example, a few years ago, Microsoft introduce d the concept of Managed Identities for securing services and promoted it heavily. The issue was that not all Azure services supported Managed Identities - at least not at first. This is the sort of detail that makes technical leadership difficult. It's easy to say "always follow this pattern". It's a lot more difficult to work through all the permutations in advance and publish helpful guidelines. In reality it's a lot more practical to identify and resolve these issue whn working closely on the specific project or use-case...
...and finally we get back to the need to shift-left with Architecture.
During the cloud migration project I found that I added far more value when I was able to get closer to the code.
This didn't mean that I was necessarily contributing to the production codebase on a regular basis, but demonstrations, POC's, code snippets etc were all really valuable to the developers.
POC's in particular often served a dual purpose. I was able to address knotty technical issues ahead of time, but I also had artifacts that I could use to communicate key concepts to a wide group of stakeholders. Non or less technical team members respond really well to visual demonstrations. It's a tactic I've used throughout my career, and it always seems to have a great payoff. I get to gain a solid understanding of the technology (which earns respect from the tech teams), and I get to demonstrate key technology changes at an early stage with an interface that'sa lot less complex tha the final product.
Over the last couple of years I've worked extensively in the world of large scale cloud data analytics, and this has definitely been helped by my ability to demonstrate. Explaining concepts like data virtualization can be difficult without the ability to show and tell. If I'm pitching or proposing a new technology it's particularly effective if I can find something that is currently unachievable with the organizations tech stack, and neatly show how the issue can be resolved.
So it's a yes to shifting left then?
Yes. I do find that people can get a bit weird about the idea of senior leadership staff coding or tackling technical tasks, but I think this is outweighed by the benefit that it brings to the actual development teams. "Working software over comprehensive documentation" doesn't mean we abandon all documentation, it means that we only write the documentation we need - and no more. It's a principle I try and abide by, and I'd encourage others to do the same.