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.
Shaping and Communicating Architecture
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.
Thinking Architecturally
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 scalab ility or reliab ility ). 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 book Building Evolutionary Architectures was heavily referenced by many speakers. Specifically, applying fitness functions to architecture by testing the structure of the code. There’s a part of me that is interested in trying this out, but I am always hesitant in enforcing high-level rules with dubious effectiveness as it tends to lead to workarounds that are more harmful to the codebase in the end.
- There were some competing ideas around different code analysis tools and methods. A common one was cyclomatic complexity and its various forms. However, during the keynote, Adam Tornhill focused on an alternative analysis with the basis that complex code isn’t inherently bad. Adam’s approach was to find areas in code that were coupled, old, or changed often using the VCS commit log and associating those changes with bugs or features. I plan on trying both and use my knowledge of the codebase to evaluate what seems more accurate and see if our teams would find this helpful.
- A couple talks focused on social aspects such as architecting for different team formations (instead of restructuring the software, consider restructuring the teams) and mapping biological size limits to team size limits (the size of an animal is limited by how biological functions scale). At our current size, these observations were less applicable, but good to know since we are constantly growing.
- Beyond accidental architecture with James Thompson had some basic tenants for architects that I strive to follow, such as architect playing the role of a guide (instead of authoritarian leader) and being heavily involved in the codebase to foster confidence in technical skills. I liked that he took the idea of an architect as guide a step further and said that dev teams truly own the architecture since they own the implementation whereas the architect only produces an abstract form of one.
- Architecting for testing and continuous delivery with Ken Mugrage was a talk I was particularly interested in because we are in the middle of our journey towards CI/CD. I was elated to discover that this talk was similar to one I recently gave internally at Solace about the strategies we should use to achieve our goals (backwards compatible changes, use of the parallel change pattern). Sounds like we are on the right track!
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!
The post A New Architect’s Take on O’Reilly Software Architecture Conference appeared first on Solace.
Top comments (3)
I really dislike the term "non-functional requirements". It makes them sound less important to business.
I often try to turn them into functional requirements. This is easy for performance as there generally is a goal of throughout and/or latency. Quite often this requirement is untouched up to the point it is in production, and then the escalation happens. Which generally puts devs in the losing position even though no agreement was made. Management usually wants to make the customer happy despite them asking unacceptable results marked as defects rather than changes. (i.e. free work)
As mentioned you need to architect for the illities. Making something scale in a certain direction needs architectural decisions in the beginning. Decisions which cannot easily be changed when development is (almost) done.
Other illities like quality and maintainability I find really difficult to change into functional requirements. Projects generally want to finish as quick as possible taking shortcuts which hamper these illities. Trying to convince business that we need to put effort in these is not something I've been really successful in. They always think it's quicker to skip these things, and do it afterwards when there is time. I am quite often involved in the unicorn project where things will go differently, or so they think.
Thanks for the insight. Regarding the more nebulous illities, I certainly agree that lacking a functional requirement makes them harder sells. For quality and maintainability, do you have an opinion about using metrics from testing or static code analysis? I know they are controversial and can be gamed, but seem tricky to track otherwise. I'm also interested in trying out Adam Tornhill's techniques where complexity itself is not inherently bad, but complex code that is constantly changing and associated with bugs may be.
I have a love-hate relation with metrics. They require a lot of work to use. You cannot simply enforce rules like a maximum fan-in or cyclomatic complexity. Breaking up something because it goes over a certain metric just slightly is just wasting effort.
A lot of thing within a (physical) library are about books. Almost everything refers to books, that does not make the design of 'book' bad, just a place which has a lot of impact if it needs changing.
Looking at metrics over time is where things are becoming more interesting.
Talking about Adam Tornhill, his book Your Code as a Crime Scene is on my to-read list.