WICSA 2005:Decisions Considered

From WICSA Conference Wiki

Revision as of 15:48, 10 November 2005 by Sc (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Decisions Considered ...

During the development of IEEE 1471, we seriously considered at one point scrapping -- or at least reconstituting -- our view-oriented approach to architectural description in the standard, and replacing it with a "decision-oriented" approach for all the reasons that have been raised in this wiki discussion by Juan, Jeff, et al. We ended up not taking that approach, for a couple reasons.

  • First, because it seemed too radical to codify that approach in 1998-1999, when most of the community was talking about multiple views like Structure, Behavior, Module, Developer ... We felt it was important to codify the practice of multiple views in the standard.
  • Second, as our approach to views via viewpoints became more extensible, we realised that anyone who wanted a decision view of their architecture could define a Decision Viewpoint within the IEEE 1471 framework.

I would still support that approach today. Here are a couple reactions, or arguments, or at least discussion points in response to the Decision position page. (All quotes are from the Position page)

"architecture results from effective decision making, not from architectural view construction"

While I would agree, I would not replace all architectural views with a decision model. Each element of each view in any architectural description (AD) embodies one or more decisions; yet none of these elements directly express the architect's intent (an important notion that Jeff and Art refer to). Sometimes these concerns are different. Simple example: I can simply capture (I) the architect's intent that this architecture shall be Client-Server. The fact that the architecture consists of 6 servers may not be stated anywhere, it shows up in (II) a diagram with 6 identical server component boxes. For some stakeholders, (I) is what they need to know. For others, (II) is needed. This gets us back to concerns, and separation of concerns.

"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."

I would agree an AD should be an instance of architectural metamodel or ontology; that was the basis for IEEE 1471. The point of the quote, I believe, is to propose a different metamodel which is decision-oriented, rather than view(point) oriented. If we can agree that stakeholder's architectural concerns are a starting point, then we can ask,

What representations of an architecture are needed to satisfy its stakeholders concerns?

This leads naturally to views, and could include a decision-oriented view. But work needs to be done to make a Decision Viewpoint understandable. We need a taxonomy of decisions. Anyone interested might look at this starting point: Burns and Lister's 1991 paper, "A Framework for Building Dependable Systems" in The Computer Journal for the notions of commitment and obligation. We need an understanding of relations between decisions. Philippe Kruchten has been doing useful recent work in this area. There are also other concepts that need to be formalised. We probably need a more robust notion of Concern, and a more rigorous notion of Architectural Constraint (I have been shocked, shocked I say, at how this term is casually used at this conference!).

On notion of a "common language": It seems to me there are at least two levels of common language in Architecting.

  • One may be a tactical language of Architecting, along the lines suggested by Art and Jeff, and in the Decision View suggested by Juan and Rafael.
  • A second level of common language, and one of the motivations for viewpoints in IEEE 1471, was that many specialties (e.g., security, safety, reliability) have their common languages, tools and models, specific to the concerns of the domain, and embodied in the relevant viewpoints. I think Art and Jeff have an uphill battle to argue that this second level of common language(s) can be replaced by a general approach to capturing decisions.

Rich Hilliard

Personal tools