Architecture is Communicating Complexity

Architecture is, if anything, first and foremost all about "communicating complexity." Furthermore, in my opinion, I'm convinced the absolute best way to communicate complexity is by "simplifying and synthesizing."

For instance, take a look at the field of architecture itself. I contend that this discipline is hugely complex. Ask five reasonably intelligent, experienced IT people to define "architecture" and you'll probably get back at least a half dozen different definitions.

I set out to simplify and synthesize a description of architecture when I built the Architecture 'Resources' Repository (www.ITscout.org/Architecture), My goal was to create a web site that virtually anyone with no training whatsoever could use to discover and explore all kinds of information about architecture.

Previously, I tried to accomplish pretty much the same kind of thing with ITscout. Of course, its focus was different. ITscout is chiefly product-centric. It attempts to single-handedly encompass and describe the entirety of the enormously big IT industry marketplace.

Getting back to architecture, I've frequently written in this blog how the task of architecting is comprised of three component parts:

1. modeling
2. documenting
3. communicating

Nearly everyone agrees that architects have to perform the first task -- modeling. Oftentimes I find architects hoping to be able to use off-the-shelf models to jump-start their architectural efforts. I tend to believe that's a big part of the reason why so many people have found the Zachman 5-row by 6-column table attractive. I know I've had lots of folks express an interest in wanting to use the graphical ITscout models for describing their technology architecture portfolios.

The second task architects must perform -- documenting -- is mostly seen as arduous and burdensome. Most people I talk to are looking for some magic silver bullet. For some reason they elect to ignore the old adage, "Garbage in, garbage out." The fact of the matter is architecture is hard work, and someone has to do that work. Indeed, the benefits are often in the doing. Capturing, classifying, categorizing, refactoring -- those are the activities that make an architecture shine.

The final step in architecting -- communicating -- is my personal bailiwick. Unfortunately, not a lot of architects seem to even recognize the importance of this task. The problem reminds me of my experiences as a software developer working with end users. If I asked people what they wanted their application to do, they usually didn't have a clue how to express their real requirements. On the other hand, if I showed them what they could have they would immediately respond back with what was wrong with what I had shown them. I often described this behavior with the simple saying that "problems get defined in terms of available solutions."

In my humble opinion, communication is what architecture is truly about. After all, I can't begin to tell you how many times I've witnessed examples of architectural "shelfware" where the only ones who read what the architects had written were the authors themselves. If a tree falls in the woods, does it make a sound? Similarly, if an architect creates and populates models that nobody sees, does it have any impact? I think not.