#2: Architectural Thinking
A modern way of thinking like a software architect
If you’re like me, you have a hand in architectural designs and decision-making without any formal architect title. In startups especially, engineers tend to wear many hats, taking on more than the developer role. Staff and Principal titles can also be very loosely defined to include architect duties. For anyone with the responsibility of defining system architecture, it’s worth understanding what an architect does and the way an architect thinks.
Like their definition of software architecture, Richards and Ford identify four main focus areas for an architect:1
Collaborating with teams to make the architecture work
Having a breadth of technical knowledge while maintaining depth
Analyzing trade-offs between solutions and technologies
Understanding how business drivers affect the architecture
Collaboration
In the archaic, ivory tower, definition of an architect, collaboration is not expected. Architects make decisions in silos and hand them down to development teams to implement. Richards and Ford identify this as the Ivory Tower Architect anti-pattern,2 and caution against architects working in isolation.
Architects can collaborate with development teams by participating in hands-on coding, and seeking feedback in their design decisions. For companies without a dedicated architect, these responsibilities may belong to a Staff+ or Founding Engineer, so in such an organization the collaboration can be built-in.
In an organization large enough to employ dedicated architects, the architects’ responsibilities can be shared with engineers, ensuring the passing of the torch to the next generation. Knowledge sharing with engineers in how the process of making architectural decisions has the added benefit of increasing the influence of the architect. The more collaborative architecture becomes, the better the adoption and success of the implementation of architectural plans.
As a developer in one such organization, I gained architectural experience by joining the Architecture Guild and by owning one aspect of the system-wide structure. With the guidance and mentoring of the rest of the guild, I had the opportunity to think like an architect as I considered and discussed the trade-offs in my technical proposals.
Continuous learning
The “Frozen Caveman anti-pattern”3 occurs when an engineers/architects who may have experienced some trauma in a past incident attempts to apply the same solution to a different problem. The caveman may have outdated tools, but continues to attempt to use them for problems in a changing business and technology ecosystem. Architects must continually expand both breadth and depth of expertise to continue to be effective in their role and avoid this mistake.
A few ways for architects to maintain technical depth shared by participants in the live weekly architecture book club sessions at Rands include:
Contributing to open source projects
Hands-on coding on work not on the critical path (to avoid becoming a blocker)
Engaging in personal projects
Writing proof of concept prototypes which may relate to architecture decisions
Examples of ways to expand breadth of experience include networking, reading books and documentation, taking courses, and participating in conferences and meetups.
Contributing hands-on in the codebase has the added benefit for an architect to better identify with the development team, improving collaboration.
Analyzing trade-offs
Recall the first law of software architecture, “everything is a trade-off.” In every technical plan, the architect must identify the trade-offs and discuss the best options for the optimal solutions. Richards and Ford suggest the goal might be the least-worst architecture given a set of desired characteristics. Where one characteristic is prioritized, for example, security, other characteristics such as low latency, may suffer some loss. Designing architecture that is as iterative as possible is one way around the prioritization of one characteristic over another.4
Expanding business domain knowledge
Architects need to understand the business domain in order to effectively analyze trade-offs and come up with solutions. Although an architect may not be needed on a business call, an architect can learn about the business domain by sitting in on management meetings. On occassion, the architect can collaborate on business decisions to affect a more successful outcome.
In the Rands discussion group, more than one participant shared examples where joining in to business meetings has lead to better architectural decisions and therefore product success. I’d love to hear about your example in the comments below.
In my next post, I’ll dig into the term connascence to elaborate on its meaning and how it may be relevant to modern programming.
Richards, Mark, & Ford, Neal. Fundamentals of Software Architecture: An Engineering Approach. (Sebastopol, CA: O'Reilly Media, 2020), 23.
Richards & Ford, Fundamentals of Software Architecture, 74.
Richards & Ford, Fundamentals of Software Architecture, 30.
Richards & Ford, Fundamentals of Software Architecture, 64.