An Obsolescence Management Framework

Regular Paper
An Obsolescence
Management Framework
for System Baseline
Evolution—Perspectives
Through the System Life
Cycle
Tom Herald,1, * Dinesh Verma,1 Caroline Lubert,2 and Robert Cloutier1
1
School of Systems and Enterprises, Stevens Institute of Technology, Hoboken, NJ 07030
2
Department of Mathematics and Statistics, James Madison University, Harrisonburg, VA 22807
AN OBSOLESCENCE MANAGEMENT FRAMEWORK FOR SYSTEM BASELINE EVOLUTION
Received 13 November 2006; Revised 27 February 2007, 23 September 2007, and 22 March 2008; Accepted 22
March 2008, after one or more revisions
Published online 4 August 2008 in Wiley InterScience (www.interscience.wiley.com)
DOI 10.1002/sys.20106
ABSTRACT
In military, civil, and commercial systems there exists a need to affordably manage the
operational effectiveness of the system of interest through the acquisition and operational
stages of its life cycle. Once a system design is baselined and instantiated, then the challenge
during development, production, and utilization life cycle stages is to maintain the currency
of the physical system baseline to facilitate affordable system support. In essence, the system
must adapt to potentially frequent asynchronous obsolescence of its constituent elements,
requirements growth (driven by the operational environmental and external constraints such
as funding, schedule or risk), and external environment changes. This paper specifically
addresses the impact that system element obsolescence has on a system baseline during the
various system life cycle phases and provides a framework for affordable system evolution.
*Author to whom all correspondence should be addressed (e-mail:

[email protected]).
Systems Engineering Vol. 12, No. 1, 2009

© 2008 Wiley Periodicals, Inc.
1
2 HERALD ET AL.
Literature search and consolidation has articulated six integral components that comprise a
comprehensive evolution framework through bottoms-up obsolescence management of con-
stituent system elements. Each of the obsolescence management components is tangibly
addressed in terms of each system life cycle phase and the available tools and methods.
Additionally, each of the obsolescence management framework components is analyzed for
life cycle phase applicability and then extended further with the criticality and type of analysis
to be done for that life cycle phase. In this way, a project can determine which studies to
perform, while in a specific life cycle phase, that maximizes the insight of impending obsoles-
cence for a particular system. © 2008 Wiley Periodicals, Inc. Syst Eng 12: 1–20, 2009
Key words: obsolescence management; framework; technology roadmapping; system costing;

obsolescence forecasting; trade study; product selection; product surveillance; health assess-
ment; technology transition; DMSMS
1. INTRODUCTION Obsolescence is defined herein to represent when a

part (hardware, software, constraint) is no longer able
Military, civil, and commercial systems are increas- to perform its required function such as; availability for
ingly characterized by capabilities and functions that purchase or ability to be repaired affordably. Obsoles-
are highly diverse, ubiquitous, distributed, and continu- cence, therefore, includes Diminishing Manufacturing
ously available. With an increasing trend towards the Sources and Material Shortages (DMSMS), technology
use of commercial technology and reusable platforms evolution, and any reason that a part is no longer viable
in the design and development of such systems, there within the system baseline. A system baseline repre-
exists a need to affordably manage the operational sents a tangible articulation of a specific system solu-
effectiveness of a system through its development, option. The causes that force a system baseline to change
erational and retirement life cycle phases [Verma, Her- are varied and include: obsolescence of the constituent
ald, and Knezevic, 1997; Verma and Plunkett, 2000; elements that make up the system, requirements growth
(which may result from environmental changes or
Defense Acquisition University, 2001]. Operational Ef-
changes in external constraints such as available fund-
fectiveness is depicted in Figure 1 and accounts for the
ing, schedule, or risk), and possible regulatory changes.
technical effectiveness of the design which includes
This paper proposes an obsolescence management
both the defined performance and its inherent availabil- framework that allows the systems engineer to deter-
ity, the process efficiency of the accompanying support mine when system components should be changed as a
system that drives the operational availability, and the result of obsolescence and what those changes should
affordability of the overall system solution across the be in order to sustain the operational effectiveness of
required operational life cycle. The supportability input the system in an affordable manner throughout the
of inherent availability shown in Figure 1 is dependent system lifecycle. The framework addresses the support-
on the availability of the parts. When a part is no longer ability and total ownership cost aspects of Figure 1. This
supportable, it directly impacts obsolescence of the research extends traditional obsolescence management
system. approaches which typically predict obsolescence at the
Figure 1. System operational effectiveness.
Systems Engineering DOI 10.1002/sys

AN OBSOLESCENCE MANAGEMENT FRAMEWORK FOR SYSTEM BASELINE EVOLUTION 3
individual component level or, worse yet, wait until the search has progressed to determine an optimized cost
system baseline is no longer supportable. These fail to effective point for changing the production baseline
address the consolidation of system component analy- configuration due to impending or current obsolescence
ses that are critical to optimize the system-level opera- [Solomon, Sandborn, and Pecht, 2000; Singh et al.,
tional effectiveness. 2004]. Deciding when to change a system baseline or
The Assistant Secretary of the Navy in the United product during development, production or during the
States published a Memorandum for Distribution extended operational life cycle phase necessitates atten-
[Young, 2005: 2] on system support and evolution tion to a set of obsolescence management aspects. The
planning which requires each new program to: “Man- extension of this system evolution production concept
age obsolescence at the piece part level for all active into the system support life cycle phase (or utilization
microelectronics. Bill of Material data can be used by stage per ISO/IEC 15288 Annex B) [ISO/IEC 15288,
program offices and contractors to effectively mitigate 2002] is even more critical where the life cycle mis-
obsolescence risk.” This memorandum requires ad- match between the required operational life of the sys-
dressing part obsolescence in a proactive way and fur- tem and the relatively short life of its constituent
ther inspires two discussions: Why was the elements is more pronounced. This mismatch is often
memorandum necessary and why does it address sys- on the order of 10:1, such as for Information Technol-
tem obsolescence at the component-level (only a bot- ogy systems with long operational life cycles [Seibel,
toms-up perspective)? First, it encourages proactive 2005; Herald and Seibel, 2004] of 20–30 years versus
management of obsolescence versus a “wait and see” the relatively short product life cycles of 2–3 years. For
approach that focuses on point-solution support and a large integrated system, asynchronous obsolescence
reaction to an obsolescence event. Reacting to an obso- events create an ongoing system effectiveness risk.
lescence event after it has already occurred, often re- The need for system evolution management result-
quires more cost to rectify, and takes on the risk of ing from obsolescence is well established; yet a frame-
system downtime which jeopardizes operational sched- work1 for performing this evolution management
ules. For the second question, from a practical stand- comprehensively and affordably requires articulation.
point, the memorandum is needed at some level of the The framework includes a spectrum of six independent
system hierarchy for management of obsolescence, and integral components to logically evolve the system
the current, industry-available, recommended tools di- baseline through the desired life cycle (system concept,
rectly support component-level obsolescence manage- development, production, utilization, support, and re-
ment. This memorandum provides insight and guidance tirement) and to effectively manage asynchronous ob-
for obsolescence management of microelectronics and solescence events (of the system elements). The
other information technologies which are indeed the evolution is expected and intended to continue through
faster moving elements of most system solutions and to system retirement.
thus require the most critical attention. Therefore, using
electronics as a starting point, a system-level analysis
should also perform this same level of Diminishing 2. SYSTEM OBSOLESCENCE
Manufacturing Sources and Material Shortages MANAGEMENT FRAMEWORK OVERVIEW
[DMSMS, 2005] rigor for the other technologies within
the physical system solution (i.e., hardware, software, 2.1. Literature Summary
infrastructure and networking, external interfaces, etc.).
A strong systems engineering framework must be adap- In order to establish the integral components of this
tive for a range of simple to complex systems and for Obsolescence Management Framework (OMF), rele-
each of the various system hierarchical levels [Shenhar vant literature was searched and categorized. The re-
and Bonen, 1997]. search suggests six components that encompass the
Charles Fine [Fine, 1998: 119] effectively indicates obsolescence management of subsystems, system ele-
the importance of the supply chain design in order to ments, and components that constitute a system of
handle the asynchronous barrage of changes to a prod- 1
Framework \Frame"work‘\, n. The development of a good frame-
uct while it is in competitive production. A business
work takes into account the importance of separating elements of a
must decide when to change the product baseline (i.e., group into subgroups that are mutually exclusive, unambiguous, and
re-initiate a life cycle for a new product design) in order taken together, include all possibilities. In practice, a good framework
to avoid obsolescence of the parts that make up the is simple, easy to remember, and easy to use. Zachman describes a
framework as a logical structure intended to provide a comprehensive
product and also to maintain competitive advantage and representation that is independent of the tools and methods used.
market share. At the University of Maryland Computer Sources: Webster’s Revised Unabridged Dictionary (1913) and
Aided Life Cycle Engineering (CALCE) Center, re- [Zachman, 1987].

4 HERALD ET AL.
interest. These components each have significant re- useful decision information for the systems engi-
search support resulting in recommended practices and neer.
tools. Variations are also noted in the implementation 6. Technology Transition (TT) takes the informa-
of each component, such as applicability and criticality tion from the Technology Roadmaps of known
in each life cycle phase and the availability of models technologies, and combines this with emerging
and tools. These components are the focus of this paper, technologies to formulate a maturity metric for
are briefly defined here, and then are discussed in more the technologies (and their associated products)
detail in subsequent sections. evolution status and its potential usefulness to the
system. TT encompasses three areas of research:
1. Technology Roadmapping (TR) uses technol- • Technology Transfer Process Description to
ogy data and constraints from commercial, civil, evolve a technology from an early stage im-
research, and military providers to formulate a mature level that is not readily usable in sys-
projected evolution path for existing, system- tem solutions.
relevant technologies through the system life cy- • Effectiveness Measures to assess the technol-
cle. TR represents a relatively near-term (0- to ogy maturity.
5-year view, and sometimes up to a 10-year view) • Transfer Methods to migrate the technology
technology or product-specific horizon. from concept to practice such that it becomes
2. System Costing (SC) leverages the insight from a useful contribution to solutions.
Technology Roadmapping and applies cost to
technology (and product) evolution across acqui- 2.2. Obsolescence Management
sition, production, and support life cycle phases. Framework Systemigram
Per Figure 1, SC is a key to optimizing technol-
ogy change decisions and includes acquisition In order to place these six obsolescence management
and life cycle cost (LCC) for a total ownership components into an OMF, the format of a Boardman
cost (TOC) understanding. Soft Systems Model Systemigram [Boardman and
3. System Obsolescence Life Cycle Forecasting Cole, 1996; Clegg and Boardman, 1996; Sagoo and
(SF) uses the technology roadmaps and cost as- Boardman, 1998] is used. The interrelationships of
sessments to formulate a predictive forecast of these technology obsolescence management compo-
WHAT system elements need to change due to nents are shown in Figure 2 and describe the activities
obsolescence and WHEN throughout the system necessary through a system life cycle due to the obso-
operational life cycle. SF has applicability for lescence of its constituent parts. The term system is
each tier of the system hierarchy from the lowest being used here in the most general sense to encompass
level of procurement. This represents a 20–50+ from subassemblies through system-of-systems, since
year life cycle view in support of TOC under- all levels may realize obsolescence over time. Figure 2
standing. For example, the F-35 Lightening II shows inputs as dark gray circles, OMF components as
multiservice and multinational piloted fighter light ovals, and the systemigram output is the dark oval
aircraft is projecting a 30+ year production and constituting the system baseline change recommenda-
an airframe life cycle of 30 years. Thus the pro- tion.
gram life cycle easily surpasses a half century. Technology and cost data are input and transformed
The US Air Force B-52 aircraft is projected to into information (understanding relationships) and are
extend its life cycle to 90 years! then analyzed for system change knowledge (under-
4. Technology Trade Study Analysis and Product standing patterns). [Fleming, 2004] The starting points
Selection (TS&PS) uses the forecasted system for the OMF data are into the TR, TPS&HA, and TT
baseline change needs (due to obsolescence) to components with inputs from product providers, acade-
identify the available solution trade space for mia, laboratories, and research as shown by the dark
each need, to analyze the tactical technology shaded circles providing inputs to the systemigram in
options, and to select the products to deploy. Figure 2. When available, information from TPS&HA
5. Technology / Product Surveillance and Health is also fed to SF and TS&PS, which then uses these data
Assessment (TPS&HA) addresses the ongoing to formulate change information that will support the
surveillance of the system configuration, related systems engineer with trade studies and product selec-
technologies, and then formulates a system tion for TS&PS. While the outputs of each OMF com-
health assessment that is used to recalibrate SF. ponent have specific value, the dark gray oval of Figure
TPS&HA monitors the ongoing product road- 2 represents the integration of this information to pro-
maps and maturity assessment data to formulate vide a system-level baseline change recommendation

Figure 2. Obsolescence management framework systemigram.
(output of the systemigram). This resultant knowledge 1. Concept—Perform initial need recognition and
permits sustaining a given system in an affordable explore alternatives with fact-finding that seeds techni-
manner through its operational life cycle. cal and economic feasibility analysis.
The systemigram in Figure 2 highlights the what to 2. Development—Transform system requirements
do for OM; however, there are also perspectives for into one or more feasible solutions, i.e., system design.
when and how to do OM through the system life cycle. 3. Production—Produce, assemble, integrate, test,
Section 3 takes the six components of the OMF and and certify, as appropriate, each system individually.
discusses each in accordance with its relationship to 4. Utilization—Operate the product or system at the
each life cycle phase (i.e., when to do OM) and offers a planned operational locations providing the desired
system capabilities. Utilization represents the user per-
sampling of current commercial, governmental and
spective.
academic capabilities tools and methods for imple-
5. Support—Maintain the system, and provide lo-
menting each (i.e., how to do OM).
gistics. Support represents the system viability perspec-
tive and is temporally coincident with the Utilization
2.3. Life Cycle Phases Mapped to OMF stage.
Components 6. Retirement—Dispose of the system with consid-
erations relating to environmental effects, contamina-
As a point of reference, the components of the OMF tion, and other hazards.
will be viewed from each life cycle phase as articulated
in ISO/IEC 15288 [2002] for determination of applica- There are two dimensions to consider when placing
bility and criticality. The life cycle phases described in the six OMF components against the six life cycle
the ISO/IEC 15288 are: phases. The first dimension is time; i.e., when does a

6 HERALD ET AL.
Figure 3. Applicability of the obsolescence management framework components.
particular OMF component have applicability? The torola chairman and widely considered as the father of
second dimension is criticality of the OMF component the practice of TR [Schaller, 2004]:
at each point in the program life cycle. The criticality
provides insight into how the OMF component should Roadmaps communicate visions, attract resources
be applied. Each OMF component is not necessarily from business and government, stimulate investiga-
tions, and monitor progress. They become the inven-
applicable in every life cycle phase. Therefore, to no-
tory of possibilities for a particular field, thus
tionally appreciate where each of the OMF components
stimulating earlier, more targeted investigations.
has applicability through the life cycle of a particular
system, refer to Figure 3. Notice in Figure 3 that there Roadmapping is usually a subjective exercise that
generally exists some degree of applicability beginning balances possible futures with likely and advantageous
late in the Concept phase and continuing through the futures [Kappel, 2001]. Technology roadmapping de-
program life cycle until system retirement. tails an understanding of both the evolution of specific
Section 3 provides discussion of the timing, analysis technologies and the potential solutions for a specific
types, and the degree of criticality of each OMF com- need. Literature describes a variety of roadmap appli-
ponent through each of the identified applicable life cations such as; science and research, cross-industry,
cycle phases. industry, technology, product, product-technology, and
project/issue [Kostoff and Schaller, 2001]. From these
3. OMF DETAILS AND LIFE CYCLE applications, two perspectives of roadmaps process im-
MAPPING plementation become evident, technology-push and re-
quirements-pull. These two roadmap perspectives are
The OMF provides the integral components of what fundamentally different in that technology-push starts
must be done through the life cycle in order to sustain with existing research and products and “looks for-
the viability of the system operational effectiveness. ward.” The output of a technology-push approach is a
Further scrutiny of the literature reveals that the ap- Product Technology Roadmap [Garcia and Bray, 1997;
proaches and tools may vary depending on the particu- Kappel, 2001]. A product roadmap starts with the solu-
lar life cycle phase. This section discusses the criticality tion (product) and forecasts it from that point, with the
of each OMF component in the various life cycle needs for this product yet to be defined.
phases, as well as providing a sample of available In contrast, the requirements-pull perspective starts
implementation capabilities and tools. with a desired end product, and searches for solutions,
technologies, and products (i.e., looking backward) that
potentially meet the desired need. The product of the
3.1. Technology Roadmapping (TR)
requirements-pull activity is an Emerging technology
The purpose for technology roadmapping is stated by roadmap [Garcia and Bray, 1997]. Although the two
Robert Galvin [Galvin, 1998], who is a former Mo- types of roadmaps are in some ways opposites, both are

of value to the system designer depending on what and remains high through the utilization and support
problem is being solved and at which life cycle phase phases. The reasons for this criticality involve both
the project currently resides. The primary focus of maintaining the affordability and consistency of the
literature is on hardware roadmapping, and in particular baseline for the production phase. During utilization,
for electronics components. However, the same process the user is interested in satisfying the functional needs
approaches can be applied to software, assemblies, and for the employed concept of operations, and it is the
systems. A system-level perspective would require this emerging roadmaps that allow for injection of innova-
TR attention for all critical system parts. tion (often referred to as technology insertion). During
Product Technology Roadmap. Product technol- the support phase, the impact of obsolescence is most
ogy roadmaps start with a given solution and are driven critical and demands a detailed vision of how each
by product and process needs. These might include the technology in a given system baseline is evolving, so it
evolution of an ATM bus or projecting a roadmap for is the product roadmap that is of greatest interest for
memory density advancement as Gordon Moore, Chair- sustaining the functional capability. Finally the retire-
man Emeritus of Intel Corporation, first did [Tuomi, ment phase represents a low criticality for TR, account-
2002]. These roadmaps are focused on transitioning the ing for a few considerations such as recycling and
existing products through their respective product life re-use. At this point, transition is back to the emerging
cycles to best understand when and how the products roadmap for disposal. This summary is consolidated
might change. These roadmaps strive to accurately pre- and depicted in the Technology Roadmapping (TR) row
dict the detailed evolution of the product both in terms of Figure 4.
of growth within the product line, and anticipated tech- The impact of ignoring TR is directly proportional
nological evolution. The roadmaps document a vision to the ability to confidently make appropriate business
that drives more focused company research. This accu- decisions (schedule, affordability, and functionality)
racy is a prime concern so the product roadmaps often throughout the system life cycle. Without this technol-
have a horizon of only five years to sometimes 10 years ogy and product-level insight, the decision to change or
for slower moving technologies. evolve a system is difficult to render and substantiate.
Emerging Technology Roadmap. The emerging Available Roadmapping Tools and Methods.
roadmap is driven by a need versus a predefined solu- Based on foundational work from both Sandia National
tion. For example, if there exists a need for energy Laboratories [Garcia and Bray, 1997] and the leader-
efficient vehicles, then possible solutions might include ship and coordination of the Center for Technology
lightweight composite materials, Toyota’s Hybrid Syn- Roadmapping (CTR) at Purdue University [Duckles
ergy Drive system [Toyota, 2005], alternative natural and Coyle, 2002] the development and implementation
gas engine, or low-friction axles. Emerging technology of a tool called Vision Strategist [Alignent, 2008]
roadmaps identify possibilities and provide a path to emerged. This tool allows for the capture and visuali-
identify, evaluate, and select technology alternatives zation of tactical information regarding specific tech-
that can be used to satisfy an identified need. nologies and begins to fulfill the intent that Robert
These two TR approaches have varying applicability Galvin articulated. There are many approaches from
depending on the particular life cycle phase of the various industries such as for computer electronics and
system. Early on in the concept phase, an emerging memory, all with the goal to forecast “what could be
technology roadmap is useful to identify the opportuni- and what should be possible.”
ties that exist for meeting a particular need. Of interest
here is open-minded alternative identification where the 3.2. System Cost Analysis (SC)
criticality of performing this analysis rigorously is low
in the beginning but grows to medium as the set of In performing any system evolution that occurs during
possible solutions emerges. Then the roadmapping any of the life cycle phases, it is almost always the case
method begins to transition from an emerging technol- that a financial analysis is part of the system change
ogy approach to a product approach as the solution decision. The life cycle cost analysis should be included
space is narrowed to viable candidate technologies. In in each system baseline change decision. What is often
the development life cycle phase, more detailed under- not so clear is which costs to include in this analysis?
standing of each potentially applicable product is nec- There are many ways to look at cost; four categories of
essary in order to render a proper selection of the cost analysis are considered in this OMF component:
baseline technology and eventually the product selec- Procurement cost, Acquisition cost, Support cost, and
tion. For this insight the product roadmap is most effec- Total Ownership Cost (TOC). These costs include the
tive. The criticality of understanding the system design, purchase, support, and disposal of the hardware
baseline technologies is high when production begins, and software system elements of a particular system

8
HERALD ET AL.

Figure 4. Obsolescence Management Framework (OMF) mapped across the system life cycle phases.
through its whole life cycle. There are other cost con- When performing a system baseline evolution a
siderations such as social and environmental impact comparative understanding of which costs are critical
costs that may result from improper disposal (such as is dependent on the particular life cycle phase, program
ozone depleting gases or ground contaminating leak- goals, and desired affordability. The criticality of per-
age); however, these costs are outside the scope of this forming a cost analysis is shown on the System Cost
system-centric OM framework. row in Figure 4.
Procurement cost. This is the easiest cost to come In the early concept phase costing is of low impor-
by for purchased commercial items since it is the cost tance, as the system alternatives are defined. However,
paid to receive the product. A second consideration is when it comes time to cull the list of potential candi-
for developed items and in this case the procurement dates down to solidify the initial design baseline, then
cost is generally the cost to make an additional copy, costing increases quickly to high critical importance.
i.e., catalog price. Once these data have been gathered and used to estab-
Acquisition cost. This represents the cost to instan- lish the system baseline, then costing tapers off to a
tiate a system baseline. Acquisition includes design and moderate criticality through production and support
development costs, procurement and material costs, due to the nature of incremental changes being easier to
manufacturing labor costs, and, finally, testing costs. perform. The utilization phase is represented by user
This is often described as the cost to design, build, and analysis of “what if” technology comparisons and the
test a stand-alone system solution. The decision to enter TOC are of greatest criticality. In the support phase,
the production phase often hinges on a mutually agree- there are elements of support and redesign for obsoles-
able acquisition cost. cence; thus all cost elements come into play as critical.
Support cost. This cost has relevance once a system Interestingly enough, the disposal phase is often viewed
is instantiated. Support cost includes all elements of as low risk; however, with emerging environmental
cost that are necessary to keep the system operational considerations such as pollution, ozone reduction, nu-
for the desired operational life cycle. There are varying clear waste, and recycling, the cost analysis returns to
perspectives on what cost elements should be included a moderate criticality to support the disposal alterna-
in support. There are the traditional logistics cost ele- tives of the system.
ments such as spares, repairs, maintenance, and annual Available System Costing Tools and Methods.
software license maintenance that are typical for per- There are many costing capabilities from a low com-
forming operational support of a system. There are also plexity spreadsheet-based capability to highly inte-
cost elements for operational resources such as fuel, grated and widely used market tools such as the Price
pilots, and support equipment. The decision on which Systems tool suite (H for hardware, S for Software, HL
elements to include is one that must be made and agreed for Logistics, True S, and True COCOMO) [Price Sys-
upon for each program. As an example, the US Air tems, 2008], SEER tool suite (SEER-SEM, SEER-SSM
Force uses the Office of the Secretary of Defense (OSD) and SEER-AccuScope for Software, SEER-H and
Cost Analysis Improvement Group (CAIG) [OSD, SEER-IC for Hardware and Life Cycle, and SEER-
1992] recommendations for the elements of cost in DFM for Manufacturability) [Galorath, 2008] and In-
military aircraft system support. tegrated Desktop Analysis and Planning System Cost
Total Ownership Cost (TOC). This is the easiest Estimation Tool (ICE) used primarily by the US Air
cost to describe and very often the hardest cost to Force [Frontier Technologies, 2008]. A new systems
calculate. In short, TOC represents all costs for a system engineering cost estimation tool is emerging on the
from the time it is conceived until the time it is formally market: The Constructive Systems Engineering Cost
retired and disposed of. The reason that this cost is very Model (COSYSMO) is being offered through the Lean
hard to put together and estimate is because TOC in- Aerospace Initiative (LAI), which is affiliated with the
volves design, development, production, operations, Massachusetts Institute of Technology. COSYSMO is
support, and disposal costs. These come from many available through three existing commercial cost esti-
varied funding sources with varying accounting prac- mation suites, PRICE Systems’ TruePlanning suite,
tices and different cost roll-ups. While consolidating all Galorath’s SEER suite, and SoftStar System’s System-
these cost elements sounds like a trivial summation, the Star is a commercial version of the COSYSMO re-
challenging part is finding and compiling the accurate search. “COSYSMO helps large corporations pinpoint
numbers to ultimately sum together [Mandelbaum and systems engineering costs that are factored into plan-
Pallas, 2001]. Perspective constitutes an additional ning and executing large system projects. The tool
complexity when determining the TOC. The perspec- provides an objective approach for government agen-
tives may include a user, a provider, and a paying cies to evaluate proposals.” [Valerdi, 2008, 2005] The
customer and will likely result in varying definitions. costing capability that best matches the needs of a

10 HERALD ET AL.
particular system should be selected, consistently im- subgroups: electronics component obsolescence, as-
plemented, and the decisions for evolution should lev- sembly obsolescence, and system life cycle manage-
erage the analyses. ment focused capabilities. Each subgroup’s capabilities
Although not yet available, work at the University (and associated tools) attacks a different part of the
of Southern California is focused on a Constructive challenge; therefore, a worthy system solution should
Cost Model for System-of-Systems Architecting and consider a combination of capabilities in order to fully
Integration (COSOSIMO). This extension is striving to manage the system.
climb up the system hierarchy to support cost analysis The first of these subgroups, electronics component
at the very top of a complex system of systems [Lane, obsolescence, addresses the lowest level of electronics
2006]. such as the resistor, capacitor, and ASIC [Huang et al.,
2001]. This capability most often uses marketing data
3.3. System Obsolescence Life Cycle analysis as the mechanism for determining current and
Forecasting (SF) projected product maturity. [MacNulty, 2002; Pecht,
As evidenced by the Assistant Secretary of the Navy 2003; Meixell and Wu, 2001; Sandborn, Mauro, and
Memorandum [Young, 2005: 2], the need for planned, Knox, 2007] Some commercial tools also take the next
affordable system evolution due to the effects of obso- step and strive to provide recommendations for replace-
lescence is a critical concern in the support of military ment of the particular part that has gone obsolete (ide-
systems (from small hand-held devices to large-scale ally this would include a pin-for-pin compatible
network-centric system of systems). Whenever the op- replacement part that can plug right in without any
erational need of the system exceeds the life cycle of system impacts). This insight provides the opportunity
the products that make up that system, this life cycle to proactively rectify the impending obsolescence—
mismatch becomes a concern to the user community of often with 30–120 days notice. Commercial tools that
that system. This concern is by and large simple in fall into this category include: Q-Star [QTEC, 2008],
concept: Provide affordable operational effectiveness TACTRAC [i2 Technologies, 2008], DNBi Supply
[Verma, Herald, and Knezevic, 1997; DAU, 2001]. Management [D&B, 2008], Parts Plus [Total Parts Plus,
Once a system has been designed and instantiated in 2008] and Advanced Component Obsolescence Man-
accordance with an operational effectiveness focus, agement (AVCOM) [MTI, 2008], which is the preferred
then the challenge during the production, utilization, solution for the US Air Force. These component-level
and support life cycle stages is to maintain the system tools are a necessary part of the obsolescence frame-
functionality through affordable evolution [Tiku, work in that they each focus on the next obsolescence
2005]. event forecasting for various segments of changing
The obsolescence forecasting component of the electronics.
OMF addresses the need to evolve a system in order to The second subgroup considers assembly-level ob-
keep it producible and operationally viable. This in- solescence capabilities. The focus is on managing an
cludes all hardware and software system elements. The assembly which is made up of hardware components.
criticality of performing this forecasting in the concep- An assembly will be manufactured, utilized, and sus-
tual phase is moderate in the early concept phase, but, tained. Thus during these life cycle phases, it will be
as the technologies and products are narrowed down to critical to make decisions such as: When is the optimal
a small feasible set, the criticality of performing obso- time to change the system baseline during production,
lescence forecasts becomes critical. During the devel- or when is the optimal time to change the system
opment phase, the decisions rendered for technology baseline during operations and support? In order to
and product selection in establishing the system base- proactively answer these questions, it is necessary to
line will in large part define the affordability of the understand the obsolescence first at the component-
system for the remainder of its use. Therefore, visuali- level and then aggregate the results to understand the
zation, understanding, and forward planning are neces- impacts at the assembly level. Assembly-level analysis
sary from this point through the majority of the support builds directly on the electronics component-level tools
phase. As the support phase winds down and then and performs the aggregation and optimization of
through the retirement phase, obsolescence forecasting change recommendations. In fact, some of the industry
is no longer critical at all. The summary of System capabilities such as Mitigation of Obsolescence Cost
Obsolescence Forecasting through the system life cycle Analysis (MOCA) from the University of Maryland
is shown in Figure 4. [CALCE, 2008; Sandborn and Singh, 2006; Sandborn
Available Obsolescence Forecasting Tools and et al., 2003; Singh et al., 2004; Solomon et al., 2000;
Methods. These capabilities are broken down into three Pecht et al., 2002] take the output of tools such as

TACTRAC or Q-Star as inputs to the assembly-level across the desired system-level life cycle for each ele-
aggregation and optimization. ment in the system of interest.
Further extensions of assembly-level analysis are There is currently a published capability that sup-
available such as the Obsolescence Management Infor- ports system analysis criteria, the Rapid Response
mation System (OMIS) [NUWC, 2008] from the Naval Technology Trade Study, R2T2 [Herald and Hertz,
Undersea Warfare Center Division in Keyport, WA. 2004; Herald and Seibel, 2004; Herald, 2003] capabil-
OMIS employs an interesting combination of compo- ity is being jointly evolved with Lockheed Martin and
nent-level, system-level and configuration management Stevens Institute of Technology. This particular tool
analyses. Like MOCA, OMIS takes the output of Q- strives to support the systems designer and architect
Star and similar tools as the input for the higher assem- with a capability to forecast system obsolescence across
bly analysis. In addition, OMIS provides the user with the desired life cycle and allow for comparisons to
an interactive graphical interface. For example the hi- alternative solutions. Once a particular solution is se-
erarchical graphics allow the user to pictorially drill lected, then a life cycle obsolescence plan is docu-
down from an aircraft level, to the avionics system, to mented for the elements (hardware, software, etc.) that
a specific avionics subsystem, to the assemblies that will require refreshment and at what points in the life
make up that avionics subsystem, and finally to the cycle these refreshments should occur. The selected
components that make up those assemblies. This visi- frequency of change can be varied to that which
bility of component-level obsolescence is useful for matches program requirements, or it can be optimized
identifying the impact of a particular obsolescence for affordability as desired.
event across a full system implementation. The output
is presented as an aggregation of the health status of all 3.4. Technology Trade Study Analysis and
the components represented at the hierarchical level of Product Selection (TS&PS)
interest.
The third subgroup of commercial obsolescence This component in our OMF is rich with decision
forecasting capabilities is system life cycle obsoles- analysis approaches to directly support the comparison
cence management. This subgroup is distinguished by and final selection from various solution options. Mi-
two significant extensions over the previous two sub- chael Pecht [2003] offers a summary of approach meth-
groups. The first is to extend the analysis from the next odologies particularly for the component-level
obsolescence events (or current obsolescence events) discussed earlier. Although primarily focused on elec-
prediction to a full life cycle perspective. In this way, tronic components (resistors, diodes, and integrated
financial planning, technical planning, and costing can circuits), these same principles and similar assessment
be more accurately estimated for a life cycle schedule criteria [Pecht, Syrus, and Humphrey, 2001] have ap-
with forecasted obsolescence event points. The second plicability up through the system hierarchy and can be
extension is the independence from component-level adapted for hardware and software, whether they are
data, thus allowing any level in the system hierarchy to COTS or developmental items. The point of this com-
be analyzed. This independence allows for all system ponent is to support a methodical approach to whittling
elements to be included in the analysis versus electron- down the list of reasonable and competitive products
ics component hardware only. Thus software, firmware, for a particular system application. Criteria for product
commercial-off-the-shelf (COTS), developed items, as selection include [Verma et al., 1996; Verma and Johan-
well as electronics component hardware products can nesen, 1999]:
now be aggregated into the system analysis for a thor-
ough system life cycle perspective [Sandborn and • Performance and Functionality
Plunkett, 2006]. The system life cycle obsolescence • Cost (Acquisition, Support, Licensing)
forecast requires new data inputs that are not typically • Training
available. For example, the component-level tools most • Reliability, Maintainability, and Availability
often use marketing data of a particular component to • Procurement and Vendor (product availability,
determine the maturity of that given component (adopt- stability, experience, market share)
ing a typical business “S” curve of product life cycle • Configuration Management
introduction, growth and saturation phases [Volker, • Technical Documentation and Data Rights
1988]). Therefore, as the market begins to saturate and • Assembly and Installation
competing technologies and products emerge, the prod- • Open Architecture and Standards.
uct of interest matures and the marketing data highlights
this. The system life cycle perspective uses knowledge This element of our OMF has critical applicability
from this typical product life cycle and extrapolates when the initial product selections are being determined

12 HERALD ET AL.
for the detailed design phase. This criticality remains maturity of the system products (including hardware
high while the system configuration is still evolving in and software) is necessary. Paul Schutte from NASA
response to system element changes until the point Langley Research Center asserts that “... technology is
during production where the final production configu- used primarily for monitoring and implementation and
ration is determined. At this point during the utilization humans are used primarily for generating alternative
of the equipment, there is very low criticality for this actions and selecting among those alternatives”
analysis since the product meets the functional require- [Schutte, 1999: 116]. TPS&HA leverages a mix of tools
ments. However, when the system changes due to emer- for monitoring and providing information to the sys-
gent requirements or obsolescence during the tems engineer. This information can be formulated at
utilization phase, the criticality again goes up in direct each level of a given system’s hierarchy, keeping in
support of system refreshment and insertions. Although mind that it is necessary to fully understand the current
the criticality in the retirement phase is low, this assess- status of each of the elements that make up that system
ment could be re-leveraged to evaluate the possible level and aggregate information of the impending ob-
advantage for recycling or reuse of the system equip- solescence.
ments. Figure 4 shows the Technology Trade Study and This information is used to support the SF and
Product Selection (TS&PS) life cycle phase applicabil- TS&PS OMF component analyses as shown in Figure
ity row in the framework. 2. The input data is typically obtained from product
Available Technology Trade Study and Product providers in the form of: technology roadmaps (product
Selection Tools and Methods. The commercial prod- type), technology forecasts for those items where a
uct selection criteria above highlight the strengths and roadmap is not available (this includes all three levels
weaknesses of each of the alternatives so that the aggre- of component, assembly, and system forecasts), and
gation can be assessed and compared. Typical commer- cost analyses. In this way, an aggregation of the lowest-
cial tools for performing these type of analyses include level information can be formulated to understand next
spreadsheet models such as Kepner-Tregoe Matrix De- higher-level impacts. Specific implementation plans
cision Making Method [Kepner-Tregoe, 2008] and the will be chosen by the systems engineer, depending on
COTS/NDI Assessment and Selection Tool (CAST) the program constraints.
[Verma et al., 1996] (NDI is a Non-Developmental This analysis is not intended to cover an industry
Item). The CAST model uses the Analytic Hierarchy sampling of available technologies and products, but
Process (AHP) [Saaty, 1980], which is a multivariable rather this analysis is performed for a specific system
decision analysis aid that provides two benefits over the instantiation and its associated bill of materials. This
spreadsheet methodology. The first benefit is the use of analysis is intended to cover all technologies and prod-
pairwise matrices. In this way the subjectivity of the ucts (hardware, software, etc.) that are in the system
criteria weightings is minimized to one-on-one com- solution. The criticality of this component is low until
parisons versus many-to-many. This eases the time and the system baseline is established and even until the first
difficulty of model development. The second benefit, obsolescence begins in production. After this point and
once the input criteria model is complete, is the calcu- up until system retirement surveillance is very critical
lation of an Inconsistency Ratio, which represents the to the continued operational effectiveness of the system
ratio of the percent of inconsistency divided by the of interest. Figure 4 summarizes the TPS&HA row in
model consistency. Using the inconsistency ratio, a user the OMF.
can have confidence that the input model has been Available Technology and Product Surveillance
consistently described, and consequently the outputs and Health Assessment Tools and Methods. The
are equivalently reliable. Since the goal of a product Technology Roadmapping tools discussed in Section
selection is to analyze multiple attributes simultane- 3.1, the System Costing tools in Section 3.2, and the
ously, a method that accounts for all of the various System Obsolescence Forecasting tools discussed in
program criteria in a methodical way is sufficient. Section 3.3 provide the input set for this ongoing tech-
nology and product surveillance. To assess the health
status of the system, there are capabilities such as the
3.5. Technology and Product Surveillance
US Navy’s Obsolescence Management Information
and Health Assessment (TPS&HA)
System (OMIS) [NUWC, 2008] and the COTS Data-
This component of the framework takes place, as shown base from Lockheed Martin Maritime Systems & Sen-
in Figure 2, after a system configuration baseline has sors [Herald and Genaw, 2005]. A screen capture of a
been established, typically at the end of the develop- portion of a system health status assessment is shown
ment phase. As soon as the configuration is set, the need in Figure 5 and represents a tangible basis for a systems
for technology surveillance to assess the health and engineer to determine an ideal point for system evolu-

tion or for alternative product solutions. In Figure 5, the

light gray bars represent the expected duration of prod-
uct manufacture and availability, the slashed bars rep-
resent the period of announced or extended support
from the original equipment manufacturer, and, finally,
the dark gray bars represent the anticipated period of
product availability (and possibly support) from possi-
ble aftermarket and third-party sources. Notice that
starting in the 5th year of the program (2008), three
products will require a proactive solution. This solution
may come in the form of a replacement (through redes-
ign or compatible replacement), or through product
emulation (also a development solution that replaces
Figure 5. Partial system health assessment screen capture from the COTS database.
the existing capability with a new technology such as
using gate array technology to replace an aging proces-
sor), or, finally, with the procurement of a stockpile of
spare parts that are expected to extend the actual end-
of-support date to some future point. Each of these
options entails additional costs, schedule, skills and
resources, retesting, and recertifications. Trading-off
when the cost of redesign becomes less than the cost of
product stockpiles is critical to understanding system
evolution decisions.
3.6. Technology Transition (TT)

The origin of technology comes from Greek roots with
“Techne,” meaning skill of hand or technique, and
“Logos,” meaning knowledge or science. From these
roots, the term technology transition (or technology
transfer) has taken on a variety of definitions. From
examination of this diverse academic literature, three
distinct groupings of study have emerged [Lipp, 2002]:
• Descriptions of the technology transition process

• Measures of the effectiveness of technology tran-
sition
• Methods to more effectively transition technol-
ogy.
These groupings cover the essence of the challenges

faced by practitioners regarding the process to advance
a specific technology along its maturity scale from
original concept to application and eventually into his-
torical archives. This OMF component monitors the
advancement of technologies as possible solutions to
system obsolescence. In order to further define the
framework, the three categories will be expanded.
Descriptions of the technology transition process.
There are two primary perspectives of transition for
technologies. The first perspective regards the advance-
ment of a technology from one maturity stage to the
next within its own purview. The second regards the
movement of a particular technology from one environ-

14 HERALD ET AL.
Figure 6. Technology readiness level process evolution descriptions.
ment to another such as from a laboratory/testing envi- be ready for prototyping in a space application; how-
ronment to an operational environment as a part of a ever, that same technology may only be at a TRL 4 for
deployed system. These perspectives have been com- an automotive industry or undersea application. This
bined into a transition process structure called Technol- technology readiness awareness creates a context
ogy Readiness Levels (TRL). TRL provides a around which the transition challenge can be methodi-
framework to describe the process for transitioning a cally addressed.
technology from Basic Technology Research to Tech- Measures of the effectiveness of technology tran-
nology Development to Technology Demonstration sition. The TRL structure provides a process for transi-
and, finally, to System Test, Launch, and Operations. tion and has enumerated a scale for measuring the
The TRL system was formally adopted by the U.S. current status of a given technology. The effectiveness
National Aeronautics and Space Administration of transitioning from one level to the next is now more
(NASA) for research project tracking and management evident. This insight permits the technology-specific
in 1991 [Wikipedia, 2008]. Since that time, several metrics for effectiveness measure to be determined and
prominent organizations such as the Defense Advanced subsequently tracked as the technology advances on the
Research Projects Agency (DARPA) have leveraged maturity scale. Other metrics consider the timing, the
TRL as a process for monitoring the formal progress risk, and the quality of the transition in order to better
and maturity of a particular technology through its life plan for transition into systems.
cycle. A description of the TRL process for NASA Methods to more effectively transition technol-
includes nine different levels as delineated in Figure 6 ogy. The Office of Naval Research (ONR) describes the
and highlights the process evolution across the TRLs transition of technology using two perspectives: the
[Mankins, 1995]. movement of an actual technology into a new applica-
The TRL framework provides the process trail that tion and the transfer of knowledge relating to the actual
sets the expectations for what must be accomplished to technology from previous applications. As an example,
move a particular technology forward in maturity. As ONR addresses these perspectives by breaking out tech-
can be seen from the TRL descriptions above, the nology into thirty-one different primary categories with
linkage to application-specific environments is cer- each one being further refined to approximately 2–20
tainly a consideration when selecting technologies. different subcategories with then 3–5 different subject
Therefore, a specific technology may reach a TRL 6 and matter experts that represent the various capabilities.

This network of technical expertise is a treasure of transition is based more on opportunity rather than
resources being offered specifically to innovatively necessity. When an opportunity presents itself it should
move technology information into sectors where it has be studied by the TS&PS component. For the support
immediate application and for application in commer- phase, there is not an urgency for technology transition
cial and governmental sectors where it was not origi- of the system configuration since functionality is in
nally envisioned. This part of technology information place and operational; however, technology transition
transition is exciting because of the unknown potential could be leveraged for potential system improvements.
unleashed by the network of domain expertise. The In the utilization phase data transfer from the design
challenge for a project (new or existing) is to proac- team to the operational team is most critical. The retire-
tively pursue and leverage these resources to drive ment phase accounts for the opportunity to leverage
innovation into new designs and system evolutions. emerging uses for existing technologies (such as for
Other organizations have also embraced the signifi- recycling and reuse applications). Figure 4 summarizes
cance of moving technology from the laboratory envi- the applicability of technology transition as the final
ronment into real-world applications with DARPA row in the OMF.
being a superior example. In a formal document pub-
lished in the late 1990s [DARPA, 1997], DARPA de-
4. CONCLUSIONS AND FURTHER
scribes military platform successes of stealth
RESEARCH
technology transition, unmanned aerial vehicle (UAV)
flight, the common affordable lightweight fighter dem-
4.1. Conclusions
onstration that lead to the Joint Strike Fighter common
platform with variants, and many more examples of In order to ensure the continued operational effective-
ground-breaking technology work that has made the ness of a system through the design, production, utili-
jump from lab concepts to innovative applications. zation, and support life cycle phases, an Obsolescence
There are also many non-DoD applications that have Management Framework (OMF) is proposed for a sys-
arisen from DARPA-sponsored technology transition, tem design and evolution. The OMF articulates the six
the Internet (from the ARPA Network and Milnet) being integral components necessary to protect a system from
just one. So how does DARPA move technology from operationally ineffective evolution due to obsolescence
the conceptual phase to availability for military imple- of the elements making up that system. From a practical
mentations? Investments are made to incrementally perspective, the OMF supports the system stakeholders
evolve technology in a methodical way. Those tech- with initial baseline definition and with proactive obso-
nologies that show incremental progress and promise lesence planning. The systems engineer, who is respon-
against the TRL scale are prioritized for the available sible for the design of the system architecture, begins
funding of the next investment year. If successful, this forecasting the impact of decisions rendered in the early
initiates development leading to a demonstration. Once project stages. The systems designer, who is responsible
this demonstration has proven the initial concepts and for selecting the baseline solution and then the smooth
possibly exposed the potential for adjacent sector use, evolution of that baseline, must understand what tech-
the technology is reviewed for possible applicability nology and products are available, must perform trade
and deployment. This transition method provides mul- studies to balance technical, cost, and schedule con-
tiple checkpoints along the way to reassess the value, straints for a best value recommendation, and must
push it in a certain direction, or change the anticipated integrate evolving technologies as appropriate. The an-
environment, as well as determine if the technology swers for When to change the system and What must
should be halted in favor of more promising options. change at those points are developed with the OMF as
The performance of technology transition assess- a guide.
ment and planning is most critical in the beginning of The six OMF components are then explored in two
the program life cycle where the newest technologies dimensions. The first dimension is the applicability of
are being traded against established technologies for each component in each typical life cycle phase. The
hardware and software products. It is necessary to as- second dimension is the criticality in each applicable
sess the status of technologies and product alternatives life cycle phase. From this contextual setting a system
for the TR OMF component. As the program moves into engineer can best apply the available industrial capa-
the development life cycle phase, technology transition bilities at the most beneficial points in the life cycle.
remains equally as critical since the design can be Although obsolesence is obvious and critical in the
updated at any point within development. During the utilization and support phases of a program life, an
production phase (after the system baseline has solidi- interesting observation of the literature shows the criti-
fied) and on through the utilization phase, technology cal applicability of these OMF components in even the

16 HERALD ET AL.
earliest conceptual and design phases. Another obser- • Consider using the OMF to create a “professional
vation is the varying usage of component capabilities survey” that gets distributed to a sample of Sys-
through time; for example, technology roadmapping tems Engineers for Review, Modification, and
applicability moves from product roadmapping needs Comment. This survey data can then be used to
to emerging roadmapping needs and back again as the corroborate and provide credibility for this litera-
system evolves. The OMF focuses these analyses for ture analysis.
best value.
5. ACRONYMS
4.2. Further Research
The management of system evolution entails affordably AHP Analytic Hierarchy Process
changing the baseline while maintaining or improving ARPA Advanced Research Projects Agency
(started in 1958; predecessor to DARPA)
mission operational effectiveness. The complexity of a
ATM Asynchronous Transfer Mode
system increases as the focus moves from the lowest
CAIG Cost Analysis Improvement Group (spon-
system elements to the higher hierarchical levels, lead-
sored by the OSD)
ing possibly to a networked system of systems where
CALCE Computer-Aided Life Cycle Engineering
the complexity of maintaining technical viability mul-
Center (University of Maryland)
tiplies exponentially [Cares, Christian, and Manke,
CAST COTS/NDI Assessment and Selection Tool
2002]. Further research opportunities exist to extend the
(Lockheed Martin Corporation)
OMF and address the complexity through the system
COCOMO Constructive Cost Model (University
hierarchy.
of Southern California)
COSYSMO Constructive Systems Engineering
• The focus of this OMF is on the evolution of
Cost Model (Massachusetts Institute of Technol-
systems solely due to the obsolescence of the
ogy)
constituent elements that make up that system. It
COSOSIMO Constructive Cost Model for Sys-
addresses the system as a constant functional tem-of-Systems Architecting and Integration
baseline over time while allowing just the physi- (University of Southern California)
cal baseline to evolve. There is often a desire to COTS Commercial Off The Shelf
enhance the system functionality through the ex- CTR Center for Technology Roadmapping (Pur-
pected system utilization phase to handle such due University)
needs as emergent external system influences, DARPA Defense Advanced Research Projects
desired capability growth requirements, and tech- Agency
nology insertion for the sake of a particular sys- DMSMS Diminishing Manufacturing Sources
tem value (i.e., not due to obsolescence issues, but and Material Shortages
possibly for such benefits as reliability improve- ISO/IEC International Organization for Stand-
ments). Just like obsolescence considerations, ardization/International Electrotechnical Com-
these real-world functional considerations are mission
also directly applicable to the physical system MOCA Mitigation of Obsolescence Cost Analysis
evolution. NASA National Aeronautics and Space Admini-
• An aspect of the Technology Trade Study Analy- stration (United States)
sis and Product Selection OMF component con- NDI Non-Developmental Item
siders the change in technical performance when NUWC Naval Undersea Warfare Center
a system baseline evolution occurs. This is not OM Obsolescence Management
explicitly discussed in this paper and yet repre- OMF Obsolescence Management Framework
sents an interesting area for further research. How OMIS Obsolescence Management Information
much additional system functionality is realized System (US Navy)
when the technology and product baseline ONR Office of Naval Research
changes? The system impact may be negative or OSD Office of the Secretary of Defense
more likely the impact may provide greater capa- R2T2 Rapid Response and Technology Trade
bilities than its technology and product predeces- Study (Lockheed Martin)
sor did. The further research might address trade SC System Costing
study quantification, leverage, forecasting, and SF System Obsolescence Life Cycle Forecasting
planning. TOC Total Ownership Cost

TPS&HA Technology/Product Surveillance and C.H. Fine, Clockspeed: Winning industry control in the age
Health Assessment of temporary advantage, Perseus Books, HarperCollins,
TR Technology Roadmapping New York, 1998.
N. Fleming, Coping with a revolution: Will the internet
TRL Technology Readiness Level
change learning? Knowledge management—emerging
TS&PS Technology Trade Study Analysis and perspectives, systems-thinking, Lincoln University, Can-
Product Selection terbury, New Zealand, 2004, http://www.systems-think-
TT Technology Transition ing.org/kmgmt/kmgmt.htm.
UAV Unmanned Aerial Vehicle Frontier Techologies, Inc., ICE—Integrated Desktop Analy-
sis and Planning System Cost Estimation tool suite is a
registered trademark for an integrated costing capability,
REFERENCES http://www.fti-net.com/AS/ICE/index.asp, 2008
Galorath, Inc., SEER tool suite is a registered trademark for
Alignent (Sopheon-Alignent Software Inc.), Vision Strategist an integrated cost estimating capability, http://www.ga-
is a registered trademark for a technology roadmapping lorath.com/index.php/products/hardware/C4, 2008.
tool, http://www.alignent.com/products/visionstrategist, R. Galvin, Science roadmaps, Science 280 (8 May 1998), 803.
2008. M.L. Garcia and O.H. Bray, Fundamentals of technology
J.T. Boardman and A.J. Cole, Integrated process improve- roadmapping, SAND97-0665, Sandia National Labora-
ment in design and manufacture using a systems approach, tory, Albuquerque, NM, http://www.sandia.gov/
Systems engineering for automation, Institution of Elec- PHMCOE/pdf/ Sandia%27sFundamentalsofTech.pdf,
trical Engineers Proceedings, Control Theory and Appli- April 1997.
cations, Vol. 143, No. 2, 1996, pp. 171–185. T.E. Herald, Rapid response system-level technology trade
CALCE Center, University of Maryland, Mitigation of Ob- study, Nat Defense Indust Assoc (NDIA) 6th Annu Syst
solescence Cost Analysis (MOCA) is a product that pro- Eng Supportability & Interoperability Conf Proc, No.
vides assembly-level obsolescence forecasting and 4870, http://www.dtic.mil/ndia/2003systems/herd.ppt,
assessment for production-phase change event schedul- October 23, 2003.
ing , http ://ww w.calce.umd.edu/con- T.E. Herald and D. Genaw, Technology and obsolescence
tracts/MOCA/MOCA_Page.htm, 2008. sustainment for integrated COTS systems, Lockheed Mar-
J.R Cares, R.J. Christian, and R.C. Manke, Fundamentals of tin Joint Symp Eng Affordability, Reston, VA, April 14,
distributed, networked military forces and the engineering 2005.
of distributed systems, Naval Undersea Warfare Center T. E. Herald and M. Hertz, Method and apparatus for estimat-
Division, NUWC-NPT Technical Report 11,366, New- ing the refresh strategy or other refresh influenced pa-
port, RI, May 9, 2002, pp. 4–6. rameters of a system over its life cycle, US Pat. Appl.
B.T. Clegg and J.T. Boardman, A systems approach to process Publish US 2004/0010474 A1, January 15, 2004.
improvement in design and manufacture, Digest No. T. E. Herald and J. Seibel, Technology management forecast-
1996/171, IEE Colloquium, November 11, 1996, pp. 3/1– ing and predictions for system of interest analysis, Int
3/9. Council Syst Eng (INCOSE) Mid-Atlantic Regional Conf
D&B Corp., DNBi Supply Management is a registered trade- (MARC), http://www.cotsresearch.com/publica-
tions/Herald-Seibel_INCOSE_MARC_2004.pdf, Sep-
mark for a component-level obsolescence forecasting and
tember 30, 2004.
analysis tool, http://www.dnb.com/us/dbproducts/sup-
Z. Huang, P.A. Sandborn, M. Pecht, and R. Solomon, Life
ply_management/all_products/index.html, 2005.
cycle forecasting of ASICs, Future Circuit International,
DARPA, Defense Advanced Research Projects Agency,
Issue 7, Technology Publishing, London, UK, 2001, pp.
Washington, DC, Technology Transition, Forward
101–107.
authored by William J. Perry, 1997.
i2 Technologies, Inc., TACTRAC and 4D Online Parts Uni-
DAU (Defense Acquisition University), Acquisition Commu-
verse are registered trademarks for component-level ob-
nity Connection, Executive Summary, Product Support, A solescence forecasting and analysis tools,
program manager’s guide to buying performance, Novem- http://www.i2.com/assets/pdf/solutionareas/i2Tactrac3_
ber 2001, https://acc.dau.mil/simplify/ lo.pdf, 2005 and http://www.i2.com/assets/pdf/solution-
ev.php?ID=64799_201&ID2=DO_TOPIC. areas/partsu_pp_v2.pdf, 2005.
DMSMS (Diminishing Manufacturing Sources and Material ISO/IEC 15288 (International Organization for Stand-
Shor tages) , Knowledge Sharing Portal, 2008, ardization and International Electrotechnical Commis-
http://www.dmsms.org. sion, Montreal, Canada), ISO/IEC 15288 2002(E),
J.M. Duckles and E.J. Coyle, Purdue’s Center for Technology Systems engineering—system life cycle processes, No-
Roadmapping: A resource for research and education in vember 2002, Annex B.
technology roadmapping, Proc IEEE Int Eng Manage- T.A. Kappel, Perspectives on roadmaps: How organizations
ment Conf, Cambridge, UK, August 18–20, 2002, Vol. 2, talk about the future, J Prod Innovation Management,
pp. 900–904. Lisle, IL, Vol 18 (2001), 39–50.

18 HERALD ET AL.
Kepner-Tregoe Consulting, Inc., Problem Solving and Deci- Price Systems L.L.C., Price Systems Costing tool suite is an
sion Making (PSDM) is a trademarked Trade Study and integrated system costing suite, http://www.pricesys-
Product Selection matrix methodology, http://www.kep- tems.com/products/price_trueplanning.asp, 2008.
ner-tregoe.com/TheKTWay/WorkingWithKT-TeachYou QTEC, a division of QinetiQ Ltd., Q-Star is a registered
-PSDM.cfm, 2008 and http://www.valuebasedmanage- trademark for a component-level obsolescence forecast-
ment.net/methods_kepner-tregoe_matrix.html, 2008. ing and an alysis tool, http://www.qtec.us/De-
R.N. Kostoff and R.R. Schaller, Science and technology fault.aspx?p=DynamicModule&pageid=243330&ssid=
roadmaps, IEEE Trans Eng Management 48(2) (2001), 98668&vnf=1, 2008.
132–143. T.L. Saaty, The analytic hierarchy process, McGraw Hill,
JA. Lane, Estimating system-of-systems development effort, New York, 1980.
Software Tech News 9(1) (March 2006), https://www.soft- J. Sagoo and J. Boardman, Formalisation of an order process-
waretechnews.com/stn_view.php?stn_id= 4&article_id=8. ing soft systems model using petri nets, Int Council Syst
S.M. Lipp, Identifying mechanisms of technology transfer Eng 8th Annu Int Symp, Vancouver, BC, Canada, July
relative to the instantiation of technology, Dissertation, 26–30, 1998.
Stevens Institute of Technology, Hoboken, NJ, 2002, pp. P.A. Sandborn and G. Plunkett, The other half of the DMSMS
5, 13–14, 72–90. problem—software obsolescence, DMSMS Knowledge
C. MacNulty, FORCEnet, the Naval component of the GIG- Sharing Portal Newsletter 4(4) (June 2006), 3, 11.
enabling the joint warfighter through network centric war- P.A. Sandborn and P. Singh, Obsolescence driven design
fare, Human Element Group Final Report V(21), National refresh planning for sustainment-dominated systems, Eng
Defense Industrial Association, Strike, Land Attack and Economist 51(2) (April–June 2006), 115–139.
Air Defense Division, Washington, DC, December 11, P.A. Sandborn, T.E. Herald, J.A. Houston, and P. Singh,
2002. Optimum technology insertion into systems based on the
J. Mandelbaum and S. Pallas, Reducing total ownership cost assessment of viability, IEEE Trans Components Packag-
in DoD—increasing affordability of DoD systems, PM ing Manufacturing Technol 26(4) (December 2003), 734–
Mag (July–August 2001), 1–10, http://findarti- 738.
cles.com/p/articles/mi_m0KAA/is_4_30/ai_80128232. P.A. Sandborn, F. Mauro, and R. Knox, A data mining based
J.C. Mankins, Technology readiness levels, Advanced Con- approach to electronic part obsolescence forecasting,
cepts Office, Office of Space Access and Technology, IEEE Trans Components Packaging Technol 30(3) (Sep-
NASA , H ousto n, TX, Apr il 6, 1995, tember 2007), 397–401.
http://www.hq.nasa.gov/office/codeq/trl/trl.pdf. R.R. Schaller, Technological innovation in the semiconductor
M.J. Meixell and S.D. Wu, Scenario analysis of demands in industry: A case study of the international technology
a technology market using leading indicators, IEEE Trans roadmap for semiconductors (ITRS), Dissertation, The
Semiconductor Manufacturing 14(1) (2001), 65–75. Institute of Public Policy, George Mason University, Har-
MTI, Advanced Component Obsolescence Management risonburg, VA, April 15, 2004.
(AVCOM) is a registered trademark for a component-level P. Schutte, Complemation: An alternative to automation, J
bill of material obsolescence forecasting and analysis tool, Inform Technol Impact 1(3) (1999), 113–118.
http://www.avcom.mtifwb.com/index.cfm?navid=26, J.S. Seibel, An attribute proposal for same vendor, version-to-
2008. version COTS upgrade decisions, Lockheed Martin Eng
NUWC Division Keyport, Naval Undersea Warfare Center in Process Improvement Center, Joint Symp, 2005, p. 12.
Keyport, WA, Obsolescence Management Information A.J. Shenhar and Z. Bonen, The new taxonomy of systems:
Systems (OMIS) as an assembly-level analysis tool, Toward an adaptive systems engineering framework,
http://www-keyport.kpt.nuwc.navy.mil/Leadership.htm, IEEE Trans Syst Man Cybernet A: Syst Hum 27(2) (March
2008. 1997), 137–145.
OSD Cost Analysis Improvement Group (CAIG), Operating P. Singh, P.A. Sandborn, T. Geiser, and D. Lorenson, Elec-
and support cost estimating guide, Appendix C. Aircraft tronic part obsolescence driven product redesign planning,
operating and support cost element structure definitions, Int J Agile Manufacturing 7(1) (2004), 23–32.
http://www.dtic.mil/pae/paeosg15.html, May 1992. R. Solomon, P.A. Sandborn, and M. Pecht, Electronic part life
M. Pecht, Electronic parts selection and management, Wiley, cycle concepts and obsolescence forecasting, IEEE Trans
New York, 2003. Components Packaging Technol 23(4) (December 2000),
M.G. Pecht, T. Syrus, and D. Humphrey, Part assessment 707–717.
guidelines and criteria for parts selection and manage- S. Tiku, Reliability capability evaluation for electronics
ment, IEEE Trans Electronic Packaging Manufacturing manufacturers, Dissertation, University of Maryland, Col-
24(4) (October 2001), 339–350. lege Park, MD, 2005.
M.G. Pecht, R. Solomon, P.A. Sandborn, C. Wilkinson, and Total Parts Plus, Inc., Parts Plus is a registered trademark for
D. Das, Life-cycle forecasting, Mitigation assessment and a component-level obsolescence forecasting and analysis
obsolescence strategies—a guide to the prediction and tool, http://www.totalpartsplus.com/partsPlus.aspx, 2008.
management of electronic parts obsolescence, CALCE Toyota Motor Sales USA, Inc., Hybrid Synergy Drive is a
EPSC Press, College Park, MD, 2002. trademark of a gasoline-powered electric drive system,

http://www.toyota.com/html/hybridsynergyview/2004/ D. Verma, T.E. Herald, and J. Knezevic, Integration of sup-

october/heartandsoul.html, 2005. portability considerations into the system engineering
I. Tuomi, The lives and death of Moore’s law, First Monday process through focused modeling and simulation, 2nd
7(11) (November 2002) [further details, G.E. Moore, Modeling, Simulation and Virtual Prototyping Conf, Ar-
Chairman Emeritus of Intel Corporation, http://www.in- lington, VA, 1997, pp. 297–305.
tel.com/technology/mooreslaw/index.htm]. D. Verma, T. Powers, B.S. Blanchard, R.G. Giffin, R. Webb,
R. Valerdi, The constructive systems engineering cost model and D.J. VanBuskirk, COTS/NDI assessment and selec-
(COSYSMO), Dissertation, University of Southern Cali- tion methodology, INCOSE Symposium, Boston, MA,
fornia, Los Angeles, CA, 2005. 1996.
R . Valer di, Lean Advancement Initiative, M.C. Volker, Technology push vs. market pull, 9th Annu
http://lean.mit.edu/index.php?option=com_content&task Canadian MBA Conf Management Technol, McMaster
=view&id=245&Itemid=1 and http://www.softstarsys- University, January 1988.
tems.com/COSYSMO_2006.htm, Massachusetts Insti- Wikipedia, The Free Encyclopedia, Technology readiness
tute of Technology, Cambridge, MA, 2008. level, http://en.wikipedia.org/wiki/Technology_Readi-
D. Verma and L.H. Johannesen, Supportability engineering ness_Level, 2008.
and logistics optimization/planning trends and challenges: J.J. Young, Jr., Diminishing Manufacturing Sources and Ma-
A system integrator’s perspective, Proc Int Logistics terial Shortages (DMSMS) management guidance, Memo
Cong, University of Exeter, May 1999. for Distribution, Research Development and Acquisition,
D. Verma and G. Plunkett, Systems engineering and support- Washington, DC, January 27, 2005, p. 2.
ability analysis: Technology refreshment for COTS-inten- J.A. Zachman, A framework for information systems archi-
sive systems, Proc Int Council Syst Eng (INCOSE), tecture, IBM Syst J 38(2–3) (1999) [reprinted from IBM
Minneapolis, MN, July 2000. Syst J 26(3) (1987), 454–470].
Tom Herald received an M.S. in Electrical Engineering from the University of Maryland, and a B.S. in EE
from the University of Pittsburgh. He recently earned the Ph.D. in Systems Engineering from Stevens
Institute of Technology in Hoboken, NJ. As part of the Systems Design and Operational Effectiveness
Program within the School of Systems and Enterprises at Stevens, the focus of his research is to provide
the systems engineer with an integrated approach for the development and execution of technology and
obsolescence evolution. Tom’s research was published (SSE Press) in 2007: An Obsolescence Forecasting
Methodology for Strategic System Sustainment Decision Making. With 25 years of industrial experience
at IBM, Loral, and now Lockheed Martin, Tom is a Systems Engineering Fellow with the Simulation,
Training and Support division in Orlando, FL. His interests include the linkages of supportability
parameters, obsolescence, and technology insertion considerations proactively influencing system designs.
Dinesh Verma received the Ph.D. and the M.S. in Industrial and Systems Engineering from Virginia Tech.
He is currently serving as Dean of the School of Systems and Enterprises and Professor in Systems
Engineering at Stevens Institute of Technology. Verma concurrently serves as Scientific Advisor to the
Director of the Embedded Systems Institute in Eindhoven, Holland. Prior to this role, he served as Technical
Director at Lockheed Martin Undersea Systems, in Manassas, VA, in the area of adapted systems and
supportability engineering processes, methods and tools for complex system development and integration.
Dr. Verma has authored over 85 technical papers, book reviews, technical monographs, and co-authored
two textbooks: Maintainability: A Key to Effective Serviceability and Maintenance Management (Wiley,
1995), and Economic Decision Analysis (Prentice Hall, 1998). He is a Fellow of the International Council
on Systems Engineering (INCOSE), a senior member of SOLE, and was elected to Sigma Xi, the honorary
research society of America.

20 HERALD ET AL.
Caroline Lubert graduated from the University of Exeter, UK, with a B.Sc. in Mathematics and a Ph.D.
in Engineering for work in Aeroacoustics. She stayed with Exeter as a postdoctoral research fellow in the
School of Engineering. She became a Senior lecturer in the School of Mathematics and Statistics at the
University of Plymouth, UK. Caroline proceeded to James Madison University in Harrisonburg, VA,
where she was awarded tenure and is a Full Professor of Mathematics. She spent AY 2003–2004 as a
Visiting Professor in the SDOE Program at Stevens Institute of Technology, Hoboken, NJ. Caroline Lubert
is the author of numerous papers and a technical monograph. She received the Young Logistician of the
Year award from the International Society of Logistics, the Alan O. Plait award for Tutorial Excellence
from the Reliability and Maintainability Symposium, and a patent for research with Dr. Verma; Weighted
Wedge Defuzzification for Conceptual System Design Evaluation.
Robert Cloutier is a Research Associate Professor in the School of Systems and Enterprises at Stevens
Institute of Technology. He has over 20 years experience in systems design and architecture, software
engineering, and project management in both commercial and defense industries. His interests include
systems engineering patterns, systems architecting, model-based systems engineering, SysML, and
architecture management. Rob belongs to the International Council on Systems Engineering (INCOSE),
IEEE and ACM. He received his Ph.D. in Systems Engineering from Stevens Institute of Technology, an
M.B.A. from Eastern University, and a B.S. from the US Naval Academy.

An Obsolescence Management Framework

Uploaded by

Copyright:

Available Formats

An Obsolescence Management Framework

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Obsolescence Management Framework

Uploaded by

Copyright:

Available Formats

Regular Paper

*Author to whom all correspondence should be addressed (e-mail:

Systems Engineering Vol. 12, No. 1, 2009

Key words: obsolescence management; framework; technology roadmapping; system costing;

1. INTRODUCTION Obsolescence is defined herein to represent when a

Figure 1. System operational effectiveness.

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Figure 2. Obsolescence management framework systemigram.

Systems Engineering DOI 10.1002/sys

Figure 3. Applicability of the obsolescence management framework components.

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

tion or for alternative product solutions. In Figure 5, the

3.6. Technology Transition (TT)

• Descriptions of the technology transition process

These groupings cover the essence of the challenges

Systems Engineering DOI 10.1002/sys

Figure 6. Technology readiness level process evolution descriptions.

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

http://www.toyota.com/html/hybridsynergyview/2004/ D. Verma, T.E. Herald, and J. Knezevic, Integration of sup-

Systems Engineering DOI 10.1002/sys

Systems Engineering DOI 10.1002/sys

You might also like