The lesser-known skills of a Software Architect
[Vikram Mandyam] / 2021-10-25
For a while in the mid-2000s, due to the whole agile and XP movement, the term ‘Architect’ was going out of fashion in the software industry. The DevOps movement has allowed the role of a software architect to make a comeback. The added velocity provided by DevOps, the humongous scale of data, the added threat of security vulnerabilities - required a structured approach to moving forward, thereby bringing back the “Architect” once again
While there is tremendous interest in the technical side of the architecture/software design, and how we can best use technology to solve the problems, these technical aspects are just one part of the role of the architect. It is not just about using the technology and architecting software. It is about creating an architecture within a specific organizational context, being cognizant of all that is happening around you, within that context. This is necessary so that you can navigate and influence that context when needed.
“All architecture is dependent on the context”
Therefore, architects must realize there are lesser-known skills that are very important to being a well-rounded architect. There are very many books, which delve deep into the role of an Architect, from a technology perspective. I will not touch upon those here.
Why is the role of a software architect a very tough role?
Change
Software architecture is a constantly moving target. This is because of the rapidly changing software development ecosystem. In any fast-moving large-scale software ecosystem, apart from “change being the only constant”, mistakes will undoubtedly happen and time/resources will never be enough as there is always more work than you can accomplish.
Trade-offs
Everything in software architecture is a trade-off. Since everything is a trade-off, knowing why a decision was made is way more important than how. Without knowing the “why”, documenting, communicating, and ensuring compliance on that decision is going to be very difficult.
Scrutiny
Architectural decision-making is the most important role of a software architect. But, almost every decision an architect makes will be challenged - by product owners, project managers, and business stakeholders due to costs and/or effort involved and by other architects/developers/peers who may think their approach is better.
Breadth vs depth
Architects need to have a wide breadth of technical knowledge while still maintaining a certain level of technical depth.
Conway’s law
Architecture and org charts don’t really mix well: most of the time org charts are thrust upon an architect. Fighting Conway’s law is tougher than you think.
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
‐ Melvin E. Conway
Hard work
As per Physics, everything tends towards entropy, the more complex the system the more the affinity to disorder. Software systems model complex systems and this means one has to expend a tremendous amount of energy to bring it within control. Architects must constantly spend energy.
Fear
Eliminating the fear of changing a system due to its legacy nature is extremely difficult. Many a time, The architect wants to change the system to maintain agility in it. The org/team resists and pushes back. A system that no one wants to touch has no agility at all. Getting the org onboard is one of the toughest tight rope act in all the profession.
The lesser known skills of a good software architect
Now that, we know why the role is tough, let us look at how to deal with them
Skill: The art of asking questions
The architect should know how to ask a lot of questions - of the product owners, of the project managers, and of the business stakeholders. What is left unsaid by the stakeholders is often more important and the architect needs to tease this out. In fact, the architect has to make the software design by answering questions related to what, who, when, where, why, and how
Skill: Reversible decisions, one-way doors and two-way doors
Make all architecture decisions reversible.
“One of an architect’s most important tasks is to eliminate irreversibility in software designs”
‐ Martin Fowler
If this is not possible, then use the famous decision-making framework from Jeff Bezos . “One-way door” decisions are irreversible, whereas “two-way door” decisions are reversible. Make “two-way door” decisions fast, but “one-way door” extremely slowly and with consideration.
Skill: Second/higher-order thinking
Higher-order thinking is most of the time linked to the long term and not short term. Consider any decision you have to make, the effect it has currently is the first order. The secondary effects that decisions will have at a later point in time are very important for an architect to consider. The secondary effects need not be related to technology only.
Skill: Leadership
All effective software architects are good leaders, regardless of their title. They lead by example and get people to follow along and do things not based on their title as architects.
Skill: The art of Negotiation
All decisions need to be documented well, effectively communicated to the right stake-holders. Providing the business value when justifying decisions is vitally important for any architecture decision. The common business justifications are “time to market”, user satisfaction, and strategic positioning. When all else fails, state things in terms of cost and effort needed, but only when all else fails. This is because, the solution to the cost and effort problem is often adding more people to the project! - which we know doesn’t work so well .
Skill: Pragmatism
Good architects do not chase the newest shiny architectures just for the sake of it. Architectural influences come and go. Effective architects prioritize correctly, placing more emphasis on the right things, which have greater business value and will be more enduring.
Skill: Risk assessment
Since the software ecosystem is constantly evolving, the architecture also has to evolve accordingly and by continually analyzing risk, an architect can correct defects within the architecture and take mitigating actions.
Skill: Spend time learning/honing skills
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe”
‐ Abraham Lincoln.
As architects, always be sharpening the axe, If a task will take a week, you are better off investing half a day or a full day in thinking it through.
Skill: Never send a human to do a machine’s job
The architect needs to know what to automate and needs to rely on good devops practices that give the speed to delivery, which will be needed as the system becomes more and more complex.