Behaviours to avoid in a software architecture role

Back in the day people were computers.

I've been in software architect roles on and off during my career (currently I'm on) and I feel like I've read similar discussions to the ones in the comments many times over the years.

But no matter how you cut it, you can't escape software architecture when doing software development. One may call the architects principal engineers, gremlins or senior developers, the role may be covered by one person or multiple and the end result may be better or worse, documented or undocumented - in the end someone worked on the software architecture.

Depending on the organization and its needs, the role may be strongly focused on technical aspects or straddling engineering and product management. A company with very specialized roles will want architects to take care of the architecture, whereas one with more flexibility might require that they also work on requirements, talk to customers, mentor developers, manage a product, etc. Some of these combinations are less than ideal.

Every time I did application architecture I was also writing code, but that's not easy and may be an anti-pattern. Typically architecture tasks (especially the documentation) are neglected under time pressure and the people revert to doing what they know best, which is coding. Application architects should be very familiar with their application domain, applicable algorithms, idoms and patterns, etc because they're essentially part of the development team.

Now I'm closer to the "architect that doesn't code" stereotype, doing systems architecture. And indeed, I do not write any code besides small applications I use to validate my assumptions or evaluate and analyze solutions. I don't remember writing one line of production code in the past years and this is neither unusual nor problematic. I work with several development teams, ensuring that their components stay technically coherent and fulfill the requirements of the system. I start by translating business requirements into technical requirements and then work together with each team observing their progress, iterating over our solutions until we are feature complete. Specifically this involves intra-component interface design, software design (in my case - how components behave and interact with each-other and the platform), architecture documentation, application architecture review, code review, etc. And meetings, tons and tons of meetings with development teams, POs, project managers, testers, lead architects, etc.

I do find that working close to the metal grounds you as an architect. Whenever I do too much diagramming and abstract concept design I feel like I'm losing something important and this is where testing your concepts comes in. But there's no general rule about what developers expect from architects. I've had teams in the same projects expect a finished concept while others were happy to implement something by themselves with minimal to no input from me as long as the external preconditions were being met.

Oh, I am sure that you do lots of work. And your company is organized in such a way that your role is critical path for lots of things.

But if a company the size of Google can get by without software architects, why does your company need to be organized in such a way that you require that role?

Back when I worked there, one of the universal shocks when people go to work for Google is that the overall architecture was light years ahead of anywhere else. The person usually given credit for that is https://research.google/people/jeff/. Based on results, he may well be the best software architect alive.

If you want to learn from his example, I recommend that you start with "a running prototype beats a whiteboard design".

hence, i am not musk or ford that don't know how to weld.

What sheer irony.

BOTH Musk and Ford knew how to weld, and considered that knowledge essential to being able to do their jobs. Sure, they didn't do a lot of welding day to day. But how could they make correct decisions about how to build new machines if they didn't know how those machines are put together?

Tip, the word is "response", not "responce".

In my view, software architecture should be part of the job of a principal engineer, and the role "software architect" should not exist as a separate thing.

Separately, you would be amazed at how many developers will happily give you code that they wrote a year or more ago, and then not remember their design decisions. So not knowing it inside and out doesn't imply that they are not the author.

There’s a concept in CS called an abstraction layer and the UI can literally change the thing underneath. I can create a UI with one button that when you press the button it triggers 50 actions to happen. It is not just about moving fonts and colors. This the exact same thing that a programming language does. A programming language abstracts away assembly language by having one programming expression execute several assembly commands. This is the job of abstraction layers and also the job of UI/UX.

Second explaining architecture is not solely an architectural job. It’s mainly the job of the person who writes documentation. The “architects” job is pretending he knows some “theory” of architecture more then the engineers actually coding the “architecture” when no such “theory” even exists.