Designing with your head, not with your guts

The 3 questions that every architect should ask

Photo by jesse orrico on Unsplash

“The imagination imitates. It is the critical spirit that creates”
- Oscar Wilde

Software engineers are always considering their work as pure creation: Identify a problem, make a logical abstraction of that, and develop a solution that never existed. However, in our days, these creative process have become more a copy and paste of snippets, technologies, frameworks, and boilerplates into our “disruptive” products. As Oscar Wilde mentions in his quote, the real creation resides in the critical spirit, the imagination is just a mean for that.

Nonetheless, most software engineers have lost that critical spirit, and their arguments during the design phase have become: “But Google is using it”, “It is an awesome platform/framework/language”, “It looks cool!”, “It’s ridiculous fast/secure/scalable (even if we don’t need it)”, etc. Where is the engineering? Since when does a couple of successful cases become the final argument to make an architectural decision? Why should the personal preferences of a group of developers or architects define the life cycle of a product? Are you prioritizing based on the company/business needs or by your personal benefit/growth?

Guts Driven Design

Those and others are just a couple of examples of what I call “Guts Driven Design” (GDD). In a GDD environment the personal preferences and light experimentation drives the architectural and low-level design decisions. One of the biggest problems with GDD is that developers and architects don’t understand the impact of their decisions, and that lack of rationale is the cause of poor architectures and huge technical debts.

Please take note that the hardest technical debts are not the ones produced by bad named methods or duplicated code fragments. It’s the Architectural Technical Debt the one that can make a refactoring process an impossible mission.

I’ll not go into details about the technical debt topic, that’s something for a future article, but if you want to know more about it please take a look to this article written by Bevan Williams.

Quality Attributes to the Rescue

So how can we design better software architectures? What is the correct process and/or steps to apply? There is no recipe for a perfect architecture, however the first step is to avoid your personal opinion and start desiging driven by Quality Attributes (QA). If you are not familiar with the concept, I present to you my favorite (and a little bit modified) definition:

A Quality Attribute is a measurable or testable property of a system that is used to measure the “goodness” of a product and how well it satisfies the needs of its stakeholders — Bass, Clements, Kazman

The concept of QA is not something new, but it seems that time and mediocre development approaches have powdered it. QAs are the foundation of Software Architecture Design in ISO/IEC 42010 and it’s a concept with almost 30 years of study and research.

What are some examples of QAs? Well… we already know the most common ones! Performance, scalability, security, modifiability, durability, among others. So the first step is to prioritize the most important ones for the project based on the business needs (note: Wikipedia has a really good list of QAs if you want to check them).

Ask Yourself These 3 Questions

How can we prioritize those QAs? There are formal methods such as QAW or ATAM, however, I’ll not go into details with those methods. I just want to present the questions that I usually ask when I’m designing, documenting or refactoring an architecture.

• WHY do we need that QA?: This is a classic question that I always ask and most of the time people struggle after a while. For instance, in one opportunity I had to evaluate a huge system that was using JEE. Instead of using JPA they were using basic JDBC connection (I’m not saying is bad, calm down). So my question was: “Why are you using raw queries with JDBC instead of JPA?” Their answer was “Performance”. To which I replied: “What is difference in performance between JPA and JDBC? Is it significant for the project? Is Performance the QA that we (the business) want to prioritize? Or is Modifiability/Maintainability?” After that, just an awkward silence (note: about the performance JPA vs JDBC debate, I would like to invite you to read these links and build your own opinion [1] [2] [3] [4] [5])
• HOW that QA affects other QAs? Are we ok with those tradeoffs?: Some years ago, a professor introduced us to one of the multiple variants of that famous “Iron Triangle”: Time — Quality — Cost. In any project you may find those 3 elements, but you can only choose 2 of them. Meaning that, if you want something with high quality in a short period of time, don’t expect it to be cheap, and so on. Business people want everything: A high performance, ultra secure, scalable, high available, interoperable and usable product for yesterday. However, in most of the cases, it’s extremely difficult to do so, and sometimes impossible for certain QAs. The best example is Performance vs Security. Do you want something extremely fast? If so, somewhere in your system you’ll impact negatively the system’s security (this quality attribute means more layers, encryption algorithms, steps, etc). That doesn't mean that you are going to avoid or forget one QA, that means that you can’t satisfy everything and you need to live with that decision, but more important you need to be sure, WHY do you want to live with it.
• WHAT patterns and tactics are we using to satisfy those QAs? How do we know the architectural decisions that we’re making will benefit the QAs we prioritized? This question depicts the importance of patterns and tactics. Patterns are reusable solutions to common problems in a given context, they represent experience and knowledge from others who already suffered that problem and solved it. On the other hand, tactics are proven design strategies for specific quality attributes responses. In general terms, patterns are conceptual solutions that may benefit multiple QAs at the same time — e.g A four-tier deployment pattern benefits modifiability security, and deployability — while the Ping/Echo, Voting and Heartbeat are specific tactics for detecting faults, and, therefore, to achieve Availability.

Next Steps

This article is just an appetizer for a real software architecture design process, but in any case it’s a good starting point. It’s clear that desigining using Quality Attributes is the first step to avoid being influenced from personal preferences, but what about the experimentation? Well… that’s a story for a different occasion (if you’re feeling motivated enough, go ahead with this link).