Using real options to select stable middleware-induced software architectures

Abstract

The requirements that force decisions towards building distributed system architectures are usually of non-functional nature. Scalability, openness, heterogeneity, and fault-tolerance are examples of such non-functional requirements. The current trend is to build distributed systems with middleware, which provide the application developer with primitives for managing the complexity of distribution, system resources, and for realizing many of the non-functional requirements. As non-functional requirements evolve, the "coupling" between middleware and architecture becomes the focal point for understanding the stability of the distributed software system architecture in the face of change. We hypothesise that the choice of a stable distributed software architecture depends on the choice of the underlying middleware and its flexibility in responding to future changes in non-functional requirements. We devise an option-based model to value such flexibility and guide the selection. We empirically evaluate the model using a case study that adequately represents a medium-size component-based distributed architecture. We report on how a likely future change in scalability could impact the architectural structure of two versions, each induced with a distinct middleware: one with CORBA and the other with J2EE. Our hypothesis is verified to be true for the given change. We conclude with some observations that could stimulate future research in the area of relating requirements to software architectures.

Towards engineered architecture evolution

“…Modularity is not the only way to utilize options in software design. Real options have been used for valuing the stability of middleware [4], and for analyzing the economic value of applying certain architectural patterns [23]. However, all these techniques are not yet integrated into an architecture evolution process.…”

“…Management of uncertainty becomes a critical aspect of open evolution. This is exemplified by the work on architecture real options [30,4,23].…”

Defining Dependable Dynamic Data-Driven Software Architectures

“…It is the manifestation of the earliest design decisions, which comprise the architectural structure (i.e., components and interfaces), the architectural topology (i.e., the architectural style), the architectural infrastructure (e.g., the middleware), the relationship among them, and their relation to other software artefacts(e.g., detailed design and implementation) [2]. In managing the change and guiding evolution, considerable emphasis is placed on the architecture of the software system as the key artefact involved [7].…”

Contribution to the design, implementation and standardization of semantic middleware architectures for the Smart Grid

“…It is the most complex and complete possibility available according to the studied middleware designs and implementations, and relies on a structure to encase the services and features of a software-based system. One example of this concept is Enterprise Service Bus architectures [32].…”

“…In the same way, the infrastructure will end up being paid to the third party providing support to the end user during an amount of time t when, as described in (32), the investment that has been made by the third party will be returned if the percentage charged to the end user during t makes up for the total cost of the infrastructure sold to the end user (represented as % ). These concepts have been included as in (34).…”