Integrating business and engineering strategy through Modular Open Systems Approach.The Modular Open Systems Approach is an integrated business and engineering strategy to maintain the superiority of U.S. military forces within tightening budget constraints A Budget Constraint represents the combinations of goods and services that a consumer can purchase given current prices and his income. Consumer theory uses the concepts of a budget constraint and a preference ordering to analyze consumer choices. and the unprecedented rate of technological change. MOSA MOSA Modular Open Systems Approach (US DoD acquisition) MOSA Ministry of Social Affairs (Lebanon) MOSA MOtoSAldatrici (Italy) MOSA Monmouth Ocean Soccer Association makes possible the effective application of business practices and successful engineering of systems through exploitation of technological change and by providing the capability to easily and effectively reconfigure and integrate systems into integrated and interoperable joint warfighting systems of systems. Leveraging the commercial industry investment on new technologies, practices, and products results in a faster response to technological change. Adaptive and agile open and modular architectures for systems and systems of systems facilitate the effective integration of systems into larger meta-systems. Generally speaking, MOSA supports program teams in the acquisition community to: * Reduce development cycle time and product support costs * Design for affordable reconfiguration, modernization, and change * Effectively integrate and/or retrofit ret·ro·fit v. ret·ro·fit·ted or ret·ro·fit, ret·ro·fit·ting, ret·ro·fits v.tr. 1. To provide (a jet, automobile, computer, or factory, for example) with parts, devices, or equipment not in earlier increments with later increments within an evolutionary acquisition context * Develop agile, robust, and adaptive systems An adaptive system is a system that is able to adapt its behavior according to changes in its environment or in parts of the system itself. A human being, for instance, is certainly an adaptive system; so are organizations and families. and integrated architectures needed for assembling a joint, network-centric, and reconfigurable force. MOSA Policies and Directions The main Department of Defense MOSA policy and directions are stated in DoD Directive 5000.1; an under secretary of defense (acquisition, technology and logistics) directive dated April 4, 2004; and an instruction memorandum by the director of defense systems (AT & L) dated June 7, 2004. DoDD 5000.1 directs all acquisition programs to employ MOSA as part of their application of systems engineering. The USD USD In currencies, this is the abbreviation for the U.S. Dollar. Notes: The currency market, also known as the Foreign Exchange market, is the largest financial market in the world, with a daily average volume of over US $1 trillion. (AT & L) memorandum directs Services to develop a coordinated business and technical approach to MOSA across their respective programs to progress toward joint integrated warfare The conduct of military operations in any combat environment wherein opposing forces employ non-conventional weapons in combination with conventional weapons. . It also designates the Open Systems Joint Task Force (OSJTF OSJTF Open Systems Joint Task Force ) as the DoD lead for MOSA and directs the task force to establish and chair the MOSA review team to synchronize See synchronization. MOSA implementation across the Services and DoD agencies to leverage open systems benefits across joint integrated warfare systems. It further directs all programs subject to milestone review to brief their MOSA implementation status to the milestone decision authority. The director of defense systems instruction memorandum describes how requirements stated in the USD (AT & L) directive should be addressed for systems and systems of systems in the formal acquisition process. Based on the instruction, acquisition programs should address MOSA early in their program and acquisition planning and discuss MOSA implementation in the context of their overall acquisition strategy and, to the extent feasible, in their technology development strategy. The memorandum instructs program managers to use either the MOSA program assessment and rating tool (PART), which is an adaptation of the Office of Management and Budget The Office of Management and Budget (OMB), formerly the Bureau of the Budget, is an agency of the federal government that evaluates, formulates, and coordinates management procedures and program objectives within and among departments and agencies of the Executive Branch. tool for rating programs across the federal government, or an equivalent method of assessment to generate objective data on MOSA implementation progress. [ILLUSTRATION OMITTED] Planning for MOSA Implementation MOSA implementation should be based on upfront planning and initiated early in the program and acquisition planning. The essential elements and the supportive technical and business practices needed to develop affordable and adaptable open systems are depicted graphically above. Needed are an integrated product and process development (IPPD IPPD Integrated Product and Process Development IPPD Intellectual Property Policy Directorate (Canada) IPPD Integrated Product and Process Design IPPD Intradermal Purified Protein Derivative (tuberculin skin test) ) team approach; application of sound systems engineering processes; and development of a MOSA implementation plan that, at a minimum, addresses the following five fundamental principles (discussed in detail later): * Identify and analyze capabilities and strategies that could most effectively be pursued by open systems design solutions * Assess the feasibility of open systems design solutions * Establish metrics/tools to assess MOSA implementation progress * Use MOSA principles to develop an open architecture * Establish a procedure to identify and resolve MOSA implementation issues In the Business world, companies frequently set-up a connection between which they transfer data. When the connection is being set-up, it is referred to as implementation. When issues occur during this phase, they are known as implementation issues. and report the unresolved issues to Milestone Decision Authority. The effectiveness of MOSA is largely determined by the degree to which it is an integral part of a sound systems engineering process. Programs and contractors are encouraged to use popular systems engineering standards (EIA (Electronic Industries Alliance, Arlington, VA, www.eia.org) A membership organization founded in 1924 as the Radio Manufacturing Association. It sets standards for consumer products and electronic components. 632, ISO (1) See ISO speed. (2) (International Organization for Standardization, Geneva, Switzerland, www.iso.ch) An organization that sets international standards, founded in 1946. The U.S. member body is ANSI. 15288, IEEE (Institute of Electrical and Electronics Engineers, New York, www.ieee.org) A membership organization that includes engineers, scientists and students in electronics and allied fields. 1220, for example) as the foundation for applying MOSA. The preferred strategy for applying these standards and implementing MOSA is to employ an IPPD team composed of government and industry representatives and, at a minimum, including those who specify, design, build, test, operate, and maintain DoD systems. Team responsibilities include selecting standardized systems engineering processes and establishing a plan for implementing MOSA. Other responsibilities are overall coordination of MOSA-related activities and ensuring effective implementation of MOSA principles. The MOSA implementation plan is a roadmap with specific objectives, tasks, principles, and milestones for putting MOSA into practice. Pinpointing MOSA-enabled Capabilities and Strategies Identifying specific operational and performance capabilities and strategies that could be enabled by open systems design is an important MOSA planning activity. There are many acquisition strategies, operational capabilities, and performance requirements that lend themselves to the use of open systems in a program, among them: * Evolutionary acquisition and spiral development * Requirements that place great emphasis on long-term sustainment and affordability * Capability to constitute and reconfigure functionally compatible forces and systems * Seamless, high speed, digital information exchange among diverse warfighting elements * Overarching o·ver·arch·ing adj. 1. Forming an arch overhead or above: overarching branches. 2. Extending over or throughout: "I am not sure whether the missing ingredient . . . capabilities for a mission area that form a system of systems * Application of an integrated approach for adding future capabilities and advanced technologies with minimum impact on existing systems * Modular contracting strategies. Open Systems Design Feasibility The MOSA is not a panacea Some antidote or remedy that completely solves a problem. Most so-called panaceas in this industry, if they survive at all, wind up sitting alongside and working with the products they were supposed to replace. , and programs shouldn't blindly follow the concept. Programs should make a business case for implementing open systems solutions after carefully analyzing capabilities and strategies contained in capability development documents and their acquisition strategy to ensure they lend themselves to the development of an open architecture. They may use a dynamic business case analysis model and apply market research findings to evaluate the appropriateness and feasibility of open systems. Business case models should take into consideration evolving capability requirements and the changes in technology to evaluate the total life-cycle costs of designing the system as an open rather than a closed system. Programs should use market research and analysis to identify technologies, standards, and compliant products needed to develop an open system. Tools to Assess MOSA Implementation Progress Programs can either develop their own assessment tool or apply the MOSA PART to gauge their MOSA policy compliance. The MOSA PART is an analytic tool that evaluates responses to a set of interrelated in·ter·re·late tr. & intr.v. in·ter·re·lat·ed, in·ter·re·lat·ing, in·ter·re·lates To place in or come into mutual relationship. in questions to provide acquisition program executives with an objective, evidence-based assessment of the degree to which the MOSA has been implemented by programs. The degree of such compliance is presented in terms of a set of MOSA implementation questions or indicators related to each of the five fundamental MOSA principles. Besides indicators that measure the degree of adherence to MOSA principles, the tool also contains instructions for use; program assessment information; an introduction to MOSA; a section on definitions; and the assessment report and overall score generated in real time by the responses. The MOSA PART can be reviewed and downloaded at <www.acq.osd.mil/osjtf/html/whatsnu.html>. A Closer Look at MOSA Principles Principle 1 -- Establish an enabling environment This principle lays the foundation for successful implementation of subsequent principles. To adhere to adhere to verb 1. follow, keep, maintain, respect, observe, be true, fulfil, obey, heed, keep to, abide by, be loyal, mind, be constant, be faithful 2. this principle, PMs must establish MOSA-supportive requirements; business practices; technology development, acquisition, test and evaluation; and product support strategies. PMs should also assign responsibility for MOSA implementation; ensure appropriate MOSA experience and training; conduct market research; establish MOSA-specific performance measures; and proactively identify and remove barriers or obstacles that can undermine effective MOSA implementation. Principle 2 -- Employ modular design In the context of systems engineering, modular design — or "modularity in design" — is an approach aiming to subdivide a system into smaller parts (modules) that can be independently created and then used in different systems to drive multiple functionalities. Effective modular design is contingent upon Adj. 1. contingent upon - determined by conditions or circumstances that follow; "arms sales contingent on the approval of congress" contingent on, dependant on, dependant upon, dependent on, dependent upon, depending on, contingent adherence to four major modular design tenets that determine the degree to which modules are cohesive (contain well-focused and well-defined functionality); encapsulated (hide the internal workings of a module's behavior and its data); self-contained (do not constrain con·strain tr.v. con·strained, con·strain·ing, con·strains 1. To compel by physical, moral, or circumstantial force; oblige: felt constrained to object. See Synonyms at force. 2. other modules); and highly binded (use broad modular definitions to enable commonality com·mon·al·i·ty n. pl. com·mon·al·i·ties 1. a. The possession, along with another or others, of a certain attribute or set of attributes: a political movement's commonality of purpose. and reuse). Principle 3 -- Designate key interfaces To effectively manage hundreds--in some cases, thousands--of interfaces that exist within and among systems, designers should group key and non-key interfaces. Such distinction enables designers and configuration managers to distinguish among interfaces; between technologically stable and volatile modules; between highly reliable and more frequently failing modules; between modules that are essential for net-centricity and those that are not; and between modules that pass vital interoperability information and those with least interoperability impact. Principle 4 -- Select open standards Specifications for hardware and software that are developed by a standards organization or a consortium involved in supporting a standard. Available to the public for developing compliant products, open standards imply "open systems;" that an existing component in a system can be replaced In order to take full advantage of modularity in design, interface standards must be well-defined, mature, widely used, and readily available. Standards should be selected based on maturity, market acceptance, and allowance for future technology insertion. As a general rule, preference is given first to the use of open interface standards, second to the de facto [Latin, In fact.] In fact, in deed, actually. This phrase is used to characterize an officer, a government, a past action, or a state of affairs that must be accepted for all practical purposes, but is illegal or illegitimate. interface standards, and finally to government and proprietary interface standards. Basing design strategies on widely supported open standards increases the chance of integrating future changes in a cost-effective manner. Principle 5 -- Certify conformance con·for·mance n. Conformity. Noun 1. conformance - correspondence in form or appearance conformity agreement, correspondence - compatibility of observations; "there was no agreement between theory and Openness of systems should be verified, validated, and ensured through rigorous and well-established assessment mechanisms, well-defined interface control and management, and proactive conformance testing Conformance testing or type testing is testing to determine whether a system meets some specified standard. To aid in this, many test procedures and test setups have been developed, either by the standard's maintainers or external organizations, specifically for . The PM, in coordination with the user, should prepare such validation and verification mechanisms as conformance certification and test plans to ensure that the system and its component modules conform to Verb 1. conform to - satisfy a condition or restriction; "Does this paper meet the requirements for the degree?" fit, meet coordinate - be co-ordinated; "These activities coordinate well" the external and internal open interfaces. This will enable plug-and-play of modules, net-centric information exchange, and reconfiguration of mission capability in response to new threats and technologies. Identifying and Resolving MOSA Implementation Issues The instruction memorandum stipulates that the MOSA implementation issues be identified and addressed through the integrated product team process and presented as issues to the MDA (1) (Monochrome Display Adapter) The first IBM PC monochrome video display standard for text. Due to its lack of graphics, MDA cards were often replaced with Hercules cards, which provided both text and graphics. See PC display modes and Hercules Graphics. only when unresolved at a lower level. Examples of such issues are: * Harsh environment within which a system must operate (e.g., excessive humidity or temperature extremes) * Rigid requirements that call for design-specific solutions * Absence of open standards or widely supported compliant products * Very expensive test mechanisms * Unforeseen performance or operational requirement changes that limit open systems development. DoD programs must address MOSA early in the program and acquisition planning processes (at the concept and technology development phase) to expedite and maximize MOSA benefits. Concept studies should consider open systems implications on total ownership costs and development cycle time of alternative solutions. Moreover, if solutions call for commercial-off-the-shelf product use, system developers must ensure that the interfaces to such products remain open. Technology development projects should also, from the outset, identify the key interfaces between technology-embedded products to ensure continuing access to such technologies throughout the system life cycle. Cyrus Azani * Col. Kenneth Flowers, USA Azani is Northrop Grumman Northrop Grumman Corporation (NYSE: NOC) is an aerospace and defense conglomerate that is the result of the 1994 purchase of Grumman by Northrop. The company is the third largest defense contractor for the U.S. senior systems engineer providing technical support to the Open Systems Joint Task Force since 1996. He holds a doctorate in systems engineering and engineering management. Flowers is director, Open Systems Joint Task Force. The authors welcome comments and questions. Azani can be reached at cyrus.azani.ctr@osd.mil and Flowers at kenneth.flowers@osd.mil. |
|
||||||||||||||||||||
Printer friendly
Cite/link
Email
Feedback
Reader Opinion