Mistrik / Bahsoon / Kazman Economics-Driven Software Architecture

1. Auflage 2014
ISBN: 978-0-12-410507-2
Verlag: Elsevier Science & Techn.
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 380 Seiten

Economics-driven Software Architecture presents a guide for engineers and architects who need to understand the economic impact of architecture design decisions: the long term and strategic viability, cost-effectiveness, and sustainability of applications and systems. Economics-driven software development can increase quality, productivity, and profitability, but comprehensive knowledge is needed to understand the architectural challenges involved in dealing with the development of large, architecturally challenging systems in an economic way. This book covers how to apply economic considerations during the software architecting activities of a project. Architecture-centric approaches to development and systematic evolution, where managing complexity, cost reduction, risk mitigation, evolvability, strategic planning and long-term value creation are among the major drivers for adopting such approaches. It assists the objective assessment of the lifetime costs and benefits of evolving systems, and the identification of legacy situations, where architecture or a component is indispensable but can no longer be evolved to meet changing needs at economic cost. Such consideration will form the scientific foundation for reasoning about the economics of nonfunctional requirements in the context of architectures and architecting. - Familiarizes readers with essential considerations in economic-informed and value-driven software design and analysis - Introduces techniques for making value-based software architecting decisions - Provides readers a better understanding of the methods of economics-driven architecting

Autoren/Hrsg.

Mistrik, Ivan

Bahsoon, Rami

Kazman, Rick

Zhang, Yuanyuan

Leseproben

Foreword by John Grundy Economics-Driven Software Architecting
John Grundy Swinburne University of Technology Software architecting has become a critical part of most software systems’ development projects. However, as popularized in the seminal papers by Shaw and Garlan (1996) and Kruchten (1995), most software architecture research and practice have historically been focused on the technical aspects of the task, not on value-driven or value-creation aspects (Boehm and Sullivan, 2000; Bahsoon and Emmerich, 2008). Given the huge impact software architecture choices have on system performance, scalability, and maintainability, not to mention the actual adoption and deployment of systems, it has become accepted that software architecting can no longer ignore economics-driven imperatives (Bass et al., 2003; Kruchten et al., 2006). So saying, there is a need to both incorporate an economics-driven perspective into the software architecting of systems and to balance this with continuing to solve increasingly challenging technical problems. There are several major areas for incorporating a software economics perspective in the architecting process: • Requirements Constraints (particularly Quality of Service on software architecture) on architecture—requirements are increasingly challenged to meet with increased demand on scaling, reliability, robustness, and security. Most, if not all, of these constrain the architectural solution space, sometimes in conflicting ways. Meeting some implies more costly, less flexible and less extensible architectural solutions. Expected or unanticipated changing QoS can have dramatic impact on architecture, including rendering a particular architecture choice no longer tenable. • Technical Constraints on architecture—technical choices may be constrained by a range of issues and are not limited to cost of solution platform (software, hardware, network, third-party applications); availability; open versus proprietary; and likely future technological change (e.g., the emergence of the cloud computing paradigm). Once commitment has been made to one set of technical solutions, change is almost invariably expensive. • Deployment environment constraints—architectural solutions make heavy use of other applications and components in their deployment environment, as well as platform hardware and networks. With the advent of cloud computing, a variety of platform-as-a-service and infrastructure-as-a-service, with elastic availability, have complicated this aspect further. Different platforms offer different technical and QoS constraints, but they also come with differing cost models. • Process constraints greatly impact software architecting—the advent of agile methods with the concept of the “emergent” architecture has some strong cost incentives: Implement only as much as you have to and no more. Unfortunately, as applications and user requirements evolve, sometimes dramatic re-architecting and reengineering become necessary, with attendant cost implications. • Team constraints are an increasingly interesting area. Sometimes many of the above decisions are actually made due to team or organizational preferences, biases, and prior experiences. Sometimes dominant individuals or politically or economically powerful lobbies hold sway over key architectural solution decisions, disregarding some of the factors above and including cost and longer term software economic implications. Sometimes architecture choices are driven by the concept of “value” to the team, for example, a reason for exploring interesting new technologies and solving interesting technical problems, instead of value to business, stakeholders, or even maximization of the actual value of the software itself. • Finally, business constraints must be taken into account. These constraints include limitations on purchase or usage of hardware and software, desire to leverage value in the future if not the present, balancing cost versus opportunity, and potentially increasing the attractiveness of the product due to architectural decisions that appeal to likely or potential stakeholders. Simply choosing the “cheapest” options often turns out to be a false economy. Similarly, massively overengineering applications and the consequences of cost and loss of time-to-market edge can have severe economic and value implications. The concept of economics needs to be incorporated into the software architecting process itself. Traditionally, most, if not all, of the practice of software architecture has been technical in focus. However, many constraints impacting on architectural decision making have major implications for platform and software costs, team costs, enhancement of software value, enhancement of company value and capability, and positioning of product and organization for (un)anticipated future demand. Following are some suggestions on how each area described above might be advanced. Requirements impact on architecture economics
Architectures must realize the functional and nonfunctional requirements that have been set for them. As several recent works have stated (Avgeriou et al., 2011), many now think software architecting and requirements engineering must proceed hand in hand rather than the former rigidly follow the later. In fact, architectural choices often constrain the requirements as often as not (Tang et al., 2011; Woods and Rozanski, 2011). Quality of Service (QoS) constraints have a major impact on the economics of software architecture, both in terms of the expense of its solution and the value inherent to the solution. Typically, the higher the QoS expectations e.g. greater the throughput, reliability, security, and scalability needed by stakeholders for their application, greater the complexity, implementation and cost required. However, a simple, cheap, quick-to-build web application that is intended to manage highly mission-critical or sensitive data is going to have much less–if any–value, than one demonstrably safe, secure, robust and clearly meeting the QoS requirements set for it. Similarly, an over-engineered solution that will never be required to scale, be as secure, manage highly private data, or face a range of difficult deployment environment conditions, will waste design, development, testing and deployment resources to little or no added value. Balancing the current QoS needs against architectural decisions that meet these, but do not greatly exceed them, is challenging. In particular, as many QoS constraints and suitable architectural solutions conflict, trade-off analysis can be very challenging. Factoring in cost in terms of development time, testing, required platform support and business value needs to be a part of decision making, not just technical solutions (Bahsoon and Emmerich, 2011). A major difficulty is changing requirements. Adding or modifying functionality is difficult, but incorporating potentially massive QoS constraint changes usually presents a much greater challenge. With the complexity and connectedness of today’s applications, this is probably going to get even more difficult. Architectural solutions allowing for more flexible QoS changes are likely to be ever more necessary (Allen et al., 1998). Technology impact on architecture economics
Different technical solutions for software architectures come with different inherent costs: Some are free (e.g., open-source versus bought solutions). Some are easily modified and configurable, whereas others are very constrained, saving expense if built-in functionality is required but incurring cost if extension is needed. Some require expensive hardware or third-party software investment, whereas others allow for an elastic, demand-driven pay-as-you-go infrastructure. Some are widely used and thus embody well-known and supported approaches; others are bespoke solutions, possibly optimized but potentially with poorly known or undiscovered weaknesses. Technology choice will therefore impact architectural economics dramatically in terms of both cost (both to build and to maintain), and value (e.g., is the solution able to be deployed with a wide range of off-the-shelf components, or does it require purchase of expensive, third-party components, putting off potential buyers?). Some technology choices are more costly up front, for example, cost to purchase, more difficult to use, more time consuming for the team, requiring more costly deployment environmental support. However, they enable an architecture to be more “robust” under requirements change; for example, they provide dynamic load balancing and runtime component switching, enable elastic resource management, and so on. As with requirements change, anticipating future technology demands is difficult in many situations but may enable more cost-effective (in the long run) architecture choices to be made and may maximize software value. Environmental impact on architecture economics
Software does not run in isolation; it is deployed on hardware, networks, and with other third-party applications and services. These may well impact architecture choices and themselves impact the cost effectiveness of solutions and the value of the system as a whole. A major traditional cost has been overengineering solutions, not just the software architecture itself but its deployment environment—for example, massive overallocation of compute...