Posted on by SATURN Conferencein
Forrest Shull, Carnegie Mellon Software Engineering Institute (SEI);
Thomas DuBois, The Boeing Company;
Nick Guertin, Office of the Deputy Assistant Secretary of the Navy for Research, Development, Test, and Evaluation;
Michael McLendon, SEI;
and Douglas C. Schmidt, Vanderbilt University and SEI
Forrest Shull opened the session with a brief introduction to Open Systems Architectures (OSA), an initiative within the DoD, to make systems more configurable and adaptable than they are today. This initiative ties in with the Better Buying Power Initiative, which focuses on making systems more efficient and effective. It's about system architecture, but software architecture is buried within that. How do we make systems more modular, more open, and still deal with interfaces between the components when the systems are part of a community? How much to make open and how much to keep behind the wall are issues that this initiative must deal with. Each panelist gave a brief on their opinions of where OSA stands today and what its challenges are.
Nick Guertin: A diagram of the past Naval business model shows a problem with increasing vendor lock-in, and the government needs a way to make business choices in a more risk-prudent manner. The future Naval business model needs to get away from shifts that take years and intends to use OSA for affordable design, testing, maintenance, and replacement. The challenge is to create modularity with OSA, plug and play, and payloads over platforms. To do this, the Navy plans to procure basic platforms that are able to quickly change modular components for flexibility. And by developing product lines, the Navy can reduce vendor lock-in, build in adaptability, and integrate and deliver faster. Modularization will increase competition across the lifecycle as contracts are created by functional module, and a common product line can be repurposed across many platforms.
Thomas DuBois: His program, Future Vertical Lift, is intended to replace all the helicopters in service and is organized across five capability sets and three families of aircraft by size. The program wants as much reuse as possible to reduce the costs. This program is the perfect opportunity to begin applying some OSA principles; they'll find out if it drives down cost and creates a platform that will serve many missions and capabilities. The first test case was a project called the Joint Common Architecture Demonstration, in which they created a fusion application, software to test the application, and artifacts to prove that they conformed to the open-systems standards. This project ended in a blind test, meaning that the development team did not know what environment the application would be run in - it had to work anywhere while meeting specific latency requirements. And the demo was a success! The results are preliminary, but he sees them as the beginning of a trend. DuBois noted four opportunities for further study:
(1) Make data modeling easier.
(2) Study formal methods of behavior modeling.
(3) Propose and test new methods for RDT&E.
(4) Solve the integration challenge.
Douglas Schmidt: How can we keep an unfair advantage in a flat world? We can't, if we have to keep reinventing the software layers over and over again from scratch. The hardware world has benefited from standardization and commoditization for decades; in contrast, software tends to get buggier, slower, and more expensive over time. This is especially true for cyber-physical systems (CPS) that the DoD requires. Why is this? The hardware community has learned to live within a certain number of constraints, and people innovate within those constraints. Software isn't as standardized, and solutions are stove-piped and spaghetti-laden; meanwhile, size and importance are growing. Ironically, funding for software research has dropped dramatically, and the gap between the need for CPS and the ability to affording it is widening. Elements of a collaborative R&D strategy include advancing the practice of mission-critical CPS via intentionally coordinated research and OSA-based technology transition. There are good examples of holistic approaches to OSA, such as FACE (Future Airborne Capability Environment). We can get there by investing wisely in R&D, leveraging COTS hardware and software advances, and mastering principles and patterns for developing complex systems.
Michael McLendon: OSA nests within DoD's acquisition reform policies as a result of the Better Buying Power (BBP) Initiative. BBP 1.0 included papers on OSA and on data rights, so the issues have mistakenly sometimes been conflated. The point is that the DoD needs to reduce the lifecycle costs of systems and to increase the speed of development. We used to have more time to do analysis; we don't have that time anymore. To meet the required pace, we have to focus on commonality and reuse. The cycle time for recognizing the need for OSA is about 16 years, but the concept of form-fit-function goes back decades. Issues repeat themselves decade after decade, and OSA fits that pattern. We need to think about solving the problem in different ways now. OSA is about architecture and systems. You first need an awareness and commitment to the value of architecture to drive an overall strategy. It's not usually viewed as part of the critical path, and this is a deficiency. 80% of the cost of a system is affected by early design decisions, so architecture must be part of the systems engineering tradeoff process. In addition, the DoD needs positions for leads in software acquisition, and every program should have a chief architect. These needs must be filled to really take advantage of OSA and to create "S-OSA," or sustainable open systems architecture.