97 Things Every Software Architect Should Know

Monson-Haefel, R. (2009). 97 Things Every Software Architect Should Know. Sebastopol, CA: O'Reilly Media Inc.

http://www.amazon.com/Things-Every-Software-Architect-Should/dp/059652269X

Introduction 

"97 Things Every Software Architect Should Know" is an anthology of advice from industry experts prescribing through their individual experiences, what a software architect should be like. Compiled by Richard Monson-Haefel, this collection of articles elucidates the role of a software architect within the context of a business. 

Valuable Insights

Although the compendium has a number of articles which I find helpful while being slightly disputed with some, I find the following three "things" the most valuable.

Architectural Tradeoffs

[Thing #22 | Mark Richards]

A software architect must always be aware of the trade-offs that exist in every quality goal that she attempts to achieve. She must understand and communicate effectively the impact of achieving those and the risks involved to the stakeholders of the project while evaluating and making decisions to best reach the quality goals. 

The author of the article, Mark Richards, give the example of the Swedish endeavor to build a ship called the Vasa. In the 1620's, the King of Sweden, in efforts to defeat Poland, commissioned the building of this ship. The requirements of the ship were extravagant requiring the ship to have unsurpassed abilities. The architect of the ship had no experience in designing ships of the scale of Vasa. He did not communicate his reservations about this ship to the king but instead designed to ship as he would a smaller one. In a tragic turn of events, the ship sank within a few minutes of setting sail.

I personally believe that all risks and qualities should be communicated with the stakeholders of a project so that a decision can be made which best suits the requirements. Working onsite with the client, I have, on numerous occasions, had to ensure that the client as well as my colleagues and I understand the risks involved in certain requirements. I may not have used formal methods such as ATAM or CBAM. However, I believe that I have been instrumental in driving the team and the client towards acknowledging certain risks.

This article served as a refresher for me for a graduate course I had namely "Software Architecture and Product Lines". I was lucky to have been taught by a senior member of the technical staff at the Software Engineering Institute (SEI).

Understand the Business Domain

[Thing #30 | Mark Richards]

Software architecture is generally viewed as a very technical and dry subject. However, it is important for a software architect to understand the domain of the business that she is serving. This will inspire the software architect to think of what the actual business problem is and how it can be solved keeping the most effective returns to the business. This naturally leads to architecture patterns which best serve the purpose.

Understanding the business domain will also give the architect insight into regulations that are required for the client's industry. For example, a health care business will require HIPAA compliance to ensure customer privacy while a retail business accepting credit card payments will require PCI compliance for secure transactions. The architect, armed with this information, can make clear decisions regarding the design of the application as well as the scope of components affected or involved in these.

Similarly, when the architect understands business trends, she can create sensible solutions and patterns which serve the business to lead those trends. For example, a banking application depositing checks through a picture taken from a mobile phone can be path breaking and reduce the lines at the ATM machine as well as the teller.

This is one of my favorite articles in the book as it expresses the need for a technical person to immerse into the depths of an industry outside of their comfort zone. Furthermore, I will assert that even the developers and QA engineers must make efforts to understand the business domain they are working in. Lost in the world of programming, we tend to forget the reason for the work we do. Understanding the business domain will enable the architect as well as the developers and test engineers make decisions which make the best sense for the business.

Your Customer is Not Your Customer

[Thing #82 | Eben Hewitt]

One of the major aspects of working in a software services company is the tendency to believe that the applications one builds servers the client it is delivered to. This leads to fallaciously looking at the client as the customer. Eben Hewitt highlights through this article how misleading that may be to an architect to accept the word of the immediate client as what the software system requires.

There are a number of things that the customer does not think are required. However, they may be requirements which may affect the end user. Non functional requirements are usually the ones targeted to get the axe. On many occasions, the customer may emphasize that the core functionality be built first and then the peripheral qualities. However, these may negatively affect the entire application itself. For example, a banking system without proper security measures is bound to fail. Similarly, a system for which it is expected that hundreds of users interact and perform concurrent processes cannot be developed on a framework which is single threaded. Such systems may solve the functional challenges but will collapse.

Requirements gathering should not turn into design and implementation discussions. The customer must only discuss their requirements without delving into how they should be implemented. I have been affected by one such situation with a client. I had been given a view of how the end users currently work and expect certain data. I erroneously used that information and designed an application which would correspond to exactly that. Being careful to develop just a Minimum Viable Product (MVP), we still saw that the manner in which the "customer's customer" received the data was a daily report. I designed the system with the same information as an online system. The design flaw was revealed at runtime when a single query took over a minute to execute. This caused frustration to the end user.

I ended up designing a far more effective system in the end, however, this was a great learning experience. One must listen to what the customer's customer wants, needs and expects rather than being led into implementing how they want it served.