The challenge

A few weeks ago I was reading this Linked in article by fellow Architect Luca Mezzalira

linkedin post snippet

I’ve read a quite a few bits by Luca through his weekly newsletter “Dear Architects,”, if you haven’t subscribed, give it a go, I happen to like it. Luca has asked his readers as simple question to reflect on. It’s about the field of architecture and how it’s changing. Literally the ask is :“change my mind”. We all know that’s a hard thing to do, but reading between the lines this is more to start a broader conversation. Somehow I liked this challenge and will attempt to reflect, challenge and bring some nuance or insights from my perspective.

So, let’s talk #Architecture.

FWIW I may not be in the best position to present the definitive and/or historical perspective of Architecture (why do we write this with a capital “A” anyway?) and the architects role here since I’m not that old and very rarely wear khaki pants ;-). But, I have been an active participant and student of the field for at least the past 20+ years now, so let’s have a bit of fun with this.

Idea 1: Decision making and owning decisions is becoming more and more distributed.

I don’t particularly see this as a change or something that we see happening all of a sudden. Maybe we’re recognizing (and documenting) things a bit better nowadays, so there is more visibility of this happening. We have built(discovered?) better practices and formats(C4, ADRs, etc.) for tracking what we think is important and costly to change at a later point in time. From my perspective architecture has always been intertwined at every level of detail in systems and applications we develop.

This is why developers and architects must spend time in the mud together and jointly figure out how to best approach and solve significant challenges.

BTW These decisions in implementation have always been made by developers, especially since they cannot always wait for formal architects to step in. There may be decisions that can exclusively be labeled as the architects domain but I’d be hesitant to do so since everything we decide must also be fit for purpose, and thus requires (deep) engineering knowledge. If we fail to recognize this as architects, I think we are failing at our job, which is to align business and technology well by helping everyone to succeed, not by being a bottleneck.

Idea 2: <well, actually a bunch of ideas>

Let’s review them one by one.
The role is shifting from:

2(A) Design authority to coach

To me, these are non-overlapping-magisteria and thus both require individual attention. Architects can be and imho should offer to coach, they usually are the senior people in an org and have a lot to share. This is also based on my experience where helping others grow and learn is a fascinating way to learn yourself and be humbled by your own lack of deep knowledge of the decisions you’ve made previously. It’s refreshing and sharing knowledge is a great way to reflect on what has been significant, what worked and what probably was not so good.

The design authority aspect is a bit problematic I think, but I interpret this to be referring to the ‘good-ol’ Ivory Tower concept in which the architects rule the IT landscape as sources of great wisdom: “Respect my authoriteeeey!” (as Eric Cartman would say). The whole authority-enchilada is a separate issue I’ll address later, but the hubris of the “wisdom at a distance” is more problematic and should in be minimized. The only way you can make good decisions is if you have a direct feedback loop and feel (or at least share) the pain of where things are not well thought out and need to be adjusted.

2(B) Gatekeeper to enabler

This is a key cultural change that I had high hopes for were already behind us, but since Luca mentions this, there may still be a lot of work to do on this part. To me, it’s so counter productive to not be a guide and create alignment instead of holding a passive stance (the department that says “No” comes to mind here). You would think that almost Twenty five years after the agile manifesto was established things would have moved on a bit, apparently old habits die hard.

2(C) Owner of decisions to facilitator of good ones

Again, to me these two are not overlapping aspects or opposites, but let’s review. “Owner of decisions”, reading between the lines here tells me a lot about the perceived persona, the “know-it-all”, the ones working in ivory towers. That’s just bad, this needs to change. Taking ownership and being accountable for decisions taken is a positive thing in my eyes. It does however say nothing on “how to make good decisions” and this is where the second aspect comes into play. (I do hope btw that previously also some good decisions were made;-)).

It is in everyone’s interest to make good decisions. Architects should lead this, also in documenting and communicating what has been decided. It’s that simple.

Idea 3: " …scaling through others by enabling teams to make decisions within guardrails…"

NGL, this one feels like Luca is positioning “wisdom at a distance”, which I don’t particularly like. I think this needs to change radically, less prescriptive, more constructive, close collaboration.

There’s a personal pet-peeve of mine here where I prefer “Guiderails over guardrails”. The analogy I use is that you don’t drive your car along the guardrail to get from A-to-B, it’s a last resort and damaging. We can be a lot more supportive and guiding to make the journey a lot smoother and less damaging don’t you think?

Back to the statement of scaling, I don’t like the top-down perspective this expresses. Especially since in 2C we’ve talked about facilitating the making of good decisions. To me that means that those who best understand a given context are in the best position to help define and make these. The architect facilitates, inspires, guides and finally collects and communicates the outcome, but the initiative is with the architect who leads those who need a decision and understand (or live with) the impact.

Idea 4: “Is this a loss of control”

<not precisely addressing the full statement but addressing the significant piece, but #closeEnough>

To me this is stereotypical for the “Ivory Tower illusion”, where we may have been under the illusion that there was control in the first place. This may have been a remnant from simpler times, where architects could oversee the landscape (or pretended to do so). Times where the amount of significant decisions to make were relatively small or less consequential. Nowadays with the huge scale of systems and application development there simply is too much to decide and track. The architect has in that scenario become a bottleneck and that links up nicely with the “Ivory Tower” motion in which some architects have retreated to gather their composure.

But can we now speak of a loss of control or has something better emerged? I think the latter, we may formally have to close a few gaps, but the notion that decisions are taken at every level and we communicate about that is a very positive one. This may of course at some scale create conflict and friction (going back to: “the left hand doesn’t know what the right hand is doing”). But since we are building in agile ways (remember, software should be soft) we should also have a lot more adaptive capacity in our ways to align things. Now when I think of this, it also may be beneficial to have competing approaches in the field, because multiple things can be true at the same time. As long as we’re communicating about the decisions and direction we’re taking we should be able to jointly navigate our way to success.

Authority

This, I think, has addressed most of Luca’s statements, but there’s one more thing I’d like to highlight. That is the authority part.

I do think that it is necessary that there is someone who can have a final say in making a decision or setting direction. We’ve seen too many unnecessary heated discussions. We need someone to be able to veto or break the tie. Most of this power should be with the technical exec, who may delegate this to others (often the architects and/or senior technical people).

I do think architects should collect the deeper knowledge that helps and has helped to build systems collectively and provide their collected insights as part of business continuity.

I do think lived experience and competence matter when making and collecting architectural strategic decisions and knowledge. For any decision maker, the minimum bar is to at least be informed on what is known(documented), because they have to deal with so many unknowns when building a system already. Architecture is also not the only perspective that is important. You don’t build the perfect runway for a start-up. Good enough is good-enough, and because sometimes leaps of faith need to be made. This is where information and knowledge helps to de-risk a decision and inject just-enough sense. This is where architects should mostly work on in my opinion.

I’m not 100% sure on this but I think giving this “decision making power” has also corrupted architects (or their image). The resulting perceived “Ivory Tower” and architects wielding this power without feeling the pain of the consequences their decisions have is problematic. My take is that this is due to the lack of feedback (and maybe some ego, that is not left at the door). When I think of architects I see very smart people that are striving for the best, well intended and well-thought-out solutions. However when this task is done in relative isolation, we often end up on that all too familiar road… This has to change.

Future

So, how do I see the future of architects and architecture?

The good thing is our job is going to be around for a while. My guess is that collaboration that unlocks a better flow of knowledge should be the highest priority. Architects are the custodians of business specific engineering knowledge, that is compiled to create clarity, enable continuity, innovation and instill confidence. Architecture will remain the job of people, because it’s not always purely fact-based work, but spotting opportunities, a-symmetry, gaps, options, challenges and collecting opinions that drive the direction setting. How we will go about that is something we can speculate a bit on. This is also where I do see the opportunity to use AI and make our jobs even more valuable.

Embrace AI

We will have to embrace these assistive capabilities to help research, challenge, document, analyze and verify our writings. We can create better strategies, tell better stories, deliver more consistent and coherent networks of decisions, provide designs faster and create more clarity in the materials we create to document significant choices. This makes our role even more significant and valuable for the companies that we work for. It also makes our work a lot more fun and fast paced (if that is at least what you’re looking for)

Organizations (especially large ones) will find themselves in a position where architects are no longer the bottleneck and they may be able to salvage of lot of the legacy decisions they’ve made, re-analyze them at scale, create better modernization strategies and shed a lot of weight from the inertia that has been build up in the IT landscape. I think that’s an exciting future which will still require a lot of personal engagement and devotion to drive for positive wholesome and impactful outcomes.

Let’s architect our future.