Monday, October 31, 2005

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.

Revell-Monogram RMX1181  Revell-Monogram RMX2598Revell-Monogram RMX1917Revell-Monogram RMX0310
Revell-Monogram RMX1648Revell-Monogram RMX0445Revell-Monogram RMX5975Revell-Monogram RMX8883

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!


Post a Comment

<< Home