Architecture Description Really Matters

Architecture description can affect the "life and death" of the software system that it describes.

I was hired many years ago as a corporate level principal architect. The first assignment I got was to describe the architecture of an existing software system product inherited from a company acquisition. The original people who created the system had left the company. There were no architecture or design documents; no one had insight about it to be able to describe what it really was. The marketing folks didn’t know how to market it, so the product faced the “death penalty”. To the engineering teams, the product was current, state-of-the-art, and very competitive with lots of great ideas built-in. By collecting information from multiple channels, I provided architecture description for this system, and did it justice. Also, I provided architecture for its future evolution. Both marketing folks and engineering teams were happy with the results.

From this experience, we can see what’s involved with architecture description, and how we can perform our roles effectively. In the context of overall architecture design, architecture description is to transform the collected and organized architectural information and intents into viable models. The creation and adoption of effective architecture approaches, methodologies, patterns, reference models, etc., can certainly benefit architecture description. The architecture description is the end product in the architecture development process; and it is the ultimately visible representation of architecture.

More details can be found at: http://msdn.microsoft.com/en-us/library/bb421528.aspx