Hands-on Architect – The Oxymoron
The topic of the architect being hands-on is a timely piece considering a lot of my recent discussions. I have seen many articles outlining why architects should code or be hands-on, which may work for very technical application architect roles, but from an enterprise and solution architecture perspective, is an oxymoron. The broader view needed for the architect, compromises the hands-on role. While the focused view needed for the hands-on role, compromises the architecture role.
Therefore, the term ‘hands-on architect’ is in fact counterintuitive and does not help drive the right business outcomes needed for an organisation looking at getting architecture advice and support to shape their business and technology initiatives. The best way to explain this is to use a battlefield analogy and how a general would manage his army.
To get the best value from an architect for your business requires you setting the operating viewpoint for the architect to ensure they can deliver a good outcome. Using my battlefield analogy, this is like having the general at the top of the mountain, (or in an elevated position) who can see the battle unfolding. They can see the troop movements; they can see the enemy positions; they can see the tactical and strategic formations of the enemy trying to engage your army. This vantage point is crucial for the general to see what is happening and ensure their troops and various military capabilities are deployed and manoeuvred correctly to respond and win the battle. You will not get the best value from a good general if they do not see the entire battlefield.
In the same way, this logic applies to the architect. They need to see and understand the overall problem they are trying to solve by understanding the wider business and technology context and impacts. They need to understand how other existing and planned solutions impact the solution they are developing, understand the strengths and weaknesses in the current processes, and understand the business challenges outside technology. This is only possible if they work from the right viewpoint to see and understand the overall business and technology landscape.
When architects operate at the technical hands-on level, they are closer to the technology implementation viewpoint, and in most cases miss the overall bigger picture. This is similar to having the general down in the trenches, where they can only see the immediate conflict in front and respond to it rather than the overall battle.
There are three outcomes when you use architects at the hands-on level:
- The Architect becomes an out of touch Technical Specialist (who also cannot operate as a good Architect) – A good architect, who operates at the right viewpoint, may not have the technical skills to perform the specialist role. Typically, architects have technical hands-on skills in their path to become an architect, but technology is a fast-evolving space that it does not take too long to get out of touch in a hands-on technical implementation or coding role. So, the architect you have hired may not have had recent hand- on experience to be a good technical specialist needed to implement a robust solution. Going back to our battlefield analogy, do you want your general at the frontline, in a hand-to-hand situation if he has not been in direct combat for a while?
In addition, due to the viewpoint and their operating focus, even if your architect has good architecture skills, they may not be able to work as an effective architect and be blinded on potential architecture risks and issues. This is possibly the worst outcome, as you now have neither the architect or the technical specialist for your project. - The Architect becomes a good Technical Specialist (who still cannot operate as a good Architect) – Unlike the scenario I described above, let’s assume you do find an architect who also has the technical specialist skills to be hands-on. However, this again will come at the expense of not having the broader architecture focus you need to guide and influence the project. This scenario will also create a false sense of security, assuming the project has the right technical as well as the architecture skills needed for a good outcome.
Ultimately, you have converted the architect to a technical hands-on specialist. If this is the case, why are you paying for an architect to be on the project? You would have been better served hiring a technical specialist for the role, that may also be more cost effective. - The Architect operates as a good architect (but at the expense of the Technical Specialist role) – In the third scenario, you may end up having an architect who will maintain the correct viewpoint and provide the architecture direction you need. However, due to the high-level architecture viewpoint, the technical hands-on role they are performing will suffer as they now do not have the highly detailed or focused view required to perform the hands-on role. This may then result in technical and delivery failures even though it has been architected correctly. Ultimately, this will lead to a bad outcome for the project and stakeholders.
Some would argue that the architect can change their viewpoints as needed to address both areas. This is theoretically possible, however based on many engagements and my industry experience over the last 20 years, I have not seen this being done well. There is always a cost when trying to perform the two roles simultaneously at the two different viewpoints.
I understand businesses do this to ensure that they have the technical delivery and architecture expertise both covered for a project by getting one person and saving costs. However, there is the greater cost of not having the correct architecture support needed and potentially losing many magnitudes of the dollars saved due to the lack of direction and governance. Going back to my analogy, if you have invested millions (or billions) on your military capability, do you want to save costs by not having the right general to lead the army. Do you look at saving costs by getting your best frontline soldier to lead the army as well?
My advice to most of our clients looking for hands-on architects is to get the right person onboard to perform the technical role they need, and don’t hire an architect for it. In addition, if you need the architecture guidance and governance on a project, hire the right architect with the correct viewpoint to get the best outcome, or else you are just wasting your money.
Furthermore, if costs and budgets are a key deciding factor (and usually it is), getting the right architecture advice at the right points of the project is more crucial, than costing in a full-time architect for the entire project duration. Getting just the right amount of architecture support (with the right skills) at the crucial points and channelling your limited budget at the right technical specialists will put you in a much better position than trying to create this counterintuitive, multi-purpose role.
Image credit: Gladiator movie – Dreamworks
