When seeking an irresistible force that can shift the immovable object of IT inertia, two candidates come to mind and only one of them is an Arkansas-based retail chain. "The Wal-Mart Effect" may get the headlines in trendy business magazines, but bigger still is the U.S. Department of Defense with 3 million uniformed and civilian employees compared with Wal-Mart's 1.5 million, and a fiscal 2005 budget of just over $400 billion compared with Wal-Mart's annual sales of somewhat more than $250 billion.

When the DOD tells its IT and other systems suppliers to follow specific rules in defining, designing and documenting products and services, it's not just a good idea; in many cases, it's the law.

The DOD possesses immense direct buying power, and its standards tend to ripple throughout the development and procurement processes of other industry sectors. This should motivate enterprise IT professionals to stay abreast of accelerating trends such as the spreading adoption of DODAF (Department of Defense Architecture Framework) as the basis for large systems development and especially complex systems integration.

Anyone hoping to do future business with the DOD is likely to encounter epic prose such as this requirement from an "Instructions to Offerors" document issued last year by a U.S. Air Force project. The document reads: "Provide DoD Architecture Framework (DoDAF)-based architectural views, specifically Operational Views 1 & 2 and Overall Systems View."

Companies would be well-advised to know what this means and where to find the tools that can help an organization comply with such a demand or perhaps assist a customer in doing so.

Released in version 1.0 in October 2003, DODAF supplanted the former framework known as C4ISR (Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance).

The first formal statement of DODAF was followed last February by the release of two more informative volumes, the 87-page "Definitions and Guidelines" and the 254-page "Product Descriptions," put forth by the DODAF Working Group.

Immediately, some clarification may be useful. As used in the title of DODAF Volume II, "product" means not something that's bought from an IT vendor but, rather, a piece of graphics, text or tabular data that describes the elements of an architecture or their relationships.

DODAF categorizes the various products in terms of their support for three views: the Operational view, which the DODAF manuals describe with the tag line "What needs to be accomplished and who does it"; the Systems view, which "Relates systems and characteristics to operational needs"; and the Technical Standards view, which "Prescribes standards and conventions."

The highest-level DODAF product, the "Overview and Summary Information," or "AV-1" deliverable, takes its name from its relevance to "All views." Its immediate subordinates are OV-1, the High-Level Operational Concept Graphic; SV-1, the Systems Interface Description; and TV-1, the Technical Standards Profile.

Two benefits flow from the imposition of a standard framework in general and from DODAF in particular: completeness and consistency.To appreciate why DODAF is worth the effort, imagine the task of comparing documents that describe several different automobiles. One might categorize the tires as "rotating equipment," one might call them "performance and handling enhancement devices," and a third might call them "safety subsystems." These different treatments might lead designers and auditors to examine different standards documents for applicable requirements; they might make it difficult even to assure that tires were included with every vehicle under consideration.

By separating statements of function (operational view) from descriptions of mechanism (systems view), as well as from the statement of applicable general requirements (technical standards view), an architectural framework makes it easier to compare different approaches to a problem.

It also, crucially, eases the task of integrating several systems into a larger composite system, maximizing the chance that incompatible approaches will be discovered while it's least expensive to reconcile them.

One of the important improvements in DODAF, compared with its C4ISR predecessor, is that DODAF is intended to shift the focus from collections of documents to repositories of data items as the architecture of what an organization knows. When "data, not documents" becomes the mantra for modernized workflow and digital asset management systems, this reduces redundant effort, eliminates opportunities for inconsistency, and leads to more streamlined processes.

Many toolmakers and application developers are finding XML an excellent technology for implementing this approach. For example, Popkin Software & Systems Inc. maps the System Architect Repository component of its System Architect modeling tool kit directly to the DODAF AV-2 Integrated Dictionary product.

Popkin uses generation and comparison of XML structures in its SA Compare tool that documents the differences among multiple AV-2 products. The C4ISR option for System Architect is Popkin's current offering for DODAF compliance, with its diverse diagramming strengths providing good support for the various graphic styles that are needed for DODAF deliverables. eWEEK Labs reviewed Version 10 of System Architect in September.

Extensive DODAF support is offered in Telelogic Enterprise Architect for DODAF, introduced in October by Telelogic AB. The company's DODAF solution combines requirements management with its DOORS (Dynamic Object-Oriented Requirements System), modeling with its Tau/Architect, and change management with its Synergy tool (formerly produced by Continuus Software Corp. before Telelogic acquired that company in late 2000).

The modeling capabilities of Telelogic's suite are especially well-integrated.

Also forthcoming next month will be DODAF support from top-tier architecture toolmaker Computas AS. Version 3.6 of the company's Metis modeling product is on the radar at eWEEK Labs for review early this year.

Other toolmakers are treating DODAF as a foundation for next-generation approaches to the integration of modeling and management. At the beginning of last month, Wizdom Systems Inc. announced plans to extend the static, snapshot-in-time models of a DODAF-based project description into dynamic management tools that also include process cost, process duration, and process quality impact identification and measurement.

One particular DODAF product, the OV-5 Operations Activity Model, could become the core of such a capability in future Wizdom tools in a time frame yet to be detailed.

Other developer-oriented tools are building bridges between DODAF and more familiar and broadly supported notations and methodologies, such as UML (Unified Modeling Language).

I-Logix Inc. delivered at the end of November its Rhapsody DODAF Pack using UML 2.0 as a standard notation. This enables automated consistency checking and even automatic generation of many key DODAF products, including the top-level products for all the DODAF views.

It's common to find DODAF products and services categorized as military or defense-related offerings, but it would be a mistake to relegate DODAF mastery to that kind of narrow niche of the enterprise IT skill set.

With homeland security and related mandates and priorities steering much of IT investment in the near future, the "DODAF effect" could have a broad impact on enterprise systems development.