Tension and disconnects between software and systems engineering functions are not new. Grady Campbell wrote in 2004 that "systems engineering and software engineering need to overcome a conceptual incompatibility (physical versus informational views of a system)" and that systems engineering decisions can create or contribute to software risk if they "prematurely over-constrain software engineering choices" or "inadequately communicate information, including unknowns and uncertainties, needed for effective software engineering." This tension holds true for Department of Defense (DoD) programs as well, which historically decompose systems from the system level down to subsystem behavior and breakdown work for the program based on this decomposition. Hardware-focused views are typically deemed not appropriate for software, and some systems engineers (and most systems engineering standards) have not yet adopted an integrated view of the two disciplines. An integrated view is necessary, however, because in complex software-reliant systems, software components often interact with multiple hardware components at different levels of the system architecture. In this blog post, I describe recently published research conducted by me and other members of the SEI's Client Technical Solutions Division highlighting interactions on DoD programs between Agile software-development teams and their systems engineering counterparts in the development of software-reliant systems.
In a previous post, we defined DevOps as ensuring collaboration and integration of operations and development teams through the shared goal of delivering business value. Typically, when we envision DevOps implemented in an organization, we imagine a well-oiled machine that automates
- infrastructure provisioning
- code testing
- application deployment
Ultimately, these practices are a result of applying DevOps methods and tools. DevOps works for all sizes, from a team of one to an enterprise organization.
Earlier this month, the U.S. Postal Service reported that hackers broke into their computer system and stole data records associated with 2.9 million customers and 750,000 employees and retirees, according to reports on the breach. In the JP Morgan Chase cyber breach earlier this year, it was reported that hackers stole the personal data of 76 million households as well as information from approximately 8 million small businesses. This breach and other recent thefts of data from Adobe (152 million records), EBay (145 million records), and The Home Depot (56 million records) highlight a fundamental shift in the economic and operational environment, with data at the heart of today's information economy. In this new economy, it is vital for organizations to evolve the manner in which they manage and secure information. Ninety percent of the data that is processed, stored, disseminated, and consumed in the world today was created in the past two years. Organizations are increasingly creating, collecting, and analyzing data on everything (as exemplified in the growth of big data analytics). While this trend produces great benefits to businesses, it introduces new security, safety, and privacy challenges in protecting the data and controlling its appropriate use. In this blog post, I will discuss the challenges that organizations face in this new economy, define the concept of information resilience, and explore the body of knowledge associated with the CERT Resilience Management Model (CERT-RMM) as a means for helping organizations protect and sustain vital information.
Melvin Conway, an eminent computer scientist and programmer, create Conway's Law, which states: Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. Thus, a company with frontend, backend, and database teams might lean heavily towards three-tier architectures. The structure of the application developed will be determined, in large part, by the communication structure of the organization developing it. In short, form is a product of communication.
Soldiers in battle or emergency workers responding to a disaster often find themselves in environments with limited computing resources, rapidly-changing mission requirements, high levels of stress, and limited connectivity, which are often referred to as "tactical edge environments." These types of scenarios make it hard to use mobile software applications that would be of value to a soldier or emergency personnel, including speech and image recognition, natural language processing, and situational awareness, since these computation-intensive tasks take a heavy toll on a mobile device's battery power and computing resources. As part of the Advanced Mobile Systems Initiative at the Carnegie Mellon University Software Engineering Institute (SEI), my research has focused on cyber foraging, which uses discoverable, forward-deployed servers to extend the capabilities of mobile devices by offloading expensive (battery draining) computations to more powerful resources that can be accessed in the cloud, or for staging data particular to a mission. This blog post is the latest installment in a serieson how my research uses tactical cloudlets as a strategy for providing infrastructure to support computation offload and data staging at the tactical edge.
A DevOps approach must be specifically tailored to an organization, team, and project to reflect the business needs of the organization and the goals of the project.
Software developers focus on topics such as programming, architecture, and implementation of product features. The operations team, conversely, focuses on hosting, deployment, and system sustainment. All professionals naturally consider their area of expertise first and foremost when discussing a topic. For example, when discussing a new feature a developer may first think "How can I implement that in the existing code base?" whereas an operations engineer may initially consider "How could that affect the load on our servers?"
DevOps is a software development approach that brings development and operations staff (IT) together. The approach unites previously siloed organizations that tend to cooperate only when their interests converge, resulting in an inefficient and expensive struggle to release a product. DevOps is exactly what the founders of the Agile Manifesto envisioned: a nimble, streamlined process for developing and deploying software while continuously integrating feedback and new requirements. Since 2011, the number of organizations adopting DevOps has increased by 26 percent. According to recent research, those organizations adopting DevOps ship code 30 times faster. Despite its obvious benefits, I still encounter many organizations that hesitate to embrace DevOps. In this blog post, I am introducing a new series that will offer weekly guidelines and practical advice to organizations seeking to adopt the DevOps approach.
In an era of sequestration and austerity, the federal government is seeking software reuse strategies that will allow them to move away from stove-piped development toward open, reusable architectures. The government is also motivated to explore reusable architectures for purposes beyond fiscal constraints: to leverage existing technology, curtail wasted effort, and increase capabilities rather than reinventing them. An open architecture in a software system adopts open standards that support a modular, loosely coupled, and highly cohesive system structure that includes the publication of key interfaces within the system and full design disclosure.