Third SEI Software Architecture Technology User Network Workshop
May 14-16, 2007 | Sheraton Station Square | Pittsburgh, Pennsylvania

Working Sessions

SATURN working sessions are interactive, breakout sessions that offer small groups of people who are interested in a specific topic the opportunity to discuss the topic in detail. These sessions engage leading-edge software architects, managers, developers, acquirers, and researchers in identifying emerging solutions to pervasive problems. Participants are asked to describe their interest in the area, discuss why it is important to their organization, define the gaps between what technology offers and industry needs, describe the specific challenges and successes they have faced, and discuss possible solutions.

 

W1: Architecture Competence
W2: Architecture-Based System Evolution
W3: System and SoS Architecture Evaluation - Early Identification of Inconsistencies in Addressing Quality Attributes
W4: Economics-Driven Architecting

 

W1: Architecture Competence
Facilitators: Len Bass & Paul Clements

What does it mean for a software architect to be competent? What does it mean for an architecture team or a software development organization to have competence in architecture? How can competence be recognized, measured, and-most importantly-improved? If architecture is as important to the success of organizations building software-intensive systems as we believe it is, it stands to reason that an improvement in architecture competence can lead to a significant improvement in an organization's performance.

Competence is often defined as the ability of an individual or organization to consistently create valuable results without excessively costly behavior. This definition has the virtue of being measurable, provided we can find appropriate measures for the value of the results produced by architects.

This working group will attempt to use that definition to produce measures and improvement strategies for competence-of individuals, of teams, and of organizations.

Discussion questions will include

  1. How can we measure the value of an architecture?
  2. In addition to architectures, do architects produce other "valuable results?" If so, how can we measure their value?
  3. If you were going to assess an organization's architecture competence, what would you ask? What would you measure?
  4. If you were going to assess an individual's architecture competence, what would you ask? What would you measure?

W2: Architecture-Based System Evolution
Facilitators: Robert Nord & Felix Bachmann

Architects are faced with myriad challenges to solve on any given day-challenges that have to do with evolving a system rather than starting from a clean slate. Evolving a system could be motivated by the need to improve a deficient architecture, to modify an architecture to support new business goals, or to migrate a collection of existing systems towards a unified vision.

We have been mapping the evolution landscape to understand how to better support evolution in terms of

We will begin this working session by describing a situation where we needed to provide support to a group of architects evolving a system. Then, we will describe the approach we used to construct a new method for architecture improvement in terms of our collection of architecture analysis concepts and techniques. Those concepts and techniques include elicitation of business goals, architecture documentation and rationale, quality attribute models, architectural tactics, and the costs and benefits associated with architectural decisions.

We will invite participants to share their experiences in a situation where they were faced with evolving a system and their approach to solving the challenge. Then, we will all map the approach into the evolution landscape to better understand and compare the approaches, identify gaps, and review opportunities for further work.

W3: System and SoS Architecture Evaluation - Early Identification of Inconsistencies in Addressing Quality Attributes
Facilitators: Mike Gagliardi & Bill Wood

Software-intensive systems often suffer from severe integration and operational/behavioral problems due to a lack of consistency in how the system and software architectures address system quality attributes. Those problems often result in rearchitecting and redesign efforts and operational failures that significantly impact system cost, schedule, and mission effectiveness.

The effect is further exacerbated in a system of systems (SoS) context. Each of the major system and software elements being developed for the SoS may have its own architecture documentation that might be built with diverse tools, use diverse notations, and be developed concurrently by different contractors. The development is usually done in a number of phases, with roughly 18 months to 2 years between them. That makes it difficult to evaluate whether the integrated systems composed of many of these elements will satisfy their functional and quality attribute requirements.

We have begun a two-pronged approach to address the early identification of quality attribute inconsistencies within system and SoS architectures. The first approach is to expand the scope of the existing ATAM into system architecture, making minor enhancements to the methodology as needed to address the issue at the system level. The second approach is top down at the SoS level and involves performing a "first pass" identification of inconsistencies across the constituent systems, using existing mission threads that are augmented with quality attribute concerns.

During this facilitated working session, we will describe the two approaches and ask participants to share their comments and concerns. We will also encourage participants to share their own experiences and their thoughts about system and SoS architecture evaluation in general.

W4: Economics-Driven Architecting
Facilitators: Rick Kazman & Mark Klein

There is often a disconnect between how executives and managers define and foresee value and how architects can promote or hinder it through their design decisions. This lack of effective communication results in a weak partnership between architects and executives. Opportunities may be missed where the architect inform executives on value-driven impact of design decisions. This information exchange is particularly critical when the organization needs to deal with architecture evolution and uncertainty.

Currently, architects and project managers do not have the tools they need to rigorously consider the implications of software architecture decisions with respect to multiple quality attributes and with respect to business goals and potentially uncertain future market conditions. We've been using the SEI Cost Benefit Analysis Method (CBAM) to address the lack of economic considerations in software architecture. Recently, we have also started to work on using real option techniques to evaluate architectural decisions, such as application of patterns, with respect to quality attributes.

During this facilitated working session, we will describe the current state of work at the SEI in the area of economics-driven architecting. We will encourage participants to share their comments, concerns, own experiences with various techniques, and any challenges they faced when considering economics while making architecture decisions. We will compare of the approaches discussed, identify gaps, and review opportunities for further work.