UNCLASSIFIED

Design for Change (DfC) in Capability Systems

Brendan J. Kirby and Nicholas Kempt Land Operations Division, DSTO, P. O. Box 1500, Edinburgh, SA 5111, brendan.kirby@dsto.defence.gov.au. Abstract This paper gives a brief literature review of a changeability paradigm denoted by Design for Change (DfC) that attempts to ameliorate the problems encountered in developing and acquiring complex civilian and defence systems. A DfC system consists of a robust, flexible, agile and adaptable framework, providing for a continual evolution of the system architecture. A highly changeable system is flexible, while a system that is intractable to change has system lock-in. The concept of Degree of Changeability is raised in this paper as a means to qualitatively discuss to what extent DfC principles need to be adopted by the systems development in order to satisfy changeable requirements. An initial methodology for utilising DfC principles for the development of a military system is proposed. It is proposed to apply DfC principles to military systems that are pursuing operational flexibility and multirole employment for ADF vehicles and platforms. This work will look at practical ways of applying DfC principles, techniques and tools to assist with the Defence capability requirements of a combined arms team for the Australian Army. INTRODUCTION WHAT ARE THE CHALLENGES? A number of complex civilian and defence systems have either failed or been unsatisfactory in meeting customer requirements, agreed budgets or deadlines. To set the scene and motivation for this paper, a few examples are quoted below. Iridium and Globalstar both pioneered mobile space-based telephony in the 1990s. In 1991, the prediction of customer use was 40 million subscribers for a satellite based mobile phone network. But despite the technical breakthroughs, within 7 to 9 years (by the time the satellite constellations were deployed) both systems failed commercially clocking up losses of over $4 and $3.5 billion, respectively (deWeck et al. 2004). The failure was due at least in part, to traditional thinking in terms of inflexible project design, high capital investment systems and an uncertain client commitment (predicting a specified number of users and their usage rate both uncertain and speculative). Delivering the Bowman Combat Infrastructure Platform (CIP) was very difficult to achieve within the given schedule and budgetary goals. The first contract was terminated because of a lack of confidence in the consortium that they would be able to meet time and budget agreements. General Dynamics took over both projects and delivered Bowman by March 2004 and the CIP by March 2006 (both with numerous provisos although the CIP was trialled successfully in Iraq in 2005). The problem was that the goals were set with an old mindset where the project was meant to be completed and remain the same until a mid-life upgrade (NAO 2006c). This was not the case. Continual development and changes were required, especially in the light of feedback from operations in Iraq and Afghanistan. Bourn, head of the UK National Audit Office (NAO) stated that the MoD and the contractor needed to respond flexibly to inevitable change and to the remaining technical challenges and to be adaptable towards new technical challenges that would emerge (NAO 2006b). The Government Accountability Office (GAO) and the US Army Test and Evaluation Command have recently found that poor requirements management, inadequate systems testing and low quality data have contributed to delays in the implementation of a number of enterprise resource plans (ERP) one such plan being the Defense Enterprise Accounting and Management System (GAO 2010b). This

UNCLASSIFIED

UNCLASSIFIED

system has suffered a 3 year slippage in schedule and a $938 million increase in life-cycle cost estimate. The TTCP Action Group on Airborne Missions Systems (TTCP 2007) delineates a number of Air Force platforms whose mission systems are facing significant problems such as system obsolescence, software maintenance issues, delayed upgrades, the system not yet operational, capacity shortfalls, and three listed cases where the mission computer itself is obsolete at the time of introduction into service. The complex context and the needs that many military systems face is discussed below. BACKGROUND THE SETTING FOR DESIGN FOR CHANGE Defence systems are commonly acquired with around a 10 year lag time between concept definition and in-service dates (Lim 2009). Since technology, market forces, cultural environments, operational contexts and capability requirements are shifting at an unpredictable rate within this 10 year window, it is uncertain to what extent future defence systems will meet the needs for which they were originally slated. Current Australian Army requirements include developing combined arms teams that are integrated, modular, robust in their structure and yet able to be quickly adjusted and adapted to meet the needs of various tasks. Not only do the platforms and vehicles need to be flexible and adaptable, but the combined arms teams organisational structure needs to be flexible and adaptable as well. It is imperative to utilise Defence investment as prudently as possible to avoid acquiring equipment and systems that are unable to meet the latest requirements upon introduction into service. This raises the need to incorporate into the systems design phases the concept of changeability. If design for change principles can be built into system processes throughout the system development life cycle then as userrequirements and capabilityrequirements are updated, the specifications for the system and its implementation can also be adjusted. Fricke and Schulz have identified three major drivers that may affect systems development: a dynamic marketplace, the rapid evolution of technology and a large variety of environments that a system or product must encounter (Fricke and Schulz 2005). Managing uncertainty and change will need to become paramount for contemporary systems development strategies. New techniques will need to be adopted in order to develop systems that are flexible, adaptable, agile and robust able to adjust with societys and governments changing requirements. THE STANDARD APPROACH SYSTEMS ENGINEERING METHODS Various Systems Engineering (SE) methodologies have emerged to address the challenge of the design1, development and production of complex systems, and to attempt to solve the problems raised above. SE techniques are used in complex projects such as spacecraft and computer design, robotics, software integration, and construction. SE is a formal process for the development of a complex system, driven by a set of established requirements, derived from the intended mission of the system throughout its life cycle (Austin 2008). The recently updated standard SE reference is the INCOSE Systems Engineering Handbook (2010) which covers all of the main key process activities for systems engineers. A special report on the relationship between SE capability and project performance was conducted by Elm et al. (2007), which found that projects with better SE capabilities delivered better project performance. Reviews of SE have also been conducted (Grzybowski et al. 2009), some looking at the effectiveness of SE and metrics of SE performance (Vanek et al. 2007). Another review by Oppenheim et al. (2010) looked at ways to improve current processes under Lean Systems Engineering.

Systems design is the process of defining what characteristics the new system should have, with a plan on how to create it viz: an architecture, components, modules, interfaces and data for a system to satisfy specific requirements (Watson et al. 2008).

UNCLASSIFIED

UNCLASSIFIED

THE COST OF INTRODUCING LATE CHANGES Developing a system that is innately inflexible augurs poorly for that systems future in environments that are characterised with ongoing change. Fricke et al. (2000) discuss the problem of changes in system design remonstrating the extra cost of late changes made at each subsequent stage of the program estimated changes costing about a factor of ten more during the next phase than the previous one; known as the Rule of Ten by some authors (Boehm 1981; Clark and Fujimoto 1991). They indicate that the option taken by many in product development circles is to simply avoid or prevent changes, or at most, to incorporate them at the beginning of system development (frontloading changes). But due to the burgeoning of systems complexity, it is unreasonable to expect forecasting of what design changes are required to be able to satisfy complex future demands (Wheelwright and Clark 1992). Fricke and Schulz (2005) commented on a study by Ward et al. (1995) of Toyotas system development cycle, noting that it introduced delays into their design decisions resulting in better performance in development time and quality. This indicated the increasing necessity to decrease the time between freezing the architecture (i.e. design properties, functions and features etc.) of a system and the product delivery, as much as possible. But even this strategy is not sufficient for highly changeable systems, environments and user requirements. Feiler et al. also show how the implementation of changes during system development is fraught with dramatically increasing costs (Feiler et al. 2009). The cheapest change to implement is during the requirements phase, which then is increased by 2.5 times during the design phases (for the system, software architecture and component software). The cost per change increases to 110 times that during the requirements phase at the operational phase (system deployment). System changes should be captured and implemented earlier (if at all possible) during requirements capture or system design phases. What is becoming more evident as acquisition projects increase in scope and complexity, is that the traditional linear approach (design, development, production, training, support and an initial delivery of capability, possibly followed by one or two mid-life upgrades) may not provide the capability that todays customer requires within either the time period or expense expected (NAO 2006c). HOW CAN DESIGN FOR CHANGE ASSIST? What is DfC? DeWeck, from the MIT Strategic Engineering group, defines design for changeability as a study of how complex systems and products change over time and how they can be designed for changeability (Watson et al. 2008). The idea behind DfC is that systems can be designed to be able to undergo modifications during and after their initial-design, development and configuration stages without being penalised with prohibitive costs or subsequent large increases in system complexity. The Four Aspects of DfC Designing a system for change means that there are four essential aspects required of a system if it is to be changeable: robust, flexible, agile and adaptable (Fricke and Schulz 2005). Robustness is required of a system in order to remain stable when unwanted changes occur (system insensitivity to a changing environment) so that the system continues to perform as expected. A flexible system is characteristic of a system that can be changed easily (when needed). Agility is a measure of how rapidly that system can be changed. Adaptability represents the systems ability to be able to handle changes (varying operational conditions) without external intervention or assistance (Fricke and Schulz 2005). These are illustrated in Figure 1 below. These four aspects are what characterise whether a system is designed for change. To what degree of changeability and in what manner the system is required to be changeable is determined by the design principles that are employed. The three basic principles of changeability are simple, modular and independent (Fricke and Schulz 2005). All three principles need to be incorporated into the system design if the system is to be fully changeable. This is where variable system design requirements

UNCLASSIFIED

UNCLASSIFIED

come into play as not every system will need to be fully changeable it may only need to be flexible and adaptable, and not agile, for example. In addition to the three basic principles of system design, Fricke and Schulz add the six extending principles: scalable, integrable, non-hierarchical, autonomous, decentralised and redundant (Fricke and Schulz 2005). These six extending principles are not independent of each other and can interact positively and/or negatively with each other hence the system design needs to take these interactions into account.

Figure 1 The Four Aspects of Changeability (Fricke and Schulz 2005)

Flexibility and System Lock-in A flexible system is one that can be readily altered (but according to Fricke and Schulz it will require external assistance) and has a high degree of changeability (Fricke and Schulz 2005). Those systems that are unable to be changed easily or economically are designated as having lock-in. Sometimes lock-in occurs because the cost to change to a better design is too great even though the technology or architecture exists resulting in a systems continued use that is sub-optimal. If systems can be designed with embedded flexibility which lower switching costs, then performance under future uncertainty can be improved upon (deWeck 2011). The MIT Strategic Engineering group is devising tools for analysis options for change propagation, such as Time expanded Decision Networks (TDN), the sensitivity Design Structure Matrix (sDSM) and the Technology Infusion Analysis (TIA) process (deWeck 2011). Strategic Engineering is used to prepare complex systems and projects for an uncertain future of changing conditions and requirements. The methodology is to embed flexibility into the design of systems at an early stage of development. The design of a system that has flexible elements entails the need for a reconfigurable component, so that systems can change reversibly between a predetermined number of different configurations without prohibitive costs of time or expense (deWeck 2011). A Review of Design for Change DfC is not a new concept. Simmons lamented the longevity of Naval systems design and acquisition processes, and even in 1975 began to comprehend that systems requirements were changing rapidly, threats were dynamic and becoming more complex, and the way forward was to design for change (Simmons 1975). Simmons presented a graphical presentation of average program acquisition times for major weapon systems and new classes of ships. His initiative was to suggest that the payload and the platform be uncoupled and developed concurrently rather than in series, which would speed up the system development time by a number of years (depending upon the project). A faster weapons system development time could then meet the changing threat environment more efficaciously (Simmons 1975). In 1994 Koopman and Siewiorek published an article on the design abstraction and design for change discussing design process dynamics (Koopman and Siewiorek 1994). They discussed a multi-layered design framework with two loops representing primary design activity cycles between

UNCLASSIFIED

UNCLASSIFIED

each pair of layers in the framework hierarchy. Each loop represented a structure synthesis and a behaviour refinement. They saw design as an ongoing dynamic and not as a one-off occurrence. The structure loop was a means of refining and evaluating different structures while keeping the behaviour constant at an agreed state. The behaviour refinement loop would then cycle through different behaviours while employing an pre-selected structure. They recommended that the design process be abstracted so that changes could be readily moved into subsystems or components. For example, when designing a car, the transmission can be kept at the generic level so that it may be later changed to an automatic or manual category, or be adapted with new technology without disruption to the remainder of the design (Koopman and Siewiorek 1994). Koopman and Siewiorek pin down two important factors that should be addressed when considering DfC systems: 1) anticipating the types of changes that may need to be accommodated by the system, and 2) to comprehend what the forces of change (from governmental and cultural forces, market competition, and new technologies) could possibly be encountered in years to come (Koopman and Siewiorek 1994). Once the types of change and forces of change can be better appreciated, Koopmans design abstraction model then provides a framework that attempts to understand and manage these changes. Lim has looked at the System Development Life Cycle (SDLC) defined from the inception of the system up until the Initial Operating Capability (IOC) for US Air Force aircraft and has plotted the average number of months from program initialisation to the IOC (from 1969 to 1998) (Lim 2009). For one particular case, the Raptor F-22, the time from inception to IOC was about 20 years! High performance and cost penalties can be incurred if these systems are not designed with lifelong evolution in mind. Lim makes a key statement, in that the lifetime evolution of the system needs to incorporate future requirements and technologies; which is tantamount to DfC (Lim 2009). Lim discusses design for affordability where various methods and processes are utilised in order to maximise the systems affordability for the customer. This incorporates a balance between benefits, costs, availability and risks (Lim 2009). Kott et al. (2008) have looked at the need for DfC when considering technological change and growth. For the proposed but now unfunded US Navys CG(X) Combat System, they were emphasising flexibility, adaptability and scalability for the ships systems configuration. Figure 2 below shows an example of the expected cycles of staff turnover, equipment obsolesence and introduction of new capabilities. The introduction of external systems (eg. The Global Information Grid) would also drive the need for system changes. Hence Kotts emphasis on an agile combat system.

Figure 2: Life-Cycles of Staff and Combat System of the CG(X) (Kott et al. 2008)
UNCLASSIFIED

UNCLASSIFIED

Extensible System Design Crawley (2003) stated that an extensible system (as a subset of a flexible system) would offer a reduction in overall life cycle cost due to reuse, commonality and ease of learning. There would be reductions in development time and cost due to new functions being adopted more quickly. He also advocated deployment in stages as a means of handling changing budgets and policies (Crawley 2003). He noted that flexible systems might not always be optimal (depending upon the level of changeability needed), and that extensibility needed to be incorporated into system design up-front, which could lead to long-term cost savings (the total cost of ownership over life of type). Taylor et al. (2005) considered the complexity of a space exploration system which is required to achieve predetermined mission tasks as well as undefined and unforeseen mission objectives as they arise. They state that the traditional approach (e.g. a point design sufficient for a narrow interval of time) of only satisfying current program objectives, is not sufficient in the light of political, organisational and budgetary uncertainty, technology evolution and changing scientific interests. In order to avoid decisions that lead to system lock-in the system should be designed to be extensible i.e. the capability of a system to evolve and or adapt (either by changing itself, or being changed via external intervention e.g. redesign or upgrade) so that it can provide operational support in different future environments and accomodate changes in the needs of key stakeholders (Taylor et al. 2005). COST REQUIREMENTS FOR DESIGN FOR CHANGE SYSTEMS Fricke et al. (2005) have plotted Cost versus Degree of Changeability for DfC systems, but here we have enumerated the abscissae scale; refer to Figure 3 below. If we assume that Figure 3 applies at the beginning of the system development cycle, then the degree of changeability can be chosen according to estimated cost incurred. The difficulty arises as to how to decide what degree of changeability is necessary to meet the requirements suitably, and then how is that degree of changeability achieved.

1 Difficult to Change

5 Easily Changed

Figure 3: Cost Vs Degree of Changeability (Fricke and Schulz 2005)

Fricke et al. show in Figure 3 that the degree of changeability desired for a system has to be balanced out with the cost. If the degree of changeability is 1.0, then the system will be difficult to change. If the degree of changeability is 5.0 then the system will be easily changed. The question system designers and clients need to answer is what degree of changeability is actually required to enable the system to navigate changes encountered during the SDLC and beyond (during the life of type). If the degree of changeability is chosen to be unnecessarily flexible (in an unchanging context) then too much financial outlay will be made; or if the changeability is too small, then the ramifications can

UNCLASSIFIED

UNCLASSIFIED

be disastrous (as discussed for the Iridium and Globalstar systems). Perhaps, a changeability of 3.5 according to Figure 3 would give the minimum total cost for a reasonable degree of system flexibility. Rather than assume a time independent relationship, we have (following Frickes idea) plotted the variability of DfC with respect to time. Figure 4 shows Cost To Make A Change (on a logarithmic scale) versus Stage of System Development (Time). This figure assumes the total cost to build the same system with no changeability is constant. This figure is applicable up until the IOC. The plots are for a system that has been hypothetically designed initially with three levels of changeability, these are shown as Low, Medium and High DfC. It is expected that the cost to make a change (during the SDLC) for a High DfC system would remain relatively constant throughout the development cycle, but with a high initial cost. These curves are meant to be illustrative and indicative, not quantitative.
Cost to Make a Change ($)
100x Need to identify cross-overs

Low DfC

Medium DfC
10x

High DfC
x

Early stages of system design and development

Middle stages of system design and development

Completed system (In Service)

Stage of System Development (Time)

Figure 4: Initial Cost plus Cost to Make a Change Vs Stage of System Development
For a Medium DfC system, it is expected that initially it is less expensive than the High DfC system, but that the cost to make a change becomes more expensive at some cross-over point. Exactly where in the SDLC is not clear. The cheapest initial option is with Low DfC. But these savings backfire when changes to the system are required later in the SDLC. The Low DfC curve is expected to exceed the Cost to Make a Change curves for the Medium and High DfC levels at the middle stages, and to become very expensive at the latter stages of SDLC. Identifying the location of these cross-overs in Cost to Make a Change curves can be of strategic importance in system design planning, and in matching DfC within budgetary limitations. Especially since the Medium DfC might become the preferred option for some projects and programs. WHEN TO UTILISE DfC AND WHEN NOT TO? Based on some of Steiners work (Steiner 1999), Fricke and Schulz (2005) state that it is not necessarily beneficial to incorporate DfC into every system architecture. It is expected to be beneficial for systems where:
The system has a long lifecycle with short cycle times of technology requiring sub-systems to

be upgraded regularly;
The system has a core behaviour that is stable, but varies in secondary functions; The system architecture is in a rapidly changing environment with strong competitive forces

and with a variable customer requirements base;

The architecture and the system are interconnected with other systems in an operational

context;
UNCLASSIFIED

UNCLASSIFIED There are high deployment and maintenance costs; The system is highly complex and unprecedented with an unknown employment context.

These requirements and system characteristics are commensurate with those from a number of major military project acquisitions. The caveat is that DfC will not always be financially viable in some circumstances, such as:
Those systems that are short lived and not requiring product variability; Systems that are already very well known that are to be applied in slowly changing

environmental context with no expected customer changes;

Systems that are quite robust and stable over time, in different contexts and environments, and Those systems that are designed for ultrahigh performance markets where no drop in

performance is tolerable (Fricke and Schulz 2005). Wisdom to Anticipate Requirements for DfC A High DfC system has the advantage of a low cost for a change at most stages of the SDLC. A Low DfC system will suffer from a rapid increase in cost to make a change (if requested by the customer) as the system develops. Clearly, if only a few changes are required, then the economic viability of a High DfC system becomes uncertain, and a Low DfC system may surpass it in overall value. The wisdom needed is to determine the degree of changeability during early stages of the SDLC. To achieve this wisdom requires an insightful assessment of environmental context, technology life cycles, likely adjustments in customer requirements and the advent of new paradigms and technologies. DIFFERENT STRATEGIES FOR DESIGN FOR CHANGE This paper reviews some of the basis principles associated with DfC. It does not claim to review the entire field2. Some of the methodologies described in the following sections are indicative of what might be partially adopted and included in a first cut DfC methodology. i) A Staged Deployment for Complex Systems In 2003 deWeck proposed a staged deployment of a system capability so that overspending or underspending caused by initial errors in anticipating system capacity or requirements, could both be avoided (deWeck 2003). He advocated embedding the capability and deploying in stages up front. DeWecks proposed alternative to the traditional method is to embed flexibility into the system design and to deploy a smaller, more affordable system initially, which can increase in capacity and capability as demand rises. The process recommended by deWeck (2003) is: 1. Conduct a market survey of the service to be offered; 2. Conduct baseline architecture trade study; 3. Identify paths for staged deployment; 4. Select an initial stage architecture (based on a real options analysis); 5. Obtain government approval for the system (if required), implement the system, and build it; 6. Operate and observe actual demand on system use; and 7. Make periodic reconfigurations up to end of life. DeWeck et al. discuss a system flexibility that enabled decision points throughout the process. At each decision point various parameters could be analysed for their uncertain values (deWeck et al.
Change propagation analysis, flexible platforms, architecture options for systems adaptability, decision modelling, uncertainty modelling, system change modelling using tools such as non-homogeneous Markov chains, Time-expanded Decision Networks, and Change Propagation Networks are not covered.
2

UNCLASSIFIED

UNCLASSIFIED

2004). Depending upon updated parameter values more appropriate decisions could be made. Monitoring uncertain parameters during the course of the process could decrease overall uncertainty thereby diminishing project risk. DeWeck et al. indicate that a staged system deployment utilising legacy components reduces the amount of freedom in system design in latter stages of the system development (deWeck et al. 2004). Architecture design in this case would need to be carefully modelled encapsulating these legacy systems recognising that system flexibility would not be as high. They also point out that technologies may not be known or able to be modelled accurately leading to indeterminate costs to embed system flexibility. The authors state that user requirements will not be fixed and will encounter a degree of fluctuation. This uncertainty will need to be modelled and taken into account throughout the process. Market conditions and user requirements can be updated at key decision points during system development which is a marked improvement upon traditional system design concepts with a fixed level of demand or system expectations. This staged development and deployment approach may be added into a DfC methodology, and could provide system designers and managers with options to more closely correlate the system evolution path to the actual unfolding demand scenario (deWeck et al. 2004). ii) Addressing Uncertainties in System Design - a MATE Methodology Rhodes and Ross stated that in order to develop a successful system, one needed to make effective architectural design choices when faced with enormous complexity and continual change (Rhodes and Ross 2009). They delineate a number of areas that would hinder system development:
Premature design selections without consideration or analysis of other options; Inadequate technical feasibility studies in the early stages of design; Insufficient regard for preferences of key decision makers; Disconnects between perceived and actual decision maker preferences; Pursuit of a detailed design without understanding the effects on the larger system; Limited incorporation of interdisciplinary expert opinion and diverse stakeholder interest.

Rhodes and Ross describe how knowledge only increases as project development continues, while detailed design is transpiring under a situation where knowledge is still limited. They ask the pertinent question, How then can we make decisions? Their solution is to develop a Multi-Attribute Tradespace Exploration (MATE) methodology (Rhodes and Ross 2009). This methodology helped to address uncertainties in the system design. As the understanding regarding uncertainties improved, the knowledge of the system increased, enabling the cost committed to be more appropriately placed and timed, which improved managements decision making and influence in project direction. This provides another option for a DfC methodology, which might also incorporate aspects of MATE. iii) A Five Step Flexibility Evaluation Framework DeWeck has also done some work in embedding flexibility into component manufacturing systems and processes for low, intermediate and high volume demand scenarios (Hauser and de Weck 2007). Hauser and deWeck present an interesting five-step framework to determine the value of flexibility and ranking of different manufacturing processes. They used a discrete time simulation to predict product value, remaining tool value and asset utilisation (Hauser and de Weck 2007). For a manufacturing firm, the evaluation of flexibility within a strategic production planning process is very important. Hauser and deWeck propose a framework of five steps as outlined in Figure 5 below (Hauser and de Weck 2007): 1. Build a set of (market) scenarios of possible future (market) evolution; 2. Define process alternatives for new possible (production) system processes, including a baseline process; 3. Create a model in which the behaviour of the (firm) system can be simulated depending on
UNCLASSIFIED

UNCLASSIFIED

the diverse combination of (market) scenarios and process alternatives; 4. Run the discrete time simulation for every combination of (market) scenario and process alternative; 5. Evaluate the simulation results and rank the most adequate (manufacturing) process for the firm. Hauser and deWeck (2007) found from the results of their simulation that for intermediate and uncertain production volumes, those manufacturing processes that embedded flexibility could outperform traditional processes. Flexibility in parts manufacturing was found to be a complex topic, as the application of flexibility to parts, tools and process parameters could easily vary.

Figure 5: Flexibility Evaluation Framework (Hauser and deWeck 2007)

This framework might find some application to Defence systems development, if the system and environment can be simplified and approximated into a discrete time simulation. The economic management of the purchase of different vehicles, a variety of battle management and communication systems, various radios and service specific protocols may be simulated to assist with DfC modelling for the Australian armys combined arms fighting system. (Not that the complex Defence acquisition environment can be modelled as a manufacturing system but perhaps this framework might be used to inform aspects of Defence systems development.) iv) A Model Based Approach to Decrease System Development Risk At the recent Systems Engineering conference in San Diego, Wagner et al. (2010) presented a modelbased approach to decrease system development risk and to minimise time delays and costs. They quoted from Feiler et al. where the source lines of code for a system over the last four decades has been shown to be doubling every four years (Feiler et al. 2009). This indicates that software development could hit an upper threshold as the cost to develop the code may not be affordable. Wagner et al. write that significant added expense and time delays in system development are due to error propagation, untested integration verification and test capabilities, incomplete design trade analysis, issues due to certification or qualification being found too late, lack of parallelising development activities, poor system risk identification and mitigation, and failure to utilise known automated techniques (Wagner et al. 2010). They propose a model-based architecture development approach to address the above complex issues. They state that an architecture tool is not a panacea and that enterprise processes and disciplined Systems Engineering will need to be adopted closely. They also recommend a team approach, parallel development paths and prototype development to support risk mitigation. The application of these concepts should result in lower costs for design changes. FIRST STEPS TOWARDS A DfC SYSTEMS METHODOLOGY In support of a large defence project procurement and the development of a combined arms team, the DSTO is investigating the efficacy of utilising DfC principles in planning for adaptable, robust, flexible and agile systems to meet future requirements and demands. The methodology outlined

UNCLASSIFIED

UNCLASSIFIED

below is a first attempt to begin to delineate a process of adopting DfC principles for an integrated, networked military system consisting of numerous vehicles, platforms and C2 systems: 1. Identify likely forces of change (eg. Different operational context, i.e. Afghanistan); 2. Identify possible types of change (eg. Required integration of a variant C2 system); 3. Identify entrenched, non-essential (and possibly unnecessary) system processes; 4. Determine system characteristics, timescale, requirements, environment and whether it need be structured for DfC; 5. Apply Frickes basic principles: modularity, independence and simplicity to the system design; 6. Adopt some or all of Frickes extending principles: integrable, scalable, autonomous, nonhierarchical, redundant and decentralised; 7. Estimate what degree of changeability is required: how flexible, adaptable, robust and agile; 8. Balance the cost to make a change with the stage of system development; 9. Consider staged system deployment; 10. Consider possible use of the MATE Methodology; 11. Investigate a Model Based architecture development technique; 12. Utilise deWecks Five Step Flexibility Evaluation Framework if feasible; 13. Track error propagation and conduct change propogation analysis; 14. Encourage a corporate culture that embraces change. This is not a final discrete list of stages of a DfC systems development methodology. Some useful but yet unknown steps may have been omitted; some included above may later be removed, and other steps may be aggregated under more general descriptions. Use of other tools and techniques will be avidly investigated. Further work and research will be required in order to determine how to devise and fine tune a generic DfC systems development methodology. DISCUSSION The introduction of DfC basic principles (modular, simple and independent) into system design at the appropriate phase of development in the SDLC will need to be monitored carefully. The level that the extending principles (autonomous, redundant, integrable, scalable, non-hierarchical and decentralised) are incorporated into the systems design will be a difficult decision. Some of these extending principles are antagonistic towards DfC if introduced into the same system. The result of constructing a system with the basic and extending DfC principles will be a system that is robust, agile, adaptable and flexible. Estimating the degree of changeability achieved by a particular DfC system will be an area for future work and will require a better understanding of DfC systems engagement with variable parameters. It would be prudent to begin to incorporate DfC principles into the Australian defence capability development process. One way to do this initially is follow Wagner et al.s (2010) recommendation to increase design stability by requirements validation and systems analysis earlier in the SDLC and prior to implementation. The remit for some Land systems is to make them robust, resilient, flexible, survivable, responsive, precise, agile, lethal, network enabled and adaptable. From such a description it is evident that within shifting modern battlespace contexts, military systems should become designed for change. CONCLUSION This brief literature review supports DfC as a valid approach that can be adopted for the effective development of complex systems. If a system satisfies the criteria for the beneficial application of

UNCLASSIFIED

UNCLASSIFIED

DfC, then it is recommended to embed flexible design and thereby lower future switching costs, and avoid lock-in. The degree of changeability is a concept qualitatively discussed in this paper and is difficult to determine accurately. It is determined by the extent of incorporation of the basic principles of DfC, that is, to what extent the system is modular, simple and independent. The extending principles can also be applied to make the system more changeable under varying conditions. A first attempt at forming a DfC systems development methodology was also proposed. This will be further investigated in support of the Australian Armys combined arms teams program.

REFERENCES Austin T. E., (2008) The Road to Developing a World Class Automotive Systems Engineering Capability, Systems Engineering, 2008 (SP-2190); also in 2008 World Congress, Detroit, Michigan April 14-17, 2008. Boehm B. W., Software Engineering economics, Prentice Hall, Englewood Cliffs, NJ, (1981). Clark K. and Fujimoto T., Product development performance, strategy, organization and management in the world auto industries, Harvard Business School Press, Boston, (1991). Crawley, E., Extensibility in Space Transportation; in MIT-NASA Workshop: Transformational Technologies ed. by Smitherman D.V., et al., NASA/CP2005213741; Proceedings of a workshop sponsored by NASA held in Cambridge, Massachusetts, December 1112, (2003). de Weck, O., Staged Deployment of Complex Systems; in MIT-NASA Workshop: Transformational Technologies ed. by Smitherman D.V., et al., NASA/CP2005213741; Proceedings of a workshop sponsored by NASA held in Cambridge, Massachusetts, December 1112, (2003). deWeck, O. L., deNeufville, R. and Chaize M., Staged Deployment of Communications Satellite Constellations in Low Earth Orbit, Journ. Aerospace Computing, Information and Communication, Vol. 1 No.3, (2004) pp.119-136. deWeck, O., Eckert, C. and Clarkson, J., A Classification of Uncertainty for Early Product and System Design, Int. Conf. on Engineering Design, ICED07, 28-31st August (2007) Paris, France. deWeck, O., MIT Strategic Engineering: Designing Systems for an Uncertain Future, http://strategic.mit.edu/ (accessed 4/2/2011). Elm, J. P., Goldenson, D. R., Emam, K. E., Donatelli, N. and Neisa A. (2007) A Survey of Systems Engineering Effectiveness Initial Results, NDIA SE Effectiveness Committee, CMU/SEI2007 SR014. Field F., Kirchain R., and Roth R., Process Cost Modeling: Strategic Engineering and Economic Evaluation of Materials Technologies; JOM October (2007) page 21 http://www.tms.org/pubs/journals/JOM/JOMbyIssue.asp?issue=JOM\2007\October (at 4/2/2011). Feiler, P. H., Hansson, J., de Niz, D. and Wrage, L., System Architecture Virtual Integration: An Industrial Case Study, Technical Report (2009), Software Engineering Institute (SEI), Carnegie Mellon University(CMU); ESC-TR-2009-017 or CMU/SEI-2009-TR-017, http://www.sei.cmu.edu. Fossa, C. E., Raines, R. A., Gunsch, G. H. and Temple M. A., An Overview of the Iridium Low Earth Orbit (LEO) Satellite System, Proc. IEEE (1998) National Aerospace and Electronics Conference, A99-17228 03-01, pp. 152-159. Fricke E., Gebhard B., Negele H. and Igenbergs E., Coping with changescauses, findings, and strategies, Systems Engineering 3(4) (2000) 169179. Fricke E. and Schulz A. P., Design for Changeability (DfC): Principles to Enable Changes in Systems Throughout Their Entire Lifecycle, Systems Engineering, Vol. 8, No. 4 (2005). GAO; Defense Logistics: Actions Needed to Improve Implementation of the Army Logistics Modernization Program, GAO-10-461 Washington, D.C.: Apr. 30, (2010).

UNCLASSIFIED

UNCLASSIFIED

GAO; Financial Management Improvement and Audit Readiness Efforts Continue to Evolve, Statement of Asif A. Khan, Director Financial Management and Assurance; US Department of Defense, Sept 29, (2010b); GAO-10-1059T. Grzybowski R., Whiting M., Vanek R. and Jackson P., (2009) Corning-Cornell Project to Evaluate Effectiveness of Systems Engineering Techniques: Results from a Literature Review and Interview Research, Cornell University Systems Engineering Program, July 7. Hauser D. P. and de Weck O. L., Flexibility in Component Manufacturing Systems: Evaluation Framework and Case Study Journal of Intelligent Manufacturing, (2007), Vol. 18 (3), pp 421-432. IGC (2007) UK Defense Projects Over Budget And Behind Schedule; Information and Analysis on Legal Aspects of International Public Procurement, volume 4; number 12; Dec p.97. www.crowell.com/documents/docassocfktype_articles_917.pdf (accessed 4/2/2011). INCOSE (2010) INCOSE Systems Engineering Handbook A Guide for System Life Cycle Processes and Activities, Version 3.2. Koopman, P. J. Jr and Siewiorek, D. P., Design Abstraction and Design For Change, August 16, (1994) CMU, http://www.ece.cmu.edu/~koopman/abs_chng/abstract.html (accessed 4/2/2011). Kott K., Adams K. M. and Dove R., (2008), Agility and the Combat System, Naval Engineers Journal, Volume 4, Page 67. Krigsman, M., Department of Defense IT: Years late and billions over-budget, Sept 30, (2010). http://www.zdnet.com/blog/projectfailures/department-of-defense-it-years-late-and-billions-overbudget/11123 (accessed 4/2/2011). Lim D., A Systematic Approach To Design For Lifelong; Aircraft Evolution, PhD Thesis, School of Aerospace Engineering, Georgia Institute of Technology, (2009). NAO (2006a) Delivering digital tactical communications through the Bowman CIP programme, Report by the comptroller and auditor general 25 July, MoD. NAO (2006b) Delivering digital tactical communications through the Bowman CIP programme, http://www.nao.org.uk/whats_new/0506/05061050.aspx?alreadysearchfor=yes, (accessed 4/2/2011). NAO (2006c) Delivering digital tactical communications through the Bowman CIP programme, http://www.nao.org.uk/publications/0506/ministry_of_defence_deliverin.aspx (at 4/2/2011). NAO (2007) Performance of the Ministry of Defence 2006-07, Briefing for the Defence Committee; http://www.nao.org.uk/publications/0607/performance_of_mod.aspx, Nov. p. 38 (accessed 4/2/2011). Oppenheim, B. W., Murman E. M. and Secor D. A., (2010) Lean Enablers for Systems Engineering, Published online 2 February 2010 in Wiley Online Library (wileyonlinelibrary.com); DOI 10.1002/sys.20161. Systems Engineering Vol 14, No. 1, 2011. Rhodes, D. and Ross, M., Concept Design and Tradespace Exploration, Systems Engineering Advancement Research Initiative (SEARI), MIT, session 7, 2 July (2009). Ricks, T. E., General reported shortages in Iraq, Washington Post, Oct. 18 (2004). http://www.washingtonpost.com/wp-dyn/articles/A40321-2004Oct17.html (accessed 4/2/2011). Simmons, J. L., Design for Change The Impact of Changing Threats and Missions on System Design Philosophy, Naval Engineers Journal, April (1975). Steiner R., Enduring system architectures, Proc. 10th Int. Symp. INCOSE, Brighton, (1999). Taylor C., Broniatowski D., Boas R., Silve M., Crawley E., deWeck O. and Hoffman J.; Paradigm Shift in Design for NASAs Space Exploration, 1st Space Exploration Conference: Continuing the Voyage of Discovery; 30 Jan - 1 Feb (2005), Orlando, Florida, AIAA 2005-2766. Taylor (2011) Stanford University, DfC Group https://www.stanford.edu/group/designforchange/bigpicture.html (accessed 4/2/2011).

UNCLASSIFIED

UNCLASSIFIED

TTCP (2007); The Technical Cooperation Program (TTCP) Aerospace Systems Group, Action Group AER Ag-7, Airborne Mission Systems, Final Report, TTCP-AER-AG7-TR-2007. Vanek R., Jackson P., and Grzybowski R., (2007) Systems Engineering Metrics and Applications in Product Development: A Critical Literature Review and Agenda for Further Research, published online 25 February 2008 in Wiley InterScience (www.interscience.wiley.com), DOI 10.1002/sys.20089. Wagner, Brockwell, Daniels, Loesh, Gosnell; Use of a Model-Based Approach to Minimize System Development Risk and Time-to-Field for New Systems; NDIA 13th Annual Systems Engineering Conference, Oct (2010), Hyatt Regency Mission Bay, San Diego USA. Ward A., Liker J. K., Cristiano J. J. and Sobek D. K., The Second Toyota Paradox: How delaying decisions can make better cars faster, Sloan Management Rev 36(3) (1995), 4361. Watson, S. L., Watson, W. R., and Reigeluth, C. M., (2008); Systems design for change in education and training; In Spector J. M., Merrill M. D., van Merrienboer J. J. G. and Driscoll M. P. (Eds.), Handbook of Research on Educational Communications and Technology. Wheelwright S. and Clark K., Revolutionizing product development, The Free Press, NY, (1992).

UNCLASSIFIED

UNCLASSIFIED

Biography Brendan Kirby Graduated in 1989 from The University of Melbourne with a PhD in Applied Nuclear Techniques of Analysis. For CSIRO he derived a new theory of waste collection during worsted rectilinear combing. At Monash University he extended a mathematical model of X-ray attenuation. At DSTO has worked on situation awareness, battlespace visualisation and command support systems, land capability systems preparedness for NCW, ideas supporting emergence in complex adaptive systems, the integration of land force combat capabilities, equations describing competition in a military conflict and command and control structures during Talisman Sabre 2007. Nicholas Kempt Nicholas Kempt is a Senior Land Systems Scientist in the Land Operations Division of Defence Science and Technology Organisation. He has over 20 years of experience conducting System and Operational Analysis studies in the Army, Air Force, Joint and Intelligence domains. His current research interests include MBSE, system architecting and whole-of-system analysis.

UNCLASSIFIED