The Modern Architect - Technology Pilots

shutterstock_1021731178.jpg

The concept of the architect has gone through some transformations in recent years. Agile has had a huge impact on that. The big upfront design most synonymous with the traditional architect is being discarded for smaller, iterative, and more adaptive deliveries. And that’s a good thing. But it has left the traditional view of what an architect is in some limbo. As a result, there’s sometimes an idea that the architect role is no longer needed. In many organisations today, arguably “architect” is more of a job title (with the higher pay associated with it), rather than a role on a team. 

I believe in having architects, but only if they bring discernible benefit, and only those who have managed to adapt their style to the modern development team's needs.

Traditionally, architects fell into broadly two camps.

  • The reactive architect would work closely with teams, largely in a support role, to provide solutions to problems the team comes across daily. Usually very technical, often quite hands-on. 

  • The proactive architect tended not to have many dealings with the teams, designing things in isolation, determining the “strategic” and “target” direction. They also tended to do this on a long cadence. They would not always be from a technical background, rarely touching or looking at code, but focused on marrying the business and system needs.

Neither camp fits into my model of the ideal architect, or at least what I believe an architect should be. My favourite interview question for architects is “What is an architect?”. There isn’t one answer or an ideal one. I’m generally looking for clarity of thought on their concept of the role. But there are some wrong answers. 

So, what should a modern architect look like? First of all, the compulsory one-line definition.

An individual that serves to remove short, medium and long term technology impediments to delivering business and product strategy quickly, safely and predictably.

The modern architect maps out the quickest and safest path to go from where they are to where they need to be. The modern architect reacts when problems arise by working with those closest to the problem to identify a solution. The modern architect looks along the road to pick out potential oncoming impediments and charts a different course if needed. 

Think of them as pilots, captains of a plane. They work out a route before departure. During the flight, they work with their team to react to passenger issues or unexpected weather changes. They will also keep an eye on upcoming potential causes of turbulence (e.g. rising hot air zone), and change course to avoid it before it causes an issue. But they will still arrive at the same destination as fast as possible and safely. Architects are Technology Pilots.

The modern architect working in an agile environment needs to be reactive and proactive in equal measure, in a constant short and long-term decision-making cycle. Short term tactical decisions need to take into account the long term strategy, while long term strategy needs to adapt to the short term decisions made. In military decision-making parlance, this is a cycle akin to the OODA Loop. OODA is a decision cycle that constantly observes your environment and adapting based on those observations. 

How does this work in practice? We can look at one of my experiences as an example. I was given a goal by a Chief Digital Officer of producing an internal development function on a digital platform to replace legacy systems with modern applications. I developed a strategy that included the first step of an exemplar app running on a digital platform. The strategy focused on having a platform for easy development of further apps to meet business demand. But it depended on delivering the exemplar app quickly. While I was involved in resolving issues, I continuously adapted the technology strategy on changes to our situation to ensure meeting the CDO goals. 

Because of this constant cycle of short and long term actions and decision making, there needs to be a harmonious relationship between the reactive and proactive. It is no longer feasible to have separate individuals focusing on the tactical (reactive) and strategic (proactive). Separating the two concerns creates a crevasse between the tactical and strategic decisions and between the decision-makers, so much so that rather than them being viewed as two sides of the same coin, they end up being bywords for the wrong way and right way respectively, which leads to waste of time and effort and money as battle lines are drawn to determine who is right. This separation of concerns is embodied in organisations by the Enterprise Architect (strategy) and Solution/Application/Technical Architect (tactical) roles. We need to remove the plethora of layers of architects and come back to the core of it all, which is to deliver working software. 

This post was inspired by a former colleague who asked me for advice on what an architect is. This colleague was the tech lead on a team where I was the architect. And it was that relationship that helped formulate my approach to architecture and my philosophy on what an architect should be. A symbiotic relationship between them looks after all things technical from the low-level detail to the long-term strategy. The architect with a bias for the strategic and the tech lead with a bias for the low-level detail (code design, development practices etc.….). No individual can do it all, but no individual can do without the other. And it has to be a relationship of equals. The pilot and co-pilot relationship is for all intents and purposes a relationship of equals where the co-pilot will not hesitate to dispute the pilot’s decisions and has the skills to take over command if necessary. This has to be the same as the architect and tech lead. It is not a relationship that differs by seniority but simply differs by focus. 

That, in a nutshell, is my view on the modern architect. A Technology Pilot, who knows where they’re going, plans how they’re getting there but also has the skills to react to the unexpected and the foresight to avoid turbulence along their way.

Previous
Previous

Just say no - to versioning APIs

Next
Next

Learning never stops