Regular Paper Time-Expanded Decision Networks: A Framework ...strategic.mit.edu/docs/2_16_SE_10_2_TDN.pdf · Time-Expanded Decision Networks (TDNs) are a method to clearly and rigorously

Time-Expanded DecisionNetworks: A Frameworkfor Designing EvolvableComplex Systems*Matthew R. Silver and Olivier L. de Weck†

Department of Aeronautics & Astronautics, Engineering Systems Division, Massachusetts Institute of Technology, 77 Massachusetts Avenue, Cambridge, MA 02139

TIME-EXPANDED DECISION NETWORKS

Received 10 October 2006; Accepted 13 February 2007, after one or more revisionsPublished online in Wiley InterScience (www.interscience.wiley.com).DOI 10.1002/sys.20069

ABSTRACT

This paper describes the concept of Time-Expanded Decision Networks (TDNs), a newmethodology to design and analyze flexibility in large-scale complex systems. This includesa preliminary application of the methodology to the design of Heavy Lift Launch Vehicles forNASA’s space exploration initiative. Synthesizing concepts from Decision Theory, Real Op-tions Analysis, Network Optimization, and Scenario Planning, TDN provides a holistic frame-work to quantify the value of system flexibility, analyze development and operational paths,and identify designs that can allow managers and systems engineers to react more easily toexogenous uncertainty. TDN consists of five principle steps, which can be implemented as asoftware tool: (1) Design a set of potential system configurations; (2) quantify switching coststo create a “static network” that captures the difficulty of switching among these configurations;(3) create a time-expanded decision network by expanding the static network in time,including chance and decision nodes; (4) evaluate minimum cost paths through the networkunder plausible operating scenarios; and (5) modify the set of initial design configurations toexploit high-leverage switches and repeat the process to convergence. Results can informdecisions about how and where to embed flexibility in order to enable system evolution alongvarious development and operational paths. © 2007 Wiley Periodicals, Inc. Syst Eng 10:167–186, 2007

Regular Paper

* An earlier version of this paper was published and presented as follows: M. Silver and O. de Weck, Time-expanded decision network methodologyfor designing evolvable systems, AIAA-2006-6964, 11th AIAA/ISSMO Multidisciplinary Analysis Optim Conf, Portsmouth, VA, September 6–8,2006.†Author to whom all correspondence should be addressed (e-mail:[email protected]).

Systems Engineering, Vol. 10, No. 2, 2007© 2007 Wiley Periodicals, Inc.

167

Key words: changeability; flexibility; real options; time-expanded networks; decision theory;system optimization; lock-in

NOMENCLATURE

c = arc traversal cost,cO = organizational premium for system

change,CLCi = estimated lifecycle cost of the ith sys-

tem configuration,CD = development cost (DDT&E),CF = fixed recurring cost per time period,CV = variable cost as a function of demand

per time period,CSW(A, B) = cost of switching from A to B,∆CD(B, A) = incremental DDT&E of the new sys-

tem configuration B starting from A,CR(A) = cost of retiring system A,

∆CR(A, B) = incremental retirement cost of systemA when switching to B,

Dj = demand during time period j,i = number of system configurations con-

sidered,m = number of arcs in the network,n = number of nodes in the network,N = number of people involved in operat-

ing the system,N(n, m) = static network with a set of nodes, n,

and set of arcs, m,O(C) = “order of” computational cost for C

configurations, O(Z) = “order of” computational cost for Z

time periods,Pi = point design, i, performance of the sys-

tem when in the ith configuration,r = discount rate,S = start node,t = arc traversal time,

T = number of steps considered,Ti = time period i,

∆T = time step,Z = end node.

1. INTRODUCTION

There is increasing recognition that adaptability[Ashby, 1966] and more recently changeability [Frickeand Schulz, 2005] are critical to the long-term effective-ness and, in relevant cases, profitability of complextechnical products and systems. Many complex systemsexhibit high degrees of architectural lock-in. Thismakes it difficult for these systems to adapt themselves

or for them to be changed by an external agent in theface of environmental change and uncertainty [Arthur,1989; Simon, 1996; Cowan, 1990]. Lock-in and itsrelationship to technological evolution has been thesubject of much research in various fields includingengineering [Utterback, 1974; Silver 2005b], econom-ics [Arthur, 1989; Arrow, 2000; David, 2000], politicaleconomy [Nelson and Winter 1982] and strategic inno-vation management [Henderson et al., 1990; Christen-son, 1997; Hax, Wilde, and Thurow, 2001]. The exactcauses of lock-in are still debated [Liebowitz, 1985].They are generally acknowledged to be multidimen-sional, taking root in sociotechnical issues such asnetwork externalities [Katz, 1984; Witt, 1997], the costof learning new technologies [Utterback, 1974] andoperating procedures, the risks associated with switch-ing to new systems, the tradeoff between operatingslightly inefficient fielded technologies and developingnew technologies [Sarsfield, 2001], and broader issuesassociated with political and organizational inertia[Puffert, 2003]. The relative importance of these factorsin creating lock-in varies, depending upon the architec-ture of the system and the nature of the system’s opera-tions.

For large-scale technical systems, these factors canbe grouped into the general concept of switching costs,which are weighed—whether formally or informally—against the benefits of switching to new systems, prod-ucts or operating procedures. Switching costs can bereal dollars, or quantifiable costs associated with per-sonnel considerations, political implications, or thetime it takes to switch to a new technology or systemconfiguration. They are further associated with whatmight be called switching risk [Dixit, 1992].

Increasing the adaptability or flexibility of a systemdemands lowering future switching costs before theenvironmental changes which demand a switch arise.Suh and de Weck have used the concept of switchingcosts to find where to embed flexibility in automotiveplatforms [de Weck and Suh, 2006]. Beyond cost,adaptability is complicated by uncertainty in the oper-ating environment. More specifically, a large variancebetween time-scales of environmental fluctuations andthose associated with switching times and total systemlife-cycle times greatly hampers operators’ ability toreact strategically to exogenous change.1 We argue that,in order to avoid architectural lock-in and by extensionallow operators to react strategically in the face ofenvironmental fluctuations, the causes of switching

168 SILVER AND DE WECK

Systems Engineering DOI 10.1002/sys

costs and risks must be mitigated during the designstage, with explicit and rigorous consideration of uncer-tainty in the future acquisition and operating environ-ments.

Much recent research has addressed the need todesign for flexibility and methods to design for it. RealOptions Analysis, for example, is a method of valuingsystem flexibility by framing system design in terms ofstock-option theory.2 Similarly, the concepts of Spiralor Evolutionary Development emphasize the need forcontinual development and improvement of large sys-tems rather than all-at-once development and operation.At their core, these methods seek either ways of system-atically and strategically identifying the benefit of vari-ous kinds of flexibility and introducing it at the designstage, or delaying critical design decisions until exoge-nous uncertainties are resolved. The differences be-tween adaptability in the systems themselves versusadaptability in the system development process haverecently been clarified by Haberfellner and de Weck[2005].

Building on these studies, we introduce a new meth-odology and associated modeling tools to design“evolvable” complex systems. Given their size andlong-life cycles, complex technical systems are bestcharacterized as operational organizations evolving inthe face of exogenous uncertainty, able to take variousdevelopment paths when confronted with environ-mental change, rather than fixed sets of technical com-ponents.3 In a nod to information theory, thedeterminant of a system’s “evolvability” is a functionof the number of possible states that it might take, ratherthan the state it is in, with the crucial caveat thatchanging between states incurs some kind of switchingcost and associated switching risk.

Time-Expanded Decision Networks (TDNs) are amethod to clearly and rigorously represent feasiblepaths and, to the extent possible, quantify the expectedswitching costs along those paths. These paths and costscan then be represented on a directed network witharc-costs representing cost-elements incurred duringsystem operation, and expanded through a life-cycle

using standard methods from time-expanded networktheory [see Jarvis and Ratliff, 1982]. Once formulated,designers can use the time-expanded decision networkto conduct scenario planning and iteratively designmore evolvable complex systems.

As noted, while the sources of architectural lock-inare multidimensional, from an economic perspective itstems from high capital expenses (capex), associatedwith switching to new systems or system configura-tions. Framed this way, the problem becomes fairlysimple: Lock-in will occur if the cost of switching fromone system configuration to another exceeds the ex-pected benefits, discounted at some rate and assuminga level of risk [Simon, 1996].4 In order to design foradaptability (changeability), we must lower switchingcosts. This insight leads directly to two important ques-tions: (1) How can we quantify switching costs and (2)once quantified, how can we design systems to diminishthe appropriate elements of switching costs in order toimprove life-cycle adaptability? The TDN methodol-ogy described in the next section (Section 2) addressesthese questions explicitly. Section 3 discusses how themethod scales with problem size, and Section 4 thenapplies the method to the specific example of launchvehicle development and operations under demand un-certainty. The paper concludes with a summary, limita-tions, and recommendations for future work in Section5.

2. TIME-EXPANDED DECISION NETWORK(TDN)

The TDN methodology involves identifying and quan-tifying switching costs, creating an optimization modelbased on the concept of a time-expanded network, andrunning this model under probabilistic or manuallygenerated demand scenarios to identify optimal de-signs. TDN is, in effect, a method to run “quantitativescenario planning” for system design, in which systemresponses are encoded through a time-expanded net-work. The crux lies in identifying how and whereswitching costs are incurred and how these can belowered in order to maximize adaptability and, perhapsmore importantly, determining exactly how much one

1We employ here a classic distinction between strategic and tacticaldecisions. For example, see Shapiro [1989: 127]: “We should distin-guish between strategic decisions, which involve long-lasting com-mitments, from tactical decisions, which are short-term responses tothe current environment. In the language of game theory, the strategicdecisions determine the evolution of state variables that provide asetting in which current tactics are played out.”2For a good overview of Real Options Theory, see Trigeorgis [1996].3This touches upon concepts from the theory of Complex AdaptiveSystems (CAS). For example, see Olson [2001]. Another comparisonwith CAS is through the concept of real options [see Baldwin andClark, 2000]. These studies, however, were not used explicitly indeveloping the method.

4The simplified problem is complicated by uncertainty in the operat-ing environment, which reduces incentives to switch even if thebenefit is equal or slightly above the cost of switching. This is due tothe fact the environment could change again, making the switchunnecessary, so there is a “benefit of waiting.” This phenomenon hasbeen called “sunk cost hysteresis” by economists and has been studiedand modeled extensively [Dixit 1992]. The phenomenon is outsidethe scope of this paper, but could be included into the methodologylater.

TIME-EXPANDED DECISION NETWORKS 169


should be willing to spend to lower these switchingcosts at the development stage.

The TDN methodology consists of the five stepsshown in Figure 1. These steps are described in moredetail below, using a generic example of designing asystem with three potential instantiations (configura-tions A, B, and C) and are then implemented in thefollowing section (Section 4) in the context of launchvehicle design and operations.

2.1. Designing an Initial Set of FeasibleSystem Configurations

The first step involves creating a family or set of inde-pendent or point designs, and an associated high-levelcost model for their individual development and opera-tion. Such a family can consist of a core system orproduct platform with options to expand, or it caninclude wholly unrelated point designs. Creating appro-priate point designs is itself a complex process includ-ing initial requirements definitions and trade-studies.Important early stage questions include how best toframe requirements, what metrics should measure sys-tem performance, how can one incorporate appropriatelevels modularity into the system, and to what level ofdetail should initial design descend?

However, the TDN methodology explicitly recog-nizes that requirements, demand, and metrics are allsubject to change as the systems evolves. Using theinitial designs as inputs, it determines the “evolvability”of a set of designs in the face of environmental change.TDN thus shifts the emphasis from point designs to aset of system configurations and identifies specific sub-systems and interfaces for redesign. Therefore, for thecurrent purposes, we take point designs as inputs, not-ing that myriad complex systems from nuclear reactors,

to road networks, to launch vehicles, and their associ-ated cost models have been created in the past.5

Once a set of conceptual designs has been created,the basic elements of life-cycle cost for each pointdesign i can be estimated (see Table I). Nonrecurringcosts include initial development, CDi, and the cost of aswitch, Csw. The latter is described in more detail below.CDi is often described as DDT&E (design, develop-ment, testing, and evaluation), and includes nonrecur-ring engineering and facilities costs such as design,analysis, testing of subsystems, system integration, sys-tem tests, and construction of any support equipmentand facilities [Wertz and Larson, 1999]. Fixed recurringcosts CFi, are those incurred at every time period regard-less of demand and/or expected changes in the operat-ing environment, including labor, facilities, andoverhead. For large, complex systems, labor is usuallya major driver for fixed recurring cost. Variable recur-ring cost CVi, is a function of the demand during a givenyear or time period. It includes operating costs, produc-tion materials, and variable labor costs, among otherelements. Models of variable recurring cost often takeinto account benefits of learning, which reduces the costper unit as a function of cumulative production levels.

Regardless of how these three traditional cost-ele-ments are modeled, they are generally used to estimatelife cycle cost CLCi of a given design or system configu-ration i, as a function of the number of periods T, andthe demand in each period, Dj:

CLCi(D, T) = CDi + CFi × T + ∑ j=1

T

CVi(Dj). (1)

Discounting (time value of money) can also be in-cluded when estimating lifecycle costs which leads to

CLCi(D, T, r) = CDi + ∑ j=1

TCFi + CVi(Dj)

(1 + r) j . (2)

In this formulation the initial DDT&E costs, CDi,, arenot discounted. A large discount rate r will tend to

Figure 1. Flow diagram of the 5-step TDN methodology.

Table I. High-Level System Cost Elements

5While inputs to TDN can be taken as given for the current paper, theneed to develop better methods to represent the design space such thata good set of initial designs can be created is an important area forfurther development.



reduce the impact of future expenditures on the lifecy-cle cost relative to the initial expenditures. For commer-cial systems that generate revenue, Eq. (2) can alsoinclude the revenues (with positive sign) and the costsalready discussed (with negative sign) in which case Eq.(2) expresses the net present value (NPV) of the systemor project.

2.2. Quantifying Switching Costs andCreating a Static Network

2.2.1. Switching CostsOnce an initial set of system configurations has beendesigned along with an estimate of the three traditionalcost-elements (DDT&E, fixed, variable) established foreach point design, we must now identify the cost ofswitching between these system configurations. Asnoted, switching costs are difficult to quantify becausethey combine direct production costs as well as indirectorganizational and political costs associated with learn-ing and changing established operating procedures. Forour current purposes we assume that switching costscomprehend two principal elements:

1. Technical cost associated with altering and pro-ducing a new configuration and/or technology

2. A premium for organizational change.

The first element includes the cost of designing,building, and testing the new system (∆CD) and the costof retiring the old system (∆CR). Thus, the technical costof switching from configuration A to B is the incre-mental cost of developing B, potentially reusing ele-ments of A, plus the cost of retiring those parts of A thatare no longer used when transitioning to B:

CSW(A, B) = ∆CD(B, A) + ∆CR(A, B). (3)

One key assumption is that while A and B will notoperate concurrently, there can be commonality be-tween A and B. If A and B share common subsystemsor are based on common platforms, CD and CR must beestimated using more detailed analysis of which sub-systems are re-used and which must be changed. Thepremium for organizational change, cO, is optional, butcan be a function of the number of people (N) involvedin designing and operating the technology:

CSW(A, B, N) = cO(N) × [∆CD(B, A) + ∆CR(A, B)]. (4)

As a whole, adequately quantifying switching costsis a difficult problem which merits further study. Recentwork on formal change propagation analysis [Eckert,Clarkson, and Zanker, 2004] provides guidance in thisarea. One realistic example of how to quantify switch-ing costs is presented below, in the context of launchsystem design (Section 4).

2.2.2. The Static NetworkOnce switching costs between system configurationshave been estimated, they can be placed in a matrix,with original system configurations (“from”) on therows and new system configurations (“to”) as the col-umns. To take a generic example, imagine three possi-ble point designs for a given system: A, B, C. The costof switching from each to each, CSW(A, B), is placed ina matrix (Table II.). Numbers at each cell in the matrixrepresent the nondiscounted cost of switching from theith row (configuration) to the jth column (configura-tion). It should be clear that these can only representestimated switching costs, as the actual switching costsmay turn out to be different once a switch is actuallyexecuted in the future. The matrix is not necessarilysymmetric. The entries on the main diagonal are zero,indicating that there is no direct switching cost associ-ated with remaining in the same system configuration.

This matrix is formally equivalent to what is calleda weighted node-node adjacency matrix in networkflow theory and graph theory more generally [Ford andFulkerson, 1962; Ahuja, Magnanti, and Orlin, 1993].That is, the matrix of switching costs defines a networkwhose nodes are the point-designs (configurations) andwhose directed arc weights are the switching costsaccording to Eq. (3) or (4). The resulting graph isrepresented in Figure 2.

We call this representation a “static network.” Itcovers all possible switches between the three systemsat any given point in time. Because all n nodes in thegraph are connected to all nodes as well as to them-selves, as a rule the number of arcs in this static networkwill be n2. It is important to note that here the cost ofnot switching, that is, staying at the same node in thestatic network, is zero. This is denoted by the fact that

Table II. Generic Switching Cost Matrix for System Configurations A, B, and C



an arc from a node back to itself is zero. This does notmean that the cost for keeping the system operating inthat configuration is zero—there are still fixed andvariable recurring costs, as described below.

2.2.3. Completing the Static NetworkTo frame the system’s life-cycle as a dynamic networkflow problem we must add costs associated with devel-oping and operating the system in the first place [seeEqs. (1) and (2)]. Then we must add the element of timeto each link. The costs associated with operating eachsystem configuration (CD, CF, CV) on the static networkabove can be coded into the network as follows.

Let N represent the static switching network definedabove (Fig. 2) consisting of a set of nodes (point de-signs) P0, P1, P2, ...., Pn and directed arcs associatedwith switching costs, CSW(X, Y). Let Pij represent thedirectional arc from node Pi to node Pj. Associate theself-loops (that is, all arcs from a node to itself Pii) withthe sum of fixed recurring and variable recurring costelements for that configuration, i, during one time pe-riod ∆T:

Pii = CFi + CVi(Dj) (undiscounted). (5)

Now create a source node S and a sink node Z andconnect them both to all nodes with appropriate direc-tional arcs. Associate all arcs Psi flowing from thesource to the point designs with the initial developmentcost of design i, PDi. This represents the DDT&E costof the initially chosen configuration. Associate all arcsflowing from point designs i with the sink Piz with thecost = 0.6 The result is a static network (Fig. 3) with all

information relevant to the life-cycle cost, as a functionof demand, encoded in the arcs.

2.3. Creating the Time Expanded Network

The goal of the TDN is to capture the cost of operatingand switching system configurations through time,seeking least-cost paths through the network as a func-tion of changing operational requirements such as de-mand. The network above captures all possibledevelopment paths during a system’s life-cycle assum-ing the set of configurations represented in the initialstatic network, but it is not dynamic—that is, it does notinclude the element of time. The introduction of timeinto a directed network transforms it into a dynamicnetwork flow problem. The generic problem involvesfinding min or max-cost flows from a source S to a sinkZ, in a directed network with transversal costs c. Dy-namic network flow problems further associate each arcwith two variables: traversal cost c and a traversal timet. Often the reformulated objective is to find the maxi-mum flow that can be sent through the network in timeT, where costs represent maximum capacity. A solution

6Making all sink arcs = 0 makes the assumption that there are noretirement costs associated with the system at the end of its lifecycle.Retirement costs could be encoded into the network at these arcs asfuture work.

Figure 3. Complete static network representing switchingand staying costs, as well as development costs. Developmentis represented by the dotted line from source S to all initialnodes. Retirement is represented by the dotted lines to the sinkZ.

Figure 2. Graph representation of the switching cost matrixbetween A, B, and C, representing a partial static network.



to the maximal dynamic network flow problem was firstpresented by Ford and Fulkerson [1962] and sub-sequently elaborated upon in a host of different practi-cal applications, e.g., time-varying traffic flowmodeling [Köhler, Langkau, and Skutella, 2002].

Dynamic network flow problems can be solved byreformulating the dynamic network into a time-ex-panded static network, and then solving a traditionalmax or min cost flow problem on the resulting staticnetwork [Ahuja, Magnanti, and Orlin, 1993]. A timeexpanded network splits the problem into T time peri-ods, with each node in the original network duplicatedat every time period. Arcs connect the nodes dependingon traversal period, and the new network contains onlycost information for each arc.

Methods to reformulate static networks into time-expanded networks are well established [see Ford andFulkerson, 1962, pp. 146]. We first divide the life-cycleinto T time periods and associate each arc with a tra-versal time t. For simplicity and generality, let us as-sume here that each arc in the network (switching orstaying) takes exactly one time period ∆T to traverse.7

Each node in the static network is duplicated in eachtime period, and arcs between these nodes are expandedthrough the new network-based traversal times t.

Figure 4 expands the static network created by hy-pothetical system configurations A, B, C, into a time-expanded network over 3 time periods, T1, T2, T3. It isassumed for simplicity that the traversal time associatedwith each arc is exactly one time period, ∆T. Flow startsat the start node S and ends at the end node Z. Figure 4represents the development alternatives and costs overa life-cycle, given three system configurations A, B, Cand our four elements of cost (CD, CF, CV, CSW); how-ever, one critical element is still missing: If a paththrough the network includes a switching arc, the “op-erating arc” during that time period will have beenavoided. In other words, a min-cost flow through theabove network can selectively chose to avoid costsassociated with periods of high-demand by switchingbefore them. In reality, an existing system will continueto operate to meet existing demand while a new systemconfiguration is being developed.

We therefore introduce a final distinction, taking acue from decision theory, between chance nodes and

decision nodes, and thereby decoupling operating pe-riod’s costs from switching decisions. This is done bysplitting each time period with chance nodes (circles)at the beginning, and decision nodes (squares) at theend. Fixed and recurring costs are incorporated into thesub-arcs following the chance nodes at the beginning ofeach time period (let us call them chance arcs). Switch-ing costs on the other hand are incorporated into the arcsfollowing the decision nodes at the end of each timeperiod (let us call them decision arcs). The chance arcsrepresent the costs of operating the system at a level ofdemand, Dj, in time period Tj. The resulting time-ex-panded network is shown in Figure 5.

Initially, coming out of the start node S-19, a systemconfiguration (A, B, or C) must be chosen which causescapital expenditures for DDT&E. If A is chosen, thisamounts to CD(A). At the beginning of time period T1,the demand that will have to be satisfied during thisperiod, D1, is revealed at chance node 1. This allowscalculation of the operating costs during that time pe-riod (both fixed and variable). Towards the end of thetime period we encounter decision node 2. We have todecide whether to remain in configuration A (with noswitching costs incurred), or whether to switch to con-figuration B or C, with the respective switching costsbeing incurred at that time. This process repeats itselfuntil the last time period T3 at which time the system isretired as indicated by transition to the end node, Z-20.The sequence in which the nodes are numbered isimportant and will be discussed below.

2.4. Create Scenarios and RunOptimization

2.4.1. Operational Scenarios: Modeling DemandIt is now possible to introduce operational scenariosover time, by changing the cost of traversing the chancearcs as a function of operational demand and time-vary-

7Changes to this assumption can easily be made based on specificmodeling needs. Sometimes, for example, switching to a new systemwill take multiple time periods. These kinds of issues can be ad-dressed in different ways by, for example, changing the length of eachtime period or changing the cost of switching to take account of thefact that it is really spread of multiple time periods (years). For ourmodeling purposes in Section 4, we assume that 1 time period is 5calendar years, and that it corresponds to making major developmentdecisions in context of the budget reviews in the U.S. government.

Figure 4. Initial Time-expanded Decision Network (TDN)with three configurations and three time periods.



ing requirements on the system by creating variousdemand scenarios. Demand scenarios can be determi-nistic, involving known levels of demand at each pe-riod, or they may be probabilistic, in which casemultiple instances of the TDN have to be solved, onefor each uncertain scenario.

A simple way to examine the space of demandpossibilities is to create a number of discrete demandprofiles that are likely to occur over time (i.e., steadilyrising demand, constant demand, falling demand, and alimited combination of the three) and applying these tothe network. Another way involves modeling using

Geometric Brownian Motion (GBM) and applyingmultiple combinations of demand scenarios (Fig. 6)[see Haberfellner and de Weck, 2005]. In all cases thedemand scenarios are time-discretized, and the infor-mation is injected in the appropriate chance nodes.

An important point with respect to the TDN meth-odology is that the four cost elements can be calculatedusing separate and standard cost models and then usedas inputs to the time-expanded network. That is, thetotal cost of operating in each time period can becomputed as a function of the demand scenario and theparticular present state (configuration) of the system,

Figure 5. Refined Time-expanded Decision Network. Chance nodes are circles, decision nodes are squares. Nodes are numberedin topological order.

Figure 6. Geometric Brownian Motion (GBM) model of uncertain demand, ∆T = 1 month, D0 = 50,000, µ = 8% p.a., σ = 40%p.a.—three scenarios are shown, based on de Weck, de Neufville, and Chaize [2004].



and then these costs can be used as the cost of traversingthe chance arcs and decision arcs in each time period.

2.4.2. Optimization: Finding the Shortest PathsThe ultimate goal of the TDN methodology is to createa simulation of future states of the system to find theset, or sets, of design configurations that minimize lifecycle cost (or maximize NPV) under various demandscenarios. By extension, we want to identify exactlywhere lowering switching costs may maximize adapt-ability. The set may, or may not include more than onepoint design, depending on the relevant ratios of thefour cost elements (CD, CF, CV, CSW) and the demandat each time period. In other words, this may or may notinvolve switching from one design to another during thelifecycle.

Once the costs of operation are coded into the chancearcs of the time-expanded network, finding least-costpaths involves implementing standard network optimi-zation algorithms. If no loops exist in the network, asin Figure 5, nodes can be ordered topologically—thatis, ordered in terms of how far they are from the source.When this is the case, a simple reaching algorithm canbe used to find the shortest path. The so-called reachingalgorithm [Ahuja, Magnanti, and Orlin, 1993,Lauschke 2006] can solve the shortest path problem(i.e., the problem of finding the graph geodesic betweentwo given nodes) on an m-edge graph in m steps for anacyclic graph. The reaching algorithm is used in thispaper. For each operational scenario a different acyclicpath through the TDN may be optimal. Even though onemay chose to cycle between configurations, the graphwill still be acyclic due to time expansion as discussedabove. We are interested in identifying those configu-rations A, B, C, … that are most often chosen as initialconfigurations and those switches i → j that are selectedmost often to switch among these configurations duringthe lifecycle.

2.5. Modifying System Configurations:Iterative Design

Once formulated, the time-expanded decision networkmodel is a powerful tool to help formulate and refineinitial point designs as well as identify opportunities forcommonality and real options [Trigeorgis, 1996]among these configurations. A real option can beframed simply as a feature embedded “in” or “on” aninitial design configuration to lower future switchingcosts. The TDN can be used in many different ways tocreatively identify point designs, and interfaces thatmay lower future operating costs. By combining myriaddemand scenarios and network optimization algo-rithms, designers can selectively tweak elements of

point designs, increasing and decreasing commonality,to see exactly how this affects least-cost operating anddevelopment paths through the network. As will beillustrated in the example below (Section 4), this infor-mation can be used to exploit high-leverage switchesthat in turn open vast new operating spaces that wouldnever have been exploited had switching options notbeen considered and incorporated into previous de-signs.

The TDN method can be incorporating into a com-puter program that enables systems designers to framethe problem of “design for evolvability” more rigor-ously, to automate aspects of the analysis process, andto identify relationships between designs and the envi-ronment that would be very difficult for humans dis-cover. This does not mean, however, that it automatesdecision-making. The system designer’s knowledge iscrucial and is primarily required in creating and select-ing interesting feasible system configurations, model-ing the four main elements of cost as well as incapturing the uncertain scenarios. A software programbased on this method should therefore be considered aniterative design tool which frees system engineers tocreatively develop more evolvable (and thus profitable)systems.

3. SCALING THE METHOD

An important question here arises: what is the compu-tational cost of conducting such quantitative scenarioplanning and how does it scale with number of configu-rations and number of time periods? This section ad-dresses this question.

Of the five steps described above (Fig. 1), the firsttwo are conducted manually. That is, configurations andswitching costs are inputs to a TDN program. Theprogram then creates the static network at a computa-tional cost, O(C2), where C is the number of configura-tions. The next three steps involve creating thetime-expanded network, applying demand scenarios tothe time-expanded network, and finding shortest pathsfor each scenario.

Creating the time expanded network is generallynegligible from a computational (processing time) per-spective—it involves creating a matrix with appropriatenumbering and enough spaces to account for every nodeN in the network. Given T time periods and C systemconfigurations, the TDN will have the following num-ber of nodes, including the dummy start and end nodes:

N = 2 × C × T + 2. (6)

The factor of 2 comes from having split each nodein Fig. 4 into a chance node and a decision node (seeFig. 5). Memory issues can potentially arise when there



are many system configurations (C > 1000) and manytime periods (T > 1000). Generally, however, TDN isintended for analyzing a limited number of configura-tions, C~O(10–100), for a few major time periods orstages, T~O(10–20) from a strategic perspective, and inthis regime TDN performs reasonably well.

The real computational costs are incurred during theprocess of iteratively applying scenarios and findingshortest paths. The two steps which contribute to thecomputational cost here are the computation of chance-arc costs (operating costs) as a function of demandscenario, and the running of the shortest path algorithm.Operating costs are calculated as a function of demand,Dj, in each time period and associated with chance-arcson the time-expanded network (Fig. 5). Given T timeperiods and C system configurations, this is simply thenumber of chance arcs, or C × T calculations per sce-nario.

The time expanded network defined above is acy-clic, meaning that it contains no cycles. It is thereforepossible to implement the reaching algorithm, to findshortest paths efficiently [Ahuja, Magnanti, and Orlin,1993]. This is significant, since the number of all pos-sible paths through the time expanded network is

# paths = CT. (7)

Thus, the number of paths increases exponentially withthe number of time periods if we were to attempt anexhaustive search of all paths.

The reaching algorithm, on the other hand, finds ashortest path in O(M) time, where M is the number ofarcs in the network. It has been proven that no otheralgorithm can have better complexity because any otheralgorithm would have to at least examine every edge,which would itself take M steps [Ahuja, Magnanti, andOrlin, 1993]. In our case,

M = (T − 1) × C2 + C × (T + 2), (8)

where the first term accounts for the switching arcs(decision arcs) assuming that we can switch from anyconfiguration to any other configuration at any timeperiod, and the second term accounts for the chance arcsas well as the initial development and final retirementarcs.

Within each scenario, then, total complexity cost isO(Z), where

Z = (T − 1) × C2 + C × (T + 2) + C × T (9)

For consideration of complexity, this reduces to Eq.(10) for each of S scenarios:

O(Z) = C2T + CT + C. (10)

Therefore, the computational cost of the TDNmethod, when implemented in conjunction with thereaching algorithm, scales quadratically with the num-ber of configurations C and linearly with the number oftime periods T and scenarios S. The complexity of themethod is

O(SC 2T). (11)

This appears to represent a significant improvementover traditional multistage decision trees which areknown to branch exponentially—similar to Eq. (7)—asa function of the number of decision states and decisionstages. A more detailed comparison of the complexityof TDN with traditional decision trees is left for futurework.

4. APPLICATION OF TDN TO THE DESIGNOF HEAVY LIFT LAUNCH VEHICLES

The TDN method described above has been pro-grammed as a functional software tool8 and applied tothe problem of designing an “evolvable” Heavy LiftLaunch Vehicle (HLLV) system for NASA’s Vision forSpace Exploration (VSE). This vision calls for thereturn of human explorers to the surface of the Moonby 2020, followed by crewed Mars missions. There issubstantial uncertainty surrounding the number andtiming of future missions, primarily due to budgetaryfluctuations.

Like most large, complex systems, launch vehiclearchitectures and space system architectures generallysuffer from architectural lock-in [Shishko, 2001; Silver,2005b]. To apply the TDN method to this problem, fourdifferent initial vehicle configurations were created—one clean sheet design, one based on Evolved Expend-able Launch Vehicles (EELVs), and two based onShuttle-Derived Vehicle (SDV) alternatives—and re-lated cost elements and switching costs were computed.The methodology was run using 10 plausible scenariosfor Lunar and Mars exploration campaigns, and totallife-cycle costs were calculated. Initial results demon-strated preferred vehicle configurations, and iterativemethods quantified the value of lowering switchingcosts under a uniform scenario probability distribution.

4.1. Step 1: Initial System Configurations

The model was implemented using four point designs(Fig. 7) of interest to NASA during the heavy lift launchdecision in support of the 2005 Exploration SystemsArchitecture Study. The four launch vehicle configura-tions considered are as follows:

8Using the Matlab V7.1/Simulink technical computing environment.



1. P1 = A: Shuttle Derived (SDV-A) Inline HeavyLift; 3 Space Shuttle Main Engines; 2 four-seg-ment solid rocket boosters; Performance: 80 met-ric tons to low earth orbit

2. P2 = B: Shuttle Derived (SDV-B) Inline HeavyLift; 3 Space Shuttle Main Engines; 4 four-seg-ment solid rocket boosters; Performance: 115metric tons to low earth orbit

3. P3 = C: Evolved Expendable Launch Vehicle(EELV) derived rocket; Delta V core; 2 Zenithboosters; Performance: 62 metric tons to lowearth orbit

4. P4 = D: Clean Sheet (CS) Heavy Lift Vehicle;Performance: 105 mt to low earth orbit.

An N2 diagram showing the components of the launchvehicle models and implementation of the TDN methodis shown in Figure 8. The N2 diagram references steps1–5 shown in Figure 1.

After performance and risk were estimated for eachconfiguration, the first step of the TDN process in-volved estimating initial development costs for all fourvehicles as well as fixed and recurring operating costsas a function of demand (“traffic model”). This wasinitially done by NASA and supplemented by theauthors using traditional cost-estimating tools. Formore information on this process and the underlyingassumptions, see Silver [2005a].

4.2. Step 2: Calculating Switching Costsand Creating the Static NetworkThe next step involved calculating switching costs be-tween the vehicle configurations shown in Figure 7. Asnoted above, this depends crucially on the amount ofcommonality between the systems and any real options(reserved interfaces, extra margins, etc.) embedded inthem. Systems can share subsystems at different levels.For example, Shuttle-derived vehicles and EELV de-rived vehicles might be designed to use common large-scale subsystems such as launch pads, with minoralterations. At a deeper level in the system decomposi-tion, two shuttle derived vehicles might share almost allfirst order subsystems—launch pads, manufacturing

Figure 8. N2 diagram of TDN implementation for the launch vehicle design problem.

Figure 7. Four launch vehicle point designs used in the TDNapplication. From left to right: Shuttle Derived A (1); ShuttleDerived B (2); EELV derived C (3); Clean Sheet design D (4).



facilities, rocket boosters, main engines—with altera-tions only to specific second-order subsystems—i.e.,the external fuel tank. To calculate switching costs,then, we must break the system into its constituentsubsystems to identify commonality at the appropriatelevel.

To take one example of how point designs can in-volve commonality at a level deeper than the majorsubsystem level, imagine four shuttle-derived point de-signs (Fig. 9): a side-mount configuration with 4-seg-ment solid rock boosters (SRBs); a side mountconfiguration with 5-segment SRBs; an inline vehiclewith 4-segment SRBs; and an inline launch vehicle with5-segment SRBs. Each of these system configurationpairs has commonality in a different way—some sharethe same solid rocket boosters, others the layout ofcargo to external tank. Calculating switching costs be-tween these systems demands examining how theircommon elements affect subsystem design.

Figure 9 demonstrates how this can be done bydecomposing major subsystems and examining howthey affect subsystem design, in this case the subsystemis the “facilities,” and the components are specificbuildings or parts of these buildings. As the highlightsdemonstrate, different facilities must be altered depend-ing on whether additional SRBs are added, or if thelayout of the external tanks is modified (side mounted

versus vertically stacked). These elements are not mu-tually exclusive and therefore the switching costs be-tween each system must take into account what isalready built and what has yet to be built.

In the TDN path optimization, the resulting switch-ing costs between systems 1, 2, 3, and 4 (shown in Fig.7) are needed. These are presented in Table III (in unitsof millions of dollars).

4.3. Step 3: Create Time-ExpandedNetwork and Demand Scenarios

Once the four cost elements were determined, we cre-ated the time expanded decision network (Fig. 10). Inthis case we had four system configurations and dividedthe time horizon into four periods. Each time period wasassumed to represent 5 years, so the total life-cycle is20 years. This TDN has CT = 256 possible scenario-in-dependent paths [Eq. (7)] and by plugging C = 4 and T= 4 into Eq. (8), we obtain M = 72 arcs, some of whichare shown in Figure 10.

Next the demand scenarios were created. As noted,modeling demand is complex and can be carried out innumerous ways depending on the application. For thisapplication, demand for the launch vehicles takes theform of tons of payload needed to be shipped to low-earth orbit (IMLEO) per time period9 and how manylaunches this would necessitate. NASA is principally

Figure 9. Estimating switching cost by decomposing subsystems between SDV configurations ($M).



concerned with returning to the Moon and possiblysending crewed missions to Mars; therefore, we had totranslate variations in kind and timing of Lunar andMars missions to launch-vehicle demand [see Silver2005a]. Next, we created ten scenarios based on howmany Lunar and Mars missions might be launchedduring each time period and translated this to differentnumbers of launches for each vehicle and, by extension,different patterns of operations costs along the chancearcs in the time-expanded network (Fig. 10). The 10future demand scenarios are shown in Table IV. Theunderlying assumption of these scenarios is that theMoon will serve as a stepping stone to Mars.

4.4. Step 4: Path Optimization

Once the demand scenarios we created and the resultingoperations costs coded into the network we ran thenetwork optimization (reaching) algorithm under eachscenario. The result was ten different shortest pathsthrough the life-cycle, as a function of each demand

scenario. Two vehicle configurations (1 and 3) wereused, and no switches were employed. Figure 11 illus-trates the two shortest paths, and Figure 12 shows thetotal life-cycle cost predicted for each scenario. Sce-nario 6 resulted in the highest total life cycle cost,because it contained the highest number of both Moonand Mars missions.

4.5. Step 5: Iterative Design

The results demonstrate that two vehicles, namely con-figuration 1 (SDV-A) and 3 (EELV-derived), respec-tively, were optimal under different operating regimes.This raises the question: Would it be worthwhile todecrease the switching costs between these two vehiclesand, if so, how much should we be willing to pay to dothis? This question can be easily answered using TDN.Specifically, we can systematically lower the switchingcosts between two vehicles in order to determine (a) atwhat switching cost level switching between the con-figurations would start to occur under each demandscenario and (b) what the savings would be, if any, interms of total life-cycle cost.

We carried out this numerical experiment, system-atically lowered the cost of switching from the EELV-derived vehicle, configuration 3, to the shuttle-derivedSRB vehicle, configuration 1, from $4 billion to $1billion, in steps of $1 billion. The results are summa-rized in Figure 13.

The results demonstrate that if the switching cost isset to $4 billion, one switch is made in scenario 8 aftertwo time periods—this is a scenario where we encoun-

Table III. Switching Costs ($M) between Four Selected Launch Vehicle Configurations

Figure 10. The time expanded decision network (TDN) for the launch vehicle case.

9Based on preliminary architectures, we estimated that a lunar mission required approximately 130 metric tons to lunar orbit, while a Mars missionrequires on the order of 600 metric tons to be delivered to Low Earth orbit. Uncertainty in these numbers can be introduced by varying both thefrequency of demand (number of missions) and the level of demand (mass of each mission). In our model we varied only frequency.



Figure 11. Two resulting shortest paths through the life-cycle: vehicles 1 and 3 are chosen.

Table IV. Ten Demand Scenarios for Future Launch Vehicle Usage across Four Time Periodsa

aThe total number of lunar missions (requiring 130 metric tons to LEO) is in light gray, the number of Mars missions (requiring 600 metric tons in LEO) is in dark gray.



ter few lunar missions initially and many Mars missionslater. As the switching cost is lowered further, switchesalso occur in other scenarios (see Fig. 13).

4.6. Calculating the Benefit

What would be the benefit of lowering switching costsin this way? The answer depends on the exact scenario

Figure 12. Total life cycle costs ($ billion) for all ten scenarios.

Figure 13. Switches as a function of switching cost level between $1 billion and $4 billion.



that ends up occurring in the future. The simulationsdemonstrated that if scenario 8 occurs, a switch be-tween the vehicles occurs even at a relatively highswitching cost. In this case the savings of loweringswitching costs between these vehicles would be high.Another way to present this, however, is to determinehow much is saved in terms of expected-cost if eachscenario is equally likely. We created ten scenarios(Table IV), so each scenario would have a 10% chanceof occurring.

Figure 14 illustrates the total life-cycle cost as afunction of the switching cost between the vehicles,both for scenario 8 in particular and for the case whereevery scenario is equally likely. SC_Normal is thIeoriginal case (with switching costs shown in Table III),so it should be used as the baseline. The results demon-strate that indeed, savings are greatest if scenario 8

occurs, but that there are also LCC savings on averageacross all scenarios.

Figure 15 makes this even more apparent. It showsthe exact amount saved as switching costs are loweredbetween the two most-used vehicles (3 and 1). If wethink all scenarios are equally likely, we can save up to$600 million on average by lowering the switchingcosts to $1 billion dollars. If we think that scenario 8will probably occur, we can save as much as $2.8 billionby lowering the switching cost between configurations3 and 1 to $1 billion. This therefore tells us specificallyhow much we should be willing to pay to lower theswitching costs to those desired numbers. Switchingcosts can be lowered by embedding provisions in con-figuration 3 that will make it easier to switch (makechanges) to configuration 1 at a later time. There are anumber of ways to accomplish this such as stand-ardization, extra margins, inclusion of interfaces forfuture expansion. This is an appropriate place to applythe principles of changeability enumerated by Frickeand Schulz [2005].

The benefit obtained from lowering switching costsin a way is the maximum price we would be willing topay on a real option that allows (but doesn’t require)switching from configuration 3 (EELV) to 1 (SDV) ata later date. If it is cheaper to lower the switching coststhan not to switch and incur future costs due to opera-tional inefficiency, then the switching costs should belowered. If this is not the case, then it makes more senseto keep the switching costs where they are in the initialconfiguration and accept some amount of lock-in. Twofinal points should be noted. First, we can weight sce-narios as we please rather than resorting to averages.Second, lowering the switching cost might change theperformance characteristics of the system, and there-fore change the life-cycle costs. This should be takeninto account during iterative design.

Figure 14. Total life cycle cost (LCC) as a function ofswitching cost between EELV (3) and SDV vehicle (1). Thelighter bars show average LCC across all 10 scenarios; thedarker bars show the LCC for scenario 8 specifically.

Figure 15. Total LCC savings as a function of switching cost: average for equally weighted 10 scenarios versus savings forscenario 8 alone.



5. NOTES ON MODEL FORMULATION

The generic TDN modeling framework described inthis paper can be implemented in different ways basedon specific modeling demands, and applied to a varietyof systems and industries. This section reviews somemodeling issues raised in this paper including areas forfuture work:

• Complete Information: Classic shortest path al-gorithms assume perfect information about fu-ture operating costs. In reality operators do notknow what operating scenarios will exist in thefuture. This “limit to rationality” can be ac-counted for by revising the shortest path algo-rithm to limit the number of future time periodsconsidered at each point in time. However, whileacademically interesting, this may not be practi-cally useful. The goal for the model is to increasesystem flexibility and enable practitioners tochange their behavior, not to model an operatingenvironment per se. Designing systems thatevolve optimally demands realism in potentialoperating scenarios and carefully consideredprobabilities of occurrence to identify and designoptimal switches, not necessarily realism in op-erator judgment.

• Number of Time Periods: We can split the life-cy-cle into an arbitrary number of time units witheach time unit representing an arbitrary amountof real-world time. Note, however, that the num-ber of potential paths increases exponentiallywith the number of time periods, T. This is miti-gated by the fact that the shortest path algorithmscales linearly with the number of time periods.

• Time to switch: Switching time can be modeledin ways similar to classic “project cost curve”problems. In these it is generally assumed that aproject is an ordered set of jobs. Each job has anassociated normal completion time and a crashcompletion time, and the cost of doing the job (inour case, making the switch) varies linearly be-tween these two times. Project cost curves have along history [Ford and Fulkerson, 1962: 151].

• Mixed Strategies: We may want to operate morethan one kind of a system configuration at thesame time. This can be done by sending morethan one unit of flow through the network. Thisis an area for future study.

• Decision Rules: There are a number of ways inwhich TDN can be used to study the effect of avariety of decision rules on lifecycle cost or NPV.Specifically, the path chosen by the reaching al-gorithm will always be optimal, since it assumes

complete information about the future for eachscenario. In an unfolding lifecycle scenario deci-sion-makers will have to make the decisionwhether to stay or switch based on incompleteinformation. TDN can be used to study the effec-tiveness of various decision rules by comparingthem to the shortest path baseline.

• Transition Rules: As discussed above, at eachtransition point between time periods (stages)one has to decide whether to remain in the currentstate or transition to one of the (C – 1) other states.This gives rise to the C2 switching arcs betweentime periods and the CT total paths. One mayreduce the number of paths a priori by introduc-ing so-called transition rules, which prohibit cer-tain switches from occurring. This concept wasimplemented in de Weck, de Neufville, andChaize [2004], where the staged deployment ofsatellite constellations was optimized under de-mand uncertainty. Instead of allowing switchesbetween all 600 configurations, the number ofallowable paths was reduced by (i) forming 15families of 40 configurations each that sharedcommon subsystems and only allowing switcheswithin each family and (ii) by only allowingswitches that would grow the system in terms ofcapacity.

• Operational Flexibility: When actual demand Dj

is revealed at a chance node at the beginning oftime period j, the fixed and variable cost at thistime period may not automatically be determinedaccording to Eq. (5). If capacity exceeds demand,one may deliberately choose to shut down part ofthe system during period j, in order to temporarilyreduce fixed costs. When this is possible, wecould potentially extend the TDN method to takeinto account operational flexibility while being inthe ith system configuration, not just switchingflexibility between configurations i and j. Con-current consideration of operational and designflexibility is left for future work.

• Impact on Design Cost: When lowering theswitching costs from $4 billion to $1 billion inSection 4.5, we did not explicitly say how thiswould be accomplished. Generally, loweringswitching costs will require an increase in upfrontdesign cost. This relationship between switchingcost and upfront development cost would be afruitful area of future research. In an extreme casewe may decide to design a system that has zeroswitching costs to reversibly achieve any of the Csystem configurations under consideration. Suchsystems are referred to as reconfigurable systems[Siddiqi, de Weck, and Iagnemma, 2006], since



they can switch between configurations at no orvery low cost. The ability to be reconfigurable,however, is often associated with significantlyincreased system complexity (more actuators,sensors, etc.) and upfront effort. Given an explicitrelationship between switching costs and upfrontdevelopment effort, TDN could be used to findthe optimal degree of system flexibility that bal-ances upfront expenditures with ease of down-stream switching.

6. APPLICATIONS

TDN is a generic modeling methodology that can beapplied to a host of system-design problems. In the veinof “real options thinking,” we can distinguish betweendesigning for evolvability at the subsystem level or atthe system (architectural) level. In the former case, theeach design can be considered an instantiation of onesystem with modified subsystems, and the switchingcosts will involve the cost of changing those subsys-tems. By contrast, the example of designing launchvehicles presented above involved more radical con-figuration changes at the level of the entire systemarchitecture.

More specifically, we envision that TDN could beapplied to the following kinds of systems:

• Complex Electromechanical Products: Systemsin this category, from microchips to automobiles,must resolve a host of often conflicting designrequirements in catering to one of many potentialtarget markets. Concepts developed to addressthese issues such as flexible platforming and ad-aptation to dynamic market segments can be han-dled more rigorously with the TDN methodology.

• Real-Estate and Building Architecture: Tradi-tional building architecture used to define the“program” for a building as driven by its initialuse. This is true for residential construction butalso for many public buildings (museums, librar-ies, etc.) and office buildings. Increasingly, how-ever, there is a realization that building usechanges over time and that—in order to reducefuture remodeling costs—buildings can be delib-erately designed to be evolvable over time. Anexample of this was provided by Kalligeros andde Weck [2004], where BPs new North Sea Ex-ploration Headquarters in Aberdeen, Scotland,was designed in a modular fashion.

• Infrastructure Projects and Strategic Planning:Many large-scale infrastructure projects, fromelectricity grids to water and gas pipelines, in-

volve networked structures providing services todiverse populations over long life-cycles. Thesestructures exhibit significant lock-in, with seriousconsequences if the nature and amount of demandcannot be met. TDN can help design responses tocritical scenarios and develop networks with bet-ter evolved reaction to match demand shifts.

• Airline Expansion Decisions: Airlines create net-works of transportation which are shaped by, butcan also shape, patterns of demand and operation.Decisions about both network structure and vehi-cle fleet selection are interdependent, and createsignificant path dependence for airlines [Taylorand de Weck, 2007]. TDN can help create a mixof fleet selection, routing, and maintenance strat-egy, which allows for appropriate flexibility inthe face of changing demand.

• Factory Design Under Uncertainty: Companiesin multiple industries face the problem of capac-ity planning under uncertainty. Once built, facto-ries create a specific fixed and variable coststructure in the face of shifting demand, withsignificant impact on a company’s bottom line.Often, factors in the environment that indicatedthat a given factory in a given location would befavorable change rapidly, leaving companies withthe decision to operate at lower margins or writeoff the sunken investment. TDN can be used todesign both the factories themselves, and selectfactory locations, in a way that allows for greaterflexibility and profitability over the life-cycle.

• Strategic Contracting Decisions: Design and ac-quisition decisions also depend on a host of con-tracts and legal constraints among developers,acquires, and operators. Whether for system de-sign, or even in purely business matters, contractsare designed to create lock-in using the legalsystem, in order to change the incentive structures(cost of switching) among contracting parties[Joskow, 1985]. Contracting decisions that affectthe evolution of a system, or a business process,can be made more rigorous by explicitly incorpo-rating the costs of switching (even if the latter arepurely legal costs). The TDN methodology canthus be applied in the area of pure business strat-egy and contracting.

7. CONCLUSIONS

TDN represents an advance over similar methods todesign and analyze system flexibility.

First, it is formulated to enable designers to explic-itly address the problem of high switching costs, a



principal cause of architectural lock-in, early in thedesign process in a clear and rigorous manner.

Second, by exploiting the inherent structure of thetime-expanded graph, TDN overcomes the problem ofexponentially branching development options, a seri-ous impediment to the practical implementation of bothreal options and decision theory-based design methods.Specifically, by expanding the static switching networkin time, we can generate an acyclic graph withM~O(C2T) edges, which can be solved by a shortestpath reaching algorithm in M-linear time. This is sig-nificantly more efficient than enumerating all potentialCT paths for all S scenarios. In this way, TDN reformu-lates life-cycle evaluation as a network optimizationproblem with clearly defined user inputs.

Third, TDN enables quantitative, user-directed sce-nario planning.

Fourth, TDN lends itself easily to implementation asan iterative computational tool, reducing the cognitiveload on system designers and allowing them to concen-trate on design alternatives, switching options and de-velopment scenarios.

Finally, the method is generic, being applicable toany systems and sub-systems where architectural lock-in and the high-switching costs are a potential problem.Examples of applications that could use TDN would bethe design of a factory under uncertain capacity require-ments, or fleet acquisition for an airline under uncertaintraffic models, among others.

TDN developed from the realization that, if properlyframed, switching costs between system configurationsdefine a network whose nodes are point-designs andarc-costs are both operating and switching costs. Usingconcepts from operations research, this “static net-work” can be expanded into a “time expanded network”in order to model a complete life-cycle. The time ex-panded network provides a compact representation ofall possible development paths for the set of pointdesigns, and thus avoids exponentially branching devel-opment options often encountered in traditional deci-sion theory. Used in conjunction with established costmodeling techniques including the estimation of fixedand variable operating costs, the time-expanded net-work model can be implemented as a software tool andused iteratively to identify optimal switches and designincreasingly complex evolvable systems.

REFERENCES

R.K. Ahuja, T.L. Magnanti, and J.B Orlin, Network flows:Theory, algorithms, and applications, Prentice Hall,Englewood Cliffs, NJ, February 1993.

K. Arrow, Forward to W.B. Arthur, Increasing returns andpath dependence in the economy, University of MichiganPress, Ann Arbor, 1994.

K. Arrow, Increasing returns: Historiographic issues and pathdependence, Eur J Hist Econ Thought 7 (2000), 171–180.

B. Arthur, Competing technologies, increasing returns, andlock-in by historical events, Econ J 99 (1989).

W.R. Ashby, Design for a brain: The origin of adaptivebehavior. Science Paperbacks, London, 1966.

C. Baldwin, and K.B. Clark, Design rules, Volume 1: Thepower of modularity, MIT Press, Cambridge, MA, 2000.

C.M. Christensen, The innovator’s dilemma, Harper Collins,New York, 1997.

R. Cowan, Nuclear power reactors: A study in technologicallock-in, J Econ Hist 50(3) (September 1990), 541–567.

P. David, “Path dependence, its critics and the quest for‘historical economics,’” Evolution and path dependencein economic ideas: Past and present, P. Garrouste and S.Ioannides (Editors), Edward Elgar, Cheltenham, UK,2000.

O. de Weck and E.S. Suh, Flexible product platforms: Frame-work and case study, Proc IDETC/CIE 2006 ASME 2006Int Des Eng Tech Conf Comput Inform Eng Conf, Sep-tember 10–13, 2006, Philadelphia, PA, DETC 2006-99163.

O. de Weck, R. de Neufville, and M. Chaize, Staged deploy-ment of communications satellite constellations in lowEarth orbit, J Aerospace Comput Inform Commun 1(March 2004), 119–136.

A. Dixit, Investment and hysteresis, J Econ Perspectives 6(1)(1992), 107–132.

G. Dosi (Editor), Technical change and economic theory,London, New York, Printer Publishers, 1988.

C. Eckert, P. Clarkson, and W. Zanker, Change and customi-sation in complex engineering domains, Res Eng Des15(1) (2004), 1–21.

L.R. Ford Jr. and D.R. Fulkerson, Flows in networks, Prince-ton University Press, Princeton, NJ, 1962.

E. Fricke and A.P. Schulz, Design for changeability (DfC):Principles to enable changes in systems throughout theirentire lifecycle, Syst Eng 8(4) (2005), 342–359.

R. Haberfellner and O.L. de Weck, Agile SYSTEMS ENGI-NEERING versus engineering AGILE SYSTEMS, IN-COSE 2005 Syst Eng Symp, Rochester, NY, July 10–15,2005.

A.C. Hax, D.L. Wilde, and L. Thurow, The Delta Project:Discovering new sources of profitability in a networkedeconomy, Palgrav, New York, 2001.

R. Henderson, Of life cycles real and imaginary: The unex-pectedly long old age of optical lithography, ResearchPolicy 24 (July 1995) (Issue 4), 631–643.

R.M. Henderson and K.B. Clark, Architectural innovation:The reconfiguration of existing systems and the failure ofestablished firms, Admin Sci Quart 35 (1990), 9–30.

J.J. Jarvis and H.D. Ratliff, Some equivalent objectives fordynamic network flow problems, Management Sci 28(1)(January 1982), 106–109.



P.L. Joskow, Vertical integration and long term contracts: Thecase of coal burning electric generating plants, WorkingPaper, Massachusetts Institute of Technology, Center forEnergy Policy Research, 1985, MIT-EL 85-001 WP.

K.C. Kalligeros and O.L. de Weck, Flexible design of com-mercial systems under market uncertainty: Frameworkand application, AIAA-2004-4646, 10th AIAA/ISSMOMultidisciplinary Anal Optim Conf, Albany, NY, August30–September 1, 2004.

M. Katz, Systems competition and network effects, J EconPerspectives 8(2) (1984), 93–115.

E. Köhler, K. Langkau, and M. Skutella, Time-expandedgraphs for flow-dependent transit times, Lecture Notes inComputer Science, Volume 2461, Springer, Heidelberg,2002.

A. Lauschke, Reaching algorithm, from MathWorld—aWolfram Web Resource, http://mathworld.wolf-ram.com/ReachingAlgorithm.html, last accessed October9, 2006.

S.J. Liebowitz and S.E. Margolis, Path dependence, lock-in,and history, J Law Econ Org 11(1) (1995) 205–226.

R. Nelson and S. Winter, An evolutionary theory of economicchange, Harvard University Press, Cambridge, MA, 1982.

E.E. Olson, G.H. Eoyang, R. Beckhard, and P. Vaill, Facili-tating organization change: Lessons from complexity sci-ence, Wiley, San Francisco, CA, 2001.

D.J. Puffert, “Path dependence, network form, and techno-logical change,” History matters: Economic growth, tech-nology, and demographic change, T.W. Guinnane, W.A.Sundstrom, and W. Whatley (Editors), Stanford Univer-sity Press, 2004.

L. Sarsfield, The technology puzzle: Quantitative methods fordeveloping advanced aerospace technology, RANDCorp., Santa Monica, CA, 2001.

C. Shapiro, The theory of business strategy, Rand J Econ20(1) (1989), 125–137.

R. Shishko, Lessons learned from the Space Station Program:The role of life cycle cost, Technical Report, Jet Propul-sion Laboratory, Pasadena, CA, 2003.

A. Siddiqi, O. de Weck, and K. Iagnemma, Reconfigurabilityin planetary surface vehicles: Modeling approaches andcase study, J Br Interplanet Soc (JBIS) 59 (December2006) 450–460.

M. Silver, Heavy lift launch: When is bigger not better? 1stSpace Exploration Conf: Continuing the Voyage of Dis-covery, Orlando, FL, January 30–31, 2005a, AIAA-2005-2606.

M. Silver and O. de Weck, Designing sustainable launchsystems: Flexibility, lock-in, and system evolution, 1stSpace Syst Des Conf Proc, Georgia Institute of Technol-ogy, November 2005.

H.A. Simon, The sciences of the artificial (3rd edition), MITPress. Cambridge, MA, 1996.

C. Taylor and O. de Weck, Coupled vehicle design andnetwork flow optimization for air transportation systems,J Aircraft (2007), in press.

L. Trigeorgis (Editor), Real options in capital investment:Models, strategies, and applications, Praeger, 13, 1995.

J.M. Utterback, Innovation in industry and the diffusion oftechnology, Sci NS 183 (February 15, 1974), 620–626.

J. Wertz and W. Larson, Space mission analysis and design(3rd edition), Microcosm Press, El Segundo, CA andSpringer, London, 1999, p. 786.

U. Witt, Lock-in vs. industrial mass Industrial change undernetwork externalities, Int J Indust Org 15 (1997), 753–773.

Matthew R. Silver is a doctoral student in the Engineering Systems Division at the Massachusetts Instituteof Technology. He has a background in basic physical research, systems analysis and design, andmanagement and is currently affiliated with the Strategic Engineering group at the Massachusetts Instituteof Technology. Mr. Silver has been a research scientist at the MIT Space Systems Lab for 3 years, wherehe focused on the analysis and design of complex system architectures, and consulted on technologystrategy and transfer for companies such as Payload Systems Inc. Prior to this he worked as a systemsengineer at the Canadian Space Agency, where he developed and tested advanced concepts for spaceexploration. Matt has two masters’ degrees in Aerospace Engineering and Technology and Policy fromthe Massachusetts Institute of Technology and a bachelor’s degree with double major in Astrophysics andArt History from Williams College.

Olivier L. de Weck is currently an Associate Professor with a dual appointment between the Departmentof Aeronautics and Astronautics and the Engineering Systems Division (ESD) at MIT. His researchinterests are in Systems Engineering, Multidisciplinary Design Optimization and Space Systems. In 2001he obtained a Ph.D. in Aerospace Systems from MIT. From 1987 to 1993 he attended the Swiss FederalInstitute of Technology (ETH Zurich) in Switzerland, where he earned a Diplom Ingenieur degree (M.S.equivalent) in industrial engineering. From 1993 to 1997 he served as liaison engineer and later asengineering program manager for the Swiss F/A-18 program at McDonnell Douglas (now Boeing) in St.Louis, MO. He served as the General Chair for the 2nd AIAA Multidisciplinary Design Optimization(MDO) Specialist Conference in 2006 and obtained two best paper awards at the 2004 INCOSE SystemsEngineering Conference. His research focus is on Strategic Engineering of complex systems.



Documents

Regular Paper Time-Expanded Decision Networks: A Framework ...strategic.mit.edu/docs/2_16_SE_10_2_TDN.pdf · Time-Expanded Decision Networks (TDNs) are a method to clearly and rigorously