Regular Paper

Creating a Proactive Obsolescence

Management System Framework through the
Systems Engineering Continuum
Todd G. Pobiak,* Thomas A. Mazzuchi, and Shahram Sarkani

School of Engineering & Applied Science, George Washington University, 1776 G Street, NW, Washington, DC 20052
PROACTIVE OBSOLESCENCE MANAGEMENT SYSTEM FRAMEWORK VIA THE SE CONTINUUM

Received 26 October 2011; Revised 25 November 2011; Accepted 25 November 2012, after one or more revisions
Published online 23 May 2013 in Wiley Online Library (wileyonlinelibrary.com).
DOI 10.1002/sys.21258

ABSTRACT
With commercial and military systems becoming more complex, using more sophisticated products,
complex processes, and specialized people and having longer system life cycles, it is essential that
organizations have a systematic approach to managing systems from an Obsolescence Management
System perspective. This paper presents a new systems engineering architecture framework, House of
Systems Engineering (HoSE), and shows how its constructs can be applied to support the building of a
proactive Obsolescence Management System framework. We first provide a brief overview of the HoSE,
including the systems engineering aspects and the systems architecture methodology used in the HoSE.
Next, we discuss the 2-dimensional Obsolescence Management System framework based on the HoSE.
Finally, a case study is performed to justify the framework. The case study results suggest that the
framework is beneficial in finding gaps in an Obsolescence Management Plan. © 2013 Wiley Periodicals,
Inc. Syst Eng 17: 125–139, 2014

Key words: Obsolescence Management; DMSMS; framework; systems engineering; House of Systems
Engineering; architecture framework

1. INTRODUCTION prises [e.g., military]), have a systematic approach to manag-

Obsolescence is not just a components engineering problem;
obsolescence is not just a program problem; obsolescence is
an enterprise problem [Drake, 2003]. As early as the 1940s,
utility companies were struggling with obsolescence issues
[Bonbright, 1941]. With military and commercial systems
becoming more complex, using more sophisticated compo-
nents, and having a longer system life cycle, it is essential that
enterprises, both private enterprises (e.g., commercial nuclear
power plants [DiSandro and Torok, 2005] and public enter-
*Author to whom all correspondence should be addressed (e-mail: tpo-
biak@gwu.edu; Todd.Pobiak@hii-nns.com).
Systems Engineering Vol. 17, No. 2, 2014
© 2013 Wiley Periodicals, Inc.
125
ing these systems. Stogdill [1999: 18] points out that: “ Ob-
solescence issues are not unique to any particular weapon or
support system. Obsolescence occurs in all systems with a
service life longer than that of one or more of their compo-
nents” .
A longer system life cycle has led to a significant concern
regarding component obsolescence. Obsolescence can be
caused by the rapid changes in technology (components,
material, etc.), uneconomical production requirements, envi-
ronmental or safety requirements, and limited availability of
items. Rapid advances in technology have shortened compo-
nent life cycles from between 10 and 20 years to between 3
and 5 years [McDermott, Shearer, and Tomczykowski, 1999].
Perry [1994: 3] pointed out in his acquisition reform memo-
randum “ that the design cycle for commercial technology is
approximately 3–4 years and for the Department of Defense
126
126 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI

(DOD) it is 8–10 years.” Many DOD systems are technologi- ance to Obsolescence Management decision-makers in devel-
cally obsolete at the time they are fielded. Driven by the oping an Obsolescence Management plan.
consumer electronics product sector, newer and better elec-
tronic components are being introduced more frequently,
rendering older components obsolete [Singh and Sandborn, 2. AN OVERVIEW OF THE HOUSE OF SYSTEMS
2006]. It is estimated that approximately 3% of the global pool ENGINEERING (HoSE)
of electronic components goes obsolete every month [Sand-
born, Mauro, and Knox, 2007]. Nonelectronic (mechanical) The House of Systems Engineering (HoSE) (Fig. 1) is a
obsolescence issues have been surfacing for several years in systems engineering architecture framework. The concept of
the military aviation community. By fiscal year 2020, the Air the HoSE was originally introduced in 2010 [Pobiak, 2010].
Force is projecting that the average age of its aircraft will The HoSE shows the big picture of systems engineering rather
exceed 30 years. Most of these aircraft were designed to fly than a stovepipe approach. It is our hope that this system
for 20–25 years [Howard, 2002]. There also needs to be a engineering architecture framework (HoSE), discussed be-
focus on software obsolescence since software is being used low, will be used to build successful systems (e.g., the Obso-
in nearly all modern systems today. These systems rely on lescence Management System), will support educational
software to replace discrete logic circuits and control mecha- institutions in teaching system engineering principles, and
nisms that were used in the past. will be a valuable tool for systems engineers from a holistic
Regardless if it is newer developments in technology (i.e., approach.
IC processing power), or the manufacturer is no longer in Frameworks help organize and assess completeness of
business to produce and supply a custom component, organi- integrated models of their enterprises [Bahill, Botta, and
zations must be prepared to deal with this issue of component, Daniels, 2006). Architecture is the art and science of building.
technology, and manufacture obsolescence. Organizations However, in engineering context, if one were to apply the
that are in this type of technology driven environment will definition of architecture cited above, the art or science of
sooner or later need to address the obsolescence issue from a building, then one can easily extend architecture to the de-
proactive system approach if they are going to compete and signing and building of any complex system. Building one
survive in the global economy. room at a time without the blueprints for the whole house is
analogous to developing business resources and systems
As pointed out by Herald et al. [2009: 3], a proactive
without an enterprise architecture framework. The result is
management approach to obsolescence is much better than a
“ ‘wait and see’ approach that focuses on point-solution sup- duplication of functions, inefficient information exchanges,
port and reaction to an obsolescence event. Reacting to an
obsolescence event after it has already occurred, often re-
quires more cost to rectify, and takes on the risk of system
downtime which jeopardizes operational schedules.” Proc-
esses must be in place to proactively deal with obsolescence.
A framework provides a systematic taxonomy1 of con-
cepts, and it provides a way of viewing a system from many
different perspectives and showing how they are all related
[Sowa and Zachman, 1992]. System architecture shows a
logical construct (or architecture) for defining and controlling
the interfaces and the integration of all of the system compo-
nents. A framework should be established for rationalizing
the various architectural concepts and specifications in order
to provide clear communication, to allow for improving and
integrating development methodologies and tools, and to
establish credibility and confidence in systems [Zachman,
1987].
The systems engineering architecture framework proposed
to support the development of the Obsolescence Management
System framework is the House of System Engineering
(HoSE). The HoSE leverages the framework description pro-
vided by Sowa and Zachman [1992]. The foundation of the
HoSE is based on sound system engineering principles dis-
cussed in the INCOSE Systems Engineering Handbook [IN-
COSE, 2010] and the Systems and Software Engineering
International Standard [ISO/IEC-15288, 2008]. The Obsoles-
cence Management System framework shall provide guid-
1
Taxonomy—from ancient Greek “ arrangement” and ancient Greek nomia Figure 1. House of Systems Engineering (HoSE). [Color figure can
“ method” — the study of the general principles of scientific classification be viewed in the online issue, which is available at wileyonlineli-
[Merriam-Webster, 2011]. brary.com.]

Systems Engineering DOI 10.1002/sys

 PROACTIVE OBSOLESCENCE
PROACTIVE OBSOLESCENCE MANAGEMENT
MANAGEMENT SYSTEM
SYSTEM FRAMEWORK
FRAMEWORK VIA
VIA THE
THE SE
SE CONTINUUM
CONTINUUM 127
127

and a lack of integration [Bernard, 2005]. The architecture of

a system generally refers to the structural description of the
set of elements that comprise that system and the contextual
relationships between them [Morganwalp and Sage, 2004].

2.1. Main Features of the HoSE

Figure 2 shows the three major structures of the HoSE:
foundation, frame (SE3 Cube), and roof.

2.1.1. Foundation
The foundation of the HoSE is based on the systems engineer-
ing principals outlined in both the INCOSE Systems Engi-
neering Handbook [INCOSE, 2010] and the Systems and
Software Engineering International Standard [ISO/IEC-
15288, 2008].

2.1.2. Frame (SE3 Cube)

The frame of the HoSE, also referred to as the System Engi-
neering Cube (SE3 Cube), is the main structure of the frame-
work. Figure 3 highlights the main features of the SE3 Cube.
The SE3 Cube has the risk cube color code scheme (green,
yellow, and red) to represent that every System Life Cycle
Stage shall involve Risk Management. The SE3 Cube consists Figure 3. Frame: Systems Engineering Cube (SE3 Cube). [Color
of the following six main aspects: System of Interest (SOI), figure can be viewed in the online issue, which is available at
System Life Cycle Processes, System Life Cycle Stages, wileyonlinelibrary.com.]

Horizontal Crosscutting Element (Horizontal SE3 Cube

View), Vertical Crosscutting Element (Vertical SE3 Cube
View), and the SE3 Cube Element (SE3 Cube Viewpoint).
Below are the descriptions of each of these six aspects of the
SE3 Cube.
2.1.2.1. System of Interest (SOI). The System of Interest
(SOI) represents the system under observation. It represents
a distinct system view, such as the system itself, its subsys-
tems, its components, and its parts. This could be an aircraft
system (system), wing motor drive subsystem (subsys-
tem/system element), motor (component), or transistor (part).
It is the selected SOI that will be analyzed from a systems
engineering perspective across the various System Life Cycle
Processes and System Life Cycle Stages. The Vertical SE3
Cube View, discussed later, will explain this concept in more
detail.
2.1.2.2. System Life Cycle Processes. The HoSE uses the
four System Life Cycle Processes as expressed in Systems
and Software Engineering International Standard [ISO/IEC-
15288, 2008]. The four System Life Cycle Process described
in ISO/IEC 15288 are as follows:
2.1.2.2.1. Agreement Processes. The Agreement Processes
define the necessary activities to establish an agreement
between two enterprises.
2.1.2.2.2. Organizational Project-Enabling Processes.
The Organizational Project-Enabling Processes ensure
the enterprise’s capability to acquire and supply serv-
ices and products through the initiation, support, and
control of projects. They provide the necessary re-
Figure 2. Three major structures of the House of Systems Engineer- sources and infrastructure to support projects and en-
ing. [Color figure can be viewed in the online issue, which is sure the satisfaction of established agreements and
available at wileyonlinelibrary.com.] organizational objectives.

Systems Engineering DOI 10.1002/sys

128 POBIAK, MAZZUCHI, AND SARKANI
2.1.2.2.3. Project Processes. The Project Processes are
used to establish and develop project plans, carry out
the project plans, evaluate actual achievement, and
progress against the established plans, and control exe-
cution of the project through to completion.
2.1.2.2.4. Technical Processes. The Technical Processes
are used to define the requirements for a product or
system, transform the established requirements into
successful product, allow for consistent reproduction
of the product where necessary, utilize the product to
provide the required services, sustain those services,
and dispose of the product when the services are no
longer necessary.
2.1.2.3. System Life Cycle Stages. The HoSE identifies
seven System Life Cycle Stages as expressed in INCOSE
Systems Engineering Handbook Software [INCOSE, 2010].
The seven System Life Cycle Stages described in the IN-
COSE Systems Engineering Handbook are as follows:
2.1.2.3.1. Exploratory Research. The Exploratory Re-
search Stage identifies stakeholders’ needs, and ex-
plores ideas and technologies to integrate into systems.
2.1.2.3.2. Concept. The Concept Stage refine stakehold-
ers’ needs, search feasible concepts, and proposes prac-
tical solutions for systems.
2.1.2.3.3. Development. The Development Stage refines
system requirements, creates solution description,
builds a system, and verifies and validates a system.
2.1.2.3.4. Production. The Production Stage produces sys-
tems, inspects, verifies, and validates systems.
2.1.2.3.5. Utilization. The Utilization Stage operates the
system to meet users’ system and service needs.
2.1.2.3.6. Support. The Support Stage provides sustained
capability to systems.
2.1.2.3.7. Retirement. The Retirement Stage stores, ar-
chives, or disposes of the system and services when no
longer required.
2.1.2.4. Horizontal Crosscutting Element (Horizontal
SE3 Cube View). The horizontal crosscutting element (hori-
zontal SE3 Cube View) is a representative view of multiple
SOI’s from the perspective of a specific System Life Cycle
Stage. For example, if multiple SOI’s (e.g., jet propulsion
system, jet electronic system, etc.) were being evaluated at
any give System Life Cycle Stage (e.g., production stage), the
horizontal SE3 Cube View would represent all common Sys-
tem Life Cycle Process and artifacts for those SOI’s. This
horizontal SE3 Cube View would be useful for systems engi-
neers to determine what common System Life Cycle Process
could be applied across multiple SOI’s (e.g., jet propulsion
system, jet electronic system, etc.). This would eliminate the
duplication of processes, resources, etc.
2.1.2.5. Vertical Crosscutting Element (Vertical SE3
Cube View). The vertical crosscutting element (vertical SE3
Cube View) is a representative view of a specific SOI (e.g.,
jet propulsion system) across all System Life Cycle Stages
(Exploratory Research through Retirement). From the per-
spective of the vertical SE3 Cube View, all System Life Cycle
Processes and artifacts across all System Life Cycles Stages
can be viewed from a specific SOI perspective. The vertical
SE3 Cube View is beneficial to systems engineers in evaluat-
ing whether there are any gaps in the System Life Cycle
Systems Engineering DOI 10.1002/sys
Processes and artifacts across all System Life Cycles for a
specific SOI.
2.1.2.6. SE3 Cube Element (SE3 Cube Viewpoint). The
SE3 Cube Element (SE3 Cube Viewpoint) is a distinct view-
point of a SOI (e.g., Radar System) at a specific System Life
Cycle Stage. SE3 Cube Viewpoint would be beneficial if a
systems engineer wanted to focus on a particular attribute (a
specific process, requirement, metric, etc.) of a SOI at a
particular System Life Cycle Stage. SE3 Cube Viewpoint can
be seen as one of many Knowledge Management cells (e.g.,
processes, information, data, metrics, etc.) within the HoSE
framework. These knowledge management cells would then
transfer this information to the main repository of the system.
2.1.3. Roof
The roof represents Knowledge Management; it represents
the repository of information (policies, procedures, processes,
data, stakeholder requirements, etc.). Knowledge Manage-
ment leverages relevant knowledge assets to improve effi-
ciency, effectiveness, and innovation [Stankosky, 2004]. The
roof has the risk cube color coded scheme (green, yellow, and
red) to represent that Risk Management protects the complete
system.
3. AN OBSOLESCENCE MANAGEMENT
SYSTEM FRAMEWORK
To support the objectives in Section 1, we took the SE3 Cube
(Fig. 3), and converted it to a 2-dimensional framework to
support the development of an Obsolescence Management
System framework from a systems engineering perspective.
Table I represents the initially suggested framework. It is
constructed as a 25 × 7 matrix with 25 general system engi-
neering System Life Cycle Processes as rows (A–Y), and 7
System Life Cycle Stages (1–7). There are a total of 176 cells
in the framework. The rows and columns will be used in
combination to determine cell applicability for the Obsoles-
cence Management System requirements identified below
(e.g., J1–J7 (The Obsolescence Management System require-
ment is applicable to the Decision Management Process and
is applicable throughout all System Life Cycle Stages (Ex-
ploratory Research—Retirement), Y7 (the Obsolescence
Management System requirement is applicable to the Dis-
posal Process and is applicable to the Retirement System Life
Cycle Stage).
Table I shows the HoSE’s SE3 Cube Viewpoint (small
bolded outlined box) in the 2-dimensional framework; it is the
individual cell within the framework matrix. Table I also
shows the HoSE’s vertical SE3 Cube View (large bolded
outlined box) in the 2-dimensional layout. It is the complete
view of all viewpoints within the framework.
This framework is intended to provide a complete view of
the Obsolescence Management System. Therefore, each
viewpoint in the matrix needs to be evaluated to determine
how the System Life Cycle Processes apply to Obsolescence
Management at each System Life Cycle Stage (when). Devel-
oping a system can be very complex (e.g., from defining the
stakeholder needs, developing the requirements, synthesizing
those requirements, developing the system, etc.). The need
 PROACTIVE
PROACTIVE OBSOLESCENCE
OBSOLESCENCE MANAGEMENT
MANAGEMENT SYSTEMSYSTEM FRAMEWORK
FRAMEWORK VIA THEVIA
SE THE 129 129
SE CONTINUUM
CONTINUUM

Table I. Obsolescence Management System Framework

Systems Engineering DOI 10.1002/sys

130 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI
has already been determined: Develop an Obsolescence Man-
agement System framework to support a system from concept
through retirement. For the purposes of this paper (and for
simplicity), only the requirements portion of the Obsoles-
cence Management System will be identified from a systems
engineering perspective. Future works by the authors will
address the Obsolescence Management System framework in
more detail.
3.1. Obsolescence Management System
Framework SE3 Cube Viewpoint Evaluation
The requirements for the Obsolescence Management System
were derived from the key aspects of the System Life Cycle
Processes, as described in the Systems and Software Engi-
neering International Standard [ISO/IEC-15288, 2008], lit-
erature review, and the authors’ knowledge on the subject
matter. As a good practice for writing system requirements,
shall was used in each of the Obsolescence Management
System requirement statements. To better understand the cor-
relations between the Obsolescence Management System re-
quirements and the System Life Cycle Processes, the 25
System Life Cycle Processes in ISO/IEC 15288 will be de-
scribed, along with the initially suggested Obsolescence Man-
agement System requirements, as follows.
3.1.1. Agreement Processes
3.1.1.1. Acquisition Process. The purpose of the Acquisi-
tion Process is to obtain a service or product in accordance
with the requirements of the acquirer. This process involves
developing acquisition strategy, developing contract/agree-
ment document, supplier selection, developing a communica-
tion strategy, and supplier payments.
These are the Obsolescence Management System (OMS)
requirements that have been determined to fall under the
Acquisition Process (requirements are applicable at A3–A7
except where noted): OMS requirements shall be stated in
agreement (contracts, statement of work, etc.) documents
(A3); OMS requirement agreements/contracts shall be moni-
tored; OMS requirement agreement shall be updated as required;
OMS shall be supported by the supplier selection process; OMS
shall have a transfer strategy with supplier for products (e.g.,
drawings, specifications, tooling, etc.) and services; OMS shall
have a communication plan with suppliers.
3.1.1.2. Supplier Process. The purpose of the Supply
Process is to provide an acquirer with a service or product that
meets the agreed-upon requirements. This process involves
identifying an acquirer for a service or product, con-
tracts/agreement requirements, developing a communication
strategy, and acquirer payments.
These are the OMS requirements that have been deter-
mined to fall under the Supplier Process (requirements are
applicable at B3–B7 except where noted): OMS requirements
shall be stated in agreement (contracts, statement of work,
etc.) documents (B3); OMS requirement agreements shall be
monitored; OMS requirement agreements shall be updated as
required; OMS shall have a transfer strategy with acquirer for
products (e.g., drawings, specifications, tooling, etc.) and
services; OMS shall have a communication plan with the
acquirer.
Systems Engineering DOI 10.1002/sys
3.1.2. Organizational Project-Enabling Processes
3.1.2.1. Life Cycle Model Management Process. The
purpose of the Life Cycle Model Management Process is to
provide life cycle policies, processes, procedures, and models
that support the organization’s objectives that are defined,
adapted, improved, and maintained to support project needs.
This process involves establishing policies and procedures,
monitoring process execution, prioritizing, and planning im-
provement opportunities.
These are the OMS requirements that have been deter-
mined to fall under the Life Cycle Model Management Proc-
ess (requirements are applicable at C3–C7 except where
noted): OMS requirements shall be documented in an organi-
zation’s Obsolescence Management System Plan (OMSP)
(C3); OMSP shall be incorporated into applicable organiza-
tional procedures (C3); OMSP shall be updated as required;
OMS shall ensure that policies, procedures, and process are
up-to-date; OMS shall plan and prioritize organizational Ob-
solescence Management improvements.
Note: see Section 3.2.1, Context Diagram for an Obsoles-
cence Management System Process.
3.1.2.2. Infrastructure Management Process. The pur-
pose of the Infrastructure Management Process is to provide
the infrastructure and services to projects to meet organiza-
tional objectives throughout the life cycle. This process de-
fines infrastructure requirements (tools, facilities,
communications and information technology resources),
maintains infrastructure requirements, and improves infra-
structure resources as project requirements change.
These are the OMS requirements that have been deter-
mined to fall under the Infrastructure Management Process
(requirements are applicable at D1–D7): OMS shall specify
hardware requirements (e.g., computers, etc.); OMS shall
specify software requirements (e.g., database, etc.); OMS
shall be supported by information technology services; OMS
shall specify stowage facilities requirements (required tem-
perature control, security, etc.). OMS infrastructure needs
shall be continuously identified, improved, and communi-
cated.
3.1.2.3. Project Portfolio Management Process. The
purpose of the Project Portfolio Management Process is to
initiate and sustain projects in order to meet the strategic
objectives of the organization. This process secures business
and investment opportunities; provides budgets and re-
sources; and defines project management authorities and ac-
countabilities.
These are the OMS requirements that have been deter-
mined to fall under the Project Portfolio Management Process
(requirements are applicable at E1–E7): OMS shall be con-
sidered an investment opportunity for an organization to
support projects; OMS shall use a valid and realistic cost
avoidance methodology to support return on investment
(ROI) calculations; OMS shall be justified by a business case
analysis; OMS shall support the goal to reduce total owner-
ship cost; OMS shall support the goal to reduce system life
cycle cost; OMS shall identify who has organizational respon-
sibility, accountability, and authority for Obsolescence Man-
agement; OMS shall specify how obsolescence issues will be
reported and on what timeline.
 PROACTIVEOBSOLESCENCE
PROACTIVE OBSOLESCENCEMANAGEMENT
MANAGEMENTSYSTEM
SYSTEMFRAMEWORK
FRAMEWORKVIA
3.1.2.4. Human Resource Management Process. The
purpose of the Human Resource Management Process is to
provide the organization with the necessary human resources.
This process identifies the skills required for a project; en-
sures that personnel skills are developed, maintained, and
enhanced; individual information, knowledge, and skills are
recorded, shared, and reused. Human Resource Management
Process is also responsible for knowledge management infra-
structure.
These are the OMS requirements that have been deter-
mined to fall under the Human Resource Management Proc-
ess (requirements are applicable at F1–F7): OMS shall
determine the human resource skills required to support Ob-
solescence Management; OMS shall develop or obtain edu-
cational and training resources to support Obsolescence
Management; OMS shall maintain records for those employ-
ees that have had education and training in Obsolescence
Management; OMS shall develop and maintain a knowledge
management repository for all information relating to Obso-
lescence Management for the entire system hierarchy.
3.1.2.5. Quality Management Process. The purpose of
the Quality Management Process is to ensure that services and
products meet the organization’s quality objectives to obtain
customer satisfaction. This process defines quality processes
and procedures, defines quality objectives, establishes ac-
countability and authorities, reports customer satisfaction
status, and takes action when quality objectives are not met.
These are the OMS requirements that have been deter-
mined to fall under the Quality Management Process (require-
ments are applicable at G1–G7 except where noted): OMS
shall use quality management measures (supplier audits, Bill
of Material reviews, etc.) to ensure that the system meets
technical, quality, cost, and schedule requirements to achieve
customer satisfaction; OMS shall ensure that organization
quality management objectives support Obsolescence Man-
agement; OMS shall be integrated into the Quality Manage-
ment Plan (G3).
3.1.3. Project Process
3.1.3.1. Project Planning Process. The purpose of the
Project Planning Process is to create and communicate effec-
tive and feasible project plans. This process delivers project
plans; defines roles, responsibilities, authorities, and account-
abilities for the project; requests services and resources
needed to meet project objectives; directs staff according to
project plans; activates project plans.
These are the OMS requirements that have been deter-
mined to fall under the Planning Process (requirements are
applicable at H1–H7 except where noted): OMS shall indicate
obsolescence resource constraints (e.g., budget, component
quantity, technologies, etc.); OMS shall be included in the
work breakdown structure; OMS shall define roles, responsi-
bilities, accountabilities, and authorities for Obsolescence
Management; OMS shall estimate the budget required to
support the project; OMS shall determine the required human
resource to support the project; OMS shall identify the infra-
structure requirements (stowage capacity needs, information
technology assets: computers, software, etc.) to support the
project; OMS shall be integrated into the Systems Engineer-
ing Plan (H3).
VIATHE
THESE
SECONTINUUM
CONTINUUM 131
3.1.3.2. Project Assessment and Control Process. The
purpose of the Project Assessment and Control Process is to
determine the project status and direct the project plan to
make certain that the project performs according to the estab-
lished plans. This process evaluates projects’ progress against
established requirements; analyzes project performance indi-
cators; ensures that adequate resources and services are pro-
vided to achieve project plan; communicates project status to
responsible parties; defines and directs corrective actions
when project plan is not being achieved.
These are the OMS requirements that have been deter-
mined to fall under the Project Assessment and Control
Process (requirements are applicable at I3–I7 except where
noted): OMS shall specify what performance measures and
data to monitor (e.g., obsolescence metric data); OMS shall
dictate that audits be performed on suppliers with products
that have potential for obsolescence; OMS shall mandate
supplier surveys to assist in predicting product obsolescence;
OMS shall use predictive tools [e.g., Obsolescence Manage-
ment Information System (OMIS), Government and Industry
Data Exchange Program (GIDEP), etc.] to evaluate hierarchy
of system to predicting product obsolescence; OMS shall
report and communicate Obsolescence Management issues as
they arise, and define and direct corrective actions; OMS shall
evaluate new technologies to assist with eliminating obsoles-
cence issues (I1–I6)—consider using the Mitigation of Obso-
lescence Cost Analysis (MOCA) software for technology
insertions to help mitigate obsolescence issues [Sandborn,
2004].
3.1.3.3. Decision Management Process. The purpose of
the Decision Management Process is to choose the best course
of project action where alternatives exist. This process defines
and plans decisions; analyzes decision information; and
tracks decisions.
These are the OMS requirements that have been deter-
mined to fall under the Decision Management process (re-
quirements are applicable at J1–J7 except where noted): OMS
shall determine who has the authority to make what decisions
(e.g., management buy-in) related to Obsolescence Manage-
ment; OMS shall make decisions related to technical (e.g.,
electrical, mechanical, etc.) obsolescence issues; OMS shall
make decisions related to enterprise (contracts, budgets, poli-
cies, procedures, etc.) obsolescence issues; OMS shall make
obsolescence decisions based on obsolescence prioritization
planning (J3–J6); OMS shall make obsolescence decisions
based on trade-studies; OMS shall make decisions related to
technology refresh plans (J1–J6); OMS shall make decisions
related to technology insertion plans (J1–J6); OMS shall
make decisions related to Risk Management regarding obso-
lescence; OMS shall determine how decisions for obsoles-
cence will be reported and maintained.
3.1.3.4. Risk Management Process. The purpose of the
Risk Management Process is to continuously identify, ana-
lyze, treat, and monitor the risks.
These are the OMS requirements that have been deter-
mined to fall under the Risk Management Process (require-
ments are applicable at K1–K7): OMS shall identify
obsolescence risks; OMS shall analyze obsolescence risks;
OMS shall prioritize obsolescence risks; OMS shall deter-
Systems Engineering DOI 10.1002/sys
132 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI
mine how the obsolescence risks will be mitigated; OMS shall
determine how obsolescence risks will be reported.
3.1.3.5. Configuration Management Process. The pur-
pose of the Configuration Management Process is to deter-
mine and maintain the integrity of all identified outputs of a
process or project and make them available to the appropriate
stakeholders. This process plans and performs configuration
management.
These are the OMS requirements that have been deter-
mined to fall under the Configuration Management Process
(requirements are applicable at L3–L7 except where noted):
OMS shall mandate system configuration control; OMS shall
identify items (e.g., system elements, components, parts)
under configuration control that have been identified as a
candidate for becoming obsolete (markings, identifiers, etc.);
OMS shall store controlled obsolete items (e.g., system ele-
ments, components, and parts that will be retained for main-
taining existing systems that use these items) in the
appropriate environment (e.g., temperature); OMS shall
maintain strict control and access to controlled obsolete items;
OMS shall maintain configuration data for controlled obso-
lete items; OMS shall update the configuration data when
obsolete items are deleted from the system and new items are
added to replace these obsolete items (L3–L6).
3.1.3.6. Information Management Process. The purpose
of the Information Management Process is to provide rele-
vant, timely, complete, and valid information to designated
stakeholders. This process produces, collects, transforms,
stores, retrieves, disseminates, and disposes of information. It
manages technical, project, organizational, agreement, and
user information.
These are the OMS requirements that have been deter-
mined to fall under the Information Management Process
(requirements are applicable at M1–M7): OMS shall define
the Obsolescence Management information that needs to be
managed; OMS shall determine the content and format of
information; OMS shall identify who has the authority to
originate, generate, archive, and dispose of this information;
OMS shall determine who can access and retrieve this Obso-
lescence Management information.
3.1.3.7. Measurement Process. The purpose of the Meas-
urement Process is to gather, analyze, and report data relating
to the products and processes, to support effective manage-
ment of those processes, and to validate quality of products.
These are the OMS requirements that have been deter-
mined to fall under the Measurement Process (requirements
are applicable at N1–N7): OMS shall determine the obso-
lescence information needs of technical and management
personnel; OMS shall determine the required data to be
collected, analyzed, and reported to support obsolescence
needs; OMs shall define the criteria to evaluate this obso-
lescence data.
3.1.4. Technical Processes
3.1.4.1. Stakeholder Requirements Definition Process.
The purpose of the Stakeholder requirements Definition Proc-
ess is to define the system requirements that can provide the
products and services needed by stakeholders in a defined
environment. This process elicits requirements, defines stake-
Systems Engineering DOI 10.1002/sys
holder requirements, analyzes stakeholder requirements, and
maintains stakeholder requirements.
These are the OMS requirements that have been deter-
mined to fall under the Stakeholder Requirements Definition
Process (requirements are applicable at O1–O3): OMS shall
identify all stakeholders who have knowledge and experience
in Obsolescence Management; OMS shall document all Ob-
solescence Management System requirements (this paper can
be used as a starting point for those requirements); OMS shall
define any constraints on the Obsolescence Management
System requirements (e.g., budget, stowage capacity, human
resources, etc.).
3.1.4.2. Requirements Analysis Process. The purpose of
the Requirements Analysis Process is to take stakeholder
requirements and transform them into a technical view of a
required product that could meet those services. This process
defines system requirements, analyzes system requirements,
and maintains system requirements.
These are the OMS requirements that have been deter-
mined to fall under the Requirements Analysis Process (re-
quirements are applicable at P2–P3): OMS shall, during the
defining of the systems functional boundaries and interfaces,
consider generic system development [common design across
various platforms (e.g., aircraft carriers and submarines)] and
common interfaces (plug and play modules) to eliminate
redesign or rework due to obsolescence; OMS, when consid-
ering how long the system needs to last/perform, shall take
into account how obsolescence might affect critical systems;
OMS shall define all stakeholder constraints/limitations re-
lated to obsolescence; OMS, when specifying system require-
ments and functions based on risk and criticality, shall be sure
to consider obsolescence issues related to reliability, avail-
ability, and supportability; OMS shall analyze all Obsoles-
cence Management requirements and make sure all
requirements have been clearly identified and defined.
3.1.4.3. Architectural Design Process. The purpose of the
Architectural Design Process is to synthesize design solution
so that system requirements are satisfied. This process per-
forms effectiveness assessments, tradeoff analysis, and risk
analysis that will lead to the most feasible and optimized
design.
These are the OMS requirements that have been deter-
mined to fall under the Architectural Design Process (require-
ments are applicable at Q1–Q7, except where noted): OMS,
when developing the design criteria for system elements, shall
verify that it is sustainable through life time support methods;
OMS shall, when determining to use commercial-off-the-
shelf (COTS) system elements, evaluate alternative design
solution through trade studies (Q1–Q6); OMS shall ensure
that COTS will be supported by design configuration methods
and obsolescence control and notification (Q1–Q6); OMS
shall determine whether obsolescence system elements can be
reused and how these elements will be managed and control-
led for reuse and retention; OMS shall design and refine
(technology insertions or technology refresh) system alterna-
tives through the use of trade studies, business case analysis,
and technology roadmaps—technology evaluations (avail-
able and emerging) (Q1–Q6).
3.1.4.4. Implementation Process. The purpose of the
Implementation Process is to create a specified system ele-
 PROACTIVE OBSOLESCENCE
PROACTIVE MANAGEMENT
OBSOLESCENCE SYSTEM
MANAGEMENT
SYSTEM
ment. This process uses the allocated requirements for the
system element to design, code, fabricate, or build each
individual element using specified processes, standards, ma-
terial, and technologies based on drawings, instructions, and
other design information.
These are the OMS requirements that have been deter-
mined to fall under the Implementation Process (requirements
are applicable at R1–R7 except where noted): OMS shall
determine how procedures, fabrication processes, tooling,
and equipment will be managed and supported in regards to
obsolescence (R3); OMS shall determine a system element
replacement strategy (technology insertion, technology re-
fresh, etc.) to mitigate obsolescence issues; OMS shall focus
on critical limitation areas, such as old and new technologies
and materials that might introduce risks associated with ob-
solescence.
3.1.4.5. Integration Process. The purpose of the Integra-
tion Process is to develop a system by assembling it based on
the architectural design. This process assembles system ele-
ments to form complete or partial systems to create a product
dictated by the system requirements.
These are the OMS requirements that have been deter-
mined to fall under the Integration Process (requirements are
applicable at S4 except where noted): OMS shall ensure that
system elements are available for integration and not delayed
due to obsolescence issues; OMS shall determine how system
integration items (e.g., jigs, assembly equipment) will be
managed in regards to system element obsolescence (S4–S7);
OMS shall ensure, when obtaining system elements from
stowage that have been identified as controlled obsolete
items, that there are appropriate control requirements (secu-
rity, inventory management, etc.) in place (S4–S7).
3.1.4.6. Verification Process. The purpose of the Verifi-
cation Process is to confirm that the system fulfills the speci-
fied design requirements. This process plans verification and
performs verification on the system elements.
The following is the OMS requirement that has been
determined to fall under the Verification Process (requirement
is applicable to T3–T4): OMS shall verify that design meets
Obsolescence Management system requirements (e.g., sus-
tainment requirements, configuration requirements, risk man-
agement requirements, etc.).
3.1.4.7. Transition Process. The purpose of the Transition
Process is to create a capability to provide services directed
by stakeholder requirements in the operational environment.
This process installs a verified system, along with enabling
systems as defined in agreements.
These are the OMS requirements that have been deter-
mined to fall under this Transition Process (requirements are
applicable at U4–U5): OMS shall ensure that proper system
configuration is recorded to properly track system element
obsolescence issues; OMS shall ensure that proper storage,
handling, and shipping methods have been established for
system elements obsolescence items so they are not damaged,
mishandled, or misplaced; OMS shall ensure that service is
sustainable by the Obsolescence Management system; OMS
shall ensure that enabling systems are sustainable and do not
have obsolescence issues.
3.1.4.8. Validation Process. The purpose of the Validation
Process is to provide evidence that the system’s services,
FRAMEWORK
VIAVIA
FRAMEWORK THE SESE
THE CONTINUUM 133133
CONTINUUM
when in operation, meet the terms of the stakeholders’ re-
quirements in its intended operational environment.
The following is the OMS requirement that has been
determined to fall under the Validation Process (requirement
is applicable to V3–V4): OMS shall validate that the right
Obsolescence Management system requirements have been
created that supports the stakeholder obsolescence require-
ments in the operational environment and that they will
achieve customer satisfaction.
3.1.4.9. Operation Process. The purpose of the Operation
Process is to deliver expected services when the system is in
use. This process prepares the system for operations, performs
system activation, and verifies that the system is meeting the
customer’s needs.
These are the OMS requirements that have been deter-
mined to fall under the Operation Process (requirements are
applicable at W5): OMS shall monitor system elements that
have been identified as having obsolescence concerns; OMS
shall identify new system elements that might become obso-
lete; OMS shall prioritize and resolve these system elements
obsolescence issues; OMS shall develop modernization (e.g.,
technology insertions, technology refresh, etc.) plans to sus-
tain system elements due to system element obsolescence
issues during operation.
3.1.4.10. Maintenance Process. The purpose of the Main-
tenance Process is to sustain system capability to provide a
service. This process plans maintenance and performs main-
tenance.
These are the OMS requirements that have been deter-
mined to fall under the Maintenance Process (requirements
are applicable at X6): OMS shall determine how system
elements with obsolescence issues will be obtained (e.g.,
bridge buy, life time buy, etc.) to support the system; OMS
shall determine the appropriate quantities of obsolete sys-
tem elements that need to be available to support the system
maintenance replacement plan and predicted failure rates;
OMS shall document and record the replacement of obso-
lete system elements; OMS shall determine the proper
storage and handling of the obsolete system elements that
will be used to support the system; OMS shall determine if
the obsolete system elements that are being replaced for
maintenance can be refurbished to sustain the life of these
system elements.
3.1.4.11. Disposal Process. The purpose of the Disposal
Process is to end the system entity existence. This process
plans disposal, performs disposal, and finalizes disposal.
These are the OMS requirements that have been deter-
mined to fall under the Disposal Process (requirements are
applicable at Y7): OMS shall identify obsolete system ele-
ments to be retained for reuse to support systems that still have
these system elements installed; OMS shall determine the
proper storage and handling of these Obsolete system ele-
ments (e.g., might have radiation concerns, etc.); OMS shall
determine the proper disposal/destruction methods of system
elements to prevent counterfeit system elements reentering
the supply chain.
Systems Engineering DOI 10.1002/sys
134
134 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI
3.2. Supporting Artifact for the Obsolescence
Management System Framework
3.2.1. Context Diagram for the Obsolescence Management
System Process
The Context Diagram for the Obsolescence Management
System Process would be an artifact that would fall under the
Life Cycle Management Process. This will be an excellent
artifact to use to show the Obsolescence Management System
Process, both in diagram and text, to systems engineers and
others that need to be knowledgeable in this process.
The following format for the context diagram was used to
ensure consistency with ISO/IEC-15288 [ISO/IEC-15288,
2008], and to following the same guidelines as presented in
the INCOSE Systems Engineering Handbook [INCOSE,
2010].
3.2.1.1. Purpose. The Purpose of the Obsolescence Man-
agement System Process is to manage, analyze, monitor,
resolve, record, and report obsolescence issues continuously
throughout the System Life Cycle Stages.
The Obsolescence Management Process needs to be im-
plemented across the System Life Cycle Processes.
Figure 4. Context diagram for the Obsolescence Management System Process.
Systems Engineering DOI 10.1002/sys
3.2.1.2. Description. It is inevitable that system elements
will go obsolete over time. Obsolescence Management en-
sures that system elements are managed, analyzed, monitored,
and, if obsolescence issues arise, then will be resolved, re-
corded, and reported.
A typical strategy for coping with obsolescence issues is
determining the probability of system elements going obso-
lete and the impact (technical, schedule, cost) to the system.
An obsolescence prioritization schema is very important to
make sure the most critical system elements are analyzed first
to reduce the likelihood of the system shutting down. Figure
4 shows the context diagram for the Obsolescence Manage-
ment System Process.
3.2.1.3. Inputs. The inputs to the Obsolescence Manage-
ment Process include the following:
• Candidate Obsolescence Issues—Obsolescence issues
may come from any stakeholder and originate from any
System Life Cycle Process. Obsolescence issues need
to be identified at the very beginning of the life cycle
(concept stage) and through the very end of the life
cycle (retirement).
 PROACTIVE
PROACTIVEOBSOLESCENCE
OBSOLESCENCEMANAGEMENT
MANAGEMENTSYSTEM
SYSTEMFRAMEWORK
FRAMEWORKVIA
• Technology Roadmaps—use to assist in evaluating sys-
tems, processes, and technologies as they relate to
obsolescence.
• Business Case Analysis—use to assist the Obsoles-
cence Management System in the decision making
process
• Trade Studies—use to support obsolescence in deter-
mining alternative solutions.
3.2.1.4. Controls/Enablers. This process is governed by
the following controls and enablers:
• Applicable Laws and Regulations
• Government and Industry Standards— relevant gov-
ernment and industry specifications and standards
• Contracts and Agreements—terms and conditions of
contracts and agreements
• Project Procedures and Standards— including project
plans and project system engineering plans
• Project Directives
• Organization/Enterprise Policies, Procedures, and
Standards
• Organization/Enterprise Infrastructure
• Project Infrastructure.
3.2.1.5. Outputs. Outputs of the Obsolescence Manage-
ment Process include the following:
• Obsolescence Management System Plan.
• Obsolescence Management Profile—Sometimes re-
ferred to as a obsolescence prioritization matrix; it
contains the findings of the Obsolescence Management
Process.
• Obsolescence Management Reporting—The obsoles-
cence issues are documented and communicated along
with mitigation plans, and current status. For selected
obsolescence issues, an action plan is produced to direct
the project team to properly respond to the obsoles-
cence issue.
3.2.1.6. Process Activities. The Obsolescence Manage-
ment Process includes the following activities:
• Plan Obsolescence Management:
– Identify and define the components required in the
Obsolescence Management Plan.
– Document the Obsolescence Management strategy
(plan).
• Manage the Obsolescence Profile:
– Define and document obsolescence issue thresholds
and acceptable and unacceptable obsolescence issue
conditions (at the system and subsystem level).
– Communicate the obsolescence issues with the ap-
propriate stakeholders.
Table II. Case Study Results for the Agreement Processes
VIATHE
THESE CONTINUUM 135
SECONTINUUM 135
• Analyze Obsolescence Issues:
– Identify obsolescence issue.
– Analyze risks for probability and impact (technical,
schedule, cost, overall) to determine the magnitude
of the obsolescence issue and its priority for resolu-
tion.
– Define a resolution scheme and resources for each
obsolescence issue, including identification of a per-
son who will be responsible for continuous assess-
ment of the status of the situation until it is resolved.
• Resolve Obsolescence Issues:
– Using the criteria for acceptable and unacceptable
obsolescence issues, generate a plan of action when
the obsolescence threshold exceeds acceptable lev-
els.
• Monitor Obsolescence Issues:
– Maintain a record of obsolescence issues and how
they were managed.
– Maintain transparent Obsolescence Management
communications.
• Evaluate the Obsolescence Management Process:
– Define, analyze, and document measures indicating
the status of the obsolescence issues and the effec-
tiveness of the management of these obsolescence
issues.
4. A CASE STUDY ILLUSTRATION FOR THE
OBSOLESCENCE MANAGEMENT SYSTEM
FRAMEWORK
To validate and test that the Obsolescence Management Sys-
tem framework met the requirements stated in Section 1—
“ The Obsolescence Management System framework shall
provide guidance to Obsolescence Management decision-
makers in developing an Obsolescence Management plan” —
a case study was performed. The case study included
reviewing and analyzing an East Coast Technical Organiza-
tion’s (ECTO) Obsolescence Management System Plan (Ob-
solescence Management Plan). The organization developed
its first Obsolescence Management plan within the last 5
years. The case study was then compared against the initially
suggested Obsolescence Management System framework re-
quirements to determine if there were gaps in the organiza-
tion’s Obsolescence Management Plan.
A summary of the case study results for the Agreement
Processes, Organizational Project-Enabling Processes, Pro-
Systems Engineering DOI 10.1002/sys
136
136 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI

Table III. Case Study Results for the Organizational Project-Enabling Process

ject Processes, and Technical Processes are shown in Tables
II, III, IV, and V, respectively. From the summary results, it
can be seen that there are Obsolescence Management System
requirement gaps in the ECTO’s OMP throughout the System
Life Cycle Processes.
5. CONCLUSION AND RECOMMENDATION
To ensure that systems continue to be effective and opera-
tional throughout the System Life Cycle Stages (exploratory
research, concept, development, utilization, support, and re-
tirement), an Obsolescence Management System (OMS)
framework is proposed to support this effort. In this paper, we
have provided a summary background of obsolescence issues
and concerns and the need for organizations to have a system-
atic approach to managing systems from an Obsolescence
Management System perspective. We presented a new sys-
tems engineering architecture framework, House of Systems
Engineering (HoSE), and explained and defined its con-
structs. Next, we showed how the HoSE constructs were
applied to build a 2-dimensional Obsolescence Management
System framework and explained how its constructs would
support Obsolescence Management from a System Life Cycle
Processes and System Life Cycle Stages perspective; we
identified Obsolescence Management System requirements

Table IV. Case Study Results for the Project Processes

Systems Engineering DOI 10.1002/sys

 PROACTIVE
PROACTIVEOBSOLESCENCE
OBSOLESCENCEMANAGEMENT
MANAGEMENTSYSTEM
SYSTEMFRAMEWORK
FRAMEWORKVIA
Table V. Case Study Results for the Technical Processes
for each of the 25 System Life Cycle Processes and associated
System Life Cycle Stage(s). We also presented a context
diagram for the Obsolescence Management System Process.
Finally, we provided a case study to justify the Obsolescence
Management System framework by comparing the Obsoles-
cence Management System framework requirements against
an east coast technical organization’s Obsolescence Manage-
ment Plan. The case study results suggest that the framework
is beneficial in finding gaps in an Obsolescence Management
plan and therefore would be beneficial in developing an
Obsolescence Management System Plan. The case study did
not reveal any additional Obsolescence Management System
requirements; however, that does not mean there are not
additional requirements to be identified. Therefore, the Ob-
solescence Management System framework should continue
to be reviewed, analyzed, and updated to make the framework
as robust as possible.
Since Obsolescence Management is becoming more and
more recognized by enterprises as being very important for
long-term system success, it is recommended that enterprises
leverage off the various Obsolescence Management working
group’s research in this area. It is also recommended that the
following questions be continuously asked: (1) What are the
current gaps in Obsolescence Management [e.g., lack of focus
on total enterprise obsolescence issues (people, processes,
resources, contracts, etc.)]? (2) What are the latest research
finding related to Obsolescence Management? (3) What are
VIATHE
THESE CONTINUUM 137
SECONTINUUM 137
the key foundational attributes of an Obsolescence Manage-
ment System (e.g., potential problems it could solve, imple-
mentation requirements, and expected benefits)?
In conclusion, it is hoped that this Obsolescence Manage-
ment System framework will be of value for Obsolescence
Management decision-makers in the development of an Ob-
solescence Management Plan.
REFERENCES
T. Bahill, R. Botta, and J. Daniels, The Zachman framework popu-
lated with baseball models, J Enterprise Architecture 2(4)
(2006), 50–68.
S.A. Bernard, An introduction to enterprise architecture, 2nd edition,
AuthorHouse, Bloomington, IN, 2005.
J.C. Bonbright, Major controversies as to the criteria of reasonable
public utility rates, Amer Econ Rev 30(5) (February 1941),
379–389.
R. DiSandro and R. Torok, Managing I&C reliability and obsoles-
cence, Nuclear News 48(5) (2005), 26–32.
M. Drake, Sharing obsolescence information at Raytheon with the
component obsolescence and reuse tool, Reliab Maintainability
Symp, 2003, pp. 277–279.
T. Herald, D. Verma, C. Lubert, and R. Cloutier, An obsolescence
management framework for system baseline evolution—per-
Systems Engineering DOI 10.1002/sys
138
138 POBIAK,
POBIAK,MAZZUCHI,
MAZZUCHI,AND
ANDSARKANI
SARKANI

spectives through the system life cycle, Syst Eng 12(1) (2009),
1–20.
M.A. Howard, Component obsolescence: It’s not just for electronics
anymore, DMSMS Conf, 2002, pp. 1–10.
INCOSE, Systems engineering handbook—a guide for system life
cycle processes and activities, Version 3.2, International Council
on Systems Engineering, Seattle, WA, 2010.
ISO/IEC-15288, Systems and software engineering—system life
cycle process, International Organization for Standardization,
Geneva, 2008.
J. McDermott, J. Shearer, and W. Tomczykowski, Resolution cost
factors for diminishing manufacturing sources and material
shortages, Final Report DMEA90-98-F-0018, US Department of
Defense, Washington, DC, 1999.
Merriam-Webster, Taxonomy, http://www.merriam-web-
ster.com/dictionary/taxonomy, retrieved December 29, 2011.
J.M. Morganwalp and A.P. Sage, Enterprise architecture measures
of effectiveness, Int J Technol Policy Management 4(1) (2004),
81–94.
W.J. Perry, Secretary of Defense memorandum for the secretaries of
military departments—subject: Acquisition reform, Department
of Defense, Washington, DC, 1994.
T.G. Pobiak, The House of Enterprise Architecture Framework,
HRA-INCOSE Cyber Security Enterprise Architecture Conf,
Virginia Beach, VA, 2010.
P. Sandborn, Beyond reactive thinking—we should be developing
pro-active approaches to obsolescence management too!
DMSMS Center Excellence Newsl 2(4) (2004), p. 4 and 9.
P.A. Sandborn, F. Mauro, and R. Knox, A data mining based ap-
proach to electronic part obsolescence forecasting, IEEE Trans
Components Packaging Technol 30(3) (2007), 397–401.
P. Singh and P. Sandborn, Obsolescence driven design refresh plan-
ning for sustainment dominated systems, Eng Econ 51(2) (2006),
115–139.
J.F. Sowa and J.A. Zachman, Extending and formalizing the frame-
work for information systems architecture, IBM Syst J 31(3)
(1992), 590–616.
M. Stankosky, Enterprise management engineering: A systems ap-
proach to leverage knowledge assets in the 21st century economy,
Eur Conf Knowledge Management, 2004, pp. 1–6.
R.C. Stogdill, Dealing with obsolete parts. IEEE Des Test Comput
(1999), 17–25.
J.A. Zachman, A framework for information systems architecture,
IBM Syst J 26(3) (1987), 276–292.

Todd Pobiak has over 21 years of engineering experience. He has worked in both the manufacturing and design
environments. He was employed at Canon Virginia, Inc., Newport News, VA for 8 years as an electrical engineer. Todd
was the founder of PageTech, Inc., Yorktown, VA, a telecommunication company that he operated for 10 years, which
specialized in the sales and service of telecommunication products. Todd is currently an engineer 4 in the Reactor Plant
Planning Yard (RPPY) at Huntington Ingalls—Newport News Shipbuilding, VA. He specializes in the modernization
of the CVN68 Class Aircraft Carriers. He received his engineering degree from The Pennsylvania State University,
University Park, State College, PA (1991), and holds an MBA from Strayer University, Newport News, VA (2007). He
has also completed all requirements for a Ph.D. in Systems Engineering from The George Washington University,
Washington, DC. His dissertation focus was on obsolescence management.

Thomas Mazzuchi received a B.A. (1978) in Mathematics from Gettysburg College, Gettysburg, PA, and an M.S. (1979)
and a D.Sc. (1982), both in Operations Research, from the George Washington University, Washington, DC. Currently,
he is a Professor of Engineering Management and Systems Engineering in the School of Engineering and Applied
Science at the George Washington University. He has also served as Chair of the Department of Operations Research,
as Chair of the Department of Engineering Management and Systems Engineering, and as Interim Dean of the School
of Engineering and Applied Science. Dr. Mazzuchi has been engaged in consulting and research in the area of reliability
and risk analysis for over 25 years. He served for 21⁄2 years as a research mathematician at the International Operations
and Process Research Laboratory of the Royal Dutch Shell Company, Amsterdam, Netherlands. While at Shell, Dr.
Mazzuchi was involved with reliability and risk analysis of large processing systems, maintenance optimization of
off-shore platforms, and quality control procedures at large-scale chemical plants. During his academic career, he has
held research contracts in development of testing procedures for both the U.S. Air Force and the U.S. Army, in spares
provisioning modeling with the U. S. Postal Service, in mission assurance with NASA, and in maritime safety and risk
assessment with the Port Authority of New Orleans, the Washington Office of Marine Safety, Washington State
Department of Transportation, and the San Francisco Bay Area Transit Authority.

Systems Engineering DOI 10.1002/sys

 PROACTIVE
PROACTIVEOBSOLESCENCE
OBSOLESCENCEMANAGEMENT
MANAGEMENTSYSTEM
SYSTEMFRAMEWORK
FRAMEWORKVIA
VIATHE
THESE CONTINUUM 139
SECONTINUUM 139

Shahram Sarkani, Ph.D., P.E., is Professor of Engineering Management and Systems Engineering, and Faculty Adviser
and Academic Director of EMSE Off-Campus Programs (since 2001), at the George Washington University, Washing-
ton, DC. Professor Sarkani joined the George Washingotn University faculty in 1986, where his administrative
appointments include chair of the Civil, Mechanical, and Environmental Engineering Department (1994–1997) and
Interim Associate Dean for Research, School of Engineering and Applied Science (1997–2001). In over 150 technical
publications and presentations, his research in systems engineering, systems analysis, and applied enterprise systems
engineering has application to risk analysis, structural safety, and reliability. He has conducted sponsored research with
such organizations as NASA, NIST, NSF, U.S. AID, and the U.S. Departments of Interior, Navy, and Transportation.
Professor Sarkani holds the Ph.D. in Civil Engineering from Rice University, Houston, TX, and B.S. and M.S. degrees
in Civil Engineering from Louisiana State University, Baton Rouge, LA. He is a Registered Professional Engineer in
Virginia.

Systems Engineering DOI 10.1002/sys