5 Reasons Why Architects Who Can’t Code, Can’t Architect

This article discusses the advantages architects can gain by remaining technically hands-on. It is aimed at architects, both new, veteran or in-between, who might believe their focus should only be on the "bigger picture," leaving coding or building to developers. By the time you complete this piece, you will understand why staying technically grounded can make your architectural solutions even better.

With more than two decades of deep experience in various technical roles, I have found that the ability to switch between these roles allows me to see solutions from multiple perspectives and actively engage. In this series of articles, I hope to inspire, possibly jolt, other technical professionals at different stages of their careers to do the same, by sharing my insights and experiences.

Reason #1: Flight time

In the airline industry, a minimum of 1,500 flight hours is required to obtain a pilot’s license. Even those 1,500 hours may not contain every scenario a pilot may encounter in the sky. More flight time affords more experience, resulting in a better pilot.

The barrier to entry to become an Architect appears to be much lower in the IT industry. I have often come across people with just 2 or 3 years of working experience bearing the title of Architect. Let me quickly dispel a myth that you might believe. The semester or year-long course at university, or even your Masters dissertation on System Design, as taxing and in-depth as it was, was theoretical. Architecture does not live in the pages of a textbook or in the safe confines of a lecture theatre.

In the same way that an airline pilot learns how to navigate different weather conditions by actually flying the plane, you learn how to architect by building solutions.

Reason #2: Relevance

Fans of the movie franchise “American Pie” will get this reference - “This one time, at band camp...”. The character always goes back to something that took place at band camp. Architects who stop coding or learning will always revert to what they’ve done before.

To be completely transparent, I also fell into this trap. When I first started on an API Marketplace project, I pointed out that we could de-risk the pilot significantly by using well-established, tried and trusted enterprise middleware tools. Tools which I had years of experience with. Had we went down that route, I would have missed the opportunity to learn how to design micro-services, the magic of containerisation or the anguish of hand-rolling your own container platform and the joys of using a managed container service.

You can learn so much more about how something works by testing it out for yourself instead of reading a white-paper. Instead of going back to a trusty “playbook”, force yourself to research alternative solutions which might be available.

Reason #3: No hablo español (I don’t speak Spanish)

One of the key functions of an Architect is to help clarify queries from developers. The phrase “when in doubt, ask” also features prominently on our house building plans, which means the practice applies outside IT.

From my experience, these discussions are so much easier if you understand the developer’s context. Your TOGAF certification, while a great trophy on your profile, is not likely to help you understand Node’s event loop and help you identify the issue that is blocking testing is due to resource contention or a thread race condition. I learnt about the event loop by coding and researching. No elaborate setup - just an editor and a command line. I grappled with the concept and understood how it worked by applying and testing concepts from Jake Archibald’s excellent explanation on YouTube. It is also important to have a good grasp of the problem to support the delivery team (aka “dropping in reinforcements”) in the right way. Adding in additional developers with the wrong skillset could make the issue worse!

Understanding the technical details also helps me design solutions accordingly. Although my Afrikaans is not great and I no hablo español, I am proud to say that I speak “developer” fluently.

Reason #4: Systems do not live in boxes

When designing solutions, systems are typically represented as boxes and integrations as lines. From years of experience, I have found that every system is unique, each with a personality of their own.

In much the same way that you get to know a person, you learn the character traits of a system by spending time with it. You observe little nuances like the brief pause when navigating between screens, learn that if you extend the data model of a SaaS offering, you might not be able to use out of the box APIs. This allows you to design accordingly - for example to use a message queue to guarantee processing or buffer load, or when to use a system token instead of a user token.

You have to dive deep to go past a theoretical understanding to truly appreciate the complexities of a system.

Reason #5: High-level designs are hard to change from a high-level

High-level designs help establish an initial frame of reference - but can be dangerous.

One of those dangers is that it leaves too much up to the imagination of the development team. Simple example: I wouldn’t dare engage a construction company with a high-level plan of a “I would like a 4-bedroom house”. In much the same way, an Architect needs to be specific about what needs to be built. In IT, Enterprise Architects, are typically responsible for the “high-level” design, which is then “fleshed out” by a Solution Architect, which is then implemented by a development team. The danger I often see play out is - when issues arise, during development, testing or operations, a “temporary workaround/patch” (albeit with promises to fix it later) is implemented due to the levels of review and update needed.

The metaphor which springs to mind is relaying instructions to a rover on Mars. Due to the signal travel time, it can take up to 24 minutes to send an instruction. Having an Enterprise Architect updating a design in response to an unexpected issue is similar to passing a command to the rover to stop, as it heads toward the edge of a cliff. It might be too little, too late!

In the anticipation of potential counter-arguments, I would like to pre-empt a few which might come up:

Response #1: The function of an Architect is collaboration

Yes, one of the functions is collaboration. This is typically done as part of the solutioning process. An Architect first understands the requirement, works with technical teams to understand the landscape, then outlines precisely how the solution should be built. The designs or instruction provided by an Architect should be detailed and prescriptive.

Response #2: This is quite an elitist view

Absolutely and unapologetically so. In my opinion, the title of an “Architect” is earned. It carries massive responsibility. Being able to roll up your sleeves, fire up your favourite IDE or code editor and actually code something to see how it works helps the Architect make a better informed decision. From decades of experience, I am of the firm belief that good and competent Architects, like swords, are forged in the fires of development roles. I'm certain that you might also take an "elitist view" if you're welcomed onto your next flight by a pilot with just a few hours flight time.

I hope that this article has triggered a reaction - positive or negative. Let me know in the comments if you agree or not.

Note: I work at Amazon, but this is my own opinion.