Technical debt in the engineering of complex systems

The metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems.

studies are focused on predicting, planning, and mitigating obsolescence cost and risk during the later maintenance or sustainment phases, and very few shed light on investigating technical, process, people, and culture factors from the early acquisition phases. With no intention to suggest that COTS is the only factor leading to obsolescence, we conjecture that a systematic approach is needed to explore alternative tools and mechanisms for enhancing early technology and COTS decisions in the acquisition phase. Discussion on multi-facet factors impacting obsolescence is out of the scope of this paper.
The metaphor of technical debt (TD) stemmed from the field of software engineering, first introduced by Ward Cunningham, 17 referring to delayed tasks and immature artifacts that constitute a "debt", because they incur extra costs in the future refactoring, rework, evolution, and/or maintenance activities. 18,19 Over the past three decades, the topic of TD has attracted a large number of studies. Using COTS decisions as a case context, this study investigates linkages between COTS integration risks and TD analogy. In this context, engineering decisions focused on acquiring quick technology commercial solutions would may incur more "debt" to the user/customer organizations, which will need to be "paid off" in later maintenance or sustainment phases in the form of continuous upgrades or living with degraded performance and suitability. To stimulate further discussion and investigation, this paper adapts the TD metaphor in the engineering of complex systems, extends the current TD landscape, proposes a COTS TD taxonomy and a systematic methodology to support the identification, analysis, and management of TD associated with COTS decisions. The taxonomy is extended from a previous conference paper, 20 with and additional contributions are summarized below: • The first study to adapt the metaphor of TD to the engineering of complex systems; • The expansion of the TD landscape with respect to the COTS characteristics in the engineering of complex systems; • The establishment of a TD taxonomy consisting of seven types of COTS TDs for complex systems, including functionality mismatch, performance mismatch, interoperability difficulty, versioning conflicts, documentation and support, system evolution, and organic TD; • The practical insights for applying the TD taxonomy with a set of eight management activities to raise awareness of the TD notion, as well as enable more pro-active, technical-debt-aware program management decision making in the acquisition phases to avoid expensive and unaffordable obsolescence issues in the sustainment phases.
The rest of the paper is organized as follows. Section 2 discusses the background. Section 3 presents a general overview of existing TD studies. Section 4 discusses an analogy of TD in the context of complex systems. Section 5 proposes a taxonomy of TD for the engineering of complex systems. Section 6 provides practical insights for program managers. Section 7 is the conclusion.

BACKGROUND
While we acknowledge that not all "quick" COTS decisions should be expected to lead to TDs, and that there are numerous benefits (and reasons) for committing to COTS or open-source products, this paper primarily focus on high-stake COTS decisions that are more complicated and highly uncertain with regard to their long-term consequences. In this section, we summarize three primary dimensions to consider when using commercial components/technology in the engineering of complex systems, namely, multiplicity, interoperability, and uncertainty. It is worth noting that these three dimensions are being used to organize the discussion of the background, and not intended to be a mutually exclusive, collectively exhaustive listing of the dimensions to be considered when using COTS in engineering complex systems.
• Multiplicity: Due to the common belief that proven commercial technologies allow for substantial cost savings, with fewer schedule delays and improved performance characteristics, 12 21 and the submarine force's sonar systems have been using commercial systems wherever and whenever possible. 22 Maintenance complexity (and costs) will increase exponentially as the number of independent COTS packages integrated into a system increases. 23 • Interoperability: Most commercial components are designed for a general purpose and are not tailored for a specific array, and hence may potentially cause interoperability issues. In modern data systems, many open-source frameworks and tools for data storage and processing have emerged and have been optimized in recent years, such as Hadoop, Apache Kafka, and Redis. However, the selection and integration of various tools still depend largely on the designers' experience and capability in order to build reliable, scalable, and maintainable data systems. 6 Important design assumptions may get lost due to lack of documentation or people turnover. This may in turn result in interoperability issues due to mismatched technical assumptions, expensive or infeasible to address esp. if emerged in the late engineering phases.
• Uncertainty: Commercial components have frequent, independent upgrade cycles, which is one of the root causes for many obsolescence issues in systems with long lifespans. For example, in sustainment-dominated CPS systems, their lifespans are long enough that a significant portion of the COTS components becomes obsolete prior to the system being deployed. 24,25 This is also impacted by the business models of the selected commercial suppliers. In some cases, their business models focus on providing support to the latest version of their products and one prior version. This may not serve the purpose for capital intensive complex systems with long operational lives.
As commercial components begin to dominate complex systems, the management of these risks needs to be addressed in a dynamic and iterative fashion. Due to the short-life expectancy of commercial components, as manufacturers evolve their system to keep up with customer demands, the system integrators and operators are forced to repeatedly choose whether to upgrade the component now and deal with the integration issues, or stay with the existing component and risk future obsolescence that may compromise functionality. For a system with a large number of diverse commercial components/technologies, it is not unreasonable to expect that on average a new release comes to the market every few days.
The scenery and consequences of delayed component upgrades are understandable and can be alarming. Therefore, the use of commercial components is increasingly imposing long-term management issues such as obsolescence, poor reliability, lack of readiness, and inability to readily maintain systems in an efficient and effective manner. There is a compelling need for additional metrics and measurement to enhance the understanding, communicating, analyzing, and predicting of the life cycle consequences incurred by the use of commercial components, in order to mitigate the risk of early design decisions that may lead to integration and obsolescence issues later.
The existing landscape of OM research is dominated by a focus on electrical components, namely, the piece-parts within platforms and other complex military systems. The present focus of TD in academia is on software. There is also wide-spread awareness that the use of overly restrictive and specific acquisition requirements with practices and perspectives lacking informed evidence-based views, during new program starts and onward throughout the envisioned systems life cycle, will enable unsubstantiated short-sighted decisions that may drive negative outcomes over the life cycle of a system. Hence, the compelling need for the consistent advantages associated with an efficient and effective decision-making system that provides data points that readily identify associated risks and facilitate evidence-based decision making and accountability.

WHAT IS TD?
The term "technical debt" was originally introduced by Ward Cunningham in 1992, referring to the fact of "shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. . . The danger occurs when the debt is not repaid." 17 It was later widely adopted in the software engineering field as a metaphor reflecting sub-optimal solutions: compromising one dimension in exchange for benefits in other dimensions.
Frequently, sub-optimal solutions refer to delayed tasks and immature artifacts, which constitute a "debt" and make changes more costly or even impossible in the medium to long term. 26 Next, we summarize the three taxonomies of TD that have evolved from software engineering practices centered on agile software development. 19,26 is a widely-adopted categorization in which TD refers to user-invisible aspects that could potentially impact system evolution. As illustrated in Figure 1, it differentiates software TD (i.e., embodied in mostly invisible items inside the box)  38 Thomas highlighted impact of TD due to insufficient systems engineering. 39 However, to the best of our knowledge, there is lack of a holistic approach to investigate the application of TD notion in complex systems engineering.

ADAPTING TD TO THE ENGINEERING OF COMPLEX SYSTEMS
The idea of TD is straightforward: quickly built and delivered solutions will be faster to market but often require more maintenance and sustainment actions (and perhaps degraded performance) over their useful life. Architecture decisions are important choices that are made during the design and development of complex systems. Systems engineers are responsible for ensuring that systems are designed, developed, and maintained in a way that minimizes risk and maximizes efficiency and effectiveness. It is possible for systems engineering teams to learn from software engineering teams and actively manage "technical debt" and address issues as they arise in order to avoid these negative impacts.
While this involves implementing new processes or practices to identify and prevent the accumulation of TD, some may argue that such processes and practices could vary from domain to domain. In the remaining of this paper, we apply the TD analogy to the engineering of COTS-intensive complex systems as an example, and introduce a TD Taxonomy for the engineering of complex systems. This example context is chosen for convenience, as our previous work, 20,40 demon-strated that there is a compelling need for additional metrics and measurement to enhance the understanding, communicating, analyzing, and predicting of long-term consequences incurred by the use of COTS component.
When organizations adopt commercial technologies-based solutions, they should be aware of possible internal and external factors causing COTS TD that accrue over the system's life span. Introducing commercial products or services may contribute to an increase in TD due to their (often) shorter commodity life spans, and may also be due to the particular environments within which they may need to operate during that life span. Such a notion of TD will raise awareness and special cautions while making procurement commitments, and consequently have a potential to trigger strategic planning in order to mitigate and offset integration surprises and obsolescence issues, and maintain systems reliability, availability, maintainability, and cost-control across all system life cycle phases. 11,41,42 When making COTS/Technology decisions in the context of com- engineering resources are going to be much harder to obtain to "repay" down the TD unless the users "see" and understand the rationale and the motivation to do so. For example, in the defense domain, some TD may be identified by the operational test (OT) team, but it does not necessarily make it important enough to address, unless the users weigh in to obtain resources through the relevant prioritization process. Therefore, the boundary between visible and invisible items for identifying TD items is going to blur in the complex systems context. • A new "Accountability" axis: The engineering of complex systems typically involves multiple organizations, across multiple domains, throughout rather long engineering life cycle. From both a theoretical 43 and empirical 44,45 perspectives, the misalignment of technical structure and organizational structure is a classical problem. Thus, we propose the addition of a new "Accountability" axis (shown to the right of Figure 2) to represent non-technical factors such as legal, diplomatic, political, and ethical issues, which will potentially impose constraints on long-term technical stability. The notion of TD is beneficial for identifying and analyzing root causes of technical issues in light of organization alignment structure. A recent study reported a set of common acquisition framing assumptions identified in three major defense programs, and each framing assumption corresponds with one of the critical root causes that led to significant cost, schedule, and/or performance effects on the program. 46 The identification of policy factors will contribute to the COTS decision trade-space and long-term alignment across multiple organizations and domain expertise to better cope with constraints and uncertainty, which consequently improves accountability. In particularly, when it comes to the discussion on TD repayment, this will facilitate identification of the accountable party and potential resources for repaying a TD. greater challenges on maintainability. Existing methods and models for guiding early COTS assessment activities, such as EPIC, 5 COCOTS, 42 emphasize the importance of thorough analysis and evaluation around these characteristics, in order to support acquisition decision making. However, the compounding effects of these factors on the overall system life cycle, along with system level factors, are largely overlooked in existing TD studies. We conjuncture that the identification and measurement of individual COTS factors will enable the systematic measurement and tracking of COTS evolution, and consequently be able to cope with their compounding effects observable at the system level. • Factors at system level: Existing TD research to date have mostly focused on engineering activities of a single system, and very few methods and tools to support the engineering activities associated with architecting the complex system framework and the acquisition, integration, and test of components/technologies for that framework. Existing research explored methods for estimating the Lead System Integrator (LSI) effort 47 and structural complexity analysis, 48 in order to support cost and risk analysis in defense acquisition. In this research, we propose the addition of system-level factors that drive the cost and benefit of selecting and utilizing commercial components/technologies for the engineering of complex systems. These include: size attributes associated with the number of distinct interface protocols to be provided by the system framework, and the number of organizations that are providing system components that will operate within the system framework; and early-design scale factors such as architecture modularity, component system readiness, integration team capability, maturity of integration processes, and limitations to system evolution imposed by COTS.
The expanded TD landscape offers a complementary but essential perspective for engineering complex systems involving large number of TA B L E 1 The taxonomy of TD in the engineering of complex systems.

Functionality
The degree of functionality mismatch between COTS and system needs.
Hidden cost and risk due to the need to modify and extend COTS to meet specific CPS needs; to mask unwanted COTS features for security concerns.

Performance
The degree of mismatches between COTS and system needs, w.r.t. performance properties.
Hidden cost and risk due to increased need of system modeling and simulation analysis, testing to verify reliability, security, performance, etc.
Interoperability The degree of system modularity, COTS interface complexity, and interoperability among COTS and custom components.
Incurred cost and risk for later integration activities due to integration challenges. The more complex the COTS interfaces, or the higher degree of inter-dependencies between components, the more difficult and more expensive for rework.

Version Conflict
Configuration management planning needs to address COTS refreshing strategy, version conflicts, as well as solution availability plan.
The more COTS elements, the higher frequency of COTS new releasing, the greater risk of this TD.
Documentation support The availability of COTS documentation and vendor support.
Lack of documentation and vendor support will seriously impact on issue resolution related to obsolete COTS.

System evolution
The impact of COTS usage on long-term system evolvability to leverage innovative technologies.
Requirements and design decisions imposed by COTS may place great limitation on system evolution.

Organic
Policy, people, process-centric perspective of TD Focusing on organizational decision-making, behaviors, and practices associated with personnel responsible for introductions of new technologies.
commercial products and services. These known, or perhaps unknown costs, resulting from sub-optimal decisions or policies, can be considered "organizational" debts that will need to be repaid during the later life cycle phases. A few exemplar forms for such debt repayment include planned systems upgrade, systems replacement costs, or in the worst case, defaulted systems. These unaccounted-for programmatic costs may have negative consequences that necessitate funding shifts amongst competing systems developments, to the unforeseen detriment of other planned systems modernization programs.

A COTS TD TAXONOMY FOR THE ENGINEERING OF COMPLEX SYSTEMS
Design decisions that influence longer-term consequences range from good to bad, and can have deleterious effects on missed business opportunities, unmanageable TD, or failure to provide the desired system. 37,49 It is essential that a holistic life cycle approach is carefully considered and scrutinized to reduce the risk in engineering complex systems. Using COTS decisions as an example context, this section proposes a TD taxonomy to guide the identification, analysis, and management of influential factors in key decisions. This taxonomy is derived by mapping and extending existing TD taxonomies to accommodate systems engineering activities and COTS characteristics.
As shown in Table 1, it consists of seven TD types, characterized according to risk indicators during early acquisition phase (e.g., identification, assessment, tailoring, etc.), that may contribute to integration and testing challenges, as well as obsolescence risks in later life cycles (e.g., maintenance, operation, etc.). For each TD type, we provide a description, a brief rationale, along with a list of common antipatterns. In particular, the anti-patterns reflect to common practices that turn out to be misbelief or lack of investigation, and lead to integration and operation challenges reported in two existing studies. 46 More specifically, the example TD anti-patterns are mapped with the identified acquisition framing assumptions, that is, root causes of program challenges or failures 50  Performance TD refers to the mismatches between COTS capabilities and system needs, with respect to quality/extra-functional properties such as reliability (e.g., mainly of hardware), safety assurance (e.g., of software and hardware), and performance in terms of bandwidth, processing capability, memory, etc. This is particularly significant for cases involving the use of COTS products developed for certain contexts, but applied in new contexts with newly expected capabilities, and ultimately found to lack the desired qualities as an outcome. Version conflict TD refers to imposed requirements for upgrading COTS components with respect to its newly released versions by the commercial vendors. Commercial technology vendors typically update their products very frequently (i.e., every 6-12 months), forcing integrators to re-evaluate or re-engineer various aspects of the CPS in order to maintain compatibility and interoperability with current technologies. 11 Keeping up with newer versions of every COTS component is often cumbersome, expensive, and infeasible for developing and maintaining CPS systems. Therefore, a major challenging issue is to strategically refresh COTS versions. 53 The refresh and renewal process for COTS needs to be defined a priori and managed so that COTS updates can be synchronized with each other and the organization's release and business cycles. 23 If the decision is to skip certain newer COTS versions, potential version conflict risks due to complicated inter-dependencies would be introduced, and this may eventually lead to out of sync build dependencies, 54 and/or COTS obsolescence. 3,23 Common anti-patterns include: the assumption of COTS refresh efforts done in a smooth, coordinated way. 50 As an example, in the Condor Cluster, an Air Force supercomputer built out of 1760 video game consoles, the manufacturer upgraded to a newer version and no longer supported the particular previous version, while the Air Force had no means to procure replacement units. 55 Documentation and support TD refers to issues due to unavailable, insufficient, or obsolete documentation/vendor support, especially in the face of maintaining and supporting CPS during the operation lifecycle. In general, most vendors are not supportive of having their product modified. Vendors usually do not support more than two previous releases. As COTS become the primary focus of integration efforts for development and sustainment of CPS, such systems require maintenance and support that exceeds typical COTS vendor support. An anti-pattern is that the assumption of cooperative vendors to jointly customize and stabilize COTS products for extended government use. 50 It is recommended that leveraging partner relationships with COTS vendors to achieve shared goals through innovative contracting, particularly benefit for deep volume discounts and priority service/bug fixes. 23 System evolution TD refers to the inflexibility for accommodating emerging new system functionalities that are required but are out of the initial scope. System requirements imposed by COTS products may place great limitation on system evolution over time. In COTS-based CPS systems, stakeholders may introduce some changes that may contribute to the problem of obsolescence. Candidate COTS-based solutions need to be thoroughly evaluated for imposed architectural sustainability and evolvability limitations. This category represents the third source of unavoidable TD in COTS-oriented CPS context, associated with limitations to system evolution imposed by COTS deficits or rigidity, and may correspond to Foundational TD and Data TD in Clark's taxonomy. An anti-pattern is the assumption that new capabilities can be easily added to meet future needs. 50 Sample framing assumptions include: the JLTA program assumed that the design have effectively assessed long-term versus short-term needs; and the LCS program assumed that new capabilities can be added easily to meet future needs.
Organic TD refers to any combination and degree of technological, systemic, project, and program decisions, behaviors, and practices made by the workforce, management, and/or senior/executive leadership of the organization responsible for introductions of new technologies and systems and/or the sustainment of existing systems. This category assumes that it is possible to create a framework and leadership decision cycle to enable the capability to streamline potentially overbearing acquisition processes while focusing on core critical TD management, processes, and tools that affect systems sustainment supportability, reliability, availability, maintainability, and cost. This is a people-centric category with an organizational perspective as it relates to TD. Common anti-patterns include that: (1) the reliance on commercial initiative/standards to insulate program risk; and (2) government acting as system integrator. The identified framing assumptions include: the APT program assumed that future customers would want to buy the APT with minimal COTS modifications; the JPALS program assumed that COTS/GOTS hardware and software will lower costs; the LCS program assumed that the government is suited to act as system lead integrator; and the SF program assumed an organizational policy that competitive prototyping will reduce risk and cost.

APPLY THE TD TAXONOMY TO THE ENGINEERING OF COMPLEX SYSTEMS
The proposed COTS TD taxonomy is aimed as a starting point for representing, exploring, and improving the visibility of consequences associated with COTS decisions from either the engineering team or program leadership. In general, TD management (TDM) corresponds to a set of activities involving regularly reviewing and addressing technical issues, as well as making informed decisions about trade-offs between short-term and long-term goals. By actively managing TD, it is possible to deal with existing TD to keep it at an acceptable level, and reduce its negative impacts and improve the overall health and stability of a software system. In software engineering field, many researchers have looked into varying strategies, processes, factors, and tools to identify and manage TD in software development. 56 In excelled Agile teams, TD has been increasing used as a metaphor to communicate and manage design trade-offs with both technical and non-technical stakeholders. However, in most teams, refactoring is often overlooked in prioritization and they are often triggered by development crises, in a reactive fashion. 27 Some of the factors are manageable, while others are external to the companies.
With respect to the engineering of complex systems, TDM activities are more complicated, due to greater complexity, inter-dependencies among system components, and much more external factors beyond any single team's control. Many cross-cutting systems issues make it difficult to identify and manage TD due to cross-organizational boundaries. Appropriate guidelines are necessary to clarify possible confusion and highlight cross-cutting issues while identifying, classifying, measuring, and managing TD.

TD management activities
This subsection provides practical guidelines for applying the proposed  56 More specifically, considering to measure a COTS TD item whenever it is identified; the function, performance, and interoperability TD items need to be measured and based on intensive COTS assessment and testing results. We will provide a top-down approach for assessing the cost consequences of TD in the following subsection.

TD prioritization
This activity ranks identified COTS TD items according to predefined rules. Sample techniques to support this activity include trade studies and cost-benefit analysis. 56 More specifically, this activity should be included in major milestone reviews, and involve all success-critical stakeholders as early as possible, for example, user/customer/operating organizations of the to-be CPS system. Usually, not all COTS TD can or should be repaid. Deficiencies and shortfalls almost always exist relative to needs and requirements given that resources are limited and needs are often pressing. Thus, prioritization is essential to inform future actions (or inactions).

TD prevention
This activity aims to prevent certain COTS TD from being incurred.
Example supporting techniques are process improvement, design decision support, life cycle cost planning, early testing, and human factors analysis. 56 More specifically, avoid organic TD through training programs, train COTS assessment team to mitigate or avoid TD items from the first three categories (i.e., functionality, performance, and interoperability), and explore more supportive contracting options with COTS vendors to support COTS maintenance and system evolution to the greatest possible extent.

Representing TD
To support the representation and documentation of COTS TD items in a formal manner, we provide an initial template with 15 attributes grouped into four categories: • General. This includes six attributes: (1) ID: A unique identifier for the COTS TD item; (2) Name: The name of a specific COTS TD item; (3) Location: The location of the identified TD item, for example, the The estimated extra cost of repaying the COTS TD item in the future rather than now, typically spent on maintenance due to quality issues of the system; and (3) Debt probability: The probability that the COTS TD item needs to be repaid (rather than tolerated or accepted for the life of the system). This template is intended for usage in early CPS life cycle phases, for example, design and development of CPS systems. Preferably, the earlier this information is specified, for example, at the start of a new design/development/modernization effort, the more feasible it is to appropriately assign TD monitoring and repayment responsibility within reasonable span of authority/control. This corresponds to a possible means to offset "obsolescence" cost through more informed early design decision making, as well as more pro-active TD management across all system life cycle phases.

6.3
Measuring TD TD can introduce additional risk into a system, as it can create significant cost overhead, performance degradation, security vulnerabilities or weaknesses that may be exploited, leading to a decrease in the overall affordability, reliability and sustainability of the system. Many practitioners want tools and mechanism to measure the TD for their projects. However, it is recognized that measuring TD is not easy because its impact is not uniform. In the scope of this paper, we will focus on the assessment of COTS TD in monetary cost under uncertainty. Other forms of TD consequences such as performance shortage or security vulnerability should be evaluated with specific tools for intensive testing, which is out of scope of discussion here.
In  another TD attribute, that is, contagion. Presumably, the more contagious the TD is, the higher its interest probability could be since the TD will accumulate at a faster pace and/or to a broader extent. However, it is very challenging and risky to come up with a one-size-fits-all metric for this. Based on our experience in parametric cost modeling,  Figure 4), and the productivity ranges according to the involved cost driver inputs, following Equation (2). In the equation, Risk prob _ i,j corresponds with the nonlinear relative probability of the risk occurring, and the product of PR i and PR j represents the cost consequence of the risk occurring. More specifically, each axis in Figure 4 is the risk potential ratings of a cost factor. A risk situation corresponds to an individual cell containing an identified risk probability. In this step, risk rules use cost driver's risk potential ratings to index directly into these tables of risk probability levels. The productivity range of each cost drivers represents the cost consequence of risk occurring, as summarized in the last column of Figure 3.
There are several reasons that we believe such an automatic, riskbased methodology is practical to enable quantitative measurement of COTS TD items technique. First, cost estimation models incorporate the use of cost drivers to adjust development effort and schedule calculations and reduce estimation subjectivity. As significant project factors, cost drivers can be used for identifying and quantifying project risk. Second, such cost estimation inputs are readily available during the acquisition phase. As an example, COCOTS has been integrated into several commercial estimating tools widely used in the defense domain. 59 Third, an existing COCOTS risk analyzer tool can automatically obtain a COTS integration risk analysis with no additional inputs other than the set of COCOTS glue code cost drivers inputs, which were prepared to derive the COTS integration effort estimates.
If multiple COTS TD items exist, the above measurement methodology may be applied in a bottom-up approach to derive the aggregated system TD projection according to the product breakdown structures in candidate design alternatives, and further aid the TD-aware comparison across multiple alternatives. In particular, when a system transits from development phase to production, the TD communication offers an effective way to provide context about policy and technical decisions made in earlier development phases, as well as potential projected long-term TD concerns. In another word, it enables a systematic flow of risk information across life cycles, to allow more effective program management.

Discussion
The engineering of complex systems usually involves multiple acquisition, engineering, test and evaluation, and maintenance teams or organizations. It is essential to nurture the TD-aware culture across multiple collaborative systems engineering teams. This will help to facilitate balanced communication, discussion, and decision making to address the tension between anticipated short-term benefits and longterm manifested TD issues. TD-aware culture refers to the attitudes and behaviors within or cross-boundary organization(s) regarding the management of TD. This promotes the timely synchronization, continuous transparency, and effective ownership of TD management, in order to decrease potential negative TD impact throughout the systems engineering life cycle.
It is important to make TD management a priority within the organi- of the system where TD may be accumulating. It is essential to seek diverse inputs from these team members as part of the processes of identifying and managing TD in order to better aligned long-term goals across teams.

CONCLUSIONS
As systems engineering competencies and practices grow, the compelling and critical need for a Systems Engineering TD metaphor grows as well. Acquiring and integrating commercial products may contribute to increase TD, due to their relatively short commodity life spans, and the consumer environments within which they may operate during that life span. Offsetting "obsolescence" to reduce performance risk and maintain systems reliability, availability, maintainability, and costcontrol is an underpinning competency of systems engineering, with importance across all system life cycle phases.
Using COTS-intensive complex systems as an example context, this chapter adapts the metaphor of TD, introduces a COTS TD taxonomy, and discusses how to cope with COTS TD, and establish the TD-aware culture, in order to support early identification, communication, and assessment of obsolescence risks in CPS system engineering life cycles.
The seven TD types providing the greatest insight into obsolescence mitigation include COTS functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic. This provides a foundation and a way of articulating tradeoffs between resolving issues now against living with degraded system performance later, yet leaves flexibility for promising future work along several dimensions. It is expected that such notions of TD can help to increase the efficiency, effectiveness, and accountability of complex systems, through promoting and embracing TD-aware culture and practices in the acquisition process.

DATA AVAILABILITY STATEMENT
Data sharing is not applicable to this article as no new data were created or analyzed in this study.  He holds a BS in engineering from UCLA, specializing in computer engineering.