Why Communicate?

Architects love to create visual models. It taps their creative juices. UML (Unified Modeling Language) and Visio were godsends in that they make it easy for architects to draw images that illustrate the underlying complexity associated with artifacts related to IT.

Architects hate to document models. Why? Because that involves tedious, hard work. Who wants to spend time poring over data, capturing and collecting pertinent information that describes those complex artifacts related to IT? Invariably architects search for some magic silver bullet that can somehow crawl their networks and scour their disks automatically extracting jewels of useful information about their computing environment. Ah, if only it were as simple as performing a Google-like search. Most who experiment with discovery tools that inventory, collate, and coordinate, however, come away pretty disappointed and disillusioned with what those products can actually accomplish. It turns out, in the end, that there's really no substitute for good old-fashioned hard work performed by an intelligent, adaptive, biological information processor (i.e., a living, breathing human being).

Finally, we get to the final prong of any architectural endeavor -- actually communicating the information organized around the models. A really big question that needs to be answered is, "Do architects want to convey to others what they've learned by modeling and documenting," and if so, "Who do they want to communicate that information to?"

More often than not, unfortunately, architecture teams operate like black holes. They suck up resources by scheduling lots of meetings, asking lots of questions, and then in the end, after all that fact-finding, deliver little more than a PowerPoint presentation with, perhaps, an accompanying Word document that no one but the author ever reads.

It's not uncommon in today's economic climate for architecture teams to get reorganized and reorganized, over and over again. In such cases, generally, little more gets produced beyond some UML-like diagrams that don't mean much except to the person who originally thought up the models and created the graphics.

In the real-world where architects design buildings for a living, inordinate amounts of time are devoted to communicating -- both with the consumers (i.e., customers/clients) and with the producers (i.e., developers, contractors, sub-contractors). Initially architects produce drawings, or renderings, so that their clients can visualize what they're buying, and actually see what's going to be built using their money. Then the architects produce numerous, much more detailed drawings called blueprints that are shared with contractors and sub-contractors who will do the actual construction work. Once again, communication is paramount. Note, by the way, that the client isn't expected to extrapolate what the eventual structure will look like based on the blueprints. It should also be noted that it's the architect's responsibility to perform extensive work documenting the details that involve issues pertaining to engineering, zoning, permits, etc.

IT architects can't just produce UML drawings, not if they want to convey to business people the concepts those UML graphics embody. IT architects also have to provide the extensive documentation above and beyond the sketches that they draw. When one looks at the long list of architecture tools on the market (see Products listed in the Architecture 'Resources' Repository), they'll find numerous offerings related to modeling. They'll also discover many tools that focus on documenting architecture information. But, it seems, my company, Flashmap Systems, is one of the very few who concentrate their focus on communicating architecture to untrained users. I figure we're either leading the market, or we're off course. Only our customers can say for sure!