As a relatively new architect, I jumped at the opportunity to attend the recent O’Reilly Software Architecture Conference in San Jose, California, and was eager to absorb as much as I could.
Before I became an architect, I thought the role was mainly about designing systems, and evaluating and selecting the technologies it takes to bring them to life. I didn’t fully appreciate the importance of effectively explaining these designs and technology selections to others. As such, I chose to focus on soft skills during this conference with the goal of improving my design and communication skills. My conference schedule featured two half-day tutorials on the first day and shorter talks and various events on the following two days.
In the first tutorial I attended, Seth Dobbs, vice president of engineering for Bounteous, helped crystallize some things I’ve been discovering about architecture in succinct and elegant ways. While many speakers and attendees lamented the difficulty in defining the role of an architect, I thought Seth’s description of “translating between business and technology” to be quite apt. He began by talking about the basics of communication and some common pitfalls, such as the tendency to assume there is no disconnect even if there is one. This failure in communication leads to deflections of responsibility like “I told them that” or “It’s on the wiki” . As Seth puts it, “communication is a two-way street, but we own being understood”.
The first step was recognizing that architecture is a lot like sales because ultimately, “our ideas don’t matter if we can’t get others on board”. Seth went into details about the disparate stakeholders involved in the decisions being made, such as developers and project managers. He then formed archetypes around those roles to better define what those stakeholders provide (technical or business insights), what they want to know (how a feature is being built or its cost), their goals (ease of development or communicating the business), and finally, the sorts of friction that may occur with them (skepticism or armchair solutioning).
Seth then discussed how to identify problems. A core principle of this tutorial was the business side of the technology, rooting back to Seth’s definition of an architect’s role. Therefore, it is important to distinguish between a business problem and a technical problem. For example, a database query being slow is a technical problem whereas customers waiting a long time and not returning is a business problem. There are a couple risks in attempting to solve the former instead of the latter. First, it simply may not be a problem worth solving; perhaps it is a backend query run on a schedule with no impact on the user. Secondly, you may miss more pressing issues; the database query may represent a small fraction of the slowdown and the real issue is a third-party API call. After a problem is identified, Seth eloquently described the solving of a problem as “mapping from needs/goals to solution while honoring constraints”.
The final step is presenting the architecture. Seth proposes beginning with a problem statement, then the context such as assumptions and constraints, followed by the high-level solution. The solution details can come afterwards which are more tailored for different audiences.
Seth’s tutorial was a fantastic introduction to the conference and while many of his ideas seem intuitive, his ability to formalize and present them were really helpful. The next tutorial I attended shifted from the collaborative aspects of architecture to the internal aspects.
Nathaniel Schutta, solutions architect for Pivotal, started by explaining that every solution has trade-offs. He then drilled down into how to identify and communicate these trade-offs through non-functional requirements or, more endearingly, the “ilities” (a play on words like scalability or reliability). The strategy was to identify the focus of the architecture by ranking a few ilities and using that ranking to break ties when having to make a conflicting choice between them. Having too many ilities is a sign that a solution is complex and may require multiple, separate investigations.
The lessons were reinforced by architectural katas, exercises where a small group is given a theoretical project and they work together to create a rough design. We were asked to rank the ilities for a random kata and use that to inform our design. It was an engaging exercise that helped practice architecture skills (the purpose of the katas). As an aside, a question was asked that has been on my mind ever since I became an architect, “How do you continue to grow as an architect?” Nathaniel elegantly explained that developers are able to develop expertise through their responsibilities at work, whereas architects may not get as many chances to architect major solutions. This is where learning about exercises such as architectural katas are exciting for me in that they give me an outlet to evolve as an architect.
Just as the first tutorial helped formalize intuitive thoughts I had about communication, Nathaniel was able to characterize my understanding of trade-offs in decisions and how to improve those skills.
The rest of the conference consisted of various keynotes, discussions, and shorter talks.
The conference was a wonderful opportunity to learn about the myriad of strategies and approaches to software architecture from not just the speakers, but the other attendees as well. My immediate action is to reflect on our architecture process here at Solace and see if we can improve the structure of the meetings, documents, and other output to take advantage of the communication skills I have learned. We’ll do whatever it takes to enable our teams to continue creating awesome technology!