WicsaWikiWANParty:WS1
From WICSA Conference Wiki
Contents |
WS 1 - Evolving Architectures I
Monday, 14th June 2004.
Please use this page to capture ideas, thoughts, reactions, opinions and so on about the content of this working session.
Eoin Woods & Hans van Vliet.
Participants
(Please add yourself to this list)
- Hans van Vliet
- Eoin Woods
- Lieven Desmet, K.U.Leuven
- Pierre America
- Jaap van der Heijden
- Antti-Pekka Tuovinen
Papers
A Scenario-Driven Approach for Value, Risk, and Cost Analysis in System Architecting for Innovation
Key ideas:
- Each architectural scenario represents a consistent set of architectural choices.
- Use a different set of architectural scenarios for each architectural view, and relate them to each other across the views.
- Evaluate each quality attribute in the view in which you can most easily express that attribute and use the structure of the scenarios in that view to assess the attribute.
- Try to do a quantitative assessment wherever possible. This means that numbers have a real meaning (e.g., a duration), in contrast to using a rating (e.g., a number between 1 and 5).
- Present the results of the assessment in a visually friendly manner (eg. per scenario, using colours for suggesting the different acceptance levels)
Experience Using an Expert System to Assist an Architect in Designing for Modifyability
- Reasoning about architecture means reasoning about qualities the architecture has to support
- Reasoning about a quality attribute requires a quality attribute model
- Quality attribute models are derived from requirements and/or existing designs
- Here we present a quality attribute model to reason about modifiability (Impact Analysis)
- Models can be use to estimate what would happen to an architecture when applying architectural tactics.
--Felix Bachmann 09:19, 13 Jun 2004 (EDT)
An Externalised Infrastructure for Self-Healing Systems
David Wile (coauthor Alexander Egyed) at Teknowledge Corp.
DASADA "consensus" Externalized Infrastructure
- Self-healing or QoS-improving of arbitrary systems
- Place probes to determine what is happening, where.
- Gauges interpret probes' raw data into logical model.
- Dynamism of QoS requires archtectural model of running system.
- Control layer determines unhealthy or suboptimal behavior and enables more gauges or probes, or perhaps reconfigures them.
- An "effector" layer understands how to change the running architecture
- The control layer communicates with the effectors (logical to physical).
SAFE EMAIL - an existing externalized shell for healing email virus problems
- Wrapped Outlook and all its spawnedd processes
- Safe Email gauge itself based on DB of files to be protected, registry entries, execution directories, etc.
- We broke out structure and reworked Safe Email into the Externalized Infrastructure
- Were able to add functionality, including simulations, status of system reflected on an architectural diagram, and a mail "Authority" who has censure powers.
Workshop Discussion
- The talks reflected three different aspects of the area: methods, tools and technology (systems). All three seem to be a large step from current practice. How big is this step?
- Predicting the future is hard (and the agile approaches, which suggest doing the simplest thing possible because you're not going to need the more sophisticated thing you build) are a reaction to this. However architects do allow for the future anyway - even if only implicitly. This suggests that it's worthwhile trying to improve our approaches.
- Variability is often built in where it isn't needed. Need to avoid this.
- Important to remember that architecture also reflect what isn't expected to change.
- A real problem in this area is human factors, when project managers try to stop architects planning for the future due to scope creep concerns. Need to resolve this before tools are useful. This implies better project management/architecture integration in the process.
- We aren't bad at short term prediction, but prediction of the longer term is harder because our prediction is static (i.e. prediction at a point in time). Dynamic approaches may help with this.
- A related observation is that we're bad at predicting the future, so in response we adapt and make do, dealing with evolution as we need to.
- Frameworks (such as the one discussed by David Wile) could actually make change harder (added baggage), but the intention is to make it easier, by preventing the "common stuff" needing constant reinvention.
- Perhaps we're actually trying the impossible? Architecture can be defined as the set of decisions that are hard to change later, so evolution will always be difficult!
- Some types of evolution can be predicted though, so we should make sure we make use of these where possible.
- Changes needed are often fine grained in real systems and these can often be made without affecting the architecture.
- Our fundamental goal is to avoid architectural change, but how easy this is depends a lot on the stability of the domain.
- Architecture is an artifact of the development process and we're really concerned about the cost of change to it. The aim is to make get our architectures at the right abstraction level to allow controlled and planned evolution. A related question is whether the "right" architecture is sufficient (as well as necessary) for evolution.
- The purpose of the system before and after the proposed evolution is an important part of the decision making context. If the overall purpose doesn't change, then evolution is a lot easier.
- There are a number of dimensions of evolution to consider. Two are the "runtime <--> design time" axis and the "expected change <--> unexpected change" axis.
- Architecture is a system abstraction to aid understanding - is it really the vehicle to use for evolution?
- Architecture is also a management and planning tool, so needs to contain enough information to support this.
- Evolution is often considered from a technology centric point of view, independent from the actual application architecture.
- The architecture can be considered as the set of hard decisions in areas we're still trying to master and that make evolution hard. Perhaps once we master an area (e.g. relational database use) then the area is no longer architectural and so we don't worry about its evolution.
- It is useful to consider the mechanisms for change from the policies for change. These aspects of the problem are at different levels of abstraction (mechanisms support policies).
- It's important to have criteria to guide whether evolution is appropriate or whether replacement should be used instead.
- Perhaps successful architectures are simply those that don't need to evolve much? The Internet is a good example.
Post-workshop discussion
In the discussion, there was a remark that evolution has more to with frameworks than actually with architecture. In my opinion, the possibility to support adaption/evolution in a framework depends on the underlying architecture. For example, the first paper in styles II will try to show the correlation between adaptibility support within a framework and the actual archtictural decission which make this support possible. This corresponds to another remark within the session, saying that the architecture decides (predicts) which parts of the software system are not supposed to change in time and which parts are open for evolution. (Lieven Desmet)
A lot of confusion during the workshop seems to relate to different interpretations of evolving architectures:
- The architecture changes (more or less easily) to accommodate new requirements
- The architecture stays the same, but the system changes to accommodate new requirements.
This dichotomy in turn is related to the two main classes of definitions of software architecture itself:
- Software architecture describes the main components of a system and how they work together.
- Software architecture describes the most important decisions on the system, i.e., the decisions that are most difficult and costly to change.
This dichotomy is addressed in the COPA method. The first definition is conered by the Conceptual architecture, whereas the second has a much wider scope, covering the whole of CAFCR (see COPA#CAFCR ).
My personal opinion is that we architects should evolve :-) towards the second definition in order to focus on the most important issues in our area. See also Jan Bosch's position on design decisions in WicsaWikiWanParty:Position. Pierre America
