Modeling and Documenting and Communicating! Oh My!

Dorothy: Lions and tigers and bears! Oh my!

IT Architecture reminds me of that timeless quote presented above, taken from the movie The Wizard of Oz, except the IT jungle is filled with models and documentation and communication  (Oh My!)

Let's start with models. I'm not referring to the gorgeous women models who prance down runways peddling famous fashion designer clothing. Nor am I talking about the latest car models from auto manufacturers like Ford, GM, or Toyota. I'm also not using the term in the same way that weather forecasters or economists define models, or molecular models in chemistry, graphical models in computing, or even role models in parenting. Rather, I'd like you to think about plastic models like those sold as kits by Revell.

A-10 WARTHOG	37 FORD COUPE	70 CHEVELLE SS	PT 109
CORVETTE C5	RMS TITANIC	JU87R-2 STUKA	VISIBLE V-8 ENGINE

Think of these models as cheap (as in inexpensive) representations of the real thing. Building architects also often create something similar when they want to show what a structure will look like before it's actually built. Sometimes these architectural models are 3-D. Other times, they're just 2-D drawings.

IT architects need to be able to build inexpensive representations of the real world inside the computer. For instance, a Relational Data Model uses TABLES to map to real world ENTITIES. For example, you can envision a one-to-one mapping between a row in a CUSTOMER table and a real-world instance of a customer. A Data Architecture model must also be able to reflect RELATIONSHIPS like the one-to-many relationship between customers and orders (i.e., any individual customer may place one or more orders), or the many-to-many relationship between customers and locations (i.e., customers may operate facilities located at multiple addresses).

Models provide a way to think about real world things. In other words, models contain the "hooks" from which facts can be hung. The actual facts themselves are what documentation is all about. For instance, if, once again, we're referring to Data Architecture, it's the job of documentation to capture all available knowledge about instances of entities and relationships. The models include the framework for organizing the knowledge. The documentation serves as the vehicle for saving the knowledge.

Finally, modeling and documenting won't do you much good unless you can communicate the information to the people who can actually use it. Communication involves the transfer of knowledge. Many different groups of people can benefit from simple, easy access to documentation describing knowledge organized according to models that can be readily understood. That's what IT Architecture is all about!