Common operating platform environments (COPEs) are reusable software infrastructures that incorporate open standards; define portable interfaces, interoperable protocols, and data models; offer complete design disclosure; and have a modular, loosely coupled, and well-articulated software architecture that provides applications and end users with many shared capabilities. COPEs can help reduce recurring engineering costs, as well as enable developers to build better and more powerful applications atop a COPE, rather than wrestling repeatedly with tedious and error-prone infrastructure concerns.

Despite technical advances during the past decade, however, building affordable and dependable COPE-based solutions for the DoD remains elusive. This blog posting--the second in a three-part series--builds upon the first postingto describe key success drivers for COPEs that proactively and intentionally exploit commonality across multiple DoD acquisition programs.

This blog is based on work by researchers at (and associated with) the SEI--including myself, Adam Porter, John Robert, and Mike McLendon--who are investigating how to create and govern COPEs successfully. We have identified the following three classes of drivers that DoD acquisition programs and system integrators must master to improve the odds of succeeding with COPEs:

1. Business drivers: Achieving effective governance and broad acceptance of the economic aspects of COPEs. When the DoD had the resources to acquire and sustain many redundant solutions, it was often hard to motivate the adoption of common software services and capabilities within the acquisition community. Adopting these services and capabilities were perceived as introducing program and technical risks and potentially impeding the ability of system integrators to offer more unique, custom-based solutions that were more expensive and perhaps perceived as more effective. Now that the status quo is no longer economically viable (which has been the case for many years and is now exacerbated in the shadow of sequestration), government and defense industry leadership has renewed interest in COPE initiatives. While this top-down support for COPEs is welcome and necessary, it is insufficient if program managers and system integrators do not fully accept the need to adopt new business models.
   
   Because both government and industry are significantly affected by new business models, they must devise collaborative, socio-technical ecosystems where participants share the risks and rewards of COPEs. One promising approach is managed consortia, which provide a solid commercial and legal foundation for forming and coordinating COPE government and industry stakeholders. These consortia are even more effective when they yield interoperable, open standards that are implemented by multiple open- and closed-source suppliers.
   
   Two often overlooked COPE strategy components are policy and governance, which are essential to success of collaborative approaches. These components are often not addressed explicitly because they are often not perceived as being important and are "organizational messy." DoD acquisition policy and guidance must emphasize COPE as an acquisition business and technical strategy at all levels within the acquisition and sustainment community. The collaborative environment also demands that concepts, structures, and processes for governance be an integral component of the overall COPE strategy.
   
   DoD program offices also need to work closely with system integrators to ensure that proper contracting models are adopted to incentivize cost-effective, on-time delivery of innovative and integrated solutions. While COPE based technical solutions may be feasible and desirable, these solutions cannot be achieved unless the government first puts in place the proper contract models to appropriately incentivize technical and program behaviors consistent with the government's business goals. Effective contract models can also be the means to enable rapid-delivery order execution can help streamline technology insertion. In addition, the government must negotiate necessary licenses and data rights, technical data on verification and validation facilities, and procedures to decrease total ownership costs over program life cycles by retaining access to key software and documentation artifacts throughout the development and sustainment phases.

1. Management drivers: Ensuring effective leadership and guidance of COPE initiatives. While it has become fashionable to pay lip service to the goals and benefits of COPEs, it is much harder to find program managers and senior acquisition executives who can successfully sell and defend the near-term investments in time and effort needed to achieve the long-term payoffs of COPEs. These leaders must not only recognize the strategic role of software in DoD systems, but they must also articulate this role in ways that resonate with congressional appropriators, authorizers, and their staffs.
   
   Technical and acquisition leaders should also be savvy and avoid placing their bets on technological "silver bullets" and fads. They should also manage the application of modern iterative and incremental methods at scale, as opposed to traditional waterfall methods. COPEs are most effective when they are developed with strong feedback loops between developers of the reusable COPE infrastructure and developers of applications that use the COPE. Since COPE efforts rarely have the time or resources to please all customers, it is important for managers to be goal-directed--rather than exhaustive--when determining which common assets to develop and sustain. Without continual interactions with application developers, therefore, software artifacts produced by COPE developers rarely address core business problems and thus will not be reused effectively.
   
   COPE technical managers must also know when to build and when to buy reusable software platforms and tools. Managers who cling tenaciously to particular platforms or tools, and who ignore all other options, typically trade off short-term progress for long-term pain. A more effective, long-term approach involves working with open standards and establishing affiliations with industry standard groups to ensure continuity across the COPE life cycle.

1. Technical drivers: The foundations of COPE development. The operational and programmatic success drivers for COPEs often garner the most attention because they fundamentally depend on people, who represent the most complicated and demanding part of socio-technical ecosystems. Even if we could magically solve these vexing challenges, there are still many technical drivers that influence the success or failure of COPEs.
   
   To start with, developing a successful COPE requires a clear architectural vision. This vision should be codified and documented by experienced software and system architects who possess a deep understanding of the canonical patterns and architectural styles of the domain(s) associated with a COPE. Other key elements associated with achieving an architectural vision for COPEs include
   
   
   
   Having a strategy for mitigating technical risks is particularly important for new and planned systems. Although the DoD and software R&D communities have some knowledge about foundational patterns and architectures for legacy DoD systems, they are less aware of key patterns and architectural styles for emerging systems, particularly net-centric systems-of-systems. Unfortunately, there are too few designated software and system architect positions in the acquisition community and program offices to insure an architecture focused vision is a driving foundational and life cycle technical imperative.
   
   DoD COPEs necessarily comprise a wide range of network, hardware, and software configurations; different algorithms; and different security profiles. This variation is a key driver of total ownership costs because it affects the time and effort required to assure, optimize, and manage unique system deployments and their unique and often multi-configurations throughout the life cycle. To manage this variation effectively, the SEI helped pioneer software product lines (SPLs). SPLs have been applied in COPEs to manage software variation while reusing large amounts of code that implement common features within a particular domain. SPL-based COPEs help reduce software development and sustainment costs by maintaining and validating reusable components in a common repository
   
   Other technical drivers associated with successful COPEs include (but are by no means limited to) the following:
   • developing open reference implementations for key parts of a COPE infrastructure to help DoD programs avoid getting locked into proprietary solutions
   • adopting effective licensing models to ensure broad adoption and commercialization of COPE components
   • ensuring a strong connection with R&D communities in software engineering and systems engineering to help mitigate technical risks
   • domain-engineering and use-case analysis methods that elicit and document COPE commonality and variability requirements and software architectures
   • iterative and incremental life cycle methods, processes, and toolkits that help developers better plan, measure, and improve software producibility so they have better confidence in COPE quality and cost estimates
   • software frameworks that codify the expertise needed to implement COPEs in the form of reusable algorithms and extensible and/or reusable component implementations
   • software patterns that codify expertise needed to design COPEs in the form of reusable architecture themes and styles, which can be reused even when algorithms, components implementations, or frameworks cannot
   • commercial-off-the-shelf component-based and service-oriented middleware that codifies expertise needed to develop COPEs in the form of portable open standard interfaces, interoperability protocols, and reusable building blocks
   • COPE-specific middleware components and services that provide APIs and data models via a simpler facade that shields applications from the powerful (and complex) capabilities of the underlying domain-specific middleware frameworks
   • higher-level languages, analysis tools, model-driven engineering technologies that enhance the productivity of COPE application developers and support "correct-by-construction" generation of software artifacts
   • automated verification and validation methods, standards conformance test suites, and system execution modeling tools that leverage the powerful, commoditized computing resources in a distributed, continuous manner to improve persistent quality attributes of COPEs, ensure portability and interoperability, and assure key functional and performance attributes

Succeeding with COPEs

This blog posting just scratched the surface of the technical and non-technical issues associated with developing and sustaining COPEs for the DoD. In our experience working with many COPE initiatives over the past two decades, achieving success requires a multi-dimensional perspective to foster effective COPE ecosystems and leverage key linkages between the success drivers identified above. Organizations implementing COPE initiatives that address these drivers in a thorough and holistic manner thus have a fighting chance to succeed. Many challenges persist, however, as evidenced by the relatively few COPE success stories to date for the DoD. History shows that organizations that do not understand (or do not execute) these drivers properly will fail, often at great expense and great detriment to the warfighter.

My next blog posting describes our work at the SEI on a COPE maturity model to help military and commercial organizations assess and improve their progress in developing and adopting systematic software reuse approaches for DoD acquisition programs. We welcome your feedback in the comments section below with suggestions on how the DoD can improve the technologies and ecosystems needed to develop COPEs more effectively.

Additional Resource:

To read the SEI technical report, A Framework for Evaluating Common Operating Environments: Piloting, Lessons Learned, and Opportunities, please visit
www.sei.cmu.edu/library/abstracts/reports/10sr025.cfm?DCSext.abstractsource=SearchResults