Erratum to: P. Donohoe (Ed.) Software Architecture DOI: 10.1007/978-0-387-35563-4 The book was inadvertently published with an incorrect name of the copyright holder. The name of the copyright holder for this book is: © IFIP International Federation for Information Processing. The book has been updated with the changes.

Architecture modernization requires a clear roadmap to transition to a new state. However, creating that roadmap is often difficult, particularly in complex settings. This paper investigates how one might systematically derive such roadmaps. We introduce the Architecture Options Workshop (AOWS), a systematic treatment to address the problems of moving from identi ed system risk themes to potential design options, and a roadmap for implementation. Many techniques present a range of options and leave it to stakeholders to select, or are tailored for detailed design processes. The Architecture Options Workshop, by contrast, is intended to resolve the question of what options to choose at a high level of abstraction. Applying a technical action research approach, we applied the AOWS to three di erent real-world systems. We describe the advantages -- reasonably efficient, systematic architecture modernization -- and some remaining questions for future research.

Abstract : For software developers, the selection of a particular NoSQL technology imposes a specific distributed software architecture and data model, making the technology selection difficult to defer. NoSQL database technologies provide high levels of performance, scalability, and availability by simplifying data models and supporting horizontal scaling and data replication. Each NoSQL product embodies a particular set of consistency, availability, and partition tolerance (CAP) tradeoffs, along with a data model that reduces the conceptual mismatch between data access and data storage models. This means technology selection must be done early, often with limited information about specific application requirements, and the decision must balance speed with precision, as the NoSQL solution space is large and evolving rapidly. In this paper we present the method and results of a study to compare the architecturally-relevant characteristics of three NoSQL databases for use in a large, distributed healthcare organization. We reflect on some of the fundamental difficulties of performing detailed technical evaluations of NoSQL databases specifically, and big data systems in general, that have become apparent during our study.

The selection of a particular NoSQL database for use in a big data system imposes a specific distributed software architecture and data model, making the technology selection difficult to defer and expensive to change. This paper reports on the selection of a NoSQL database for use in an Electronic Healthcare Record system being developed by a large healthcare provider. We performed application-specific prototyping and measurement to identify NoSQL products that fit data model and query use cases, and meet performance requirements. We found that database throughput varied by a factor of 10, read operation latency varied by a factor of 5, and write latency by a factor of 4 (with the highest throughput product delivering the highest latency). We also found that the throughput for workloads using strong consistency was 10-25% lower than workloads using eventual consistency. We conclude by reflecting on some of the fundamental difficulties of performing detailed technical evaluations of NoSQL databases specifically, and big data systems in general, that have become apparent during our study.

The choice of a particular NoSQL database imposes a specific distributed software architecture and data model, and is a major determinant of the overall system throughput. NoSQL database performance is in turn strongly influenced by how well the data model and query capabilities fit the application use cases, and so system-specific testing and characterization is required. This paper presents a method and the results of a study that selected among three NoSQL databases for a large, distributed healthcare organization. While the method and study considered consistency, availability, and partition tolerance (CAP) tradeoffs, and other quality attributes that influence the selection decision, this paper reports on the performance evaluation method and results. In our testing, a typical workload and configuration produced throughput that varied from 225 to 3200 operations per second between database products, while read operation latency varied by a factor of 5 and write latency by a factor of 4 (with the highest throughput product delivering the highest latency). We also found that achieving strong consistency reduced throughput by 10-25% compared to eventual consistency.

: The Interagency Program Office has been exploring a number of options for interoperation between the electronic health record systems used by DoD and the Veteran's Health Administration. These have included replacing both systems with a single new Integrated Electronic Health Record (iEHR) system and federating the information contained in existing systems, among other approaches. In addition, DoD has been exploring caching approaches to improve delivery of electronic health record applications over network links with low quality of service. The Military Health System's Joint Program Committee funded the Army Telemedicine and Advanced Technology Research Center (TATRC) to work with the SEI to investigate the use of emerging NoSQL database technology to achieve the data storage capabilities needed for these systems. The SEI conducted a stakeholder workshop with MHS stakeholders to identify architecture drivers and quality attribute requirements for these applications. These requirements were then used to create technology evaluation criteria. The SEI then worked with developers from the TATRC Advanced Concepts Team to conduct a series of technology experiments to assess the suitability of several NoSQL products against the evaluation criteria. One NoSQL product was selected for evaluation from each of the four NoSQL categories: Document Store (MongoDB), Column Family Store (Cassandra), Key-Value Store (Riak), and Graph Store (Neo4J). Each product was installed in a server cluster in the SEI Virtual Private Cloud, and performance measurements were made for each using the YCSB (Yahoo! Cloud Serving Benchmark) test driver. Several workloads were tested, including read-only, write-only, bulk load, and mixed read/write. Testing was also conducted to assess performance of the server cluster when there are network delays or partitions.

Many attempts have been made to increase the productivity and quality of software products based on software reuse. Software product line practice is one such approach, one that focuses on developing a family of products which have a majority of features in common. Hence, there are numerous requirements that are common across the family, but others are unique to individual products. Traditional requirements engineering methods were conceived to deal with single product requirements and are usually not flexible enough to address the needs arising from reusing requirements for a family of products. There is also the additional burden of correctly identifying and engineering both product-line-wide requirements and product-specific requirements as well as evolving them. Therefore, in this special issue, we want to highlight the importance and the role of requirements engineering for product line development as well as to provide insights into the state of the art in the field.

The objective of this workshop is to attract professionals from academia and industry to discuss the role of requirements engineering in product line developments, including new techniques, methods and tools that will help practitioners to improve their current requirements engineering practices. The workshop will address experiences from practitioners, empirical evidence about current practices, successful deployment of novel approaches, and current obstacles and proposed solutions. Nevertheless, REPOS also aims to become a discussion forum about the state of the art and practice for practitioners and researchers on Requirements Engineering for Software Product Lines.

This position paper describes our current work in adapting a software product line technique to the constraints of a development organization. We report on applying a commonality and variability analysis with an organization adopting a software product line approach while facing sever resource constraints because of current product development commitments. The immediate focus of the paper is on blending commonality and variability analysis into the organization's existing requirements development process. The longer-term goal of this work is to facilitate the transition to product lines in a minimally intrusive way. The paper describes how the approach was introduced and implemented, and summarizes the benefits achieved and the issues arising from the work to date.

The production method for a software product line is the coordinated set of processes, models, and tools chosen to implement the essential product line activities of core asset development and product development. This paper shows how the task of engineering a production method for a product line can be facilitated by applying concepts from the domain of method engineering. A case study of an industrial product line illustrates how its production method was engineered to achieve specific business goals.

: Software product lines are of strategic importance to the organizations that adopt them, affecting both an organization's position in an existing market and its ability to react to new and changing markets. An organization's production system (i.e., how it builds its products) is also of strategic importance, directly affecting, for example, that organization's ability to deliver new products quickly (i.e., its time to market). The production strategy for a software product line is the high-level description of how the production system realizes both the core assets and products. The production strategy is derived from the organization's business strategy and is intended to coordinate the actions of the core asset and product developers. The strategy describes how the product line practices should be employed so that the product line organization will achieve its production goals. This technical note describes a technique, which is based on well-known procedures for defining and evaluating a business strategy, for formulating the production strategy of a production system. An example of strategy creation is provided.

This tutorial introduces the essential activities and underlying practice areas of software product line development. It reviews the basic concepts of software product lines, discusses the costs and benefits of product line adoption, introduces the SEI's Framework for Software Product Line Practice, and describes approaches to applying the practices of the framework.

Companies such as Toyota have achieved significant competitive advantage by treating product production as a system that can be planned and optimized. Software product line organizations can achieve similar advantage when they explicitly coordinate the actions of core asset and product developers. We describe a technique for planning the production system for a software product line organization. The technique encompasses a production strategy, which relates the production goals of the product line to the method of core asset and product development; and a production method, which coordinates the development of core assets with the production of products. The results of the technique are documented in a production plan, which guides the product developers through the steps of production. Data gathered from representatives of SPLC Product Line Hall of Fame members and our experience working with product line organizations are used to illustrate problems and specify solutions.

Abstract : The Carnegie Mellon (trademark) Software Engineering Institute held the Seventh Department of Defense (DoD) Product Line Practice Workshop in September 2004. The workshop was a hands-on meeting to share DoD product line practices, experiences, and issues and to discuss ways in which specific product line practices are accomplished within the DoD. All of the participants were invited to give a short presentation about their organization's product line interests and experiences. In general, participants reported encouraging progress on DoD software product lines. This report summarizes the following workshop presentations: "Force XXI Battle Command Brigade and Below (FBCB2)," by Peter Blankenship, Northrop Grumman; "Austin Info Systems and Software Product Lines," by Tom Baker; "The Common Avionics Architecture System (CAAS)," by Stephanie Burns, Rockwell Collins; "RangeWare," by Ed Dunn, Naval Undersea Warfare Center (NUWC); "Argon Engineering Associates and Software Product Lines," by Dave Drum, Argon; "Army Training Support Center (ATSC)", by Frank Polster; "Army Program Executive Office (PEO) Aviation," by James Baxter; and "The Common Gunnery Architecture," by Dean Runzel, Army PEO for Simulation, Training, and Instrumentation.

Product line analysis (PLA) is early requirements engineering for a product line of software-intensive systems. It encompasses the rapid elicitation, analysis, specification, and verification of the requirements for a product line. The premise of product line analysis is that a sound initial understanding of the problem to be solved is essential before an organization embarks on a software product line as a solution.

: A software product line organization exists to produce products. Much of the research on creating products via product lines has focused on developing core assets such as requirements, architectures, and components. This technical note presents the results of a study that focused on how product line organizations create products (e.g., their production strategy and how core assets are used in the production process). These results include compiled responses to the questionnaire used in the study and follow-up interviews.