4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
1*
2
1 Department of Weapon Systems, Korea National Defense University, Seoul, Korea
2 DASI, University of South Australia, South Australia, Australia
* E-mail: yskwon@kndu.ac.kr
Capabilities based planning (CBP) is becoming popular amongst defence organisations throughout the world. CBP supersedes threat-based planning as the paradigm used to determine the equipment investment strategy for the nation’s defence forces.
It is normal to conduct CBP using a range of defence scenarios that also investigate the degree to which future materiel acquisitions can form military System of Systems (SoS) to achieve greater military effectiveness. While there is a generic commonality in capabilities based planning concepts throughout the world, each country needs to define its own processes, tools, and techniques.
This paper examines the US capabilities based planning process and comments on how it could be modified to suit the needs of the Korean defense planning environment.
KEYWORDS
1.
: capability-based planning, SoS.
Defence planning has been made more challenging in recent years because individual military systems are now routinely networked to become complex SoS. Such SoS are a forcemultiplier and are seen as crucial to the warfighting concepts of modern nations, see for example [1] whereby missions are accomplished through network-based battlespace management systems which are formed by grids of various sensors and shooters in a single theater. Specifically, a SoS results when independent and useful systems are integrated into a larger system that delivers unique capabilities. The distinguishing feature of a SoS over a large monolithic system is that a SoS comes into being from a series of acquisition actions and typically has no one single management entity.
A consequence of the SoS age is that it is becoming increasingly important to consider how each new system might be used in a SoS context.
As there are many such potential SoSs, this can be a challenging and time-consuming activity and needs to be undertaken at the level of either the entire defence force or some large component of it rather than the project level.
Defence planners have sought to deal with the complexity of SoS issues though a number of means. For example, the US, UK and many other countries have applied a joint capabilities based top-down approach to plan their defence acquisition priorities.
In this paper we are interested in uncovering those generic features of defence planning that can be tailored to fit the Korean defence environment.
The approach we have chosen is to examine the salient parts of the US defence planning process and use this as a basis for our design. This is the first of a sequence of works that will document the rationale behind the proposed defence planning process. Later papers will refine the ideas and

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010 incorporate thinking from other countries as a counter balance to the scale of the US defence enterprise.
There are three key processes in US DoD decision support system that must work in concert to deliver the capabilities required by the warfighters: Joint Capabilities Integration &
Development System (JCIDS), Defense
Acquisition System (DAS), and Planning,
Programming, Budgeting and Execution (PPBE).
Each process has an independent documentation system and area of interest that defines each program, but they are closely integrated, and performed concurrently. In particular, the total lifecycle DAS performs its process through capability needs derived from JCIDS. Therefore, in order to effectively implement the defence acquisition process in the SoS environment, it is necessary to clearly understand JCIDS at the capability level and DAS at the system level, as well as the
Capability Evolution Process (CEP) that performs a bridging function to link them smoothly between the different levels.
This paper is focused on examining these intertwined processes to gain an appreciation of how to apply capabilities based planning processes efficiently to the Korean acquisition environment. for example [2].
The fundamental change of the approach is due to the change in how warfighting will be conducted into the future. This is because in the nonlinear future battlespace, the enemies and where the battle will happen will not be clearly predictable [3].
Thus, the capabilities based approach aims to implement a set of military capability that are able to adapt to dynamic challenges and circumstances under uncertainty. This approach satisfies broad security challenges as it is focused on effects rather than performance of the weapon systems in order to mitigate the uncertainty arising from unidentified future enemies and unforeseeable missions. In addition, the capabilities based approach performs a sequential top-down process that capability is derived from concepts as shown in Fig. 1. The core elements of capabilities, shown in the figure below and abbreviated as DOTMLPF, to accomplish military capability needs are derived through the process. In other words, given any mission, the capabilities to perform the mission and functions are derived, and then, the systems required to form these capabilities are defined.
2.
US, UK and other developed countries, are applying capabilities based planning processes.
Korea has also been moving in this direction. The
United States in 2001 Defense Review QDR
(Quadrennial Defense Review) report stated that a new defense strategy will be established according to the capabilities based approach as an alternative to threat-based planning. It represents an attempt to break down traditional stovepipes and provide for transparency and coherence. It has two fundamental differences from threat based planning.
Firstly, it focuses on goals and end-states and encourages innovation. Secondly, it starts by asking questions regarding what do we need to do rather than what equipment we are replacing, see
Fig .1. Capabilities based process.
Fig. 2 illustrates an example of a top-down system definition process based on capabilities.
Within the U.S. Navy, the NCDP identifies and prioritizes capability gaps from the Sea Power 21 construct of three concept areas, enabled by
FORCEnet [4], that categorize 22 sub-missions providing over 236 discrete warfighting capabilities. It also requires systems more than 400 to meet the identified capability areas. There are more than one thousand platforms and facilities that contribute to these warfighting capabilities at any given time. These systems and platforms are constituted and deployed in four types of force packages based on current Navy operating doctrine.
The future globally networked, distributed combat

force will be composed of multi-mission systems installed on multi-mission platforms, deployed in multiple force packages.
4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
Fig .2. Capabilities based system definition [5].
3.
The capabilities based acquisition process is performed and managed by the capability derived from the user needs definition process and its products. But, even though most modern defence systems are a part of the SoS, the capabilities based acquisition in the practical defence acquisition process is restricted because of the lack of experience and awareness. This can be improved by a clear understanding of the Capability
Evolution Process (CEP) as shown in Fig. 4. The
CEP performs functions such as a bridge to link between the JCIDS at capability level and the DAS at system level.
Under the network-based SoS environment, a substantial requirement of the new defence decision support system is to introduce a capabilities-based approach. There are three key processes in US DoD decision support system that must work in concert to deliver the capabilities required by the warfighters, i.e., the requirements process as implemented in JCIDS, the acquisition process, and PPBE process. Successful defense acquisition is made more likely by synchronization of the three processes. The military forces and their capabilities are defined and allocated by the processes.
Fig .4. Relationships of JCIDS, CEP and DAS.
Fig .3. DoD decision support systems.
In the 1990s to early 2000, US the acquisition process began with Mission Needs Statement
(MNS) that stated platform based system definition according to the threat based approach. So, the system was defined through threat based
Requirement Generation System (RGS) at the system level. In 2003, the RGS was revised to conform with the capabilities based planning process at the SoS level that is more suitable for the networked based future battlespace. The JCIDS capabilities based needs definition process is a key supporting process for DOD acquisition and PPBE processes. JCIDS is a top-down approach that identifies required joint capability to carry out missions and their tasks in the future joint battle

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010 space. JCIDS plays a key role in identifying the capabilities required by the warfighters to support the National Defense Strategy, the National
Military Strategy, and the National Strategy.
(To counterbalance JCIDS, RGS is conducted in each Service based on a bottom-up system definition that can capture local needs, equipment end of life of type issues and the like.)
The JCIDS process begins with deriving joint operational concept from national security strategy as shown in Fig. 5. Operations Plan (OPLAN),
Concept of Operations Plan (CONPLAN), joint doctrine and experience from current operations provides concepts for near-term operations that can be expected to occur within next seven years. In addition, Concept of Operation (CONOP) from
Defense Planning Scenario (DPS) serve as joint concepts for mid- (8-14 years) to far-term (15 years and beyond) planning.
These concepts provide conceptual foundations of Capabilities Based Assessment (CBA). After identifying the lack of current capability and overlap through CBA, potential materiel and nonmateriel solution analysis is performed. The CBA process is the backbone of JCIDS. CBA results derived in this way can be used as a basis for related activities. As can be seen in Fig. 6, capability documents developed by the JCIDS process drive the DAS activities. JCIDS and DAS processes are performed simultaneously. The capability needs derived through the JCIDS process serve as the basis for the development and production of systems to fill those needs.
Fig.
6. JCIDS and defense acquisition system.
The US defense acquisition process has been changed continuously. Starting from DoDD 5000.1 in 1971 the acquisition process has been revised and Fig. 7 shows the transition from threat based to capability based approaches. In 2000, the acquisition process changed to begin with the system definition and MNS based on the threatbased analysis. In addition, systems engineering based evolutionary acquisition strategy was applied and the previous four milestones reduced to three.
Fig .5. JCIDS process.
Fig .7. Changes of US defense acquisition framework.
The acquisition revision in 2003 emphasized activities in its early phases, such as concept refinement and technology development. It can be seen to reflect early activities of systems engineering that emphasize the importance of

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010 operational concepts. For this reason, the acquisition process in 2003 was required to perform a system concept definition through a topdown approach in the phase of needs definition and to enter the concept refinement phase again in the early part of acquisition life-cycle framework. The revised process focused on capabilities based needs definition and also introduced big changes in the documentation supporting the joint capability. For example, existing MNS has been changed to Initial
Capabilities Document (ICD) and Operational
Requirement Document (ORD) which used to support decision at milestone B to CDD. ORD at milestone C has been changed to CPD.
In the revised acquisition process in 2008, the existing spiral development was removed from the evolutionary acquisition strategy, and only an incremental approach has been remained. It means that the capabilities based acquisition begins with definition of end state. The reason for excluding the spiral approach is that the spiral approach had tended to begin with unreasonable expectations of new technology opportunities and this repeatedly resulted in increases in cost and schedule risks. In addition, the existing Concept Decision (CD) was replaced by Materiel Development Decision
(MDD) and Concept Refinement (CR) by Materiel
Solution Analysis (MSA). Thus, non-materiel solution is performed by DCR (DOTMPF Change
Recommendation) of JCIDS, but materiel proposals are contained in the defined solution in
ICD at MSA phase in terms of technical level, cost, schedule and performance parameters. System
Development & Demonstration phase has been replaced by Engineering and Manufacturing
Development (EMD) phase in order to further emphasize existing systems engineering and technical reviews.
According to recent changes in DoD policies, defence acquisition management system life cycle has been changed. Key mandates of the Weapon
Systems Acquisition Reform Act of 2009 are as follows: documented assessment of technological maturity and integration risk of critical technologies for Major Defense Acquisition
Program (MDAP) during the Technology
Development (TD) phase; competitive prototyping and MDA completion of a formal Post-Preliminary
Design Review Assessment for all MDAPs before
MS B [6].
In the SoS environment, it is important to accomplish the required capability for performing missions in which integration and interoperability between single systems of SoS are assured. Thus, a key activity of SoS systems engineering is to establish plans for the evolution at SoS level through the needs definition process. To facilitate this, the Capability Evolution Process performs a bridging role between the JCIDS and DAS. It operates within the capabilities based and evolutionary acquisition frameworks. The
Capability Evolution Process is a time-phased sequence of the three sub-processes: Capability
Evolution Planning, Capability Engineering
Process and Portfolio Execution Process. Its principle activities and products are intended to comply with and support the JCIDS, and DoD acquisition phases and milestone requirements.
Fig .8. Revised defense acquisition process in 2009.
Fig .9. Capability Evolution Process [7].

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
Capability Evolution Planning and Capability
Engineering Process are processes that support the pre-Milestone B activities of the Defense
Definition' is to identify all systems, either inservice or in acquisition, and the important interrelationships between those force units and translates the warfighter’s description of a required capability into the domain of the acquisition community. This process phase addresses creation of acquisition portfolios for SoS systems engineering, and identifies initial system performance allocations and interface relationships among the portfolio systems. The output of the
Capability Evolution Planning is the Capability
Evolution Plan that is used as a guide in future investment decisions. The activities performed in this phase support the pre-Milestone A activities for programs entering the Defense Acquisition System.
The Capability Evolution Plan includes concept of operations, capability evolution objective, force package structure, sustainment concept and capability investment plan, etc, and also supports the establishment of the Systems Engineering Plan
(SEP) and Technology Development Strategy
(TDS) of single systems at MS A. Establishment of acquisition portfolio for meeting the required capability, and integration and interoperability across single systems of a SoS can be assured through the capability evolution planning step. identified in the approved capability document. The planned architecture consists of the operational architecture required to execute the mission capability, the functional decomposition of the operational architecture, the physical architecture for the in-service and funded acquisition systems related to the force package, and technical descriptions of the SoS interfaces. When complete, the planned architecture represents the set of mission related systems that may have to be modified, or added to, to satisfy the capability need.
‘
Identify Viable Portfolio Alternatives
’
is a function needed when portfolio is established to construct force package for meeting the capability needs. In order to identify viable portfolio alternatives, architectural principles and guidelines have to be established. The intent is to understand how the design will remain 'open', and support capability evolution growth while maintaining a high degree of integration and interoperability In the 'Perform Sensitivity Analysis' step, feasible alternatives are identified by sensitivity analysis. A widely used approach for performing sensitivity analysis across a variety of factors is the Quality
Function Deployment (QFD) technique. QFD permits the operational objectives/requirements to be related to technical design attributes against which alternatives can be evaluated. Finally,
'Identify Capability Evolution' is the function for developing preliminary the System Performance
Document (SPD) and the Capability Evolution Plan after determining preferred alternative through sensitivity analysis.
Fig .10. CEP and Capability Engineering Process [7].
As can be seen in Fig. 11, Capability Evolution
Planning consists of five sub-functions, as follows:
'Conduct AOA', ' Planned Portfolio Architecture
Definition', 'Identify Viable Portfolio Alternatives',
'Perform Sensitivity Analysis', and 'Identify
Capability Evolution'.
The aim of 'Planned Portfolio Architecture

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
Fig .11. Capability Evolution Planning N² chart.
The Capability Engineering Process performs detailed functional and performance analyses, and design synthesis at the SoS level to allocate performance, and to identify key system interfaces and integration and interoperability requirements among portfolio systems. A key product of the
Capability Engineering Process is the SPD which serves as the functional baseline for the SoS. The
SPD supports establishment of the CDD,
Specifications, Test & Evaluation Management
Plan (TEMP) which are products of Technology
Development (TD) phase. The activities performed in the Capability Engineering Process support the pre-Milestone B activities of the acquisition system.
The Portfolio Execution Process supports post
Milestone B activities of the acquisition system. It informs decision makers of the consequences of decisions on individual portfolio programs, or the effect of changes during program execution. This phase assists decision makers in moving toward achieving the performance, integration and interoperability requirements prescribed in SPD, and toward achieving the Capability Evolution Plan fielding plan. Portfolio programs as they move through their respective capability demonstrations and operational evaluations and into production and deployment.
Fig.
12. Portfolio Execution Process [7].
Major functions of the Portfolio Execution
Process include portfolio assessment, program alignment, portfolio risk assessment, and program status. Its products are as follows: integrated portfolio schedule, interface design matrix, and integration/interoperability test matrix. Portfolio deployment baseline is developed by monitoring and reviewing the EMD phase activities of single systems through functions and products of the
Portfolio Execution Process. The baseline supports establishment of initial production baseline and
CPD in the single systems. Thus, the Portfolio
Execution Process allows for continuously monitoring integration and interoperability of the portfolio of single systems, and for providing balanced information to decision makers when the portfolio is changed.
4.
As the world has evolved from the industrial age to the information age, the future battlespace environment has also been transformed into network based military forces that are best thought of as a SoS. Most of today's weapon systems have performed their functions as a part of SoS, even if this has not been clearly recognized. Nevertheless, there is a lack of the awareness and understanding of the implications of SoS on the practical acquisition process on many countries.
Introduction of the capabilities based approach emphasizes an acquisition planning phase that

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010 includes user needs definition process and effective system integration efforts. Therefore, in order to establish a capabilities based process suitable for the Korean defence acquisition environment, the following should be considered.
First of all, in order to implement a capabilities based acquisition process effectively, establishment of a systems engineering based military capability definition process and its broad awareness are required. The capability definition needs to be derived through a recursive top-down process that develops DOTMLPF solutions consisting of materiel and non-materiel elements. This also needs to be supported by bottom-up user needs from operators and maintainers. Fig. 13 shows capabilities based techniques need to be applied at three levels. In other words, the capabilities based planning approaches are a comprehensive concept that includes non-materiel required to perform missions and functions effectively as well as materiel (end product). For example, an infantry battalion can be thought as a troop of soldiers armed with rifles, but in terms of capability, in order to accomplish a given task, it should also included food, fuel, ammunition, transportation, communications, command and administrative support organizations, as well as in combat infantry soldiers, such as end product. individual component systems are optimized to meet military SoS requirements as opposed to standalone requirements.
In addition, one of the important things required for successful implementation of a CEP is stakeholder involvement and information sharing.
Stakeholders must be included in the CEP to ensure that their requirements and concerns are considered.
Key stakeholders will eventually control the process, and it is therefore important that they feel
‘they have ownership of it’. Related material release may be limited for the public, but in particular, understanding and participation of the defense industry which plays a practical role in the development and production is important. A good example of this kind of effort is evidenced in
Australia where the DCP (Defense Capability Plan) is freely available to defense industry [8]. Such disclosure also provides a common awareness and helps prepare industrial technical maturity for forthcoming system developments by informing industry of the scope and scale of the future defence equipment capital program.
Fig.
13. Capabilities based SoS level [5].
The Korean acquisition infra-structure is strongly aligned to project-centric materiel acquisition. Korean Joint Chiefs of Staff have promoted a capabilities based needs definition process, but there is no equivalent to the US
Capability Evolution Process. Perhaps the first element of such as process would be the coordination of SoS portfolios such that the
Fig .14. Capability development documents [9]
\
Any CEP will need to ensure that single system
Capability Definition Document (CDD) and the resulting System Engineering Plans (SEP) reflect the requirement so the SoS with which the system may need to be integrated. This is not a straightforward process because their individual systems will always be procured asynchronously and component system will often be used in ways that were never intended during their acquisition.
Moon and Cook [10] identified some generic activities required to manage a SoS portfolio of projects. This is reproduced below.
“A portfolio comprises a number of capabilities that need to be managed through-life as a composite system. Brook (2000) and Romano

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
(1998) provide insight into the high level management functions that will need to be performed:

Continuous assessment of the operational effectiveness of the portfolio (including readiness and cost)

Continuous assessment of the contribution of individual capabilities (and components thereof) and the potential need to upgrade or replace them.

Proposing new projects to fill forthcoming capability gaps.

Managing and integrating supporting experiments and demonstrators.

Overseeing insertion into service and integration of individual systems into the portfolio of capabilities.

Gathering feedback from users on currently fielded systems.

Maintaining whole-capability models to inform other defence activities.

Development and evaluation of tactics and doctrine (using live and virtual forces).

Evaluation of new capability options, including force mix and equipment types.

Configuration management of the portfolio
(ie understanding the inventory, including build state, both currently and into the future).

Working with operational commands to assist in creating a task force for a particular mission from the personnel available and the systems in the inventory.
Brook points out that these functions go well beyond the tasks undertaken by the relevant delegates in the UK Ministry of Defence. This may also be true of the Australian Defence
Organisation. New techniques and tools are thus needed. Brook and others point to the need for portfolio-wide architectural and systems integration activities that would need to be adapted from those employed in contemporary systems engineering to suit the nature of the portfolio.
What is clear is that portfolios are systems at a level of complexity that will require full-time architects (Rechtin, 1991; Maier, 1996) who can direct these activities: a function far different from that currently performed by senior executives.
Maier (1996) provides some heuristics derived from Rechtin (1991) that provide insight in how to undertake such a difficult architecting task.
Stable intermediate forms. Maier asserts that complex systems will develop and evolve within an overall architecture much more rapidly if there are stable intermediate forms. In this context, stability refers to the ability of the system or SoS to be capable of operating and fulfilling useful purposes before full deployment or construction is achieved.
Of greater relevance to portfolios, is Maier’s even more general interpretation that intermediate forms in an evolutionary system should be technically, economically, and politically self-supporting.
Furthermore he states that it should be possible to build and operate the intermediate forms within the economic and political framework of the planned full system.
Policy triage: ‘Let the dying die, ignore those who will recover on their own, and treat only those who would die without help.’ This heuristic gives guidance in where to expend energies in selecting and supporting components for a SoS.
Leverage at the interfaces: The greatest leverage and dangers in system architecting are at the interfaces. Maier elaborates by stating that when the components of the SoS are highly independent, operationally and managerially, the architecture of the SoS is the interfaces as there is nothing else to architect.
Ensuring collaboration.
Collaboration can be ensured if the cost and benefits of collaboration are more attractive than the cost and benefits of independence. Maier states that one of the reasons for the success of the Internet is that it fulfils this condition (the cost of complying to the standards is low and the benefits are high).
Primacy of communications.
Maier states that communications is the principal enabling technology for SoS. Consistent with systems theory, emergent properties can only appear if information exchange is sufficient. He continues by stating that when elements are procured semiindependently the standards for communications
(ie conformance to what in C4ISRAF (1997) terms is the technical architecture) are more important than the specifications of the component system itself.”

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
These generic considerations will need to be incorporated into processes and result in plans and associated implementation effort. One approach to this is to elevate systems engineering to the SoS level and this is the basis of US architecture practice that is mirrored in many countries. In this paradigm, analogies of the systems specification, systems engineering plan, functional analysis, test and evaluation master plan, etc, are prepared at the portfolio or SoS level. Also a modified systems engineering process, often referred to as a capability engineering process, is employed to determine the component systems to be modified or acquired.
Figs. 15 and 16 illustrate how this approach is used in the US to inform project plans and specifications.
Institutional support is required to apply the capabilities based acquisition process efficiently.
Korea has partially pursued capabilities based planning in the user definition processes since 2006.
In order to strengthen capabilities based approaches to defence planning and acquisition, additional human resources also need to be made available to undertake the capability engineering activities listed above and to conduct a suitable version of a CEP.
A suitable process could be based on a version of the US SoS systems engineering process shown in Table 1:
①
Translating Capability Objectives,
②
Understanding Systems and Relationships,
③
Assessing Performance to Capability Objectives,
④
Developing and Evolving an SoS Architecture,
⑤
Monitoring and Assessing Changes,
⑥
Addressing Requirements and Solution Options,
⑦
Orchestrating Upgrades to SoS. Table 1 illustrates correlation between seven core elements of SoS systems engineering and traditional systems engineering processes. As can be seen in the table, the seven core elements rely on technical management such as, risk management, configuration management, data management and interface management rather than technical efforts of systems engineering process.
Table 1. Correlation of SoS SE elements and traditional
SE process [11].
Fig.
15. Capability Evolution Plan flow-down.
Fig.
16. SPD flow-down [7].
An independent organization at the capability level that can simultaneously coordinate each component program should be set up. Under a SoS environment, the aim of acquisition is optimal

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010 performance of the component systems but to meet the required capability with minimum cost. Fig. 17 illustrates an example of an organizational hierarchy for capability-level coordination. As can be seen in the figure, every single program is integrated and coordinated synchronously by a SoS
IPT that comprises a SoS Manager and a SoS Chief
Engineer and supporting staff that is controlled by a Capability Acquisition Board (CAB).
Each CAB organization must work very closely with other CABs to ensure harmonious and interoperable developments across the entire defense organization. The major activities of the
SoS IPT include the coordination between lower single system programs and cooperation of SoS perspective and collaboration with other SoS IPTs. formation path to suit the Korean defense situation.
5.
CONCLUSIONS
This work describes the capabilities based process employed by the US SoS defense decision support system. From results of this comprehensive analysis, considerations required to apply the capabilities based acquisition process efficiently to the Korean defense acquisition environment, are presented. This work outlines generic approaches that could be employed and the authors suggest that a systemic intervention be employed to design a detailed approach to best suit the Korean defense organization.
REFERENCES
Fig .17. Acquisition organization [12].
Education & training of SoS systems engineering is required to ensure that the acquisition process is implemented successfully at the SoS level. Because SoS is inherently an interdisciplinary effort, it is based on function rather than identifiable technical activities, and requires a logic based qualitative approach. Thus,
SoS SE education should comprise expert training that ensures diversity and creativity that draws heavily on systems thinking. Just as with the formation of systems engineers, SoS systems engineers will require a combination of formal education and experiential learning in order acquire the competencies necessary for successful discharge of their duties. It will be necessary to define the career stream and the appropriate
1.
Australian Defence Force, Future Warfighting
Concept , ADDP-D.3, 2003.
2.
Australian Department of Defence, Defence
Capability Development Manual , 2006.
3.
Davis, P. K., “Architecture for Capabilities- based Planning, Mission-System Analysis, and
Transformation” RAND, p.1, 2002.
4.
Clark, V., “Sea Power 21”, Proceedings, p.1,
2002.
5.
Siel, C. R., “ Systems Engineering View of
Naval Warfighting Systems Development ” , 8th
Annual Science Engineering Technology
Conference , NDIA, pp.30-9/30-4, 2007.
6.
Gantzer, D. J., “Systems Engineering at DoD:
Focus on Policy, Standards and Guidance”,
INCOSE Chesapeake Chapter Presentation material , SE Directorate Office Defense
Research and Engineering, p.19, 2010.
7.
Siel, C. R., Naval SoS Systems Engineering
Guide Book , Vol. 1, p.6, ASN(RDA), 2006.
8.
Defence Capability Plan 2009 , Australian
Government DoD, 2009.
9.
Strategy Planning Framework Handbook 2006 , pp.26-28, Australian Government DoD, 2006.
10.
Moon, T. and Cook, S.C., “Managing National
Defence Using a 'Linked Portfolios' Approach”
Proceedings of the 11th Annual International

4 th Asia-Pacific Conference on Systems Engineering (APCOSE 2010)
Keelung, Taiwan October 4-6, 2010
Symposium of the International Council on
Systems Engineering (INCOSE) , Melbourne,
Australia, 1-5 July 2001, Paper No. 3.5.3.
11.
Systems Engineering Guide for Systems of
Systems, pp.17-20, ODUSD(A&T)SSE, 2008.
12.
Bethmann, John F., “Developing a SOS
Approach to Engineering and Acquisition with
DoD”, 2 nd Annual System of Systems
Engineering Conference , 2006.