Edward Hopper - Communicating the Essence

It’s the architect’s job to decide and communicate which quality attributes need to be emphasized in order to achieve the overarching mission of a solution. Similarly the iconic American artist Edward Hopper, in his paintings, captured the essence of a scene while abstracting the negligent elements of the situation.

In painting Haskell’s House you clearly see that the artist chose to omit the wires from the electrical poles. The busy harbor behind the house is not depicted in the painting: the core emphasis is on the house. Also notice how the sun rays draw your attention on the house and you can almost forget about the mundane details of trees, landscaping, and electrical poles. A software architect has a similar job: capture the big picture (e.g. security, environment constraints, composition of services), but note the critical solution qualities (e.g. usability, performance).

In the infamous painting, Nighthawks, Edward Hopper uses light and shadows to concentrate viewer’s attention on the situation in a dinner. Notice lack of pedestrians, cars, or any other artifacts that would detract from the developing situation inside of a dinner. The viewer may dully acknowledge the presence of outside, but all the attention is concentrated on what is happening on the inside. Similarly an application architect that works in a mature design environment simply needs to acknowledge the presence of certain assumptions, but concentrate his work on the essence of a solution.

The 1940 painting Gas shows a lonely attendant at a gas station. There are no cars fueling or on the road. The obvious, cars, is not commuicated.

If you ever have a chance to see a collection of Edward Hopper’s paintings do not miss that chance. A closer look at the paintings can be found here.

Constantin K.
Firebrand Architect™
www.SoftwareArchitectures.com

Architects need to improve their written communication skills

Effective written communication skills are essential for every software architect. Expressing your ideas clearly, tersely, and effectively is paramount. If your audience does not fully understands your vision or design, then you’ll have to build (and probably fund) the system yourself. It is your responsibility, as the architect, to ensure that your readers understand your ideas.

Written communication is important, because that’s the only effective way to communicate with a large number of people who may be geographically distributed across the world in different time zones. A single software architecture design package is often the source of reference for hundreds of people on a large scale system or a system of systems.

The international software engineering community recognizes English language is the standard language for cross cultural communication. Therefore it is paramount for any software architect to improve their skill set of the written English. Improving written English is probably even more important than improving oral English.

There might be many guidebooks for improving your writing, but my colleague and scholar of the English language recommended only one book: “The Elements of Style” by William Strunk. The book has been in print for a few decades. It is available in the original edition, the illustrated hard cover edition (my copy), and the fourth edition. The content is about the same across all of the editions. This book is a definitive reference guide for an everyday writer. The book has no prerequisites and can (and should) be used by every technical person. After using this book you will notice that your ideas are shaped more clearly and your sentences are easier to understand. This book belongs on your technical books bookshelf.

Beyond technolgoy in technical books - joy for architects

The winds are changing – the software engineering mainstream practitioners are finally starting to value the importance of the human aspects of software engineering. And that’s only good news for software and solution architects.

If you’ve been reading some of the newer technical literature, such as the Pro [Microsoft] BizTalk 2006 book, you would have noticed one paramount shift in the book’s introduction part. First the authors provide the core overview of the BizTalk architecture, as expected, but then spend the next chapter going over various human and organizational aspects of running a project.

This is important. This shows a conscious effort on behalf of the authors to convince the reader that establishing a technical and management structure is essential to the success of the project. The book provides brief guidance for setting up communication chain of command, provides an example of a rudimentary build and deployment process, and emphasizes on the importance of organization and team work.

Most books a specific technology only concentrate on technology and often neglect the human aspects of software architecture. The Pro BizTalk 2006 does a fine job of emphasizing, if not requiring, that software engineering practitioners follow best practices when utilizing BizTalk 2006.

- Firebrand Architect on duty: CK