Andrzej Zalewski

Capturing architecture evolution with maps of architectural decisions 2.0

Modern IT systems evolve being re-architected throughout their entire lifetime. Existing architecture decision-making approaches are oriented towards systems design, rather than systems evolution. However, real-life architecture evolution is substantially different to initial architectural design. It is a disorderly process, in most cases unrepeatable, and therefore difficult to be put into a predefined rut as most approaches try to do. MAD 2.0 model has been developed to support architect-practitioners working on systems evolution. It does not impose any predefined classification or hierarchy of architectural decisions and assumes a limited number of kinds of relations between architectural decisions. This makes a model of the decision process intuitive and easy to comprehend. To explain the choices made and capture their rationale, the entire decision situation is presented, including: the decision topic, considered design options, relevant requirements, and the advantages and disadvantages of every considered option. The proposed models and approach, supported by an appropriate modelling tool, has been validated in the real life conditions of one of the telecom companies.

Beyond ATAM: architecture analysis in the development of large scale software systems

Large scale software developments require substantial investment and are exposed to high level of risk. Architectural decisions taken at early stages of the development can substantially influence the entire level of technical risk. In this paper architectural decisions are divided into two basic groups: early - top level system organization decision establishing system organization patterns (the notion introduced in this paper) and detailed ones. However as it was shown on notable examples of large scale developments carried out in recent ten years in Poland, wrong decisions concerning system organization pattern can trigger severe risks that can lead to the development crisis. These risks are frequently connected with the complexity explosion syndrome - sudden, undetected growth of design complexity that exceeds the capabiblity of the development team and time budget. To manage these risks properly appropriate architecture analysis method has been introduced. On the contrary to the traditional scenario-based architecture analysis methods, like ATAM, it was based on GQM approach. A complete assessement framework have been defined comprising three goals: complexity control, organizational adequacy and satisfactory perforormance and reliability; a set of questions related to these goals, as well as metrics for the qualities expressed by these questions. The conclusion contains ex post analysis of exemplary large scale systems showing that the proposed framework provides adequate assessement of design risk. It has also been indicated that the critical risks identified during the evalution of the system organization pattern should be carefully managed.

Modelling Architectural Decisions under Changing Requirements

One of the approaches for documenting software architecture is to treat it as a set of architectural design decisions. Such decisions are always made in the context of requirements that must be fulfilled and in the context of decisions that were made before. Currently, models for representing architectural decisions are mainly concentrated on showing the decision making process of the initial architectural design. However, decisions that have been made in such a process may need to be changed during further evolution and maintenance of the software architecture, typically in response to the new or changed requirements. A graphical modelling notation for documenting architectural decisions (Maps of Architectural Decisions) has been developed by our team. In this paper, it is presented how this notation could be used to model architectural decisions under changing requirements. It is proposed how one decision change could be effectively propagated through the rest of the architectural decision model and how a rigorous and tool-supported process of updating such models could be organized.

Modeling and Analyzing Disaster Recovery Plans as Business Processes

The importance of business continuity and disaster recovery (BC/DR) plans has grown considerably in the recent years, becoming a well-established practice to achieve organizations resiliency. There are several applicable standards, like BS 25999-1:2006, sets of guidelines and best practices in this field. BC/DR plans are typically text documents and exercising is still the main measure used to verify them. On the contrary, to the common practice we suggest to model BC/DR plans as business processes using ARIS methodology and models, which have proven successful in the Enterprise Resource Planning systems projects. This provides uniform representation of BC/DR plans that can be applied across the whole distributed organization, strengthens the efficiency of traditional manual analysis techniques like walk-throughs, helps to achieve completeness, consistency and makes possible computer simulation of BC/DR processes. Timing and dynamic behavior, resource utilization and completeness properties have been also defined. It is possible to analyze them with computer support based on proposed ARIS model of BC/DR plan.

Architecture decision-making in support of complexity control

The main challenge of software engineering has always been to bring software complexity under control. Different kinds of abstractions have been devised and applied for that purpose at different levels of software design. Some of them have proven successful, such as function hierarchies, layers, APIs, abstract classes, encapsulation, interfaces etc. and are widely used in practice. Concepts from the genre of software architecture should also help to manage software complexity. We argue that, before architecture decisions and architecture decision-making become a common industrial practice, they have to support software complexity management much more efficiently than at present. Despite the substantial progress already made, it is still a major challenge both in theory (architecture decisions representation and architecture decisionmaking methods) and practice (tool support).

Evaluation of Dependability of Multi-tier Internet Business Applications with Queueing Networks

Failure to respond to the users requests within an acceptable amount of time means that system is unavailable to its users. Therefore the prediction of systems response time for different intensity of users requests, esp. identifying requests loads causing performance degradation becomes an important issue in the design of a dependable Internet system (incl. e-commerce systems). A method for modeling application server environment by the use of queueing networks has been proposed. The physical components of the environment are represented as service centres which form a separable queueing network. Model parameters, i.e. average service times and average visit counts can be experimentally measured in a test environment. Model output are response times for different request classes as well as other parameters describing systems performance. Tools supporting the measurements and model calculations have also been developed. Experiments carried out on real system show that the model predicts real systems performance with satisfactory accuracy, esp. maximum throughput of the system

Diagrammatic Modeling of Architectural Decisions

The paper presents a semi formal model of architectural decisions referred to as Maps of Architectural Decisions (MAD). In a form of a diagram they represent the most important components of architectural decisions (concerns, possible choices, constraints etc.) as well as logic of architectural decision making, i.e. dependencies between architectural decisions. This increases the level of formalism of the architectural decisions documentation, improves its readability and makes architectural knowledge gathered during the decision making process easier to comprehend, share and maintain.

A FMECA framework for Service Oriented Systems based on Web Services

Service oriented-architecture (SOA) is becoming more and more important as a paradigm for the development of distributed software systems. In this approach user applications are built of a set of collaborating services running in a distributed environment of Internet. Although the idea of SOA appeals strongly to the software development practitioners, there are also numerous pitfalls that cause risks of different severity for SOA software reliability. The paper provides a survey of these critical risks and proposes a framework for failure modes, effects and criticality analysis (FMECA) of SOA systems based on web services.

Towards Evolution Methodology for Service-Oriented Systems

Modern organisations are forced to evolve their IT systems to keep up with ever-changing business requirements. Service-Oriented Architecture addresses the challenge of boosting a system’s modifiability by composing a new functionality out of existing, independent, loosely-coupled services. This makes SOA a promising design paradigm for rapidly evolving systems. However, existing development methodologies for SOA, such as IBM’s SOMA, focus more on the transition from legacy non-SOA to SOA systems, and less on their subsequent evolution. This makes the development of an evolution methodology suitable for service-oriented systems an open research problem. The presented evolution methodology comprises an evolution process and an evolution documentation model. The process is compliant with a popular ISO 20000 norm. Its artefacts have been defined in terms of the evolution documentation model. The business-driven changes are documented with architectural decisions that capture changes made to the system at various levels of scope, together with their motivation. In order to facilitate the change-making process, a set of typical change scenarios has been defined. It comprises typical sequences of architectural decisions for cases of the most important changes. The entire approach is illustrated with a real-world example of an internet payment system.

On Cognitive Biases in Architecture Decision Making

The research carried out to date shows that architectural decision-making is far from being a rational process. Architects tend to adopt a satisfying approach, rather than looking for the optimal architecture, which is a result of many human and social factors. The results of a workshop, carried out with 14 software engineering practitioners show that cognitive biases are commonly present in architecture decision-making. A systematic approach to analysing the influence of biases on decision making has been introduced. Twelve cognitive biases identified during the workshop were analysed with regard to the elements of the decision-making context that affected the aspects of architectural decision making. Finally, we analyse the interactions between cognitive biases and the conditions of real-world software development.