Archive: 2015-11

At an open architecture summit in November 2014, Katrina G. McFarland, assistant secretary of defense for acquisition said that 75 percent of all Defense Department acquisition strategies implement open systems architecture across all services and agencies. "This department is seriously engaged in trying to understand how to help our program managers and our department and our industry look at open architecture and its benefits," McFarland said, "and understand truly what our objectives are related to intellectual property and making sure that we're doing it based on the best interest of national security relative to a business case." Open systems architecture (OSA) integrates business and technical practices to create systems with interoperable and reusable components. OSA offers outstanding potential for creating resilient and adaptable systems and is therefore a priority for the DoD. The challenges with OSA, however, make it one of the most ambitious endeavors in software architecture today. A group of researchers at the SEI recently held an informal roundtable with David Sharp, a senior technical fellow at The Boeing Company and an expert in software architecture for embedded systems and systems of systems, to discuss OSA-based approaches and how best to help the DoD achieve them. This blog post presents highlights of the discussion with Sharp on OSA approaches and how they can best be integrated in DoD system development.

Many systems and platforms, from unmanned aerial vehicles to minivans and smartphones, are realizing the promise of Open Systems Architecture (OSA). A core tenet of OSA is the broad availability of standards and designs, the sharing of information between developers, and in some cases downloadable tool kits. In return for openness, a broader community of potential developers and applications emerges, which in turn increases adoption and use. Consequently, there is a trade-off. Openness is a two way street, allowing devious opportunities for cyber intrusion and attack and less-than-ideal code to enter the system (because of the mechanisms of OSA). This blog post briefly examines the potentials, good and bad, of OSA and reviews four best practices for open source ecosystems.

According to the National Institute of Standards and Technology (NIST), Information Security Continuous Monitoring (ISCM) is a process for continuously analyzing, reporting, and responding to risks to operational resilience (in an automated manner, whenever possible). Compared to the traditional method of collecting and assessing risks at longer intervals--for instance, monthly or annually--ISCM promises to provide near-real-time situational awareness of an organization's risk profile. ISCM creates challenges as well as benefits, however, because the velocity of information gathered using ISCM is drastically increased. Development, operation, and maintenance processes built for a more leisurely pace can thus be overwhelmed. This blog post explores how organizations can leverage Agile methods to keep pace with the increased velocity of ISCM risk information, while ensuring that changes to systems are conducted in a controlled manner.

In my preceding blog posts, I promised to provide more examples highlighting the importance of software sustainment in the U.S. Department of Defense (DoD). My focus is on sustaining legacy weapons systems that are no longer in production, but are expected to remain a key component of our defense capability for decades to come. Despite the fact that these legacy systems are no longer in the acquisition phase, software upgrade cycles are needed to refresh their capabilities every 18 to 24 months. In addition, significant modernization can often be made by more extensive, focused software upgrades with relatively modest hardware changes. This third blog post describes effective sustainment engineering efforts in the Army, using examples from across its software engineering centers. These examples are tied to SEI research on capability maturity models, agility, and the Architecture Analysis and Design Language (AADL) modeling notation.