Oh you know Software Architecture? Express it in an OKR
Actually I am just behind on OKRs and need to finish this
“Software Architect isn’t a real title,” I’ve joked to people who aren’t in tech. I continue by saying I’ve honed my ability to draw mediocre boxes and arrows on a whiteboard, and also cylinders (upright, they’re databases; sideways, they’re queues).
That’s because I’ve worked with a real-life architect and I am in awe of the precision and many facets of the process. The blueprints cover structural, electrical, land survey, window schedule, not to mention the cool giant printer that’s required to print out the rolls you look over at a build site with a hardhat.
Of course, someone needs to build the damn thing, but it’s absolutely a wonder to go from CAD drawing (or back in the old days, hand-drawn drawings on those slanting desks) to framing, pipes, wires, drywall, fixtures, walls mudded and painted, &c.
Undoubtedly, it probably does not require a stretch of imagination for a Fortune 500 company to arrive at an Architecture Group which hands down Visio Diagrams from the Ivory Tower. (I always imagine said ivory tower is from Isengard.) That’s hardly the best way to approach things though; a software architect who listens, provides guidance, and understands what else is going in another corner of the organization can be an invaluable resource in a larger team of domain experts and project shepherds.
I’ve long maintained that once an [engineering] organization grows large enough, there could be a Dunbar’s Challenger whose sole job is to connect people. Who is working on similar things, if not solving the exact same problem? If the entire organization were working on a singular monolithic codebase, who is trying to build the same class?
In the same project that I met a honest-to-goodness architect, I also hired a builder. This builder had years of experience, working with electricians, plumbers, framers, painters, roofers, everyone underneath the sun who had to do with building a house. Experience is hard won and tells you to get the plumbing in before pouring new foundation. It tells you to forego salvaging an existing roof if you are going to extend it—because you will end up ripping it out anyway. It’s the stuff that you can read in a book or a blog post somewhere, but until you face the problem yourself (and make a mistake), it’s a lesson that sticks with you forevermore.
In the same vein, a good software architect draws from experience, having to push code into production, and getting paged when it falls down. It’s knowing that “it worked in dev, but at production scale it ruined my Thanksgiving.” A good software architect knows that nothing is free—Serverless is Just Other People’s Computers™—and the means to the end (the journey to getting it into production) is just as valuable as the end (it’s in production!).
Ultimately, whatever your organizational structure is, the role of a software architect, whether official in title or more of a de facto role similar to a technical lead, is to provide reasonable guidance on what to build. Blueprints are a goal, and other constraints like city building codes (system administrators / system reliability engineers) require fun things like “an electrical outlet every 5 feet”/“default ulimit is too low” which will rely on some finessing of the electrician/developers.
Trust me though, the ulimit is often way too low.