• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (1)

1 localhost commented Permalink

In my experience, much of the difficulty architecting military command and control systems ultimately derives from an inability to describe what one does. The DoDAF is an attempt—and a valiant one—to normalize the descriptions of operational and systems architectures. But the DoDAF doesn’t help with two of the most pressing problems in DoD systems engineering. First, you don’t always have a smart guy on your team. Military team members rotate in and out of tasks as they are reassigned or promoted; they rarely have the time to become proficient at architecture work. If the civilians in the group aren’t good at it either, then the end product is poor.Second, the DoDAF doesn’t help answer the question of architectural relevance: how much is enough? Every programmer knows that the devil is in the details. The current practice of architecture in the DoD ends at much too high a level of abstraction to be useful.I believe that ultimately the DoDAF will be superceded by a more rigorous business process description language. We must help the DoD to understand that they will not be able to build systems that help servicemembers do their jobs until they learn to describe exactly what those jobs entail.The acronym for the day is YSANAOYOA: Your Systems Are Not Aware Of Your Operational Architecture.

Add a Comment Add a Comment