My experience, evaluation of the market place, goal of Net-Centricity, and the current automation challenges leads me to believe that Department of Defense should develop and maintain its own LINUX type of distribution. In this series of blog postings I am going to offer my observations, research, knowledge, and conceptualization on a fundamental change in the approach of automation system development for the Department of Defense.
Why should a DoD LINUX be considered?
While serving in Iraq, my duties included processing paperwork to fund several automation systems along with contractual obligations and work schedule review. In addition, for several months I facilitated a round house update brief and informal issue discussions for automation systems that originated in intelligence sections, later increased participation to any systems that touched the intelligence communities. Unfortunately, quite a few challenges continued to create difficulties requiring developers, programmers, and Defense Industry to quickly react and modify systems to ensure soldiers success on the automation system. However, these reactions require continuous resources in labor and funding along with strong coordination, ultimately costing both the Defense Industry profit and the taxpayer.
One overwhelming challenge continuing to exasperate me is the multitude of Operating Systems (OS) used for the various devices, systems, and servers in the U.S. Army and Department of Defense. The OSes range from WindowsXP, Windows2000, Windows 98, UNIX distributions (Solaris), LINUX distributions (Red Hat, LynxOS, Linux VR) and many more. Now include the multitude of software expected to function seamlessly together, some OS specific and others cross platform. Add in the consideration of the updates and patches required to keep up with security and fixing bugs, especially if the software is in a spiral development model and the complexity is drastic. When considering several software packages are directly linked to the Operating System, the ability to upgrade either software or OS becomes impossible or cost prohibited. With all of the options, patches, variations, and operating systems, the Information Assurance demand continues to be a required area of vast resources (time and personnel). All in all, there are vast amounts of systems (combining all the hardware and software) that erode from seamless interoperability.
While facilitating discussion, I observed that multiple automation systems either had been developed or were in development for a requirement; each developer using different operating software, different mapping software, different database structure and software, and different communication software. In addition, I realized that nearly (not all) military systems gain usefulness using the core components of a Kernel, database, mapping, and communications. However, different users/customers required different features and I do not believe a single provider can sufficiently meet all the users’ requirements. This invalidates a single Defense Industry provider but does not eliminate the system integrator.
“The Concept”
Recognizing the challenges I mentioned above along with quite a few more to be addressed later, I started developing a concept I called Joint Application Computing (JAC) with the motto “You don’t know JAC.” The concept is in the infancy and therefore is missing critical components and is quite rough. Hopefully in time the concept becomes polished and adopted by the Department of Defense.
The Agency - The Department of Defense will create an agency with the purpose of building an OS distribution using the GPL concept. The agency uses military programmers, civilian programmers, and contracting vehicles (long term, short term, and problem specific) to meet technical requirements. They will maintain the kernel, evaluate and manage any collaboration efforts for modification and upgrades to the Kernel by Defense Industry. As software is added to the OS, the agency will test extensively in multitude of software suites and various networking capabilities in order to validate compliance, feasibility, and information assurance. The Agency is charged with continued development of the Kernel to insure the Defense Industry software meets DoD requirements (Example: Army FCS) and to continuously exploit advances in the marketplace.
Business Model – The goal is to provide The Defense Industry the capability to continue profitability but reduce cost overall to the Department of Defense. The Defense Industry bids on modules giving functionality to a system ranging from servers to small devices. The point is not to consolidate systems into a single provider but to increase competition and quality with the exception of the Kernel, the anchor point. The Kernel with a form of Public License would give the Defense Industry the ability to contribute and shape the development and changes of the Kernel.
The Defense Industry participants can be system integrators and build the systems from a multitude of module providers fully integrated at DoD level. Intuition (not factual or computed) would lean towards reduced development cost (hopefully more profit) for the Industry, not only working with a standard but the capability to modify the standard to meet bided products. The greatest loser in this model resides at the Operating System providers and the second layer licensing contracts currently in place. Another positive approach that differs from the LINUX community itself is the acceptance and promotion of propriety code in the modules (i.e graphic card drivers). Therefore, this model could increase competition, reduce development costs, and ensure a strong and vibrant market instead of consolidating on single vendors.
The OS – Provides a Kernel that contains security components that facilitate multiple security classifications and users. The Kernel maintains all the current requirements expected by users for LINUX but adds the tools to maintain an internal database, mapping, and communications. Multiple levels of Kernels can be developed ranging from Servers to mobile devices similar to the Google Android platform (proof it can be done). The Defense Industry then meets contracted requirements by providing modules that coordinate amongst themselves by the common internal communications in the Kernel. An example of modules is a Self Propelled Howitzer system consisting of the Kernel, Weather Module, Munitions module, Enemy Intel module, Ballistic Module, and quite a few more. Therefore, each module can be developed with the knowledge they can communicate with each other through the common interface in the Kernel and through the Defense Industry collaboration system.
Conclusion
The biggest areas that challenge the feasibility of the concept lay within Business interference (Lobbyist), Legislation, Legalities of GPL or the creation of a new Public License, and Legacy Systems.
As further conceptualization is captured I will add the following sections including Technical Environment, Open Source, Security, Information Assurance, Legal Considerations, Collaboration, Business Model and Contracting, Testing, Legislation, and the biggest topic of Business Interference (Lobbyist)
Bradley A. Riley, MAJ, student, Command and General Staff College, Ft. Gordon Satellite Campus
“The views expressed in this blog/posting are those of the author and do not reflect the official policy or position of the Department of the Army, Department of Defense, or the U.S. Government.”
No comments:
Post a Comment