Architecture Representation for the Product-Line Organizations

The product-line organizations exist today, and support specific DoD missions within specific application areas (for example, multiple product centers for Command and Control applications exist in the DoD). Each such organization may operate, maintain, evolve and procure new systems as part of the normal incremental evolution and accretion of DoD software systems. It is important to note that there are literally hundreds of product-line organiation within the DoD.

Organizational and technological diversity characterize the various product centers. Detailed expertise relative to specific products and customers has been developed within each product center. Lacking a shared domain model, the terminology, concepts and approaches used by these organizations varies tremendously. Thus, independent of development environment technology (which includes the use of software architecture representation technology) there is a high-degree of conceptual impedance mismatch among various product centers' perceptions of the application domain.

To complicate matters further there is also great variety in the DoD contractors which are used to support product-line maintenance and development, the roles they play in the product-line, and the technology and processes they use internally (even within the scope of DoD-STD-2167a) to accomplish their objectives. This both reflects and induces a large measure of technology diversity among the product centers. For example, development environment tooling may be strongly influenced by the preferences and use of commercially-available and proprietary software development tools and processes by contractors.

The need to support product-center diversity in technology and procurement is reflected in recent descriptions of the role of software architectures in the DoD software procurement process[#!saunders!#]3. To support this diversity, any one of a number of commercial (and research)-off-the-shelf architecture description languages (ADLs) and toolsets might be used—the author certainly claims no special expertise in making recommendations about which ADL to use.