Session:Rationale--Results

From WICSA Conference Wiki

Our working session was centered on Architecture Design Decisions with respect to how they are made, catalogued, socialized and their impacts. Whether decisions are explicit or implicit, their importance can not be overstated.

Our four 15-minute presentations were of high-quality, with case studies ranging from a Short-Message-Service (SMS) to an Air Traffic Control System for Canada. Participation was excellent. Participants were engaged and provided key insights and questions during the workshop.

Key gaps (or work needed) in this area include: (1) lack of a decision taxonomy, (2) recognition of the importance of 'soft-skills' in the socialization of decisions, including dealing with external influences, (3) lack of a clear understanding of the casual-effect relationship for decisions, (4) the need for a standard language and metamodel for capturingand cataloguing decisions, and (5) research in the ability to defer what traditionally have been decision-time decisions to be run-time decisions.

Examples of good architectures are needed where the key decisions are highlighted for later examination.

Our working group udentified the following major areas as worthy of attention:

- Enforcement/traceability: The gap between architecture and code has always been a severe problem in architecture-based development. Architecture and code can (and usuall do) migrate along separate paths and quickly become disconnected. How can architecture documentation be structured and/or supported to facilitate consistency between architecture and implementation?

- Human factors in documentation: What is documentation used for and by whom? How can we best produce it to serve the needs of its stakeholders? What role do people play in the creation and capture of architectural information?

- Tooling: What would a superb architecture documentation tool look like and what services would it provide? Certainly multi-view consistency and completeness checking would be a major factor. An expert system assistant would be helpful in capturing the information. It might use an Architecture Description Language (ADL), but something "compilable" into UML would be very useful. It should "round-trip engineering" to address consistency between architecture and implementation. It might help to generate architecture-based test cases.

- Inhibitors: If architecture documentation is as valuable as its proponents claim, why isn't it universally produced? What are the inhibiting factors? One possible explanation is that documentation proponents emphasize the production of a full package of polished documentation, and the implication is that this is done up front, all at once. In reality, we need to emphasize "just in time" documentation and help practitioners decide what to product now, what to produce next, and how best to order and serve up the documentation to help developers and other stakeholders who can best be served by timely information. We need to embrace the concept of "agile" documentation for architecture, producing what we need when we need it, and we need better planning or feedback functions to help us know what (and when) that is.

- Uses of documentation. Can documentation ever take the place of a person? One value ascribed to it is that it serves the project in case the architect is no longer available ("run over by a bus" is the colloquialism served up to express this). Is that a valid goal? The Agile movement explicitly rejects this as a goal of Agile development processes -- people are assumed to be readily and steadfastly available. The verdict is still out on Agile for long-term projects, but the question remains: To what extent can documentation replace talking to a person?

- UML and architecture: What would it take to make UML a true architecture description langauge? Points discussed included:

• an extensible meta-model for "real" connectors, security models, etc.
• a textual syntax for ease of translation to/from other languages
• a variety of representations
• making views (as oppposed to diagrams) a first-class concept, as well as operations on views
• perhaps an accommodation to ACME
• the ability to accommodate domain-specific concerns, views, and notations