One of the hardest things to do when developing architecture is to define the level of abstraction. How deep in the weeds does the architect or architecture team go? DoDAF states that the “degree of granularity should be driven by the type of analysis or assessments that are of interest.” But finding the right level of granularity can be very hard, and it can take multiple design iterations. If
models are made at a high level only, the architect risks developing architecture that can be easily briefed to top leaders and fills program requirements, but does not answer critical questions for field operators and true stakeholders.
This becomes a critical tradeoff in joint enterprise architecture that should not be quickly overlooked. The right level of abstraction highlights commonality and
critical differences across Services and commands. At the same time, it also addresses operational processes in enough detail to allow informed decisions for the questions being asked. If the right level of abstraction is not chosen, the model is useless to those who need it the most. Therefore, abstract too high—the models can lie; abstract too low—one gets lost in the flow. Finding the
right level of abstraction is critical in ensuring the architecture can be communicated effectively and still be useful for its intended purpose.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
| File | MIME type | Size (KB) | Language | Download | |
|---|---|---|---|---|---|
| Defense ATL Nov-Dec06.pdf | application/pdf | 133.41 KB | English | DOWNLOAD! |
Provides definitions
Introduction
There is no question that Department of Defense and chairman of the Joint Chiefs of Staff directives have increased the development of operational and systems architectures. The DoD Architectural
Framework (DoDAF) and its associated governing publications have provided considerable information and examples covering DoD architecture processes and products for those engaged in requirements and architecture development. But even though the guidance is good, there need to be more general heuristics to help guide those involved in this growth industry. Based on recent experiences with joint architecture development, we propose
some general heuristics covering the following: the architecture
team; common lexicon; process ownership; appropriate abstraction; organizational bias; level-of-war bias; and hollow-transfer activities.