Composable Capabilities on Demand (CCOD)
Definition: Composable Capabilities on Demand (CCOD) is a design concept to enable the rapid development of new capabilities, carried out by operators combining services, data, and existing systems to achieve awareness of, or respond to, a new situation or mission.
Keywords: capabilities, components, composability, net centric operations (NCO), net-centric waveform (NCW), reuse, service
MITRE SE Roles & Expectations: CCOD is a new and evolving concept rooted in net-centric principles and effective enterprise-level distributed computing tenets (e.g., modularity, loose coupling, platform independence). CCOD disrupts traditional software systems engineering in two ways: the extension of capability composition to the end-user as opposed to the developer; and enablement of the user to perform run-time composition of said capabilities. CCOD represents a dynamic composition of existing and emerging components; the result may even be a recombination of existing capabilities as opposed to a new system.
A MITRE systems engineer attempting to apply CCOD principles must understand and make use of detailed expertise in the following areas:
- Distributed and enterprise software engineering from low-level infrastructure to modular componentization
- Human systems integration for design, workflow analysis, and capability management, and acquisition, especially of malleable/componentized net-centric systems as opposed to large, monolithic, self-contained systems
- Security, information assurance, and mission assurance, which are especially challenging due to the run-time composition issues
- Governance, including contract models for component development/sustainment, infrastructure development/sustainment, testing, and related issues.
Because CCOD is an evolving concept based on still-evolving technologies and tenets, MITRE systems engineers seeking to apply CCOD must be aware that not all programs will be amenable to such an approach.
CCOD is a design concept to enable the rapid development of new capabilities by combining services, data, and existing systems to respond to a new situation or mission. Ideally, CCOD should enable operational users in the field to do this development. CJCSI 3170.01G, Joint Capabilities Integration and Development System, defines a capability as "the ability to achieve a desired effect under specified standards and conditions through combinations of means and ways...It is defined by an operational user and expressed in broad operational terms...."CCOD supports this definition by providing an environment and associated components to enable the operational user to create relevant capabilities when needed.
Composable components may include elements from traditional services and data sources (e.g., Government programs of record) as well as non-traditional ones (e.g., Twitter, Flickr, and other open-source/Web 2.0 technologies that foster the creation of user-generated content and capabilities). The resulting capabilities and combinations of services can be tailored to the task at hand and either published as a "template" (if useful to others) or discarded. Component pieces can be reused should a similar need arise in a future task.
Interoperability is facilitated by the use of "loose couplers"common data formats that leverage the information-sharing benefits of the "network" through the exchange of sufficient mission data for the most common use. Loose couplers (e.g., Keyhole Markup Language [KML], Universal Core [UCore], etc.) are defined and evolved by a stakeholder community, including operational users, developers, and MITRE domain or technology experts. Experience to date suggests that a minimalist approach to loose couplers is a key principle. Global, complex data standards may prove problematic, due to the large investment in parsing/integrating/adopting them.
Ad-hoc composability figures prominently in this development process; consequently, it is important that the component technologies be built to high usability standards, and that tools, services, and data sources be described in a manner that improves discoverability. Eventually, it may be possible for end users with no specific training to find, combine, and use tools, services, and data sources in a mission-appropriate way via approaches like social networking. The widespread adoption of the CCOD approach also depends on innovation in the development of tools, services, and data sources. Innovation is crucial for ensuring that there is sufficient variety of components to allow for the development of a mission-focused solution. This innovation can be fostered by the adoption of a layered architectural approach, which promotes the creation of multiple, partially overlapping capabilities. This, in turn, allows non-programmer end users to select the best components to incorporate into their solution.
Examples of CCOD capabilities can be found in the Agile Capability Mashup Environment (ACME) . This environment has supported a variety of customers by rapidly bringing together innovative ideas, approaches, and capabilities to meet challenging problems.
Operational Properties of a CCOD Environment
The objective of CCOD is to provide operational capability to the end user. To make this possible, capabilities in the CCOD environment have the following properties:
- User-facing: The composed capability will deliver an effect for the end user. This does not mean that capabilities will not have middleware components, but rather that middleware alone is not sufficient to provide CCOD.
- Rapidly integratable: Reusable components in a CCOD environment can be rapidly integrated, ideally by the end user.
- Quickly adaptable to the task at hand: Capabilities that are composed can be quickly adapted to changing operational context.
- Assured: The capabilities that are composed will need to be assured from a mission perspective; this involves issues such as information security, trust, versioning, and verification/validation.
- Integratable with existing operational systems and domain business processes: Components designed for CCOD will need to integrate with existing business processes, command and control systems, and ancillary information technology (IT) systems.
The employment of CCOD in government systems development and the acquisition process is nascent. CCOD's run-time and user-facing tenets provide challenges that are rarely considered in the systems engineering and acquisition realms.
CCOD Best Practices and Lessons Learned
These lessons have been derived from hands-on CCOD prototyping and operator-centric analyses of current Command and Control (C2) systems and workarounds, filtered through the lens of practiced distributed computing expertise. However, it should be emphasized that CCOD is still a budding concept, and these lessons are still forming.
- Favor the small and reusable: Using Occam's razor, where there is a choice between developing or using two or more components; usually, the small simpler one is preferred. A component should be "light weight" to ensure its ease of adoption and integration across a variety of users and uses.
- Make components discoverable: Ad-hoc mission-focused composability necessitates the ability to find the components and data best suited for a particular task in timely manner. A "marketplace" or "app store" concept is a useful construct for many CCOD environments.
- Develop components with an understanding of the end user: Early experience is leaning toward a design concept for CCOD that follows a multi-level producer/consumer design pattern. Some components will still be developed/composed by an engineer with operational/domain knowledge, but ultimately the promise of CCOD is fulfilled by the user/operator composing new functionality from existing components. Throughout the composition and use process, there are a number of users with differing roles and responsibilities:
- Combat Coder or "Mashup Engineer" develops, prepares, and publishes the data and services for consumption. This engineer has operational/domain knowledge and can compose data and visualizations into raw application components for users.
- Average users/operators tailor the raw application components to meet their specific needs, responsibilities, and preferences. This is the first layer of users who consume or interpret the data, potentially adding, modifying, or filtering it before sending it up the chain. This is a typical operator in a mission setting who has potentially complex, mission-centric responsibilities yet is not a computer programmer.
- Commander is a high-level information consumer who combines data from a number of sources to make final decisions.
- Focus on reuse: Perhaps the greatest value of composable capability is the reuse of someone else's components and compositions. Each CCOD component should be reusable and generic allowing other CCOD projects to use it, particularly outside the direct composition environment. Each solution should be used by successive CCOD projects to build on previous experience and lessons learned. Where possible, use existing open source solutions/tools that have adoption momentum and are adequate to the task at hand (e.g., Restlet, PostgreSQL, PostGIS, Smile, Jetty).
- Strongly consider RESTful architectures: This framework has proven to be robust and flexible enough to allow for quick development and integration of components. Consider the Web Application Description Language (WADL) data standard , which has been used to facilitate communication between RESTful services. While WADLs have some potential restrictions as a result of their simplicity, these restrictions were not a hindrance in a Department of Defense project using CCOD. In fact, it was an advantage to the implemented architecture. WADLs are intuitive, easy to write and understand, and require minimal effort for cross-service communication.
- Strongly consider loose couplers: Design components and services to be independent of one another through use of loose couplers. In some MITRE CCOD projects, effective loose couplers proved to be:
- UCore for mission data interoperability 
- KML for geo-referenced data 
- WADL for RESTful services
- CoT for tactical mission data interoperability 
Use standard industry data formats as loose couplers for ease of reuse, integration, and adoption of components. Loose couplers can reduce the number of required data translations from N2 to 2N.
- Explicitly design component granularity: Components of a composition must be at the appropriate abstraction level. For non-technical users to perform composition, the components must be abstract enough to be understood, flexible, and unusable. Minimize interaction between the components by using a loose coupler. Document dependencies between components/services. It is important to test the component abstraction level with the intended user population (e.g., average user, combat coder, etc.).
- Prepare design/artifacts and integration plan early to mitigate integration challenges: Due to the challenge of integrating diverse components at run-time, it is important to develop system architecture and sequence diagrams in the early stages of a CCOD project. This helps build a strong foundation when later creating an integrated system. Where possible, use approved design patterns to enhance extensibility and understanding. It is important to clearly communicate the design and goal of the various project elements to the project team early in the process. It is important to have lower-level component tests along the way, to test each self-contained component, as well as enterprise-scope testing. Incorporate many iterations, with small increments to functionality, to enable testing.
- Emphasize documentation: Documentation is crucial for any system implementing CCOD principles. The goal is to have combat coders and average users who may be unfamiliar with any component/service leverage or reuse this functionality. Document early on and throughout the development process, and provide easy discovery and navigation of the documentation. Agree upon the documentation approach at the beginning of the project. As appropriate, use tools and formal modeling approaches to ease communication outside the project.
- Separate visualization from function: One CCOD-based prototype developed at MITRE could not naturally conform to a typical Model-View-Controller (MVC) design pattern, yet separation of the visualization from data components remained critical. Data only has to be exposed in simple standards to be visualized in useful ways. These include Hypertext Markup Language (HTML) tables, Extensible Markup Language (XML) (plain, Real Simple Syndication [RSS], geoRSS, KML, RESTful Web services), comma-separated values, etc.
- Accommodate dependencies: There is greater dependence and reliance on other systems' performance and availability in a CCOD system. If there are known performance issues, it is advisable to duplicate data sources, where possible, so that no piece of the system is completely dependent on an unreliable component. Document dependencies using a modeling paradigm as appropriate.
- Scope the use of CCOD: CCOD represents a very large solution space. It is important to have a well-defined use case for CCOD that can be scoped within given resource and time restrictions.
- Seek operational context: Seek operational expertise early to define the operational scenarios and use cases to which a CCOD solution will be applied. Some use cases, situations, or entire systems may not be viable candidates for a CCOD approach (e.g., real-time semi-automated targeting systems).
- Build from existing components: Where possible, CCOD will provide capabilities built out of existing components discoverable and integratable on the network and/or adaptors interfacing with "non-composable" systems of record. Seek ways to provide composable "pieces" of large systems.
- Verification/Validation: All components should be tested to ensure that they operate as designed, prior to being integrated into the component repository or storefront. Developer testing should be documented so that users of components will be able to better understand the approved use and limitations of components.
References & Resources
- Chairman of the Joint Chiefs of Staff Instruction, March 1, 2009, CJCSI 3170.01G, Joint Capabilities Integration and Development System, accessed November 28, 2009.
- "Agile Capability Mashup Environment (ACME) Lab Drives Innovation and Integration," sidebar in REACT Fine-Tunes Air Force Capabilities Before Live-Flying, accessed April 30, 2010.
- W3C Member Submission, August 31, 2009, Web Application Description Language.
- "Universal Core Advances Information Sharing Across Government Agencies," accessed April 30, 2010.
- Open Geospatial Consortium (OGC), KML Standard,accessed February 9, 2010.
- "Creating Standards for Multiway Data Sharing," accessed April 30, 2010.
Additional References & Resources
For more information on CCOD's foundational concepts, see Alberts, D., J. Gartska, and F. Stein, July 2002, Netcentric Warfare, CCRP Publication Series.