Evaluating architectural stability with real options theory
Evolution is a key problem in software engineering and exacts huge costs. Industrial evidence even hints that companies spend more resources on maintaining and evolving their software than on the initial development. In managing the change and guiding evolution, considerable emphasis is placed on the architecture of the software system as a key artifact involved. One of the major indicators of the success (failure) of software evolution is the extent to which the software system can endure changes in requirements, while leaving the architecture of the software system intact. We refer to the presence of this "intuitive" phenomenon as architectural stability. We highlight the requirements for evaluating architectural stability. We pursue an economics-driven software engineering approach to address these requirements. We view evolving software as a value-seeking activity: software evolution is as a process in which software is undergoing a change (an incremental) and seeking value. The value is attributed to the flexibility of an architecture in enduring likely changes in requirements. To value flexibility, we contribute to a novel model that builds on an analogy with real options theory. The model examines some likely changes in requirements and values the extent to which the architecture is flexible to endure these changes. The model views an investment in an architecture as an upfront investment plus "continual" increments of future investments in likely changes in requirements. The objective is to provide insights into architectural stability and investment decisions related to the evolution of software architectures. We support the model with a three-phase method for evaluating architectural stability. The method provides guidelines on eliciting the likely changes in requirements and relating architectural decisions to value. The problem of valuing flexibility of an architecture to change requires a comprehensive solution that incorporates multiple valuation techniques, some with subjective estimates, and others based on market data, when available. To introduce discipline into this setting and capture the value from different perspectives, the method outlines a valuation points of view framework as a solution. The framework is flexible enough to account for the economic ramifications of the change on both structural (e.g., maintainability) and behavioral (e.g., throughput) qualities of an architecture and on relevant business goals (e.g., new market products). We report on our experience in using the model and its supporting method with two case studies. In the first case, we show how the model and its supporting method can be used to assess the worthiness of re-engineering a "more" stable architecture in face of likely changes in future requirements. We take refactoring as an example of re-engineering. In the second case, we show how the model and its supporting method can inform the selection of a "more" stable middleware-induced software architecture in the face of future changes in non-functional requirements. We critically discuss and reflect on the strengths and the limitations of our contribution. We conclude by highlighting some open questions that could stimulate future research in architectural stability, relating requirements to software architectures, and architectural economics.