An Abstracted and Effective Capabilities Portfolio Management Methodology Using Enterprise or System of Systems Level Architecture

The book "Systems Engineering: Practice and Theory" is a collection of articles written by developers and researches from all around the globe. Mostly they present methodologies for separate Systems Engineering processes; others consider issues of adjacent knowledge areas and sub-areas that significantly contribute to systems development, operation, and maintenance. Case studies include aircraft, spacecrafts, and space systems development, post-analysis of data collected during operation of large systems etc. Important issues related to "bottlenecks" of Systems Engineering, such as complexity, reliability, and safety of different kinds of systems, creation, operation and maintenance of services, system-human communication, and management tasks done during system projects are addressed in the collection. This book is for people who are interested in the modern state of the Systems Engineering knowledge area and for systems engineers involved in different activities of the area. Some articles may be a valuable source for university lecturers and students; most of case studies can be directly used in Systems Engineering courses as illustrative materials. following:


Current issues on system of systems problems
The definition of system of DoDAF V2.0 (DoD, Aug. 2010) has been changed from that of DoDAF V1.5. A system is not just computer hardware and software. A system is now defined in the general sense of an assemblage of components (machine or, human)-that perform activities (since they are subtypes of Performer) and interact or become interdependent. The Federal Enterprise Architecture Practice Guidance (Federal Government, 2007) has defined three types of architecture: enterprise architecture, segment architecture, and solution architecture. "Enterprise architecture" is fundamentally concerned with identifying common or shared assets -whether they are strategies, business processes, investments, data, systems, or technologies. By contrast, "segment architecture" defines a simple roadmap for a core mission area, business service, or enterprise service. "Solution architecture" defines agency IT assets such as applications or components used to automate and improve individual agency business functions. The scope of solution architecture is typically limited to a single project and is used to implement all or part of a system or business solution. From the viewpoint of a system hierarchy, the solution architecture addresses system level problems whereas enterprise architecture and segment architecture address SoS/FoS problems respectively. Systems engineering methodologies have evolved to deal with enterprise or SoS level problems.
The purpose of DoDAF V2.0 is to define concepts and models usable in DoD's six core processes: 1. Capabilities Integration and Development (JCIDS) 2. Planning, Programming, Budgeting, and Execution (PPBE) 3. Acquisition System (DAS) 4. Systems Engineering (SE) 5. Operations Planning 6. Capabilities Portfolio Management (CPM) The DoD's six core processes are good examples of addressing SoS level problems. However, DoDAF V2.0 and other guidelines state requirements rather than how to perform these processes. This chapter provides a methodology for CPM which contains detailed processes, methods, artifacts and tailored meta-model of DM2. ISO/IEC 24744 (ISO, 2007) defines that a methodology specifies the process to be executed, usually as a set of related activities, tasks and/or techniques, together with what work products must be manipulated (created, used or changed) at each occasion possibly including models, documents and other inputs and outputs. So a methodology is the specification of the process to follow together with the work products to be used and generated, plus techniques which are the consideration of people and tools involved, during a development effort.

Process, methods, tools, and environment concept of methodology element
According to Martin (Martin, 1997), it is important to have a proper balance among process, methods, tools, and environment (PMTE) when performing systems engineering tasks. He www.intechopen.com An Abstracted and Effective Capabilities Portfolio Management Methodology Using Enterprise or System of Systems Level Architecture 185 defines that a process is a logical sequence of tasks performed to achieve a particular objective, a method consists of techniques for performing a task, and a tool is an instrument when applied to a particular method. While, in ISO/IEC 24744, a method is used as a synonym of methodology, this chapter adopts Martin's PMTE paradigm. So this chapter provides the CPM methodology which has its own process, method (technique), and tool (model or artifacts). ISO/IEC 24744 (ISO, 2007) also states that a methodology element is a simple component of a methodology. Usually, methodology elements include the specification of what tasks, activities, techniques, models, documents, languages and/or notations can or must be used when applying the methodology. Methodology elements are related to each other, comprising a network of abstract concepts. Typical methodology elements are Capture Requirements, Write Code for Methods (a kind of tasks), Requirements Engineering, High-Level Modelling (kinds of activities), Pseudo-code, Dependency Graphs (notations), Class, Attribute (kinds of model building blocks), Class Model, Class Diagram, Requirements Specification (kind of work products), etc. From this concept, the elements for CPM methodology of this chapter are Capture Requirements (top level CPM requirements), High-Level Model of CPM process (kinds of activities), metamodel (Class Diagram), and Attribute.

Metamodel development requirements
A metamodel is the specification of the concepts, relations and rules that are used to define a methodology. This metamodel should be simple and consistent with the analysis methodology. And the metamodel is a schema for semantic data and a language that supports a particular process, method (technique), and tool (model or artifacts).
Probability and set theory have axioms of mutually exclusive and collectively exhaustive (hereafter, MECE) concepts, and decomposition concepts. This means no overlap, no omission of concept and complete decomposition of a concept also. Axiomatic design theory (Suh, 1990) states that the design axiom No.1 is the independence axiom, "Maintain the independence of functions (not affecting other functions)" and the design axiom No. 2 is the information axiom, "Minimize the information content of the design (functionally uncoupled design)." These are the same MECE principle concept of different viewpoints, one is a set viewpoint and the other is a functional design viewpoint. A past study (Lee and Park, 2009) adopted this concept to the metamodel design. The study pointed out that if the metamodel design satisfies the MECE principle, the classes within the metamodel is distinguished from each other clearly, the model composes a complete set of semantic, and relates to each other clearly. The metamodel requirements of this study are summarized in Table 1.
Each class of the metamodel should be mutually exclusive and collectively exhaustive concepts as defined in the axiomatic design theory.
2 Metamodel should be consistent, integrated and balanced among processes and methods to achieve the greatest benefits from the disciplined systems engineering practice.

3
The requirement space and the solution space shall be separated strictly as the systems engineering teaches to ensure the solution space is open for multiple candidates.

4
The attributes of the metamodel should result in effective benefits from the viewpoint of SoS architecting and its usage (e.g. CPM). And the study (Lee & Park, 2009) also proposed five rules for developing metamodel and those metamodel development requirements are presented in Table 2.
No. Metamodel development requirements 1 Create the minimum number of data groups 2 Do not overlap concept across data groups 3 Make the relation names among groups clear and meaningful.

4
Make the relations among the groups to represent systems engineering methodology.

5
Include the operational viewpoint and system viewpoint category while creating groups. As mentioned before, the metamodel must be consistent, integrated and balanced between process and methods to achieve the greatest benefits from the good systems engineering practice. The systems engineering method teaches that the requirement space and the solution space shall be divided strictly. These attributes of the metamodel resulted in effective benefits from the viewpoint of building architecture (e.g. SoS architecting) and the usage (e.g. CPM).

Capability Portfolio Management requirements
DoDD 7045.20 (DoD, Sep. 2008) defines that capability portfolio management (CPM) is the process of integrating, synchronizing, and coordinating Department of Defense capabilities needs with current and planned DOTMLPF 2 investments within a capability portfolio to better inform decision making and optimize defense resources and capability portfolio is a collection of grouped capabilities as defined by JCAs 3 and the associated DOTMLPF programs, initiatives, and activities.

Fig. 1. Notional class hierarchy of DM2
In order to overcome complexity and enhance usability of metamodel, Lee & Park proposed another metamodel based on DoDAF 2.0 JCIDS overlay protocol. Fig. 2 shows Lee & Park's proposal for CDM. The study articulate that the proposed metamodel is the product of an integrating effort that combines the MECE principles, systems engineering principles. The study also demonstrates that it is a simple and effective process to develope and use the artifacts of an architecture.
The CDM of current DM2 of DoDAF V2.0 is similar to the proposed Lee & Park's metamodel. Fig. 3 shows DM2 CDM overlay with the Lee & Park's proposed metamodel. And process viewpoint of methodology status, CBA guides (DoD, Dec. 2006) have relatively detailed information about CBA process and methods. The CBA process and related information could be used to perform CPM but that is not sufficient for CPM method. The following part provides CPM process, product and method which manipulate information of the product and supporting metamodel.

Proposal of Capability Portfolio Management methodology
As mentioned before, a methodology specifies the process to be executed, usually as a set of related activities, tasks and/or techniques, together with work products possibly including models, documents. CPM methodology has its own process, method (technique), and product (model or artifacts) as the tool category of Martin's PMTE. According to these requirements, the CPM methodology of this chapter shows CPM process, product and model related technique. The CPM process consists of a set of activities/tasks. Each step of activity has corresponding output product and model related technique which is used to build model and/or generate the output products.
In order to facilitate further discussions, key terms quoted from DoDD 7045.20 capability portfolio management (DoD, Sep. 2008) are defined as follows. Capability portfolio is a collection of grouped capabilities as defined by JCAs and the associated DOTMLPF programs, initiatives, and activities. And CPM is the process of integrating, synchronizing, and coordinating capability requirements with current and planned DOTMLPF investments within a capability portfolio to better inform decision making and optimize defense resources. From this definition, CPM can make a balanced capability requirements to maximize mission effects within limited resources and the capability requirements are originated from a group of capabilities defined by JCAs.

Capability Portfolio Management process
CPM requirement is to provide recommendations regarding capability requirements to capability investments. So CPM process has to generate balanced capability requirements. The capability requirements should be generated with DOTMLPF investments within a capability portfolio (a collection of grouped capabilities as defined by JCAs).
To achieve these CPM requirements a proposed process is composed of following 5 activities: (1) Define top level missions and develop scenarios (2) Build trace relation among elements of JCA, universal joint task list (hereafter, UJTL) and activity and identify mission essential task list (hereafter, METL) of DoD (3) Develop capabilities and the related conditions and resources (4) Analyze mission effectiveness and derive (transform) capability requirements (5) Derive integrated & balanced capability requirements. And more detailed tasks are listed in Table 5.

Capability Portfolio Management method and product
In order to provide CPM method and product which could be a model or artifact. This part provides descriptions, products and model related techniques for each task of CPM process.

Design operational scenarios for each mission
 Description: Designing operational scenarios for each mission is a process to define a series of activities in each thread. Through this process, the end to end sets of activities of operational nodes are designed, and states of mission accomplishments are designed by integrating those threads  Product: Operational scenario template  Model related technique: The activities within an operational scenario are kind of activity and these activities are the leaf-node activities of an activity hierarchy. Thus the level attribute of the leaf-node activity should be set as 'Leaf-node'. The leaf-node activity could directly allocate to supporting entity e.g. operational node and system node. Model related technique: Resource class is separately required with other performer type classes e.g. organization and system. The resource class has relation with activity and capability class. Resource class has resource type of DOTMLPF. Especially the Resource class typed with organization is equivalent to organization class and resource class typed with materiel is equivalent to system class.

Analyze operational effectiveness for each operational mission
 Description: Performance levels for each activity are analyzed to estimate the performance level of activities to produce best mission effectiveness within constrained resources under the given condition for activities to accomplish operational missions. It is required to determine performance indicators or standards of each activity to achieve mission effectiveness. Especially this analysis works are performed in aspect of operational missions in this step. And so, the performance levels of activities for each operational mission (e.g. JOC) are measurements of operational effectiveness (MOEs).  Product: Operational mission effectiveness and performance of activity table  Model related technique: Within activity class, mission level attributed activity element could have sub attribute of operational mission type and functional mission type. And to display and analyse the performance of scenario, a performance measure class is required. And according to the type of activity of mission scenario, the attribute of a measure could be operational effectiveness (reflect JOC), functional performance (reflect JFC) or system performance.

Analyze operational effectiveness for functional missions
 Description: Performance levels for each activity are analyzed to estimate optimized performance level of activities which produce best operational mission effectiveness within 'constrained resources' which support activities to accomplish functional missions. From the viewpoint of opposite direction, the performance level of activities performing a functional mission should be optimized to enhance the total performance of the activities performing various operational missions. This opposite directional task will be explained at 4.2.15 again. It is required to determine performance indicators or standards of each activity to achieve mission effectiveness. Especially in this step, the analysis works are performed from the viewpoint of functional missions relative to the operational missions. And so, the performance levels of activities for each functional mission (e.g. JFC) are measurements of operational effectiveness (MOEs).  Product: Functional mission effectiveness and performance of activity table  Model related technique: Within Activity class, mission level attributed Activity element could have sub attribute of operational mission type and functional mission type. And to display and analyse the performance of scenario, a Performance Measure class is required. And according to the type of activity of mission scenario, the attribute of a measure could be operational effectiveness (reflect JOC), functional performance (reflect JFC) or system performance.

Allocate operational element to supporting systems element
 Description: This phase changes operational viewpoint to system viewpoint. And this phase allocates defined organization, operational nodes, activities and input/output information to systems, system nodes, system functions and input/output data. Lessons learned from systems engineering imply that system elements are not considered before this step, and instead, requirements are defined in operational viewpoint, then operational requirement are converted into system viewpoint in order to support operational requirements. Organization class is supported by system class. Operational node class is supported by system node class. Activity class is supported by function class. Operational information class is supported by system data class.

4.2.
14 Synthesize operational performances to system performances  Description: This step aims that operational performances, which are derived from operational activities, are changed to system performance, which are derived from system functions. A system function is employed to support several operational activities. Those operational performances are synthesized into an optimized system performance from the view point of cost-effectiveness.

Metamodel for Capability Portfolio Management
From the proposed CPM process, and based on DM2 CDM and Lee & Park's metamodel, the additionally required classes (Entity type), attributes of classes and relations for each task are identified. The additionally identified classes, relations, and attribute are used to complement metamodel for CPM methodology. Table 6 shows the additionally required classes, relations and attributes. Like the study (Lee & Park, 2009) proposed metamodel, CPM metamodel should be developed in accordance with the metamodel requirement and metamodel development requirements of Table 1 and 2. And also CPM metamodel should be aligned with DM2 CDM for interoperability with DoDAF V2.0. Table 7 shows the proposed CDM classes for CPM which is aligned with classes of DM2 CDM and additionally added classes originated from Lee & Park' metamodel and the CPM task analysis. The additional JCA and UJTL classes comes from CPM task analysis of Table 6 and System Node and Function classes reflect the systems engineering concept of strict separation of requirement space and solution space. And according to the metamodel development requirements, classes are related and named meaningfully and reflect operational requirement space and system solution space. Fig. 4 shows the resulted CDM for CPM methodology.

Conclusion
The purpose of this paper is to provide an abstracted metamodel for use in CPM effectively based on DoDAF V2.0. The proposed CPM methodology provides a process, tasks of the process, products, and model related technique which supports the generation of products in accordance with the methodology definition of ISO/IEC 24744. To promote the usability, the proposed methodology suggest a detailed CPM process. Additionally, in order to be an effective and efficient methodology, the CPM metamodel is developed in accordance with the MECE principles, systems engineering principles which was proposed earlier by Lee & Park's metamodel requirements. And to obtain the interoperability with DoDAF V2.0, the proposed CPM methodology is developed in accordance with DM2 CDM.
However, the current proposed abstracted metamodel remains on a theoretical and logical level and requires validation experimentally or in field applications. In the near future, the proposed metamodel must be validated for application use. However, the proposed CPM methodology is expected to be helpful in practice in the field.