Key Things I learned after moving into a Software Architect role
A disclaimer: There have been many articles written about becoming a Software Architect out there (some of my favourites when I started the role was this article “The Path to Becoming a Software Architect”). This blog entry, however, focuses more on what key things I’ve learned since getting into the role — that I hope might still provide some snippets of things to expect coming into one.
First, some establishments of a sort of a baseline.
- I started as an engineer and moved towards a Tech Lead role prior to moving into the Architect role.
- In my case, the role is not a managerial role — I do not have a person or a team reporting to me, hence some of the key capabilities that I did in the previous role (as a direct line manager) were not as applicable moving to the role, but snippets of it are (e.g. coaching, etc).
The intricacies of the role may indeed vary from organisation to organisation, but for myself, I feel like I should establish what being a Software Architect is first to avoid some confusions. With this, we’ll rely heavily on concepts brought forth by Gregor Hohpe, author of “The Software Architect Elevator”.
The great Željko Obrenović, Principal Architect at Adevinta & a colleague (who I do consider as a mentor), brought forward in one of our Virtual Summits last year the notion that Architects are “Super Glues”.
[The Architects are the ones] who hold architecture, technical details, business needs, and people together across a large organization or complex projects.
- Hohpe
Let’s unpack that quote for a little further, through the elevator concept, that Željko brilliantly illustrated & shared within that internal summit as well (I’m redrawing it a little bit, but the concept is the same ;))
Ok, with that established — let’s proceed with key learnings.
Shifting Mindset — Leadership through Strategy first, Execution follows.
Definitely one of the key things I needed to constantly remind myself a couple of months into the role was that the responsibilities of the Architect versus my previous role, a Technical Lead, have diverse objectives. While there is a huge overlap in terms of scope, it has a huge difference in focus.
As Technical Lead that takes part of a delivery lead role in a team, one of my key objectives then was to ensure the team delivers to their commitments as best and effective as possible. You see the burn down charts as your gauge of everyone’s productivity. You take pride writing the end-of-sprint reports about wins, trends and learnings within those two-week periods of the team. Shifting to Architect, I needed to “take a couple of steps back out from the trenches” to see the horizon on where we’re heading.
Being a team technical lead was my comfort zone — I knew how to do it and how to facilitate it, but being the Architect entailed a change in mindset — to actively allocate time to consult (along the many levels of the elevator or we call it here lift ;)) and look at one, two, or three years down the line, and articulate it to get everyone on the same track.
Architectural Decision Records are geared for Discussions, not for Approvals.
Our team adopting the writing of Architectural Decision Records (ADR) has really been one of the great ways of working change that I’ve seen in our organisation in the recent years.
Why is that? Let me paint a picture pre-ADR days:
- The development team, brazened by the face of the new world called Microservices, started spinning services left, right, and centre (myself included).
- As the teams grew, and applications became a forest of services.
- On a couple of occasions, different teams will spin up new services only to realise it already duplicates another service’s purpose (or intended, future purpose), an existing service created months prior that is still growing and maturing.
- Also on a couple of occasions, the engineers (myself included) will stop post-first launch and proceed to the next services without doing the other necessary, housekeeping tasks (like understanding how to monitor and alert, etc).
Enter ADR era: why are ADRs well-embraced by our engineers? It gave the engineers a tool to do the due diligence in terms of thinking the consequences of their decision making, and having a valuable conversation across different specialisations among the organisation. It lets the engineers articulate how they came up with the decisions, what they explored and ultimately deemed not the best path forward, etc.
At the beginning of our adoption, it was almost a big event on each record — someone will put forward an ADR for a face-to-face discussion, where a group of 20 or so engineers discuss and debate the fine details of the discussion, and we found ourselves discussing 1 record for the whole meeting hour. We knew then that this approach will not scale — so we shifted to RFC-type, Code Review style of review, and that seems to be better.
Like all things, we continously tuned the process. We didn’t want to make ADRs the bottleneck of actually delivering the code as a result of the architectural decisions, so we came into an agreement on the minimum number of +1s in the Pull Requests.
I think the other reason why it was embraced fully was that it was not a bureaucratic process, a hurdle, or a tickbox that the engineers just needed to do. The ADR does not seek approvals, but rather, geared towards effective discussion across different disciplines.
A tiny tip: Occasionally, the ADR writer might make a record too long by adding information that is not really needed as part of the decision — set the expectation that the ADR is not a program specification but rather a guide (“is this more of an implementation detail?”), and certainly not a Standards documentation — that should live somewhere else.
There’s no such thing as inherently bad decisions, I think. Only not thoroughly fleshed out ones.
Some good references on ADRs:
- Documenting Architecture Decisions from Cognitect.
- A Simple but Powerful Tool to Record Your Architectural Decisions from Better Programming — they call it LADR (Lightweight ADR) but the format we use is similar.
- The book Fundamentals of Software Architecture (listed below in the P.P.S.) also has a good chapter on ADRs.
“It Depends.”
If my junior developer self hear myself now when I would then reach out to get some opinion from my now-self on a solution and I’ll now say “it depends”, my younger self would have rolled my eyes. LOL.
But it is true. The more you get exposed to various solutions & ways to address a user problem, the more you understand that a proven winner from one organisation may or may not also work in your circumstance (this is the same thinking now when it comes to hearing “quick wins” or “low-hanging fruits”, or buzzwords ;)).
The “it depends” answer does follow with a couple of open questions to further flesh out the context & rationale behind the proposal. What does one think about this intent of database queries, or if a caching layer has merits? How real-time is the data needed?
Acknowledging that no silver bullet exist (whether in solutions, or in ways of working) always make lively and very creative solutioning exercises.
Perfection is Not Practical.
The code does not “care” about how cohesive or decoupled it is; people do.
- James Coplien
Ah, the inner struggle of perfection of solutions vs being accepting that most of the time, at some point the investment / further changes planned does not provide any more value to the end user (the graph of product-to-market-fit somewhat comes to mind here).
Same goes for breaking down a monolith. One of my favourite tweets from Kelsey Hightower is this:
The elegant solution is always the ones that fits the need of the customer / end user.
The Truth is in the Code, not in the Documentation (or the JIRA tickets, mind you!)
Nothing really to expound on this, I think. We know that documentations tend to go stale, but we know that a proper, sufficient documentation is necessary.
I find myself usually starting with the documentation to look at the lay of the land, then verifying it in the code itself to see if it paints an accurate story. If no, update the docs if necessary, but the code is the source of truth.
There are many strategies or recommendations to keep the documentation up-to-date, but recently I find myself building tiny codes (thank you so much, GitHub APIs) to extract info from the code itself to gather the truth, or rely on reports from tools like Kiali to visualise traffic and how the applications work with each other.
Whiteboard-ing Sessions spark Joy (and amazing ideas and points of view).
Most of the time, I find myself becoming a rubberduck for the engineers to expand or validate what they have in their minds. (Not that I am an inanimate object the whole time, though, if we are being pedantic about the definition, haha ;))
Some of the things I surely do miss pre-pandemic was the quick and fast whiteboard-ing sessions I do with the engineers to flesh out a project or an idea. Preliminary discussions in Slack, then we’d all just run to a whiteboard nearby and start drawing diagrams and discuss the solutions.
Moving to working from home, it was important for me to translate this exercise online — tools like Miro, Mural, Excalidraw. or even the good ol’ handy blank Google Slides have really been helpful moving this online.
The creativity required to be a Translator and Communicator.
Lastly, the other cool thing I learned moving to the Architect role is becoming a translator of a technical idea or a concept into a non-technical audience.
While I was used sharing plans or solutions to the tech team constantly, it requires a different approach to get others on board as well. Context, context, and more context and thinking about what is important to your audience is key (e.g., to the Finance Team, they really don’t need to learn about the breakdown of the project timeline, so you just give a very quick slide of the milestones, but hone in on what is it going to cost in next year’s budget, etc). Over the years, I found myself being more creative with my presentations — not just visually but how to convey the story behind each.
“Everything you say sticks to someone, so be aware of everything you say,” a very wise quote I got from one of the leadership trainings I got a couple of years ago — and this is so true, but also wanted to add to it — be aware of how it is going to be translated.
A tiny wishlist for Google Slides: set an “audience” setting for each of the presentations that allows you to set which slides to skip, etc. I found myself creating either copies of a presentation (“Name of preso (Dev Audience)” or “Name of Preso (Marketing Team Audience)” or the like), or putting in the notes which ones to skip depending on the audience. Would be nice to easily toggle this!!
P.S. This post is also a love letter of sorts to Gumtree Australia & to CAMS team, the organisation that I have had the honour and pleasure of working in for the last 6 years. As I move to another organisation, I’ll remember fondly all of the learnings and interactions I’ve had, both from the local team and to the wider Adevinta (formerly eBay) Classifieds Group.
P.P.S. Also sharing some of the books/references I’ve found myself latching onto a lot over the course of my development as a Software Architect.
- Strengths Finder 2.0 — This book (and the corresponding questionnaire) was recommended to me in one of the leadership training I underwent a couple of years ago. It’s brutally insightful — especially when it comes to having a hard look at your personal strengths that you can tap to and recognise areas that, while maybe perceived as weaknesses, leverage to change the way you work and collaborate. Highly recommend.
- Accelerate: Building and Scaling High Performing Technology Organisations — With this State of DevOps report have been somewhat a standard nowadays, the book is a good reminder of the details surrounding the concepts we are now familiar with, 4 Key Metrics and all.
Favourite quote: “Architects should focus on Engineers and Outcomes, not Tools or Technologies.” - Monolith to Microservices — Ah, what has probably been my bible for a good while now. Obviously, this comes with the actual architecture we’ve been working on, but the book provides great guides into strategies to decompose — but not before it gives you a good couple of chapters to ask why you are doing it to begin with, then giving you an overview that planning to do it is not as easy as starting to develop spring boot applications left, right and centre. This paired with the tweets of Kelsey Hightower is gold.
Favourite quote: “You don’t ‘win’ by having microservices.” - Fundamentals of Software Architecture — This book I really didn’t read sequentially from start to finish after the introduction and the foundations chapters, but rather jumped back and forth into key chapters as it goes through different architecture styles.
Favourite chapter: (among the many ones) Architect Personalities (lol) - Team Topologies — A fairly new book in my arsenal, it explores ways to think about team structures, ahem, Conway’s Law, team types not with a prescriptive lens, but an exploratory view that encourages team-first thinking.
Favourite topic: Cognitive Load. Brilliant & Mindset-changing. - Clean Architecture — Another classic, isn’t it? While it is the more down-to-the-code type of book discussion, I still find it a great reference point from time to time.
Favourite quote (which was also quoted from somewhere): “If you think good architecture is expensive, try bad architecture.” - InfoQ is always a great reference — no surprises here.
- Dear Architects weekly newsletter has terrific articles curated every week — fantastic reads every week.