To think, document and reuse, an architect, analyst or designer needs models. But which notation and format to use?
Models can be expressed in text or a diagram or a combination of both. The choice depends mostly on the information to convey, but keep in mind:
- Text is better for verbal people who are very good writers/readers of one common language.
- Diagrams are better for visual people who are good creators/readers of a common diagramming notation, as well as the language used for words on the diagram. (Diagrams are not babel fish!)
A text or diagram becomes a useful architectural model when it is in a standard text structure or diagramming notation (hereafter known as the modeling language). For example, a UML “use case” model must be conveyed with a diagram notation (ovals, stick figures, and so on), plus a specification in structured text (precondition, postcondition, basic flow, alternate flows, etc.) You may need to hire a specialist to do the model, but standard modeling languages have these advantages:
- Clearer interpretation of the model (less ambiguity);
- Easier to find a particular aspect of the model;
- Prompts the modeler for complete detail.
To ensure their architectural thinking is thorough, an organization can make certain text sections or diagram elements mandatory. This is useful in an environment where controversial options are naturally suppressed. For example, a data model should have text definitions for every entity and attribute, to explain their purpose, meaning, scope, granularity, and source. This rigor has a downside: it takes a lot of time to research and write a model with more mandatory elements, which could delay a project.
To describe every aspect of an enterprise or system architecture, we may combine many models in simple modeling languages (in a long but easy-to-understand document), or fewer models in rich languages (for specialized readers, but perhaps shorter). John Zachman argues that the simple “primitive” models are essential to make architecture reuseable across the enterprise, but the rich “composites” convey the design decisions for a specific system.
The modeling language used for initial sketches and options analysis may differ from the language used in final specifications. A rich modeling language with mandatory rigor may be required to specify automation (such as for databases and business rule engines). But to get quick feedback from business representatives, use a simple modeling language, and omit details that don’t need immediate decisions.
The modeling language elements are defined by a metamodel. This is expressed in a data model, class model or other information structure. Explanations and examples of the modeling language are usually easier to understand than the formal metamodel.