WicsaWikiWANParty:Position
From WICSA Conference Wiki
An alternative view: Why Architecture Isnt Just Design Decisions. Another aspect of documenting design decisions is described in Why Design Decisions Trancend a Particular Architecture.
Another response: Decisions Considered ...
Architecture Design Decisions
One of the topics that is mentioned often, but typically not defined very precisely is the notion of architecture design decisions. Designing a software architecture can be viewed as a decision process, i.e. a sequence of easy and difficult design decisions. The software architect, in the process of translating requirements into a design, basically takes, potentially many, design decisions that, combined, give the software architecture its final shape.
One can identify at least four relevant aspects of a design decision:
• Restructuring effect: The most visible effect of a design decision is the effect on the structure of the software architecture. As a consequence of the design decision, components may be added, split, merged or removed. Although this effect is very clear at the time the decision is taken, the accumulated restructuring in response to a series of design decisions is not easy to understand. Current notations and languages do not provide support for describing design decisions individually.
• Design rules: A second aspect of a design decision is that it may define one or more design rules that have to be followed for some or all components in the system. A rule typically specifies a particular way of performing a certain task.
• Design constraints: In addition to design rules, a design decision may also impose design constraints on a subset of the components. A design constraint defines what the system, or parts of it, may not do.
• Rationale: Finally, each design decision is made in response to some functional or quality requirement(s). The software architect reasons about the best way to fulfill the requirement(s) and then imposes a decision. The rationale, including possible new principles, guidelines and other relevant information about the design of the system, should be documented.
In the traditional perspective on software architecture, most of the information about design decisions is lost during the design process. Consequently, when, during the evolution of the system, new design decisions are added to interact with the existing design decisions, it is likely that the software engineer will violate some rule or constraint, resulting in either errors in the behavior of the component or the failure of the system as a whole.
At the University of Groningen, we are working on addressing this, i.e. developing techniques and tools that allow us to maintain more information about design decisions. It would be interesting to hear about work or thoughts that you may have.
The Decision View of Software Architecture
Documenting software architectures is a key aspect to achieve success when communicating the architecture to different stakeholders. Several architectural views have been used with different purposes during the design process. Very often, design decisions are sadly forgotten buy they represent a cornerstone in the architectural modelling process. Several reasons for record design decisions are: changes in the development team, design recovery needs, loss of designs, forward and backward traces between requirements and design products, etc. From our point of view, the explicit representation of design decisions becomes a key factor for building and communicating the software architecture.
We propose here a new “view”, called the design decision, view as an improvement to the classical “4 1” Kruchten’s model. This model will represent a “4 1 1” architectural view.
Design decisions should connect requirements and architectural products in order to record and discover the rationale of the decisions taken during the design construction process. The information we believe a design decision should include for representing this using a UML notation or similar is the following: iteration number, next iteration, decision rule and motivation, next decision rule, pattern/style applied and associated use cases.
At the Universidad Politécnica de Madrid (Juan C. Dueñas - jcduenas@dit.upm.es) and the Universidad Rey Juan Carlos (Rafael Capilla - rafael.capilla@urjc.es) we are currently working towards this view; we expect that, once a knowledge base containing architectural decisions is created, and these decisions are linked between them and to the elements of the other architectural views, some activities performed in the development of the system can be supported by the navigation on that network of models. This way of understanding the software development can be called “building by browsing”.
For more details see. The Decision View of Software Architecture. Accepted position paper for the 2nd European Workhop on Software Architectures (EWSA 2005), Pisa, Italy, June 13th 14th 2005.
Architecture Decisions as the Key Representation of Architecture Intent
Architecture decisions are the primary representation of architecture. We (Art Akerman art.akerman@capitalone.com and Jeff Tyree jeff.tyree@capitalone.com) believe that architecture results from effective decisioning making, not from architectural view construction. We came to this realization after several failed attempts to promote buy-in of traditional view-based approaches to architecture development and representation.
In addition, we argue that Architecture should not be captured and maintained as a set of views, but as an instance of an architectural meta-model or ontology. The ontology provides a common architecture language, or vocabulary, that enables the level of precision needed for effective architecture decision making. Our proposed ontology is composed of architecture assets, architecture decisions, stakeholder concerns and an architecture implementation roadmap. We currently are prototyping Protege to provide tool support for this ontology.
At Capital One we are currently prototyping this approach to enhance our existing architecture processes.
For more details see. Using an Ontology to Manage Decision-Based Architecture Development: An Alternative to Views. Submitted to IBM Systems Journal for publication.
