PLAN FOR TECHNOLOGY INSERTION
FOCUS AREA: PROJECT MANAGEMENT – Change Management
Definition and Summary: Planning how to preserve the capability of a system over its life cycle by keeping the technology employed in a system sufficiently up-to-date to avoid obsolescence and associated sustainment problems
The term “technology insertion (TI)” emerged in the 90’s, partially in response to the emphasis on COTS. It is used with varying focus in the literature today. Thus, the boundaries of its definitions are evolving. It has close ties and some overlap with all of the terms in the technology puzzle
How you plan for TI and what you do depends on who you are and where you sit in the organizational scheme of things. If you are at the program office level or above your planning needs to focus on enabling TI. If you’re a program or project level manager your planning needs to focus on alignment and implementation. If you are an acquisition specialist your focus will probably be on ensuring that resources are available to investigate TI opportunities, and that implementation of TI is properly aligned with strategic TI plans.
The figure below identifies the essential activities that comprise planning for technology insertion, regardless of the level. It involves recognizing the challenge, accepting that TI is a continuous process, and making the commitment in terms of funding and resources to support it in reality. It may also involve a commitment to effecting an organizational culture change in order to realize the desired affordability gains. The spiral suggests that planning for TI is like many other planning /process improvement initiatives.
Planning for Technology Insertion
Planning for technology insertion can result in:
- Increased effective operational life of a system, or system of systems
- Improved Affordability
- Reduced Risk
SUMMARY DESCRIPTION
The term “technology insertion (TI)” emerged in the 90s, partially in response to the emphasis on COTS. It is used with varying focus in the literature today. Thus the boundaries of its definitions are evolving. It has close ties and some overlap with all of the terms in the technology puzzle presented in the figure below. In some instances some of these terms have been used interchangeably with TI. One could also include technology “adoption”, “transfer”, and “evolution” in the puzzle.
How you plan for TI and what you do depends on who you are and where you sit in the organizational scheme of things. If you are at the program office level or above your planning needs to focus on enabling TI. If you’re a program or project level manager your planning needs to focus on alignment and implementation. If you are an acquisition specialist your focus will probably be on ensuring that resources are available to investigate TI opportunities, and that implementation of TI is properly aligned with strategic TI plans.
The next figure identifies the essential activities that comprise planning for technology insertion regardless of the level. It involves recognizing the challenge, accepting that TI is a continuous process, and making the commitment in terms of funding and resources to support it in reality. It may also involve a commitment to effecting an organizational culture change in order to realize the desired affordability gains. The spiral suggests that planning for TI is like many other planning /process improvement initiatives.
DETAILED DESCRIPTION
The term “technology insertion (TI)” emerged in the 90s, partially in response to the emphasis on COTS. It is used with varying focus in the literature today. Thus the boundaries of its definitions are evolving. It has close ties and some overlap with all of the terms in the technology puzzle presented in Figure 1. In some instances some of these terms have been used interchangeably with TI.
One could also include technology “adoption”, “transfer”, and “evolution” in the puzzle. Specific definitions of these terms are provided in the Glossary.
Interoperability, adaptability, and evolvability are desired states (attributes) of a system (or system of systems) that facilitate technology insertion. Technology migration is essentially a technical strategy for achieving a desired state. Such a strategy is often an enabling factor for technology insertion but in some of the literature technology insertion is viewed as the broader process that may include a “migration” strategy. Technology transition, technology transfer, and technology insertion are sometimes used interchangeably but transition focuses more on the originator of the technology successfully “pushing” the technology to prospective domains/users while insertion focuses on the domain/user investigating and “pulling” technology into a system to meet a particular need. Technology transfer typically focuses on moving technology from one large domain to another (e.g. commercial to military or vice versa). Integration activity makes the outcomes of insertion and/or transition “transparent” to the end users. All are about sustaining or enhancing technical capability in a timely yet cost-effective way; choice of term used often depends on the experience and level of responsibility of the speaker (writer). The remaining content is premised upon the definitions of technology insertion provided at the beginning of this document.
Although the definitions are in conflict with respect to one motivating factor – capability (preserve existing vs. “get more”), they are essentially the same otherwise. Both are driven by the need to provide the warfighter with the “needed” capabilities by sustaining or improving performance and reducing cost (or preventing costs from increasing due to the need to support aging technology) in a constantly changing technical environment. An important note is that the motivation for doing technology insertion is embedded in the definition.
Planning for technology insertion may have a different focus depending on the level of responsibility, and the life cycle stage of the system (or program). Planning to sustain the capability of a legacy system is vastly different from planning for TI during architecting for a new family of systems. Planning done by the architect for a System-of-Systems(S-O-S) is significantly different from the planning done by the Project Manager responsible for one of the systems.
How you plan for TI and what you do depends on who you are and where you sit in the organizational scheme of things. If you are at the program office level or above your planning needs to focus on enabling TI. If you’re a program or project level manager your planning needs to focus on alignment and implementation. If you are an acquisition specialist your focus will probably be on ensuring that resources are available to investigate TI opportunities, and that implementation of TI is properly aligned with strategic TI plans.
Figure 2 identifies the essential activities that comprise planning for technology insertion regardless of the level. It involves recognizing the challenge, accepting that TI is a continuous process, and making the commitment in terms of funding and resources to support it in reality. It may also involve a commitment to effecting an organizational culture change in order to realize the desired affordability gains. The spiral suggests that planning for TI is like many other planning /process improvement initiatives.
Figure 2: Plan for Technology Insertion
Recognize the challenge
Primary challenges include:
· Preserve/enhance capability while applying continuously evolving technology.
· Improve affordability over the life cycle of the system. ROI may not be immediate.
TI does not just happen. Continuous system engineering is required to preserve the integrity of a system in the ever-changing technical environment.
Significant affordability gains result from enabling TI in core technologies that support a broad spectrum of projects and programs but in many domains that collection of core technologies does not yet exist. Consequently many efforts, named as “insertion initiatives” are actually focused on migrating from the current “stove pipe” scenario to an open systems approach in which participating programs (or projects) are supported by core technologies. This migration makes it possible for TI to occur in the future and have a favorable impact on affordability. Figure 3 illustrates the role of a technology insertion plan at the domain level in order to enable TI to improve affordability over time.
Figure 3: The Affordability Challenge
Within any given domain there may be a combination of long standing programs as well as new ones. Typically the programs within the domain (named A, B, C, D, and E in Figure 3) were developed independently and consequently have unique technologies. Thus at the domain level there is a literal “bucket” of technology that has to be supported in order to preserve the capabilities of the programs. This drives up the support costs more and more because of the breadth of technologies supported in addition to the costs of technology obsolescence. Planning for TI at the domain level must therefore focus on a migration strategy to establish a common core of technology that can support most of the programs in the domain. Affordability is addressed by allocating the cost of the technology across the participating programs, and by decreasing the variability of technologies to be supported. When core technologies are established then affordability is addressed by applying TI (narrower/tactical definition) to the core technologies over time.
The migration path is complex. Existing programs are in various stages of their life cycle many with huge investments. Most programs are providing a vital operational capability to the warfighter, and cannot be halted. It is not possible (from a funding perspective) to concurrently migrate all programs. So, what is the basis for decisions regarding the priority and extent of migration? What are the core technologies? What innovative technologies are out there? How/when do we select a technology? Answering these questions (which are on-going in nature) is what planning for technology insertion is all about at the domain (or program office) level. It constitutes a major cultural shift as well – from competition to joint cooperation within and among the program offices.
It may be that although you recognize the need for planning for TI, control of the subject system or capability resides at a different level. In this case your plan should focus on how to influence the strategy and decision making that is occurring at the level of control.
Make the commitment: Allocate staff, facilities, and investments for continuous engineering and testing for technology insertion and/ or product evolution. The commitment may also involve partnering with organizations (previously seen as competitors) to share the burden of continuously investigating new technologies, and also tapping the resources of technology transfer initiatives such as the SEI’s technology adoption program. At the project or system level the commitment is one of addressing technology insertion as a recurring task on the effort and planning for it like any other task. Budget for it. Acquire skilled people who are sufficiently knowledgeable in the targeted technical areas to analyze new technology candidates. Provide training to existing staff on a continual basis to ensure that they grow with the technology.
Formulate a plan
Planning for TI is an on-going process with different emphasis at different levels and at different stages of the life cycle. At the system level the plan is often produced and maintained by the contractor responsible for system integration, and approved or agreed to by the government program manager. It is at this level where key decisions from above are implemented and TI becomes a reality. There is no standard, per se, by which to judge the adequacy of a technology insertion plan, but it should address the following items as identified in Table 1. The plan has two main sections, Scope, and Management (Logistics).
Table 1: Technology Insertion Plan - Contents
Scope
Clearly define scope of applicability for the plan. What capability(ies) is the plan addressing and for what timeframe? |
Does the plan address a specific component, project, system, group of systems, a program, a domain, etc.? |
· Identify insertion opportunities
|
Where in the subject system(s) are there opportunities for inserting new technology? What components are candidates? |
· Relate them to planned increments or capabilities of the subject system |
What capability does each insertion opportunity sustain or enhance, or, what new capability is addressed? |
· Define the limits (boundaries) for the activity |
Does this activity fit into the planned acquisition strategy? Are we doing more than we should be doing in this phase of the effort? Is this well aligned with the development effort with respect to time and budget? |
Management
Address the who, what, where, when, and why for each initiative |
What is our technology insertion process?
Will it work for each insertion initiative?
How will we capture lessons learned?
Does our current management culture need to change in order to effectively plan for technology insertion? If so, how? |
· Describe the management structure that will drive the implementation of each insertion effort. Address
§ Accountability
§ Responsibility
§ Involvement of functional specialists |
Who should be involved? How will we ensure that the best new technologies are assessed before making our decision? Who needs to be involved in alternative technology assessment? What are our criteria for assessment of each opportunity?
What is the time frame for each initiative? |
· Ensure that each implementation is consistent with the approved operational requirements, acquisition strategy, and other acquisition decisions |
How good is the fit between this insertion opportunity and the over all goals of the program? Is this well aligned with the TI initiative of higher authorities? Is there a compelling need for it? Or, is it just something we would like to do? What is the priority of this insertion relative to other identified opportunities? |
· Maintain configuration control of the deployed system |
How do we safeguard the fielded system while we experiment with this insertion initiative?
How do we roll out a new release and in so-doing ensure that support people and those responsible for designing and developing subsequent blocks of capability have the right information to work with? |
· Ensure adequate testing with documented evidence that the system remains operationally effective after the technology insertion |
How will we test the system to determine the effectiveness of the TI? Should we have a pilot implementation? |
· Ensure fielding of the change is coordinated (with training and support) |
Who needs to be involved and when in order to ensure that when the release is fielded, the proper support will also be in place? |
Follow the plan: Follow the plan! Follow the Plan! Don’t abandon the plan after working so hard to make it.
Lessons Learned: Revisit the plan frequently, each time assessing its effectiveness and capturing any lessons learned. Recognize that lessons learned may be related to people or process, as well as technology.
Revise the TI process: Because of its on-going nature it is important to establish a process for TI that that is repeatable over time. The process in turn provides the guidance for each TI planning cycle, and stability for new staff or organizations that participate in the TI process. Refine the process with lessons learned from each iteration.
SUMMARY CHARACTERISTICS
NO DATA CURRENTLY AVAILABLE
Planning for technology insertion can result in:
- Increased effective operational life of a system, or system of systems
Indeed the 2nd most important driver of technology insertion is making systems more affordable over the entire life cycle.
Planning for TI at the earliest stages of software development (during architecting) establishes the evolvability and supportability of the system thereby reducing the risk and cost associated with sustaining its capability over its life cycle.
DETAILED CHARACTERISTICS
Key Characteristics of the “Plan for Technology Insertion” Gold Practice
Characteristic |
Comments |
On-going process |
· Technology keeps changing and so do requirements. Status quo drives up cost.
· TI is a means of continually adjusting to the changing environment |
Long term focus – short term implementation |
· Affordability gains are tied to scalability of TI over time and ease of inserting new technology
· Must enable TI first in order to reap the benefits
· TI initiatives are planned to reflect a strategy for long term affordability and performance |
Architecture-centric |
· Success is more likely when TI is addressed at the architecture-level.
· Use of standards and open systems approach enables TI in the future |
Consistent with quality management planning |
· Planning activities are consistent with CMMI practices. |
Top-down approach is most effective |
· Although TI planning is successful at the project/system level for sustaining a given capability, large gains are more likely when TI is addressed at the domain or program office level and then coordinated within the specific programs
· Role of Project/Program Manager is to “coordinate/align” with higher-level TI strategic planning |
Industry invests up-front and shares in downstream benefits |
· Industry is motivated (through innovative acquisition strategy) to develop new technology in order to reap the long term benefits of its insertion |
The Figure below represents a high-level process architecture for the subject practice, depicting relationships among this practice and the nature of the influences on the practice (describing how other practices might relate to this practice). These relationship statements are based on definitions of specific “best practices” found in the literature and the notion that the successful implementation of practices may “influence” (or are influenced by) the ability to successfully implement other practices. A brief description of these influences is included in the table below.
Process Architecture for the "Plan for Technology Insertion" Gold Practice
Summary of Relationship Factors
INPUTS TO THE PRACTICE |
|
Facilitate successful insertion of technology
|
TI in theory is straightforward – but in practice it is very complex. These practices set the stage for TI. If the architecture is designed for flexibility and evolvability then it is easier to insert new technology during the life of the system. Achieving agreement on interfaces is important to TI because the agreements clarify the operational requirements that must be maintained. Use of commercial specifications and standards (the open systems approach) is what adds flexibility, evolvability, and supportability to a system thus increasing the potential opportunities for TI, and the potential for increased affordability resulting from TI. A sound configuration management system is necessary to preserve the integrity of the subject system as it absorbs TI efforts. Performance-based specs give the developer the necessary freedom to explore TI initiatives but still be accountable for designated performance. Structured development methods assist the developer in becoming process focused which helps to establish a repeatable process for TI. Use of Past Performance assists the acquirer in selecting contractors that have demonstrated TI capability. It also functions as a “Lessons Learned” scenario assisting the developer in improving their TI process. |
|
Establish the focus for technology insertion
|
TI is a response to a compelling need to sustain or enhance the capability of a system(s). These practices impact how that need is defined at any given point in time. Life-cycle business case addresses long term costs of sustaining or enhancing the capability; technology obsolescence is a significant risk on many programs and risk mitigation is therefore a driving factor in planning for TI. Without clear goals established up front TI efforts can evolve into “out of control” programs resulting from using TI to address capabilities that are beyond the planned scope of the effort. Requirements tradeoffs negotiations apply to proposed technology insertion initiatives in the same way that the practice applies to initial development efforts. It provides a reality check that defines the actual boundaries of a TI effort. What is most important? What can be funded? |
|
|
Investigate technology insertion candidates
|
Organizations must continually investigate new technology candidates. Sometimes that technology is framed in reuse initiatives, or technology transfer programs. Sometimes, depending on the domain or functional environment of the subject capability, and the evolvability of the subject system or application, the capability is better sustained by replacing a “stovepipe” system with a common (enterprise-wide) system. Recognize that the best decision may be to “scrap” a system or application in favor of something more pervasive and plan accordingly. The pervasiveness as well as the cost of COTS often makes it a likely candidate for TI. These factors have to be weighed against the projected longevity of the COTS and the assessment of the system’s supportability by the COTS developer over time. COTS is viable – but only after a thorough assessment of its ability to totally address the capabilities for which is being considered. |
|
OUTPUTS FROM THE PRACTICE |
|
Direct outcome of successful technology insertion
|
Successful technology insertion efforts may contribute significantly to ensuring interoperability among applications or systems over time for those systems that have been specifically designed for interoperability. However, it does not enable interoperability. TI may increase the degree of interoperability on a specific dimension such as connectivity, or data access. |
|
Assess indirect impact of successful technology insertion
|
Since TI is on-going, and process-focused (establishing a repeatable process for TI, over time), TI should result in an improved acquisition process that focuses on product quality and affordability. Acquirers may want to review a contractor’s TI process as a basis for determining “best value” in acquisitions where success depends on the contractor’s ability to affect TI. |
|
|
|
|
|
RESOURCES:
§
Websites
o
Global Network of Environment and Technology (GNET) Technology Portal
The GNET Technology Portal serves as the "one stop shop" to link the environmental technology development activities of Federal agencies - improving the opportunity for joint programs and projects. The Portal gathers and disseminates information on government technology in a single easy to use on line tool. Although limited to the environmental domain this web site may serve as a model for organizing resources related to a technology insertion effort in other domains as well –particularly in the way it brings all the resources together.
http://www.gnet.org/portal/
§ Tools and Methods
State-of-the-art methods and tools that may be useful in implementing and improving the effectiveness of planning for technology insertion include:
- Modeling & Simulation Tools
Such tools may be used to create executable architectures to verify that the proposed TI will in fact address the subject capabilities, and also to develop testing scenarios for the effort.
Developing a roadmap would establish the strategic context for the insertion initiatives and identify the tactical efforts that are necessary to achieve the stated goals. Roadmaps provide a higher level of planning than a work-breakdown-structure. The level of abstraction keeps the focus on the goals of TI and puts it in the appropriate time frame. Such roadmaps are exemplified in the NAVY AN/UYQ-70 program case study.
A value network is a graphic representation of all of the organizations, groups, and individuals that are or could be involved in the development, marketing, and use of a technology. Valuable information is derived in the course of building such a network that provides insight into innovative technology solutions and partnerships which might provide funding or in-kind resources along with improved speed and efficiency of implementation, and the influence of key players and opinion leaders.
- INTRo (IDEALSM-Based New Technology Rollout), developed by the SEI in conjunction with Computer Associates, is a web-based resource that can be used by software professionals for technology change management as a guide to organizational and technological assessments, proven practices, and methodologies that foster learning. INTRo will be made freely available to interested users through a password-protected SEI website, with modest conditions on its use (e.g., acknowledgement of the CMU copyright and an agreement to provide feedback as part of a registration process).
http://www.sei.cmu.edu/intro/start.html
§ Experts/Contact Points
Jon Ogg, Director, Engineering & Technical Management Directorate, Aeronautical Systems Center (ASC), Air Force Material Command, Wright-Patterson Air Force Base, Dayton, Ohio.
Commercial Phone: (937)255-3208;
Email: jon.ogg@wpafb.af.mil
Responsible for managing change in avionics systems.
§ Training Opportunities:
o Managing Technological Change
http://www.sei.cmu.edu/products/courses/mtc.html
§ Bibliography:
[CMU/SEI-2002-TR-011] |
“Capability Maturity Model Integration (CMMI), Version 1.1 – Continuous Representation”, Software Engineering Institute, CMU/SEI-2002-TR-011, March 2002
http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr001.pdf
|
[CMU/SEI-2002-TR-012] |
“Capability Maturity Model Integration (CMMI), Version 1.1 – Staged Representation”, Software Engineering Institute, CMU/SEI-2002-TR-012, March 2002
http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr002.pdf
|
[Dampier, 1998] |
Dampier, David A., “Rapid Prototyping and Incremental Evolution”, Software Tech News, Vol. 2 No. 1, 1998
https://www.softwaretechnews.com/technews2-1/evolution.php |
[DESKBOOK,2002] |
“Technology Insertion and Evolutionary Acquisition”, DoD-wide Discretionary Practice, DoD On-Line Deskbook, maintained by Defense Acquisition University in partnership with OSD (AT&L)/Services/Agencies
http://legacydeskbook.dau.mil/scripts/rwisapi.dll/@e_search.env?CQ_PROCESS_LOGIN=YES
&CQ_LOGIN=YES&CQ_USER_NAME=guest&CQ_PASSWORD=guest&CQ_SAVE[SearchText
]=Technology++Insertion+Evolutionary+Acquisition&CQ_SAVE[file_name]=2\25\251\2512\
2512J03.HTM&CQ_SAVE[docid]=DskBkInfSt833&CQ_SAVE[CQlibs]=DskBkInfSt&CQ_SAVE
[T]=#FIRSTHIT |
[Evans, 1987] |
Evans, Michael W. & Marciniak, John. Software Quality Assurance and Management. New York, NY: John Wiley & Sons, Inc., 1987. |
[Failmezger, 1999] |
Environmental Management Technology Leveraging Initiative
http://www.netl.doe.gov/publications/proceedings/99/99em/emp1-4.pdf |
[Heinz, 2001] |
Heinz, Lauren, “TransPlant: Helping Organizations to Make the Transition”, News@SEI Interactive Vol. 4, No. 4, 4th Quarter 2002 |
[INTERIM, 2002] |
“Interim Defense Acquisition Guidebook”, 30 October 2002
(Replaces DoD 5000.2-R, canceled 30 October 2002)
|
[NRAC,2002] |
“Executive Summary – Life Cycle Technology Insertion”, Naval Research Advisory Committee, July, 2002
http://nrac.onr.navy.mil/webspace/exec_sum/02lcti.html |
[Ogg, 2001] |
Bowers, Pamela, “The Air Force Develops an Initiative to Manage Change in Avionics Systems” [Interviewing Jon Ogg], Crosstalk, Sept. 2001.
http://www.stsc.hill.af.mil/crosstalk/2001/09/ogg.html |
[Subramanian, 2000] |
Subramanian, Nary, & Chung, Lawrence, “Metrics for Software Adaptability”, Applied Technology Division, Anritsu Company, Richardson, TX, USA, 2000
http://www.utdallas.edu/~chung/ftp/sqm.pdf |
[Turner, 2002] |
Turner, R.G., “Implementation of Best Practices in U.S. Department of Defense Software-Intensive System Acquisitions”, Ph.D. Dissertation, George Washington University, 31 January 2002 |
[Wall, 2002] |
Wall, Robert, “Cost Problems Embroil F/A-22”, Aviation Week & Space Technology, November 18, 2002
http://www.aviationnow.com/content/publication/awst/20021118/aw34.htm |
APPENDICES
The practice of planning how to preserve the capability of a system over its life cycle by keeping the technology employed in a system sufficiently up-to-date to avoid obsolescence and associated sustainment problems, and to take advantage of greater efficiencies, lower costs, and other benefits provided by newer technology.
[Deskbook, 2002]
The process for both identifying and exploiting new technology in order to effect timely delivery of cost-effective capabilities to the warfighter.
[NRAC,2002]
NONE INDICATED
§ DoD 5000.2-R, “Mandatory Procedures for Major Defense Acquisition Programs (MDAPS) and Major Automated Information System (MAIS) Acquisition Programs”, 5 April 2002 [CANCELLED 30 October 2002]
§ Interim Defense Acquisition Guidebook, 30 October 2002 [INTERIM 2002]
Applying Best Practices. In tailoring an acquisition strategy, the Program Manager (PM) shall address management constraints imposed on the contractor(s). PMs shall avoid imposing Government-unique restrictions that significantly increase industry compliance costs or unnecessarily deter qualified contractors, including non-traditional defense firms from proposing. Examples of practices that support the implementation of these policies include … technology insertion for continuous affordability improvement throughout the product life cycle … As part of the acquisition strategy, the PM shall develop and document a support strategy for life-cycle sustainment and continuous improvement of product affordability, reliability, and supportability, while sustaining readiness. …. The support strategy shall address all applicable support requirements to include, but not be limited to … Conversion of product configuration technical data to performance specifications when required for enabling technology insertion to enhance product affordability and prevent product obsolescence
Life-Cycle Support Oversight. The support strategy shall address how the PM and other responsible organizations will maintain appropriate oversight of the fielded system. Oversight shall identify and properly address performance, readiness, ownership cost, and support issues, and shall include post-deployment evaluation to support planning for ensuring sustainment and implementing technology insertion, to continually improve product affordability. …
System Analysis and Control. System analysis and control activities shall provide the basis for evaluating and selecting alternatives, measuring progress, documenting design decisions, and enabling and managing block deliveries under an evolutionary acquisition strategy. They shall include … The maximum use of performance requirements for items identified as high pay-off for technology insertion…. An integrated data management system to Facilitate technology insertion for affordability improvements during reprocurement and post-production support…
. PMs shall use an open systems approach to achieve the following objectives:… To conduct business case analyses to justify decisions to enhance life-cycle supportability and continuously improve product affordability through technology insertion during initial procurement, re-procurement, and post-production support; and
Use performance requirements or conversion to performance requirements during reprocurement of systems, subsystems, components, spares, and services beyond the initial production contract award, and during post-production support to facilitate technology insertion and modernization of operational weapons systems.
§ Capability Maturity Model Integration (CMMI), Version 1.1, Software Engineering Institute, CMU/SEI-2002-TR-011, TR-012, March 2002
The CMMI does not specifically address planning for technology insertion as defined in this document, but it does address the processes of making innovative process and technology improvements at the organizational level.
“Organizational Innovation and Deployment”, is a key process area (KPA) for CMMI level 5 - Optimizing. The purpose is to select and deploy incremental and innovative improvements that measurably improve the organizations processes and technologies. Specific goals (SG) and practices (SP) are as follows:
All of the specific practices are equally relevant to planning for technology insertion as part of a continuous improvement process irrespective of the assessed capability maturity of the organization.
GLOSSARY
Adaptability |
The extent to which a software system adapts to change in its environment. |
Airlie Council |
Refers to a group of experts convened by the Navy’s Software Program Manager’s Network (SPMN) in 1995 who established/identified nine best practices. These practices have been augmented with other practices since 1995, and in current literature are referenced as the original Airlie best practices. |
Best Practice |
A documented practice aimed at lowering an identified risk in a system acquisition and is required or recommended by a bona fide DoD, industry, or academic source.
Methodologies and tools that consistently yield productivity and quality results when implemented in a minimum of 10 organizations and 50 software projects, and are asserted by those who use it to have been beneficial in all or most of the projects. |
Evolvability |
An attribute of a system that indicates the ease with which new functions can be added or old ones changed. |
Interoperability |
The ability of systems, units, or forces to provide and accept services from other systems, units, or forces and to use the services to enable them to operate effectively together. [Joint Publication 1 – 02] |
Migration |
Migration is a process to recover and protect the significant investment in a system by transferring the functionality, data, communications, or other key parts of the application system to a new technical infrastructure. Migration, however, must be considered in the broadest sense, tied to change in the business and technological domains, each with its own set of unique influences and objectives. |
Model |
A simplification of reality that provides a complete description of a system. |
SPMN |
Software Program Managers Network |
System Integration |
The progressive linking and testing of system components to merge their functional and technical characteristics into a comprehensive, interoperable system. Note: Integration of data systems allows data existing on disparate systems to be shared or accessed across functional or system boundaries |
Technology Insertion (TI) |
Technology Insertion - The process of taking advantage of technology opportunities to improve the performance or reduce the cost of the system by replacing existing system components with newer technology components. |
Technology Refresh |
The process of restoring or maintaining a system as a whole to its current level of performance and functionality (during development, production, deployment, and in-service management phases) by replacing the underlying COTS/ CAS that is no longer supported by the manufacturer or primary vendor. |
Technology Transition |
The process of creating or maturing a technology, introducing it to its intended adopters, and facilitating its acceptance and use |
This article, titled “The Air Force Develops an Initiative to Manage Change in Avionics Systems”, appeared in the Sep 2001 Issue of Crosstalk. Although it makes only a minor reference to the term “technology insertion”, it embodies all of the thinking that is significant to planning for technology insertion. In particular it illustrates how adequate analysis of the problem at the program level can uncover issues that need to be addressed at a much broader level in order to effect the change on a given program. It also describes the funding scenario that impacts technology insertion and addresses the on-going nature of planning for technology insertion. The article indicates that “the colors of monies …create major impediments to prudent investment in reducing total ownership cost (TOC). It also clearly shows the importance of identifying and involving key stakeholders and of assessing proposed architectures with respect to viability objectives of producibility, supportability, and accommodating future requirements growth.
[Ogg, 2001]
Although not a formal case study, this reference provides an excellent example of on-going “Planning for TI”.
The NAVY has established a web site specifically to address technology insertion on the AN/UYQ-70 program. A four-step generic TI process is defined (A- Requirements Definition, B- Requirements Analysis, C- Implementation Methods, and D- Development). Other documents on the site describe their high level process for evaluating candidate technologies against the open system architecture profiles of the Q-70 program, and diagram the migration (TI) plan for the operating system and its components. See Tech. Bulletin Issue 5 – Oct. 2000. This program is an excellent example of TI planning that aligns tactical planning of specific initiatives with the strategic level planning and the TI process defined for the program.
Note: Access to the Q-70 web site requires an SSL-enabled browser that supports 128-bit encryption. As of October 1, 2004, a DoD/PKI certificate is also required to access the Q-70 web site. If you require assistance with Q-70 information and cannot access the above web site you may contact the Q-70 support center.
TI web site: https://www.q-70.navy.mil/
TI Process defined: https://www.q-70.navy.mil/
(https://www.q-70.navy.mil/Q-70/tech_ins/Intro/process.htm)
Tech Bulletin (describes the implementation of the TI process): https://www.q-70.navy.mil/
(https://www.q-70.navy.mil/Q-70/docs/techbull/vol001/issue005/q70-i5techinsert.html)
Roadmaps: https://www.q-70.navy.mil/
(https://www.q-70.navy.mil/Q-70/tech_ins/slides/themis/5YRoadmap.pdf)
Sparc/Solaris Migration Overview: https://www.q-70.navy.mil/
(https://www.q-70.navy.mil/Q-70/docs/Migration.pdf)
DACS Gold Practice Initiative
ROI Dashboard
