Category: Software Architect

There are too many good products hidden behind bad user-interfaces. The end-user will access the system through its user interface. If the quality of the user’s experience while interacting with your product suffers, then his impression of your product will suffer, no matter how technologically advanced and path-breaking your product might be.

The user interface is an important component of architecture and an often-neglected one. The Architect should enlist the services of specialists such as user experience designer and usability experts. The user interaction experts along with the architect can drive the interface design as well as its coupling with the internal mechanisms. Involving user-interface experts at an early stage and throughout the product development phases ensures that the final product is polished and the integration of the user interface with the product is seamless. The Architect should also look at doing user-interaction testing while the product is still in beta with actual end-users and incorporate their feedback into the final product.

Often the usage of a product changes over time as technology changes and features are added. The Architect should ensure that user-interface changes with the architecture reflecting the expectations of the users.

User-interactions should be one of the goals of the complete product architecture. In fact user-interaction should be an integral part of the decision-making process for architecture trade-offs and internal product documentation as much as robustness and performance. Changes in user-interaction design should be captured over time, just like code. This is especially true in products where the user-interface is written in a different programming language than the rest of the product.

It is the architect’s responsibility to make the most common interactions not only easy but also rewarding for the end-user. Better user-interfaces lead to happier customers , which helps improve customer productivity. If your product helps people become more productive then it will contribute to the business’ bottom-line.

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.