On architects

One advantage Twitter has over Facebook is that everything is largely public (and, incidentally, why I’m not convinced by flock). Sadly, that doesn’t completely remove the trolls (Linkedin is better for that) but there can be thought provoking discourse without immeadiate descent to echo chamber or bun fight. A good example is this tweet, which included a reply from Grady Booch.

I keep being pushed to hire software architects into my org and…naw homie!!

Architecture is a skill employed by experienced engineers; not a dedicated role.

That’s how to avoid building impractical systems where one group is free from the consequences of their design.

— Nivia *always* uplifts Black & LGBTQIA+ Women (@Lanooba) January 18, 2022

To @Lanooba’s point, I do believe architects should have skin in the game. An ivory tower architect that sets impractical goals in the name of the enterprise without helping the team execute is frustrating at best and, at worst, can delay and demoralize.

Equally, @Grady_Booch is right that someone has to see and communicate the big picture. Yes, Amazon has two pizza teams that own their architecture, but they were set some architectural goal posts early on via the API Mandate.

What makes a gifted architect? The following are on my wish list:

Gifted communicator and listener

A good architect has to be able to talk/present/write in a compelling way to all organizational stakeholders. Be that less technical management and product owners or super deep engineers. They are capable of tailoring their communication to the needs of the listener and, critically take the feedback and incorporate it into their thinking.

Tech & business strong

This one maybe goes without saying. Good architects have deep and relevant experience in the domains within which they operate. This is necessary not only to make the right design decisions but also to be compelling to the engineering teams who can be suspicious or dismissive of outside direction.

Beyond that, an architect has a good handle on the strategic goals of the organization. They are designing to meet the stated and unstated desires of the firm. The latter, if taken too far, can be a quagmire, but left unconsidered will result in solutions that don’t stand the test of time.

Hands on

Except in smaller orgs, ‘Hands on’ probably shouldn’t mean that an architect is critical path for cranking out code. It does mean that they are keeping their skills sharp, learning new technology and creating proof-of-concepts to understand what does and does not work.

Macro thinker

Seeing and communicating the big picture are key skills in the architect’s arsenal. What are the ultimate goals of the system under consideration? What are the ‘guardrails’ that will help teams deliver without tying them up in red tape? How does the product integrate with other capabilities in the organization and what are the correct separation of concerns between them? An architect lost in the detail is not helping.

Trusted & Compelling

Finally, an architect needs to be a compelling, trusted, partner. The trust equation is a useful reference here: credibility in what they’re talking about, reliable in delivery, intimate with the teams (so that concerns can be openly shared) but not so obviously self orientated that motives are suspect. A lot of that self orientation can come from a place of insecurity. A topic for another day.

That’s my top-of-mind list. What would you add?