Session: What is an Architect?
Speaker: Omar Besiso
One of the first things that Omar said in this Ignite 2017 session on software architecture was “No one knows how to define what that job even is!”. It was said half in jest… but only half. The job of a software architect is fairly straight-forward to describe in broad terms; they make high-level design and technical decisions. But the vast gamut of specific tasks that fall under that statement are harder to define.
In this session Omar attempted to break down the role of architect into more specific skills and roles. Many of these were fairly familiar and well-understood; the value of solid design principles compared to specific technology experience, adapting processes to the needs of the project, the value of prototyping. But I want to look a bit closer at some of the things I took away that were less obvious or had some novel perspectives, to me at least.
One of the first topics of the session was people skills and communication and this is a subject I think often doesn’t get enough emphasis in discussion of technical roles. This is important for architects in particular as they are expected to have strong confidence and support from their teams and the way they interact with those people will obviously influence that. A few principles were highlighted that are important for an architect when dealing with people:
- Clarity and precision. Being able to clearly articulate their thinking and decision making to various personas allows the architect to align disparate stakeholders (customers, project managers, marketers, etc) to the team’s plans and priorities.
- Conviction. An architect needs confidence in their own decisions if they expect others to have confidence in them.
- Transparency. Letting people know why decisions are being made gives them confidence and investment in the process.
- Honesty. Admit and communicate mistakes openly.
There is a common perception of “ivory tower” architects, planning systems from their lofty abodes, handing down utopian designs disconnected from the realities of software in the trenches. The above principles should help to break down that stereotype and get stakeholders invested and aligned with the architect’s design and boost confidence in the process.
I’ve found these practices to be enormously beneficial to morale and satisfaction in organisations and teams that have adhered to them. Unfortunately I’ve also seen these and similar concepts paid lip service without true support or adoption. The inclusion of these kind of principles into an organisation’s core values seems to be a strong base for building teams with high job satisfaction.
One of the most crucial steps of designing a system is decomposing it into distinct components and their relationships. After a humorous run through some of the less-than-optimal decomposition techniques (such as “skills based architecture”: “we’ve got good DB guys so business logic goes in stored procedures”) there was some discussion of volatility-based decomposition, a concept I was unfamiliar with. The underlying principle of this process is that change is the most influential factor in software systems, so decompose based on the probability of components changing and the impact of those changes.
The principle of “high cohesion/low coupling” was given to drive this process; components that are closely related can be tightly coupled but otherwise should not have dependencies that prevent them from being changed independently. This obviously only touches on the surface of this concept but I found it a compelling idea and did some more in-depth reading on the topic. This article by Hakan Tuncer goes into more detail on the concepts and reasoning of the technique.
While the session went some way to answering the question of “what that job even is!” the underlying message seemed to be that you can’t actually nail it down. Each system, team and product is different and an architect always needs to adapt and evolve. The closing quote of the session from Albert Einstein sums it up well: “We can’t solve problems by using the same kind of thinking we used when we created them”.