Preview of an Enterprise Product Architecture (EPA) to Support a Modular Open Systems Approach (MOSA)

The potential for significant MOSA benefits appears unachieved to date. Recently, the requirement to use a MOSA has been made statutory and regulatory (Ref. 1-5). Previous work (Ref. 6) suggested that a customer-controlled component architecture is a necessary activity to achieve MOSA technical and business benefits across multiple programs. This paper extends that premise while previewing the concept of an Enterprise Product Architecture (EPA) for use in an acquisition environment where there is a requirements organization is contractually separated from the development organization. The requirements organization is composed of an enterprise that is responsible for multiple subordinate programs, and each subordinate program is responsible for developing major systems with their suppliers. Industry product line approaches developed the concept of an EPA (Ref. 7). This paper explores how an EPA can be used to set an enterprise-level MOSA to increase opportunities to achieve expected MOSA benefits in the context of a multi-tiered acquirer with multiple programs using different contracts with different suppliers. This paper is a preview for a more detailed version of this concept planned for a future publication. The technical approach previewed in this paper leads to a product line strategy for the enterprise focused on software and data. This paper defines key terms used for the development and application of an Enterprise Product Architecture (EPA). Products to be acquired would be accomplished through the interaction of the subordinate programs and their supplier(s). The development of the EPA begins with the establishment of functional boundaries. Interfaces between functional boundaries will be defined as a result of operational analysis that recognizes how different functional groupings interact to accomplish operational behaviors. Interfaces between functional groupings will be defined at a logical level to enable the incorporation of diverse products to accomplish requirements in the functional grouping. This paper previews the use of three independent categories of functional product groupings: Mission, Utility, and Infrastructure. EPA development includes the establishment of functional groupings that enable capabilities to be agnostic of the underlying infrastructure, hence the reason for the separately categorized Infrastructure functional groupings. Utility functional groupings represent a class of applications that provide operational functionality used by more than one Mission functional grouping. The Utility functional groupings facilitate integration and orchestration of Mission functions. Mission functional groupings represent the rest of the non-infrastructure capabilities needed for the programs to accomplish their operations.