Categories
Software Architect

The Importance of Consommé

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel
97 Things Every Software Architect Should Know – 95/97

'Coz sharing is caring

A consommé is an extremely clarified broth, usually made with beef or veal, served as a delicate soup. A well-made consommé is perfectly clear. It is considered challenging and time-consuming to make, because there is only one way to remove the fat and other solids that cloud the broth, and gain the absolute clarity the dish requires: repeated, simple, fine-grained straining. This straining again and again, this hyper-conscious refining of the mixture, creates an intensely rich flavor. It‘s as if to taste a consommé is to taste the very essence of a thing. That is, in fact, the point of the dish.

In culinary schools in America, a simple test is administered to student chefs making consommé: the teacher drops a dime into your amber broth; if you can read the date on the dime resting at the bottom of the bowl, you pass. If you can’t, you fail.

Software architecture requires a continual refinement of thought, a repeated straining of ideas until we have determined the essence of each requirement in the system. We ask, like Hamlet holding Yorick‘s skull, what is this thing? What are its properties? Its relations? We clarify our concepts, to make the relations within the architecture verifiably true, internally consistent.

Many missed requirements and bugs in software can be traced to ambiguous, general language. Ask customers, developers, analysts and users the same questions repeatedly, until they are drowsy with boredom. Now disguise your question to pose it in a different way, like an attorney looking for a snag in the alibi, to tease out anything new, any differences or contradictions. Strain and strain again.

Focus on what can be removed from the concepts presented in the architecture, the nouns that compose them, to determine their essence. Bring surgical precision to the language you find in your requirements, rejecting ambiguity, generality, unwarranted assumptions, or extraneous verbiage. This serves to make your concepts richer, more robust. Reduce and reduce again.

Test statements by asking “Would you make the same statement if I appended ‘always and forever and in every circumstance’ to it?” People resist committing to absolutes like this, and must refine their words. Force representations of concepts through a linguistic sieve to clarify them. Do this again, until you are left with only the exhaustive list of simple and verifiably true statements that describe the essential nature the system.

You’ll know when the architecture is finished: when you can look through it and read the date on a dime.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an engineering leader with a successful record in building, nurturing, managing, and leading a multi-disciplinary, diverse, and distributed team of engineers and managers developing and delivering solutions. Professionally, he oversees solution design-development-delivery, cloud transition, IT strategies, technical and organizational leadership, TOM, IT governance, digital transformation, Innovation, stakeholder management, management consulting, and technology vision & strategy. When he's not working, he enjoys reading about and working with new technologies, and trying to get his friends to make the move to new web trends. He has written, co-written, and published many articles in international journals, on various domains/topics including Open Source, Networks, Low-Code, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at the University level during his graduation days.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.