Category: Softwares

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.

People aren‘t always happy about new systems or major upgrades. This can pose a threat to the successful completion of a project.

It‘s not uncommon for people to disagree with the decision to implement a new system – especially at the beginning. This should be expected and the reasons noted. However, initial reactions to a new system is less of a concern than a sustained negative reaction.

Your goal as an Architect is to be aware of and measure the threat of acceptance problems and work towards mitigating those threats. To do this you have to be cognizant of them and consider the reasons for them. Some of the more common reasons are:

1. People may have concerns about the need for a new system (and subsequent retirement of an old system). This can also include fear of loosing functionality or loosing influence or power when roles change.
2. People fear new (unproven) technology.
3. People have cost/budget concerns
4. People simply do not like change.

Each of these reasons requires different possible solutions. Some of which you can address and others you can’t. You have to recognize the difference and deal quickly with those that you can. Start early, having discussions with your end users about the new system and its real and perceived benefits and disadvantages. The most effective long term solution is to use the design of the system itself to address the concerns. Other effective solutions include training, scheduled system demonstrations (early in the project lifecycle) and sharing knowledge of what users will get with a new system.

A “Project Champion” can help avoid user acceptance problems. Ideally this should be a person that represents the user group or stakeholders. They sometimes have to be convinced themselves. If there is none then push for one from the very beginning. Once you’ve recruited a Project Champion, give them your assistance in every way you can.