A multi-criteria decision model for migrating legacy system architectures into open system and system-of-systems architectures.
Keywords: Legacy Migration, Open Architecture, System of Systems Engineering, Analytic Hierarchy Process (AHP), Goal Programming (GP)
Timely reaction to evolving threats and technology requires agile system architectures that could quickly and cost-effectively be integrated and reconfigured within family of systems and joint system of systems warfighting constructs. Affordable agility and reconfiguration will demand open and modular forces, systems, and system of systems (SoS). The recent change in U.S. Army strategy from division-centric structures to modular brigade combat teams; publication of DoD Directive 5000.01 (DoD, 2003), which mandated implementation of the Modular Open Systems Approach (MOSA); the Naval OA (Open Architecture) Strategy (2008); and the Open Technology Development Roadmap Plan (Department of Air Force, 2006)--all are testimony to a shift in warfighting and acquisition within the DoD. If applied effectively, an open and modular architecture can enhance the adaptability of defense systems to changes in threats and technology, reduce the total ownership costs of systems, and improve life cycle supportability. Moreover, by following an open system strategy in acquisition of systems, the programs will be in a better position to leverage investments made throughout the defense industrial base to produce new commercial products, practices, and technologies that will integrate warfighting capabilities more easily in a system of systems environment and field superior capabilities more quickly and affordably. Furthermore, an open system strategy considers life cycle support requirements up front, permits system evolution with technology development, opens the diminishing defense industrial base to commercial know-how and products, anticipates technology obsolescence in system design, and supports continuing technology insertion throughout the system life cycle.
The best strategy for developing an open system architecture is to follow the MOSA, originally proposed by Azani and Flowers (2005). This approach is an integrated business and technical strategy that employs a modular design and, where appropriate, defines key interfaces using widely supported and consensus-based standards that are published and maintained by recognized industry standards organizations (i.e., open standards). By following this approach, the programs will first make a business case for open systems and then, through adherence to five major MOSA principles, develop an open architecture for the system under consideration (Azani & Khorramshahgol, 2005).
[FIGURE 1 OMITTED]
Figure 1 depicts the DoD vision, the fundamental principles, and proven benefits of following MOSA. As shown in Figure 1, MOSA must become an integral part of each acquisition strategy to achieve affordable, evolutionary, and joint combat capability. Effective implementation of MOSA is dependent on adherence to five fundamental MOSA principles (Azani & Flowers, 2005). Additional principles have been added to this list which include biotic open systems that have been around for millions of years (Azani, 2009). Although considerable literature exists on developing an open architecture for a new system (Azani, 2009; Azani & Flowers, 2005; Azani, 2000, 2001a, 2001b; Azani & Khorramshahgol, 2005a, 2005b, 2005c, 2006), no coverage of legacy systems migration into open systems is evident. Also lacking are proven models or methodologies to evaluate the feasibility of a migration decision, identification of appropriate migration candidates, and prioritization and implementation of open architectures for the selected candidate systems.
This article proposes an integrative mode/method for migrating legacy systems into open systems in a family or system of systems context. The proposed model/method is equally applicable to migration decisions involving subsystems in a single system. The model/method integrates the Modular Open Systems Approach (MOSA) with two powerful mathematical models, namely the Analytic Hierarchy Process (AHP) and Goal Programming (GP). By incorporating the MOSA concept into the model, decision makers will also enable their programs to: 1) meet challenges associated with integrating technologies from different vendors; 2) maintain continued access to cutting-edge technologies and products from multiple suppliers; 3) facilitate quick development and cost-effective change of legacy applications; and 4) address change management as system requirements evolve and new technologies become available. Through incorporating the two proven mathematical models, the suggested method enables organizations to effectively consider multiple criteria and conflicting goals in the decisionmaking process and integrate tangible as well as intangible factors from various stakeholders to reach a more acceptable and best possible decision.
The following sections present a brief introduction to an open system concept and discuss the legacy migration challenges organizations face. The AHP and GP are then explained. Finally, the proposed method is discussed and its application illustrated through an example, followed by a discussion of the advantages and limitations of the proposed methodology.
What is an Open System Concept?
The open system concept evolved from biological and physical sciences and was adopted in the information technology industry in the late 1960s and early 1970s (Azani, 2000). For many years, information systems buyers were limited to only a few major mainframe vendors, of which one vendor was clearly dominant in the marketplace. Competition was severely limited because access to the market was controlled essentially by one, or no more than a few, vendors (Azani 2002). A number of different standards organizations initiated open systems efforts, sometimes in competition with one other. Recently, some order has come to the scene, and some degree of convergence appears reasonable.
Open system definitions vary within disciplines, industries, and organizations. Nevertheless, there are some common themes that most of these definitions contain (Roark & Kiczuk, 1995). Generally speaking, open systems are systems with permeable boundaries or well-defined standardized interfaces that enable exchange of energy (e.g., electrical current via a wall plug); material (e.g., replacement of components/parts with equivalent components from competitive sources); and information (e.g., interoperability with other systems) within the joint operating environment (Azani, 2009). Within this context, open systems are defined as systems that employ modular design, use widely supported and consensus-based standards for their key interfaces, and are subjected to successful validation and verification tests to ensure the openness of their key interfaces (Azani & Flowers, 2005). Open architectures enable easier integration of properly engineered modules across a wide range of systems, effective reconfiguration and reintegration into joint warfighting and system of systems constructs, successful exchange of information and services with other modules on local and remote systems, and more affordable and quicker adaptation to evolving needs and technologies.
What is an Open Architecture?
Architecture means different things to different people. Some definitions are complex and depicted in very complicated, confusing, and long sentences (Jazayeri & Linden, 2000; Booch et al., 1999). Other definitions such as the ones proposed by Rechtin and Maier (1997) are simpler and more concise definitions of architecture. The best architecture definition is perhaps the definition proposed by recognized standards organizations such as the one by the Institute of Electrical and Electronics Engineers that defines architecture as the structure of components, their relationships, and the principles and guidelines governing their design and evolution over time. However, the architecture of a given system seems to be not only the structure of the system, but also its functions, the environment in which it will reside, and the process by which it will be built and operated (Rechtin, 1997). It also represents the highest-level conception of a system in its environment, includes the structure and behavior of the whole system in that environment, and how it will meet its requirements (Emery et al., 1996).
An open architecture depicts the structure of functional and physical modules, their interrelationships through well-defined open key interfaces, and the principles governing the design, development, reconfiguration, and evolution of such structure over time. Open architectures rely on physical modularity and functional partitioning of both hardware and software to create the flexibility needed for replacing specific subsystems and components without affecting others. The open architecture supports the functional baseline and system specifications and is an effective blueprint for developing and maintaining affordable and adaptable applications and systems. Moreover, some organizations are at a higher level of maturity in their application of open architecture, while others operate at very early levels or stages of open systems maturity (Azani, 2002). By developing open architectures, the system integrators/architects will build flexibility into their systems/applications and will achieve enduring interoperability, integrability, affordability, adaptability, and supportability for their systems.
Migration Issues and Challenges
Organizations face a number of formidable challenges in their decision making process of migrating legacies into open systems:
* How does an organization determine which legacy systems should be kept, modernized, and be migrated into open systems?
* How does the organization tackle the integration of legacy systems into joint warfighting system of systems constructs?
* How does the organization mitigate the risks associated with obsolescence and unavailability of components comprising a legacy system?
* How does the organization avoid the legacy dependence on a single source of supply for the remainder of legacy useful life?
* In case the organization decides to keep the functionality of legacy systems, how does the organization reach consensus on objectives and criteria needed for analyzing the existing functionality, evaluating their future relevance, and assessing the feasibility of their migration into open systems?
* How should the organization prioritize migration candidates, allocate resources, and develop open architectures for them?
* How does the organization deal with complexity and risks of migration and integration considering the many applications, diverse networks, various standards, and numerous platforms that exist in a typical organization?
* How does the organization deal with multiple conflicting objectives in migrating legacies into open systems?
Other challenges that decision makers face are to establish objective criteria to compare different legacy systems and select the migration candidates. Examples of such criteria are remaining useful life of the legacy system, expected life cycle cost savings as a legacy system is migrated into an open system, and the extent of future risk avoidance. Unfortunately, in most organizations the criteria used for comparison are subjective, and decision makers cannot reach a consensus on the magnitude of risks, costs, or system useful life. They are also less likely to agree on likelihood of occurrence of various types of risks encountered if the legacy system is not migrated.
Seamless integration of legacy systems can be a very complex and tedious project, across numerous applications, diverse networks, various standards, and many platforms in an organization. System integration not only is a challenging task, it is also quite risky. Not surprisingly, 88 percent of integration projects fail (Pollock, 2001). Most if not all of the legacy system integration challenges mentioned above can effectively be addressed by using the proposed methodology and by making every system a part of an integrated network of open architectures. The proposed methodology will rely on an integrated product and process teaming arrangement to establish agreed-upon objectives and criteria needed for comparison of legacy systems. After establishing objectives and criteria, the problem would be to prioritize migration candidates based on these criteria and allocate resources among them. To this end, the proposed methodology applies AHP for prioritization of legacy systems and GP for resource allocation. A powerful feature of GP is its ability to allow for consideration of multiple conflicting goals and objectives when allocating organizational resources.
Analytic Hierarchy Process (AHP)
Analytic Hierarchy Process (Saaty 1980) is based on the idea that a complex issue can be effectively examined if it is hierarchically decomposed into its parts. AHP implementation entails a hierarchy whose top level reflects the overall objective. Criteria are listed at intermediate levels, while the lowest level represents the alternatives. Elements at a certain level are compared to one another with reference to their effect on the higher level. Saaty (1994, 1996) has an inconsistency index to capture any bias when relative comparisons are made. A zero value would indicate perfect consistency, whereas larger values indicate increasing levels of inconsistency. Saaty (1994) states that the Inconsistency Ratio (IR) should be about 10 percent or less to be acceptable. If the IR exceeds the 10 percent level, value judgment may need to be revised. AHP has been applied in a number of areas ranging from engineering, economics, and politics, to marketing, sociology, and management. Vargas and Zahedi (1993) present a comprehensive survey of AHP and its applications.
AHP is a valuable component of the proposed methodology because: a) it considers the legacy system migration problem in its entirety; b) it breaks the problem down into its components and subcomponents; and c) it incorporates multiple (conflicting) objectives, uncertainty, and decision makers' preferences in the decision-making process. In addition, AHP allows for multiple stakeholders to participate in the decision making process. For excellent discussions of AHP applications, see Saaty (1994, 1996), Liberatore (1987), Vargas and Zahedi (1993), Liberatore and Nydick (2003), and Wasil and Golden (1991).
GP deals with allocating scare resources among alternatives in the best possible way, by mathematically stating the problem so as to minimize a given function subject to a set of constraints. The procedure starts with specifying a target or aspiration value for each objective, thus transforming all objectives into goals. The resultant objective function--termed achievement function--is then the summation of deviations from these goals. Since attaining all goals simultaneously is impossible, the problem is then to minimize the sum of the deviations from the goals; that is, to minimize the achievement function.
GP initially was developed by Charnes and Stedry (1964) and extended and improved by Jaaskelainen (1969) and Ignizio (1976, 1982). Ijiri (1965) also suggested the concept of "preemptive priorities," where a priority is given to an objective or a set of commensurable objectives.
The GP model, as described by Ignizio (1982), follows:
Find x = [x.sub.1], ....., [x.sub.j], ..... [x.sub.j] so as to minimize: a = [g.sub.1](n,p), ...... [g.sub.k](n,p), ..... [g.sub.K](n,p)
[f.sub.i](x) + [n.sub.i] - [p.sub.i] = [b.sub.i] for all i = 1, ....., m and x, n, p [greater than or equal to] O,
"xj" is the jth decision variable,
"a" is denoted as the achievement function; a row vector measure of the attainment of the goals or (rigid) constraints at each priority level,
"[g.sub.K](n,p)" is a function (normally linear) of the deviation variables associated with the objectives or constraints at priority level k,
"K" is the total number of priority levels in the model,
"[b.sub.i]" is the right-hand side constant for goal (or rigid constraint) i,
"[f.sub.i](x)" is the left-hand side of the linear or nonlinear goal or constraint i.
The Proposed Methodology
As mentioned earlier, the proposed methodology employs the MOSA concept, applies an Integrated Product and Process Team (IPPT) approach, and uses AHP and GP models. Such concepts and models are integrated together to evaluate, plan, and monitor the application of the methodology; set priorities among legacy candidates; allocate resources among them; and finally, develop open architectures for the selected migration candidates.
The major constructs of the proposed method are depicted in Figure 2 and its practicability and applicability will be demonstrated by a hypothetical naval organization in subsequent section of this article.
The methodology utilizes three major phases and a number of steps within each phase, as detailed in the following discussion.
[FIGURE 2 OMITTED]
PHASE I: MAKE A BUSINESS CASE FOR MIGRATION AND ESTABLISH A MIGRATION PLAN
At this phase, the team that oversees the application of the methodology is appointed, legacy system candidates are identified and prioritized, the GP problem is formulated, and organizational resources will be allocated among selected migration candidates.
Step 1.1. Use an IPPT to identify legacy systems in need of migration and assess their functionality; determine which legacy system should be kept, modernized, or eliminated; establish migration objectives and evaluation criteria; and oversee the entire migration process. The IPPT may select diverse and conflicting objectives. However, this will not present any problem as GP allows for multiple, conflicting, and non-commensurable objectives of the organization to be included in problem formulation. The preferred IPPT format will be a Delphi inquiry to remove Groupthink and bias from the process, assure anonymity and continuing feedback, and allow for a more refined and comprehensive analysis of the problem (Linstone & Turoff, 1975).
Step 1.2. Apply AHP to set priorities among the legacy systems identified earlier using the evaluation criteria identified in Step 1.1. In other words, the set of legacy system candidates generated in the previous step is presented to the members of the IPPT to obtain their subjective value judgments for a pairwise comparison matrix. The eigenvalues of this matrix represent the priorities among the criteria selected as well as the priorities among the various legacy system candidates. The priorities among the selected criteria will then be used as penalty weights in the objective function of the GP model.
Step 1.3. Using the information obtained in the two previous steps, the IPPT will formulate a GP model to allocate resources among the selected migration candidates.
Step 1.4. Establish proper migration plans and strategies (acquisition, logistics, test and evaluation, etc.) to cost effectively transform the selected legacies into open systems. The migration strategies should also specify when, how, and in what order the migration efforts should proceed.
PHASE 2: DEVELOP OPEN ARCHITECTURES FOR MIGRATING SYSTEMS
At this phase, through compliance with the five MOSA principles identified earlier, an open architecture will be developed for each approved legacy system candidate.
Step 2.1. Establish an enabling environment. Effective MOSA implementation is contingent upon adequate skills and training on the open systems concept; suitable acquisition and logistics verification and validation strategies; and establishment of an appropriate MOSA implementation roadmap with milestones and performance measures.
Step 2.2. Employ modular design tenets to repartition the legacy system into encapsulated, cohesive, and self-contained modules with well-defined internal and external interfaces.
Step 2.3. Group interfaces into key and non-key interfaces using criteria such as the rapid rate of technology turnover, high cost, interoperability requirement, and the failure rate of modules at each end of an interface.
Step 2.4. Use widely supported and consensus-based (open) standards for key system interfaces to develop an open architecture for the system.
Step 2.5. Use proper verification and validation mechanisms to ensure openness of key interfaces and the overall system architecture.
PHASE 3: GAUGE THE PROCESS AND TAKE CORRECTIVE ACTION
During this phase proper contracting language, performance measures, and validation criteria are established to ensure openness of the selected migration systems.
Step 3.1. Use appropriate contracting language (e.g., section L and section M stipulations) to ensure that subsystems, components, and commercial products delivered are open.
Step 3.2. Use appropriate performance measures (metrics) to assess the MOSA implementation progress and system openness. Examples of such metrics are the percentage of key interfaces defined by open standards, and percentage of system modules that can be acquired from multiple competitive sources when the system is migrated.
Step 3.3. Validate that the migration goals and objectives are achieved.
Application of the Proposed Model
To demonstrate its practicability and applicability, the methodology is applied to a hypothetical SoS portfolio of existing naval systems. Let us assume that the IPPT selected by the SoS Program Executive Office has decided to use the proposed model/method and has conducted an inquiry and reached a consensus on the following organizational objectives/criteria to be pursued for the next ten years:
Goal 1. Reduce total ownership cost--measured by the net present worth of total projected cost saving/avoidance resulting from gaining access to multiple sources of supply and migration to an open system architecture.
Goal 2. Reduce obsolescence risks--measured by the number of open standard-compliant products in the migrated system.
Goal 3. Improve availability and reliability--measured by an increase in system reliability and availability resulting from the latest COTS hardware and software products enabled and employed by the migrated system.
Goal 4. Improve system capability--measured by the percentage improvement in the overall system capability when its architecture is migrated into an open systems architecture. Figure 3 shows a recommended approach for measuring risks and the impacts on capability if a legacy system does not become open.
Goal 5. Enhanced integration and interoperability--measured by the number of key internal and external interfaces that will be defined by open standards as the system migrates into an open architecture.
[FIGURE 3 OMITTED]
Let us assume that the funds allocated among the candidate legacies must be proportional to the level of contribution of each legacy system toward the achievement of the goals listed above. This requirement will bring four new constraints into the GP formulation. Table I depicts the target level for each objective/goal as specified by the IPPT.
Let us further assume that goals 1, 2, and 4 must be achieved, at a minimum, by the amount specified, and an exact achievement of goals 3 and 5 is desired.
Let us assume that after careful consideration of the functionality, modernization options, and life expectancy of all the legacy systems in the SoS portfolio of naval systems, four hypothetical legacy systems (i.e., LHA 10, LPD 12, LCC 50, and LSD 70) were found to be suitable candidates for migration to open systems, Figure 4 depicts the hierarchy structure of the problem,
Let us further assume that the following preferences, based on Table 2, were elicited from the participants of the open systems migration IPPT or Delphi inquiry using the AHP preference criteria:
* Criterion 1 is very strongly preferred to criterion 2
* Criterion 1 is strongly preferred to criterion 3
* Criterion 1 is equally to moderately preferred to criterion 4
* Criterion 1 is extremely preferred to criterion 5
* Criterion 2 is moderately preferred to criterion 5
* Criterion 3 is strongly preferred to criterion 2
* Criterion 3 is moderately to strongly preferred to criterion 5
* Criterion 4 is very strongly preferred to criterion 2
* Criterion 4 is strongly preferred to criterion 3
* Criterion 4 is extremely preferred to criterion 2
Using the above preferences, the matrix in Table 2 was constructed for the pair-wise comparison of criteria and their relative weights. A number of AHP decision support software (e.g., Expert Choice, simple spreadsheet algorithm, etc.) are available to bypass the tedious calculations and quickly find the weights/priorities.
Similarly, pair-wise comparison matrices for four candidate legacy systems (i.e., LHA 10, LPD 12, LCC 50, and LSD 70), with respect to each criterion, were established. An example of these matrices and the AHP evaluation criteria is shown in Figure 5.
Table 3 shows the final assigned weight for the four legacy candidates.
As mentioned earlier, it is desired that the organizational resources be allocated among different legacy systems in direct proportion to the weights assigned to them by AHP. Thus, the following relationships should hold true:
[X.sub.A]/0.140 = [X.sub.B]/0.114 = [X.sub.C]/0.262 = [X.sub.D]/0.484
The following equations are derived from the above set of ratios:
0.114 [X.sub.A] - 0.140 [X.sub.B] = O
0.262 [X.sub.A] - 0.140 [X.sub.C] = O
0.484 [X.sub.A] - 0.140 [X.sub.D] = O
0.262 [X.sub.B] - 0.114 [X.sub.C] = O
0.484 [X.sub.B] - 0.114 [X.sub.D] = O
0.484 [X.sub.C] - 0.262 [X.sub.D] = O
These equations will be used as constraints in GP model formulation. Using the criteria weights shown in Table 2, we will now formulate a GP model to allocate resources among the migration candidates. As discussed earlier, the priorities among the criteria will be used as penalty weights in the objective function of the GP model. Table 4 shows the parameters needed for formulation of the GP model.
The GP model for this problem is as follows:
Minimize: 0.448 [N.sub.1] + 0.053 [N.sub.2] + 0.125 [N.sub.3] + 0.125 [P.sub.3] + 0.343 [N.sub.4] + 0.031 [N.sub.5] + 0.031 [P.sub.5]
3 [X.sub.A] + 1.75 [X.sub.B] + 6 [X.sub.C] + 8 [X.sub.D] + [N.sub.1]- [P.sub.1] =12
20 [X.sub.A] + 40 [X.sub.B] + 35 [X.sub.C] + 25 [X.sub.D] + [N.sub.2]- [P.sub.2] =100
15 [X.sub.A] + 10 [X.sub.B] + 5 [X.sub.C] + 5 [X.sub.D] + [N.sub.3] - [P.sub.3] =20
20 [X.sub.A] + 25 [X.sub.B] + 10 [X.sub.C] + 15 [X.sub.D] + [N.sub.4] - [P.sub.4] =60
15 [X.sub.A] + 30 [X.sub.B] + 20 [X.sub.C] + 35 [X.sub.D] + [N.sub.1] - [P.sub.5] =80
0.114 [X.sub.A] - 0.140 [X.sub.B] = 0
0.262 [X.sub.A] - 0.140 [X.sub.C] = 0
0.484 [X.sub.A] - 0.140 [X.sub.D] = 0
0.262 [X.sub.B] - 0.114 [X.sub.C] = 0
0.484 [X.sub.B] - 0.114 [X.sub.D] = 0
0.484 [X.sub.C] - 0.262 [X.sub.D] = 0
[X.sub.A], [X.sub.B], [X.sub.C], and [X.sub.D] represent the contribution level of each legacy system to the five goals specified earlier. Solving the above GP problem, the final solution is as follows:
[X.sub.A] = 0.540889; [X.sub.A] = 0.440438; [X.sub.C] - 1.012234; [X.sub.D] = 1.869929
This solution specifies that the organizational resources should be allocated among the four legacy systems based on the following percentages:
LHA 10:[0.540889/(0.540889 + 0.440438 + 1.012234 + 1.869929)] * 100 = 14 %
LPD 12:[0.440438/(0.540889 + 0.440438 + 1.012234 + 1.869929)] * 100 = 12 %
LCC 50:[1.012234/(0.540889 + 0.440438 + 1.012234 + 1.869929)] * 100 = 26 %
LSD 70:[1.869929/(0.540889 + 0.440438 + 1.012234 + 1.869929)] * 100 = 48 %
Therefore, legacy systems LHA 10, LPD 12, LCC 50, and LSD 70 should receive 14 percent, 12 percent, 26 percent, and 48 percent of the total available resources (funds), respectively. It should be noted that legacy systems LCC 50 and LSD 70 receive about 75 percent of the funds. This high resource allocation ratio is commensurate with the relatively larger contribution of these legacy systems towards achievement of the goals and objectives specified by the IPPT decision makers.
Besides proper allocation of organizational resources, the proposed methodology will also facilitate and expedite the migration decision-making process. This latter feature of the proposed model (i.e., enabling early migration to open systems) should not be taken lightly. As depicted in Figure 3, failing to migrate in a timely manner can result in degraded system capability and effectiveness. As shown in Figure 6, system capability and effectiveness is maintained by early detection/prediction of capability degradation and prompt migration to an open system architecture.
[FIGURE 6 OMITTED]
Advantages and Limitations of the Proposed Method
Six distinct advantages may be derived from the proposed methodology outlined in this article:
* The methodology works as a decision support system that integrates well-established and widely used concepts (i.e., MOSA, IPPT, Delphi) and mathematical models (i.e., AHP, GP).
* The methodology is a multi-criteria resource allocation tool, which incorporates multiple conflicting goals and provides a systematic approach to establish priority among various criteria and competing alternatives.
* The application of the methodology minimizes groupthink, facilitates brainstorming, and enables reaching consensus.
* The methodology enables systems engineers and architects to develop an open architecture for the selected migration candidates.
* The methodology ensures lower total cost of ownership; continued system effectiveness and capability; and extended useful life for subsystems, systems, family of systems, and system of systems.
* By applying the proposed methodology, the program managers can more easily integrate systems in a family or system of systems and continually leverage the investments made in commercial products, practices, and technologies.
Some limitations of the proposed method are the tedious and perhaps time-consuming IPPT process for establishing objectives, and determining the entries for numerous pair-wise comparison matrices. The use of complex mathematical formulas may be another drawback of the model although powerful software exists for AHP and GP computations.
This article proposed an integrative method for assessing the appropriateness of migrating closed legacy systems into affordable and adaptable open systems, and developing open architectures for the selected candidates. The method employed the MOSA concept, applied an Integrated Product and Process Team approach, and used Analytic Hierarchy Process and Goal Programming models as an integrated multi-criteria decisionmaking model. The methodology capitalized on AHP and GP benefits such as objectivity, consideration of tangible and intangible factors in decision making, and simultaneous incorporation of multiple conflicting objectives in the decision-making process. The methodology also took advantage of open systems benefits. The benefits of open systems--such as adaptive modular architecture and increased portability and interoperability--can significantly enhance an organization's core competencies by reducing the total cost of system ownership, increasing long-term viability, and shortening the length of development cycle time for systems and applications.
Azani, C. H. (2000, November). The open systems strategy." A viable business and engineering approach for building and sustaining advanced complex systems. Proceedings of the Defense Manufacturing Conference, Tampa, FL.
Azani, C. H. (2001a, July). Joint space operations via secured integrated network of modular open architectures. Proceedings of the Joint Aerospace Weapons Systems Support, Sensors, and Simulation Symposium and Exhibition, San Diego, CA.
Azani, C. H. (2001b, September/October). The test and evaluation challenges of following an open system strategy. ITEA Journal of Test and Evaluation. Retrieved September 14, 2009, from htt p://www.acq.osd.mil/osjtf/pdf/itea.pdf
Azani, C. H. (2002, November). Enabling system-of-systems capabilities via modular open systems maturity models. Proceedings of the 2nd Annual CMMI Technology Conference, Denver, CO.
Azani, C. H. (2009). An open systems approach to system of systems engineering. In Mo Jamshidi (Ed.), System of systems engineering: Innovations for the 21st century (pp. 21-41). Hoboken, N J: John Wiley & Sons.
Azani, C. H., & Flowers, K. (2005, January-February). Integrating business and engineering strategy through modular open systems approach. Defense AT&L, 34(1), 37-40.
Azani, C. H., & Khorramshahgol, R. (2005a, August). A methodology for developing viable and cost effective customer relationship management systems. Journal of Knowledge Management Practice. Retrieved September 14, 2009, from http://www.tlainc.com/artic196.htm
Azani C. H., & Khorramshahgol, R. (2005b, July). The open system strategy." An integrative business and engineering approach for building advanced complex systems. Proceedings of the 9th World Multi-Conference on Systemics, Cybernetics, and Informatics (WMSC12005). Orlando, FL: International Institute of Informatics and Systemics.
Azani, C. H,, & Khorramshahgol, R. (2005c). Management of technology using a modular open system strategy. Proceedings of the 12th European Concurrent Engineering Conference (ECEC) 2005 (pp. 5-12). Toulouse, France: Institut de Recherche en Informatique de Toulouse (IRIT), Universite Paul Sabatier.
Azani, C. H., & Khorramshahgol, R. (2006, October). The open software intensive system strategy: An integrative approach for building software intensive systems. The Journal of Computer Information Systems, 47(1). 56-65.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language userguide. New York: Addison Wesley Longman.
Charnes, A., & Stedry, A. C. (1966, April). Chance-constrained model for real-time control in research and development management. Management Science, 12(8), B353-B362.
Department of Defense (DoD). (2003, May). The defense acquisition system. DoD Directive 5000.01 (Certified Current as of November 20, 2007). Retrieved September 22, 2009, from http://www.dtic.mil/whs/directives/corres/pdf/500001p.pdf
Department of the Air Force. (2006, April). Open technology development." Roadmap plan (Ver. 3.1). Washington, DC: Office of the Deputy Under Secretary of Defense for Advanced Systems & Concepts.
Emery, D. E., Hilliard, R. F., & Rice, T. B. (1996, June). Experiences applying a practical architectural method. In Alfred Strohmeier (Ed.), Reliable Software Technologies--Aria-Europe '96. 1996 Ada-Europe International Conference on Reliable Software Technologies, Montreux, Switzerland (pp. 471-484). Lausanne, Switzerland: Swiss Federal Institute of Technology in Lausanne.
Ignizio, J. P. (1976). Goal programming and extensions. Lexington, MA: Lexington Books.
Ignizio, J. P. (1982). Linear programming in single & multiple objective systems. Englewood Cliffs, N J: Prentice-Hall.
Linstone, H. A., & Turoff, M. (Eds.). (1975). The Delphi method: Techniques and applications. Reading, MA: Addison-Wesley.
Ijiri, Y. (1965). Management goals and accounting for control. Chicago: Rand McNally.
Jaaskelainen, V. (1969). Accounting and mathematicalprogramming [Monograph]. Helsinki, Finland: Helsinki School of Economics.
Jazayeri, M., Ran, A., & Linden, F. (2000). Software architecture for product families: Principles and practice. Addison Wesley Longman.
Liberatore, M. J. & Nydick R. L. (2005). Decision technology. Modeling, software, and applications New York: John Wiley & Sons.
Liberatore, M. J. (1987). An extension of the analytic hierarchy process for industrial R&D projects selection and resource allocation. IEEE Transactions on Engineering Management, 34(1), 12-18.
Naval Open Architecture Enterprise Team. (2008, October 8). Naval OA strategy [White Paper]. Washington Navy Yard: Program Executive Office (PEO) Integrated Warfare Systems.
Pollock, J. (2001, October). The big issue: Interoperability vs. integration, eAl Journal, 2007(25), 48-82.
Rechtin, E., & Maier, M. W. (1997). The art of systems architecting. Boca Raton, FL: CRC Press.
Roark, C., & Kiczuk, B. (1998, September). Open systems avionics architectures. IEEE Aerospace and Electronic Systems Magazine, 70(9).
Rook, P. (1986, January). Controlling software projects. Software Engineering Journal, 1(1), 7-16. Herts, UK: Michael Faraday House,
Royce, W. W. (1970, August). Managing the development of large software systems: Concepts and techniques. In IEEE Western Electronic Show and Convention (WesCon) Technical Papers (Vol. 14, pp A/1-1-A/1-9). Reprinted in Proceedings of the 9th International Conference of Software Engineering, 1987 (pp. 328-358), Los Alamitos, CA: IEEE Computer Society Press.
Saaty, T. L. (1980). The analytic hierarchy process. New York: McGraw Hill.
Saaty, T. L (1994). How to make a decision: The analytic hierarchy process. Interfaces, 24(6), 19-43.
Saaty, T. L. (1996). Decision making with dependence and feedback. The analytic network process.
Pittsburgh, PA: RWS Publications,
Vargas, L. G., & Zahedi, F. (1993, February-March). Preface. Mathematical and Computer Modeling, 17(4-5), 9-11.
Wasil, E. A., & Golden, B. L. (Eds.). (1991). Introduction: Public sector application of the analytic hierarchy process. Socio-Economic Planning Sciences, 25(2), 87-88.
Dr. Cyrus Azani is a senior systems engineer at Northrop Grumman and has over 25 years of professional and consulting experience in program/project management, systems engineering, development of open systems architecture, and application of management science models and tools. He is a certified systems engineering and acquisition professional with a Doctor of Science degree in Systems Engineering and Engineering Management. Azani is also the author or co-author of over 50 technical publications.
(E-mail address: cyrus, firstname.lastname@example.org)
TABLE 1. THRESHOLDS/TARGET LEVELS FOR EACH GOAL Objective Target Level Improve Cost Effectiveness (at least) $12,000,000 Reduction in Obsolescence Risk (at least) 100 Improve Overall User Satisfaction 20% Improve Overall Systems Capability (at least) 60% Enhance System of Systems (SoS) Integration 80 Use AHP to assign weights to these goals. Use Goal Programming to minimize deviation from these goals and compute fund allocation percentages. TABLE 2. PAIRWISE COMPARISON MATRIX FOR CRITERIA Criteria 1 2 3 4 5 Criteria Weight 1 1 7 5 2 9 0.448 2 1 3 0.053 3 5 1 4 0.125 4 7 5 1 9 0.343 5 1 0.031 TABLE 3. THE OVERALL SYSTEM WEIGHTS Legacy Systems Weight LHA 10 (System A) 0.140 LPD 12 (System B) 0.114 LCC 50 (System C) 0.262 LSD 70 (System D) 0.484 TABLE 4. GP CONSTRAINTS AND PARAMETERS Criteria Legacy Legacy System System 1 2 3 4 5 Weight LHA 10 $3,000,000 20 15% 20% 15 0.140 LPD 12 $1,750,000 40 10% 25% 30 0.114 LCC 50 $6,000,000 35 5% 10% 20 0.262 LSD 70 $8,000,000 25 5% 15% 35 0.484 Target Level $12,000,000 100 20% 60% 80 1.00 Criteria: 7. Improve Cost Effectiveness, 2. Reduction in Obsolescence Risk, 3. Improve System User Satisfaction, 4. Improve System Capability, 5. Enhance System of Systems Integration FIGURE 4. A RECOMMENDED APPROACH FOR MEASURING CAPABILITY IMPACTS Risk Intensity if the System does not Become Open Severe Impact Moderate Impact Negligible Impact Near High High High Term Medium Medium Medium Low Low Low Mid High High High Term Medium Medium Medium Low Low Low Long High High High Term Medium Medium Medium Low Low Low Sever Impact: Enormous shift in adversaries' capability or technology causing major degradation of system capability (assigned value: twice as severe as moderate risk or .60) Moderate Impact: Some shift in adversaries capability or technology causing moderate capability degradation in near future (assigned value: three times as severe as negligible risk or .30) Negligible Impact: Negligible shift in adversaries' capability or technology causing negligible capability degradation (assigned value = . 10) FIGURE 5. SETTING LEGACY SYSTEMS PRIORITIES USING AHP EVALUATION CRITERIA Improved Integration LHA 10 LPD 12 LCC 50 LSD 70 LHA 10 1 2 3 5 LPD 12 0.5 1 5 7 LCC 50 0.33333333 0.2 1 3 LSD 70 0.2 0.14285714 0.33333333 1 Legacy Systems Weight LHA 10 (System A) 0.140 LPD 12 (System B) 0.114 LCC 50 (System C) 0.262 LSD 70 (System D) 0.484 KEY 1 Equally preferred 2 Equally to moderately preferred 3 Moderately preferred 4 Moderately to strongly preferred 5 Strongly preferred 6 Strongly to very strongly preferred 7 Very strongly preferred 8 Very strongly to extremely preferred 9 Extremely preferred