Architect Role and Expectations - Part 1

Spoiler alert, we can't define universally the role of a Software Architect. In my exploration of software architecture I stated some initial thoughts about it in Basics of Software Architecture. I mostly agree with the general sentiment that there are some expectations that have a higher potential of finding people in agreement. This writing should be more than a thought but let's see what I can fit in a 5 min read (I ended up having to do only part 1 today). Let's again explore some of the work from Mark Richards and Neal Ford:

1. Guide Architectural Decisions: while the intent on covering this is good I think it's defined too vaguely. An architect is expected to enforce architectural decisions. The reason I say this is because a guidance is not definitive. We expect an architect to support and show the way in making architectural decision that define the constraints of a system. But the implementation details are left to the development team, as they should be. The authors correct the definition later assuming that a technical decision can be made in order to preserve an architectural characteristic. The line between guiding and guaranteeing its execution is too blurred at this point. Who's accountable for the development team to follow this guidance at all times?
2. Keep an Eye on the System to Recommend Solutions for Improvement: most software is bound to decay over time. Being able to continuously analyze how the environment changes is important to spot opportunities for improvement. While the belief that "if it's not broken don't fix it" holds some truth, it doesn't go against this architect expectation. This is different than "set it and forget it" and more in line with "set it, but keep checking it". Having the tools to be able to analyze a system serves the purpose of ensuring the system can continue to run well and allows you to spot improvements before they become issues. Initially I thought this included external technology but it purely refers to internal changes which can also affect the problem domain itself. The external part is covered next.
3. Stay Relevant: isn't this an expectation for any good engineer worth their weight? Understanding its importance is easier when you look at it the other way around, how dangerous is it to not stay relevant for an architect? The responsibility an architect holds can impact the structure and design of a whole system, making short sighted decision because they lack an understanding of where the industry is going can make a big difference (e.g. building a rigid system). As a side note, early in my career I was able to get a deeper appreciation for leadership principles when I saw them applied when lives were at stakes (see "Extreme Ownership"). When I explored experts of the field some of the ideas did not feel particularly important or effective. It's when they were pushed to an extreme that they clicked and I realized how much some of them can make a difference (I should probably dedicate a thought about this another day). Long story short the same applies here, if you're just an IC, staying relevant seems a nice-to-have but when you are pushed to make important long-lasting decisions it can play a crucial role. Don't stress out thought, understand the importance but put things in perspective.
4. Ensuring Compliance with Decisions Made: this answered the doubt I had for expectation 1. I felt like the guidance language was too gentle and it should have been the second entry not the fourth on the list. I thought that guidance + ensuring compliance = enforcing. I much prefer the proposed distinction to highlight the collaborative effort an architect should go through. I see this attention to compliance with architectural decisions an important continuation of guidance. Ideally guidelines are always followed but sometimes they get unintentionally broken. Having someone responsible for ensuring system design decisions are followed is the architect's responsibility (For how long? Is it only the architect's responsibility though?).

Thoughts

I'll explore the remaining 4 tomorrow but the picture of what an architect looks like is coming together. I have yet to see an official Software Architect at any of the companies I worked at, but I see various degrees of this from different roles. I see some architectural decisions driven by the Senior Engineer leading the project, the support of a Staff Engineer (if any is available in that team) to the leader in making these decisions so they make sense across teams belonging to the same org. I also notice Distinguished Engineers or VPs/CTOs chiming in to make sure that company-wide staples are guaranteed across each org (e.g. a specific level of Security, a required level of Availability). The expectations are distributed but the size of the company plays a role on how many people are (or should) be part of the conversation. The closer you are to the project the more you are held accountable for meeting the expectations agreed upon. I am convinced this level of responsibility changes from company to company, realistically individuals within the same org are responsible for compliance and anything above that should be held accountable for doing recurring check-ins. Depending on internal processes, this can be harder or easier to do the further away you are from the development team. Defining responsibility and expectations clearly can help make the "Ensuring Compliance" part simpler to...enforce.