Read CM0808p36.pdf text version

36

Contract Management | August 2008

Open architecture, as being pursued by the U.S. Navy, is a great step forward in realizing cost savings for systems development and engineering, improving acquisition efficiency, and accomplishing force modernization. Implementing the navy's approach in other departments and agencies would contribute greatly in achieving similar benefits governmentwide.

Contract Management | August 2008

37

open architecture: a best practice in need of governmentwide implementation

The U.S. Navy currently faces a severe fiscal crisis as it attempts to enlarge the size of its fleet to 313 ships. In the midst of two military conflicts, rising personnel costs, and a tremendous force transformation and modernization effort, it was clear that present budgets would not be sustainable. One method the navy used to combat this financial predicament was to utilize "open architecture" (OA), which permits the leveraging of assets and resources the navy and the Department of Defense (DOD) have already invested in to assist in its recapitalization efforts and fleet modernization.1 As stated by former Assistant Secretary of the Navy (Research, Development, and Acquisition), Dr. Dolores Etter, "Half the cost of a new ship is in mission systems....OA is one of the real enablers for [the navy] to do things in the future and a key to making ships more affordable."2 In an attempt to curb rising costs and get programs back on schedule, this attitude can be taken DOD-wide and throughout the federal government, and, if successfully implemented, could help to reign in recent acquisitions that have gone out of control.

The navy's OA can be loosely defined as "an enterprisewide, multifaceted business and technical strategy for acquiring and maintaining national security systems as interoperable systems that adopt and exploit open system design principles and architectures."3 Within the context of the governmentwide acquisition community, OA is based on the principle that the government should be allowed to acquire systems, software, or hardware from any qualified vendor without being subject to the restrictions of proprietary data rights. Taking this approach one step further, it could also mean that the government has the rights to share the software, hardware, and technology it purchases with all government entities and/or any qualified vendors or contractors doing work for the government. While for many in the federal government outside DOD, this shift to an OA mindset may have gone unnoticed, it is a major step forward in breaking the reigns of contractorcontrolled acquisitions. This shift is crucial because it can be used as a model for those who have not yet adopted OA standards in their system acquisitions. Most importantly, this change can be used to highlight to other members of the government contracting community what exactly this change means, and perhaps how they can utilize contracting language to leverage the same benefits now sought by the navy within their own organizations. The recent push for OA by the navy is the first demonstration of a significant organizational drive toward the system standard within DOD. While the federal government as a whole has been slow to move to OA principles, the concept of OA is nothing new for many top contractors--OA concepts have been around for years. In information technology, for example, OA has been present at least since the 1981 introduction of the IBM PC hardware platform. OA has also been in existence in several other platforms, such as electrical and mechanical engineering, where systems from different vendors must cleanly, easily, and safely interoperate. It can be argued that software engineering has been slower to adopt this approach because there are many more intricacies involved in getting software to operate effectively. The increasing use of open standards in both commercial-off-the-shelf (COTS) and open source software has increased the visibility of component-based, interchangeable software for complex systems and has shown OA to be viable. In order for the federal government to reap the benefits of OA, it must transform the way it does business on a day-to-day basis and upgrade its approach to acquisitions by ensuring that all potential OA opportunities are thoughtfully considered. The navy, as one example, has been the most assertive of all the services in its efforts to transform the way it does business, making OA an integral component of its modernization efforts.4 Recent updates to the Naval Open Architecture Contract Guidebook contain new contracting language that has been designed to expand the navy's OA mandate. This language, which now requires OA principals to be required in statements of work (SOWs) and contracts, is a landmark accomplishment. By requiring contractors to adhere to OA standards developed by the navy, it can utilize hardware and/or software in future acquisitions that were previously labeled as "proprietary." Significant cost savings will be achieved by permitting the sharing of hardware and/or software that may have been procured multiple times in the past (and by various navy installations). To accomplish this goal, the navy has developed the "SHARE" system--the Software/ Hardware Asset Reuse Enterprise system. The SHARE system allows for the navy and its contractors to access an online inventory of hardware/software that has been purchased by the navy for integration into a new or existing program as a means to support OA. The navy is now requiring that future systems acquisitions have their

38

Contract Management | August 2008

open architecture: a best practice in need of governmentwide implementation

software and/or hardware registered in SHARE, and it has made a concerted effort to retroactively approach contractors and request they permit inclusion of already developed hardware and software as well. Utilizing this approach to technology development and OA encourages innovation and promotes competition. Ultimately, widespread implementations of initiatives like SHARE are imperative to lowering costs and providing better end products for the government. Considering these potential benefits, initiatives like the navy's OA mandate and SHARE should be implemented across the federal government. However, the first step toward implementing OA is to make certain that both acquisition strategies and contract guidelines are tailored to move past acquisitions that permit proprietary technology and data usage by requiring new systems to conform to a common set of OA standards. Proprietary data rights have long been at the heart of the dilemma between the government and industry in acquisition. As the government seeks to utilize competitive market forces to aid in its systems development, contracts that have limited or no data usage rights for the government restrict its ability to capitalize on existing knowledge and research and development efforts for future projects. Part of this strategy should be to overhaul the way OA is implemented at the most basic level of contracts and SOWs to ensure that new acquisitions are undertaken with OA as a priority.

utilized in contracting language across DOD and the rest of the federal government, the result will be greater competition, increased cost savings, better products delivered faster to the field, and improved functionality. The following are recommendations for specifics related to the technical approach taken by contractors, as outlined in the Naval Open Architecture Contract Guidebook, and are followed by brief summaries of the importance of each recommendation:

modular and uses COTS hardware, operating systems, and middleware that utilize nonproprietary or non-vendor-unique, key Application Programming Interfaces (APIs).7

In order for the federal government to reap the benefits of OA, it must transform the way it does business on a day-to-day basis and upgrade its approach to acquisitions by ensuring that all potential OA opportunities are thoughtfully considered.

1) Open Architecture--The Contractor shall develop and maintain an architecture that incorporates appropriate considerations for reconfigurability, portability, maintainability, technology insertion, vendor independence, reusability, scalability, interoperability, upgradeability, and longterm supportability.5

The use of open technology design and development methodologies is vital to increase the speed at which military systems are delivered to the warfighter, as well as for accelerating the development of new, adaptive capabilities that leverage existing investments in software infrastructure.8 In order to gain these advantages, the proper contract provisions must be written to include open design parameters. By requiring a modular, open design, the system, hardware, and/or software can be easily mapped for alteration by the government or other firms utilizing technology that is commercially available to anyone and that would not require involvement by the initial developer for future modification and/or support. In addition, the utilization of COTS hardware/software can decrease development efforts, allow for a faster procurement process, and increase the potential for software/hardware reusage.

3) System Requirements Accountability--The Contractor will be required to ensure that all system requirements (including those contained in the Initial Capabilities Document, Capabilities Development Document, and Capabilities Production Document) are accounted for through a demonstrated ability to trace each requirement to one or more modules that consist of components that are self-contained elements with well-defined, open, and published interfaces implemented using open standards.9

Navy OA Contracting Language: Important Points

One way to implement OA at the contracting and SOW level is to utilize the OA concepts outlined by the navy in its Naval Open Architecture Contract Guidebook. While this is not an all-inclusive list, I have tried to highlight the most important themes of the navy's OA contracting strategy. Nothing about these concepts are navy-specific; in fact, other services, departments, and agencies can take the following ideas and tailor them for use within their respective contract shops. If these principles can be

Acquisition of systems, hardware, and/or software that is based on a platform available and accessible to anyone for modification, improvement, or support is the fundamental basis of OA. Utilizing OA lowers acquisition costs, upgrade costs, training costs, opportunity costs, and can create important strategic relationships.6

2) Modular, Open Design--The Contractor shall develop an architecture that is layered and

Stipulating that a contractor must document the tracing of all system requirements is beneficial because it ensures that the system satisfies all of the requirements specified and allows for an understanding of the impact of future modifications. In addition, by requiring the developer to expressly map and publish each system requirement

Contract Management | August 2008

39

open architecture: a best practice in need of governmentwide implementation

to the applicable system modules and components, future modifications, integration, and support of the system can be easily attained without the need for involvement by the initial developer. This allows for any firm with the relevant expertise to access the system and upgrade or modify it.

4) Intercomponent Dependencies--The Contractor's design approach shall result in a layered system design, maximizing software independence from the hardware, thereby facilitating technology refresh. The design shall be optimized at the lowest component level to minimize intercomponent dependencies. 10

based on output measures such as system availability, as opposed to input measures such as parts and technical services.14 One of the primary methods for supporting PBL is utilizing COTS and open standards as a means to ensure that anyone at anytime in the future can support a system throughout its life cycle. Utilizing these instruments increases competition and preparedness because it allows any firm with the relevant system expertise to compete for support functions, not just those involved in the initial system's development

6) Open Business Practices--The Contractor shall demonstrate that the modularity of the system design promotes the identification of multiple sources of supply and/ or repair, and supports flexible business strategies that enhance subcontractor competition.

ment of a new system. The government can also leverage this advantage if it mandates the reuse of preexisting or common items in its contracts for acquiring systems. In these cases, the government does not have to pay a second time for something it has already purchased once before, or which has already been developed commercially. This concept is the backbone of SHARE; the more that services, departments, and agencies adopt this approach by requiring it in their contracts, the more software and hardware assets will be available for reuse by all.16

8) Use of Standards--In designing the system(s), the Contractor shall use the following standards in descending order of importance: Standards as specified within the contract Commercial standards-- · Standards developed by international or national industry standards bodies that have been widely adopted by industry. Examples of widely adopted standards are: i) SQL for databases (e.g. SQL for databases ANSI ISO/IEC 9075-1, ISO/IEC 9075-2, ISO/ IEC 9075-3, ISO/ IEC 9075-4, ISO/IEC 9075-5) ii) HTML for presentation layer (e.g. XML 1.0 www.webstandards.org) iii) iv) XML for data transfer Web Services for remote system calls · Standards adopted by industry consensus-based standard bodies and widely adopted in the marketplace.

Given the increased interconnectivity of systems and applications, as well as increased standardization in modern systems, it is essential that software be easily adaptable and not tied down to specific hardware.11 By stipulating software independence from hardware in a contract, the government can modify, upgrade, or update software without having to replace the hardware it has already invested in. While some dependencies are unavoidable and important, utmost care should be taken to ensure that a long dependence chain among a set of components is not created. In other words, any system development contract should require that each component is designed so that as few future components as possible will need to depend--either directly or indirectly--on it to function.12

5) Life Cycle Sustainability--The Contractor shall consider use of COTS/NDI [nondevelopmental item] and open standards to enhance the system's life cycle supportability by implementing performance-based logistics arrangements to sustain the components through their life cycle.13

In recent years, one of the primary drivers of cost increases in systems development has been the lack of competition available for sources of supply and/or repair. By requiring the contractor who is developing the system to provide information documenting that additional sources of supply or support are available, it ensures that the government can reap the benefits of competition from other firms in the future, and will be able to support its systems over the long-term.

7) Reuse of Preexisting or Common Items--The Contractor shall reuse preexisting or common items unless a determination is made to not reuse. Exceptions to reuse of preexisting items must be accompanied by justification, such as cost (both of adoption and life cycle support), schedule, functional and nonfunctional performance, etc.15

Performance-based logistics (PBL) is DOD's product support strategy to ensure system readiness by procuring performance by capitalizing on integrated logistics chains and public/private partnerships. The backbone of PBL is the purchase of system sustainment as an affordable, integrated package

Reuse of software is common in the commercial marketplace as a standard to allow for internal cost controls during design and development. In fact, a recent Government Accountability Office (GAO) review found that it was customary for as much as 70 percent of software code to be reused for the develop-

40

Contract Management | August 2008

open architecture: a best practice in need of governmentwide implementation

·

De facto standards (those widely adopted and supported in the marketplace).

About the Author

MICHAEL J. ARENDT JR. is a PhD studying public policy at the University of Maryland­ College Park, and works as a faculty research assistant at its Center for Public Policy and Private Enterprise.

Note: Standards that are not specified within this contract or that are modified must be submitted to and approved by the Government Program Manager prior to use.

Send comments about this article to [email protected]

By clearly defining which standards are to be used and the specific order of importance for consideration, virtually no room for misinterpretation is left for standards or requirements. In addition, requiring the use of exact, well-defined commercial standards permits easy access and understanding for any other firm in the marketplace to modify/support the system in the future.

endnotes

1. Otto, Scott, "Establishing a Naval Enterprise Reuse Repository: An Analysis of the Interaction between Engineering and Public Policy," accessed December 11, 2007, at www.mepp.umd.edu/students/documents/mepp_practicum_scott_otto.pdf. Guertin, Nickolas, "Naval Open Architecture, Open Architecture and Open Source in DOD," accessed March 14, 2007, at www.afei.org/brochure/7a03/ documents/NickGuertin_03.14.07.pdf. Shannon, James, "Naval Open Architecture," Gulf Coast System of Systems Community of Interest Symposium, accessed February 21, 2007, at https://acc.dau.mil/oa. Nelson, Eric M., "Open Architecture Technical Principals and Guidelines 1.5.4," International Business Machines Corp., September 19, 2007. PEO-IWS 7, Naval Open Architecture Contract Guidebook, accessed October 25, 2007, at https://acc.dau.mil/oa. "Managing International Supply and Demand at Intel," Intel Technology Journal, Vol. 9, Issue 3, August 3, 2005, available at www.intel.com/ technology/itj/2005/volume09issue03/art03_ testequipment/p05_benefits.htm. PEO-IWS 7, op. cit. Hertz, J.C., et. al., "Open Technology Development: Roadmap Plan," April 2006, available at www.acq.osd.mil/asc. PEO-IWS 7, see note 5. Ibid. Defense Science Board, "Report of the Defense Science Board Task Force on Defense Software," Department of Defense, Washington, DC, November 2000, available at www.acq.osd.mil/dsb/reports. Weide, Bruce W., "Component-Based Systems," January 2001, available at www.cse.ohio-state. edu/~weide/rsrg/documents/2001/01W2.pdf. PEO-IWS 7, see note 5. Defense Acquisition University, "Performance-Based Logistics: A Program Manager's Product Support Guide," March 2005, available at www.dau.mil. PEO-IWS 7, see note 5. U.S. General Accounting Office, "Defense Acquisitions: Stronger Management Practices are needed to Improve DOD's Software-Intensive Weapon Acquisitions," March 2004, available at www.gao.gov. PEO-IWS 7, see note 5.

2.

Conclusion

The navy's creation of SHARE is a tremendous step forward in the movement toward implementing OA across the service. In addition, the specific requirements outlined in the updated Naval Open Architecture Contract Guidebook represent a significant paradigm shift that requires navy contractors to use OA principles and guidelines and navy contracting officials to specifically detail these requirements and require proof of adherence as a stipulation within their contracts. However, these principles and guidelines are not unique to contracting by the navy and can be implemented by contracting officials in all services, departments, and agencies. It is important to understand the basic guidelines, the purpose and advantage of each, and how they can be tailored and implemented in a different organizational setting. As the acquisition environment of the future is likely to entail decreasing budgets and shorter timelines, the cost savings and increased adaptability of OA will become an increasingly more important concept in government hardware, software, and system acquisition. As OA is further adopted by government entities, the network of software and hardware assets available for reuse will only grow, thus multiplying the positive effects of OA across the government enterprise. CM

3.

4.

5.

6.

7. 8.

9. 10. 11.

12.

13. 14.

15. 16.

17.

Contract Management | August 2008

41

Information

6 pages

Find more like this

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

1132141


You might also be interested in

BETA
Alterations to Ships Accomplished by AITs
Microsoft Word - Innotiive_Company_Profile 5th Oct
Microsoft Word - TermPaper-AppleCom.doc