Fourth SEI Software Architecture Technology User Network Workshop
April 28 – May 1, 2008 | Pittsburgh, Pennsylvania

Session Abstracts

Reconstructing the Architecture Model for a Sustainable Architecture
Pia Stoll, ABB Corporate Research

Sustainable software architecture, which has evolved over more than ten years and is to live and change for at least another decade, is very difficult to capture in an architecture model. The architecture is often a mixture of old and new tactics, and the system use cases which were once valid no longer capture the essence of all of the system's functionality and business goals.

The case study of the reconstruction of an architectural model for a sustainable architecture to be presented dealt with a sustainable software architecture which had grown out of control. The original architects had left the development organization, and the new architects did not have full control of all parts of the sustainable architecture.

In an attempt to gain back the control of the architecture, the goal of the development organization's architecture team was to document the architecture according to a model so that the architecture could be communicated among its stakeholders. The team started from the SEI books Documenting Software Architecture: Views and Beyond and Software Architecture in Practice.

The team vision was to capture all domain-specific issues as trends and experiences, quality-attribute-specific issues, and business goal issues, which influence the architecture at the enterprise, system, and software levels in one model.

The effects of changing business goals and software quality attributes on system architecture and software design should be made visible in the model. By making the relationships visible, the architects would be able to see what effect a changing business goal could have on the architecture or even predict how a shift in technology would affect the system and software architecture. The model would then serve as a decision guiding tool and be used in an active fashion instead of merely being a blueprint of the software architecture construction of today.

The vision of documenting the different architecture levels in one model was more complex to realize than expected. What the case study ended up in was a conflict between the common approach of dividing the architecture into different views and the need of sustainable systems to accommodate changes in business goals, technology environment, and enterprise constructions affecting the architecture in one adaptive architecture model.

This presentation aims at opening up the discussion on how to document continuously changing architecture at the enterprise, system, and software levels in one and the same model.

Current SAT Work in Architecture Evolution
Rick Kazman, Software Engineering Institute

This presentation will review the work to date in the SEI's Software Architecture Technology (SAT) Initiative on architecture evolution.

Defining Composite Critical Scenarios for the Development of Large-Scale System Architecture Using an SEI ADD-Based Framework
Aldo Dagnino, Shakeel Mahate, Qingfneg He, David Cox, ABB Corporate Research

This presentation will discuss how SEI Attribute-Driven Design (ADD) was employed to develop a framework that was employed as a basis to develop the software architecture of a complex large-scale control system in a multinational organization. The emphasis of this presentation will be on describing details of the process that was followed to define composite critical scenarios that were employed to define the software architecture.

The project was quite challenging as it had several unique characteristics. First, the product development unit is geographically dispersed, and for this reason the business managers, architects, and development team were not located in the same geographic region. Second, there was an obvious disagreement among the stakeholders in the business unit regarding business goals, priorities, functionality, and software quality attributes. Third, the business unit already had several competing products that were maintained using different noncompatible technologies, and therefore members of each product group had strong biases towards their own technology. The authors will discuss how the above challenges were addressed to create a critical scenario framework that was agreed upon by all parties. This framework extended the ADD methodology, by clustering ADD scenarios into themes that described the system critical scenarios.

The presentation will describe how the organization's business goals were defined and collected in geographically distributed workshops. Due to the large divergence in opinions, a voting mechanism was employed to define and prioritize the business goals. Market requirements were collected to define the primary functionality of the system. Details will be provided on the method used to collect and document these requirements. Using the set of prioritized business drivers, the software qualities of the large-scale system were defined. Using the software qualities and also the market requirements, the system's critical scenarios were defined. These critical scenarios are described by common functionality themes defined by the market requirements, and a set of nonfunctional requirements defined by the software qualities. To make the system critical scenarios useful, nonfunctional requirements need to be quantified. As the same nonfunctional requirement can be employed in several critical scenarios, the functionality theme provides a context under which the nonfunctional requirements are given a value. This presentation will discuss in detail this process and provide examples for the audience.

Another aspect that will be discussed during the presentation is related to the level of granularity of the requirements needed to define the system's architectural critical scenarios. While the requirements associated with the system functionality were defined at a higher level of granularity, the nonfunctional requirements associated with the software qualities were defined at a low level of granularity. An explanation and examples will be provided during this presentation.

Evaluating Distributed Systems Architectures for Fault-Tolerant Applications
James Scott, Boeing Satellite Systems

A large body of experience has been developed within the telecommunications industry with regard to fault-tolerant distributed systems architecture. This presentation focuses on key topics to consider in evaluating a proposed architecture for use in asynchronous, event-driven applications whose system quality attributes include stringent requirements for availability, reliability, and evolvability. A representative list of such topics includes:

Architecture and design patterns derived from best practices emerging from the telecommunications industry will be discussed in order to provide additional insight into proven architecture and design practices being used in deployed fault-tolerant commercial systems. In addition, discussion will be provided as to how these topics and patterns can be applied within the context of the SEI Architecture Tradeoff Analysis Method (ATAM) of software architecture evaluation.

Challenges and Observations of Applying the SEI ATAM to a Software Testing Automation Solution
Fernando Enobi & Reginaldo Arakaki, Instituto de Pesquisas Tecnológicas de São Paulo

The automated testing solution was implemented to speed up software testing process in projects that bring very complex schedule, cost, and quality tradeoffs. The business requirements established for acquiring the testing solution automation had very critical nonfunctional requirements necessary to achieve success results. Evaluating and measuring the nonfunctional requirements became very critical to evaluate risks, non-risks, tradeoffs, and metrics and how each business requirement could be affected. The ATAM was chosen to create a link between business and nonfunctional requirements through a very clean scenario description language.

The presentation will focus on the process and give samples of the following aspects of the project:

  1. Challenges found during the software architecture evaluation
  2. Documentation level definition to guide the evaluation
  3. Necessary process and people maturity level to develop a good evaluation
  4. Registration of future analysis identified during the ATAM process
  5. Metrics collected during the process evaluation and how to check it against the architecture decisions

Architecture Curve, New Formatted SEI ATAM Report Shaped in a Single Graph
Haeran Youn, Samsung Electronics

As the size and complexity of software in embedded systems grow exponentially, software architecture becomes one of the key success factors in the Consumer Electronics (CE) industry. Our organization, Samsung Electronics, has applied the SEI Architecture Tradeoff Analysis Method (ATAM) and SEI Quality Attribute Workshop (QAW) for better software architecture for years. But, in the real competitive marketplace, the ATAM and QAW are relatively expensive tasks to perform. We tailored them in a light way and produced an additional ATAM report shaped in a single graph to figure out ATAM results at a glance comparing relatively long ATAM reports in plain text.

This presentation will

  1. Describe tailored QAW and ATAM process in Samsung Electronics.
  2. Introduce an additional ATAM report shaped in a single graph: we call it an "architecture curve."
  3. Case studies in applying the tailored ATAM and QAW.

Realizing the Business Value of IT: An Approach for Architecture Evaluation
Opal Perry, Wells Fargo & Company

This presentation will discuss our efforts to extend aspects of SEI architectural evaluation methods within a division of Wells Fargo and Company that has recently deployed a production system using a service-oriented architecture (SOA) approach. Our focus was on developing a mechanism to articulate critical business processes as the context within which quality attribute requirements could be concretely defined and the supporting architecture evaluated. In leveraging and extending the SEI methods, we sought to ensure that evaluation proceedings and results provided practical and immediate meaning to business stakeholders in terms of measuring and realizing true business value.

The concrete articulation of critical business processes and their associated quality attribute requirements represents a significant step forward in our environment as a starting point for measuring availability and performance in the context of true business value instead of simply technical uptime or response time. In the past, we might have been satisfied that a component was up 99.9% of the time or performed well within its service level, but the business could view it as a failure because some other component, which was needed to complete a critical business process, was unavailable. For this reason, the focus on the critical business processes has influenced our approach to both discovering and documenting quality attribute requirements as well as evaluating the architecture designed to achieve them.

We will describe the key aspects of our approach and how we leveraged and extended SEI techniques such as the Quality Attribute Workshop (QAW) and Architecture Tradeoff Analysis Method (ATAM) to create a practical approach for evaluating the architecture's ability to meet the essential quality attribute requirements that would provide the most business value within the context of the business capability roadmap. This customized approach was necessary in our environment due to the size of the system being evaluated, time and resource constraints, as well as cultural realities. Additionally, we will discuss how we organized stakeholder participation in pre-work and the approach taken for conducting sessions in early 2008. We will share our observations and plans for future activities and discuss the challenges in extending architecture evaluation methods within a culture not previously familiar with scenario-based methods as well as the challenges associated in bringing business and technical stakeholders together to discuss expectations and issues.

In offering this presentation, we hope to contribute to an active dialogue on architecture evaluation methods in the software development community, with a focus on the realization of true business value.

Inexpensive ATAM-Peer Review Detects and Fixes Architecture Problems Early
Howard Forstrom, ITT Corporation

ITT has pioneered a procedure for adapting SEI Architecture Tradeoff Analysis Method (ATAM) reviews into incremental peer reviews. The ATAM-Peer Review leverages the discipline and benefits of the standard ATAM Review in a lite review that is performed earlier in the process yet still reaps the major benefits of a full up ATAM. The ATAM-Peer Review has identified architecture weaknesses very early in the life cycle when fixing them was trivial. This review includes a min stakeholder analysis and an SEI Quality Attribute Workshop. By incorporating these into our project launch and performing ATAM-Peer Review training as just-in-time training, ITT has reduced the impact of this review to 4 hours.

In piloting this method, ITT succeeded in finding over 8 weaknesses that had been overlooked by the software architect and designers. These weaknesses were fixed, and the resultant architecture was successfully deployed. Specifically, a missed modifiability requirement would have limited the system's success had it not been fixed.

Applying SEI Architecture Tradeoff Analysis Method (ATAM) as Part of Formal Software Architecture Review
Christopher Byrnes & Ioannis Kyratzoglou, The MITRE Corporation

In preparation for a customer's Software System Critical Design Review (CDR); we concluded that an assessment approach based on a hybrid version of the SEI Architecture Tradeoff Analysis Method (ATAM) would be a good approach for an assessment of this software architecture. This paper will provide ideas on how to apply the ATAM within the context of a formal CDR of a large-scale complex software system.

On ADLs and Tool Support for Documenting View-Based Architectural Descriptions
Danny Weyns, Katholieke Universiteit

DistriNet is a research lab with +60 researchers. The general domain of expertise and innovation of DistriNet is the development of advanced open and distributed software applications. The research is application driven and is conducted in close collaboration with industry. One particular class of applications we target is that of decentralized systems that are characterized by a high degree of dynamism and change in either the problem or the system's environment. Example domains of interest are manufacturing control, supply chains, inland shipping, and traffic control.

To document software architecture, we follow the approach of SEI Views and Beyond (V&B). V&B is an approach for documenting software architecture by means of a set of relevant views and adding information that applies to more than one view. Views describe (parts of) the system from different perspectives, exposing different quality attributes that are of interest for particular stakeholders.

In several projects in which we applied V&B, we found that managing and maintaining a consistent architectural documentation is a tedious task, including maintaining the mapping between views, maintaining the related view packets within each view packet, updating context diagrams, maintaining consistency w.r.t. combined views, etc.

While V&B offers a well-defined approach to organize architectural documentation, there is a lack of support in ADLs and associated tools for documenting software architectures that comprise several, interrelated views. Existing ADL tools (e.g. AADL, ArchStudio, AcmeStudio) offer several ways to organize architectural documentation but do not support views as first-class concepts of architectural documentation. From our experience, there is a gap between the state of the art on documenting software architectures and the state of the practice in ADL tool support for documenting architecture.

We advocate that developing ADLs and tool support specifically targeted at view-based architectural descriptions is imperative. This can significantly increase the level of comfort for managing view-based architectural descriptions. As a first step, we investigate extending an existing ADL, i.e. xADL, with support for documenting a number of relations among view packets of structural views. We integrated this extension in ArchStudio and used this extended tool for documenting the architectures of a traffic control system as well as a digital newspaper publishing system. We observed that the tool significantly improves consistency management. Another interesting benefit is that the tool enables an architect to generate composed views on the fly, which was found to be useful in the interaction with stakeholders, particularly developers.

Currently, we are expanding the scope of xADL and Archstudio with support for documenting view packets and their relations across multiple views. From our experience, we put forward a number of challenges that are key to translating the existing body of knowledge on views and relations into proper tool support. These challenges include (1) selecting a set of practical views and relations; (2) formally specifying these views and relations, and (3) designing a tool that provides an intuitive user interface, while hiding the complexity that lies beneath.

Identifying and Documenting Primary Concerns in Industrial Software Systems
Roland Weiss & Pia Stoll, ABB Corporate Research

ABB business relies on industrial software systems in all divisions. Although the domains differ (power, automation, robotics), these systems share certain characteristics, both in functionality and in quality attributes. The sustainable software systems are tightly coupled with hardware systems, have to provide high reliability, are split into engineering and operations parts, and typically live over a long period of time. Maintaining and extending such systems pose an interesting challenge, as it includes responding to changes in: business goals, the technical environment, stakeholders' concerns and the organization.

The presentation deals with the experiences of identifying and prioritizing the primary concerns for two existing software systems within ABB business units. This covers the gathering of use cases and quality attribute scenarios for the existing systems and for their planned extensions.

The first project extended the remote interface of a Robotic software application with new functionality and requirements on integration with higher and lower level systems. The latter was documented with prioritized deployment scenarios.

The second project concerned a product line approach for three gauge systems. The software engineers collected use cases from a set of workshops with the key stakeholders and completed the identification of primary concerns in an SEI Quality Attribute Workshop. Commonalities and variation points were extracted from the use cases.

We made the following observations during the first project;

The second project made the following observations:

The result of these activities was the identification of a methodology to drive system development projects for industrial software systems. The application of use cases and QAWs enables deriving system architectures and service interfaces. Augmenting this approach with the IF method allows identifying the systems' primary concerns and prioritizing them in-line with the business goal. Finally, idiosyncrasies of the application domain have to be taken care of with specific techniques.

Quality Attributes and Requirements Traceability
Andre LeClerc, Unisys Corporation

Quality attributes are requirement that directly affect the building of application and software systems. Quality attributes in fact act as "super" requirements. It might be better to call them meta-requirements. A single quality attribute might impact hundreds of other client requirements. It would be desirable to be able to capture quality attributes in a requirements database and provide "traceability" between the QA, the requirements, the features of a solution, and the components of the eventual proposed architecture.

Unisys has developed a proprietary requirements-driven methodology called CDPro2 (Customer Driven Proposal Process). CDPro2 is both a process and a tool set to achieve traceability between the information components of requirements-driven proposals and projects. This methodology allows Unisys to capture and document requirements of an architecture, features of an architecture (including its quality attributes), components of an architecture, and the associated costs to build those architecture components.

This process/methodology is accompanied by a tool set built as on "overlay" on top of IBM's Rational Tools Suite, including the requirements management tool, Requisite Pro. Requisite Pro has been considerably extended from its basic requirements mission to become a generalized information manager. The customization allows for the capture of all sorts of information related to requirements (including quality attributes) and provides for generalized traceability between all information data types.

As a result, it allows the development team to use the tool set to capture all architecture information. This information can then be traced from the requirements to the quality attributes to the architecture components and finally to their development costs. Thus, extensive information traceability is provided. This has been particularly useful for large outsourcing engagements.

The presentation will describe the overall process and illustrate the use of the tool set but not in great depth.

Architectural Empowerment - A Quality Attribute of Software Architecture Realms to Build Empowered Organizations
Issac Eldo, Philips Medical System

It's a fact that organizations which are empowering teams and individuals are efficient and successful. At the core, empowerment requires two key elements:1) effective knowledge at every participant's disposal, so that they can make informed decisions in every step they take and 2) process/structure where everyone/teams can take and own decisions in their job scope. This will equally benefit the organization and individuals as everyone will be leveraging their talents. Empowerment is not easy to achieve, as there is a fine line between empowerment and slipping into chaos, so organizations turn more towards a central command control model. An effective implementation will depend on a deep understanding of every job circumstance and understanding what empowerment means in that situation; because of this, organizations struggle to empower.

In the software engineering realm, the lives of organizations and individuals are centered on basic tenets of software development: requirements, architecture, design, coding, testing, implementation, and support. Given this fact, in order to empower, there has to be deep knowledge of the problems (requirements) and solutions (architecture/designs) across the organization, so that everyone can make the right decisions in their jobs. And also this needs software methodologies, which promote ownership at all levels of organization, e.g., features, subsystems, etc. Architecture and architecture process are the keys to achieving this. I would like to call architecture (the end result, the knowledge) and architecture process (the architecting and designing process) the architecture realm.

Architecture realm is the glue that holds everything together–the system, participants, and the process steps. Starting from the requirement analysis to maintenance, every phase greatly depends on it, some of them more than the others. For example, 1) everyone needs knowledge of the architecture to make the right decisions, it could be spectators (someone who just hears about your project), stakeholders (marketing, sales, management, development, test, implementation, support) to potential customers (curious spectators) and customers. 2)To leverage great designers and developers, the architecture and architectural process has to be empowering and should give everyone a foundation to build on using their ideas and skills. It also should allow teams to own features and areas. 3) To have quality testing, testers need to understand the requirements and the solution for requirement, which lies in architecture and design. 4) Customers need to understand how a product's architecture will fit in to their enterprise. We can have lot of examples like these. All these, point out the need to empower the organization architecturally.

Traditionally architecture realm is measured in terms of "ility"s (flexibility, availability, scalability, extensibility…etc.). These attributes are targeting qualities of the end solution, i.e., the architecture. But an important aspect of architecture realm, which does not get enough attention, is its contribution to building successful organizations. But generally it's much more obvious when the architecture realm stands in the way of making an organization successful. As a simple example, when you think about scaling a team, if the architecture is such a way that, it needs central command and control for every decision, it's going to be very difficult. At the same time, you need to also make sure everyone is marching to one beat, building modules the way it fits into the architecture, using the framework elements of the system and using their brains to design and develop features. In order to be successful in this, when the architecture realm is put up, it needs to consider all these facts.

So architecture empowerment is about having an architecture realm (architecture and architecture process), which will help everyone involved to gain the knowledge they need to perform their duties and provide a framework which permits teams and individuals to comprehend, own, influence, and execute things they are responsible for effectively, thereby benefiting both the organization and personal lives of the employees.

If achieved, following are some key benefits to the organization from architecture empowerment

  1. Organizational Scalability
  2. Distributed Development
  3. Team Ownership and Empowerment
  4. Feature-Centric Development
  5. Architecture and Design Excellence
  6. Parallel Development
  7. System Quality
  8. Individual's talent development
  9. Power of architectural knowledge
  10. Streamlined project execution
  11. …etc.

Following are a few basic tenets to achieving architecture empowerment in an organization:

  1. Collaborative Requirement Analysis and Architecture Modeling
  2. Consumer-Centered Architecture Modeling
  3. Evolving Asset-Driven Architecture
  4. Architecture-Driven Planning Framework
  5. Multiphase Evolving Software Design Process
  6. Ownership-Centered Design Process
  7. Feature-Centered Architecture and Design Modeling
  8. Architecture- and Design-Driven Test Model
  9. …etc.

In the presentation, I will expand on these concepts and explain how and why I see these are going to empower organizations and make them more successful.

Software Architecture in the Integrated Engineering Methodology
J. D. Baker, BAE Systems

Fitting software architecture into the engineering process becomes a challenge when you are developing complex systems. What are the inputs? Where do they come from? How do I know that what the other disciplines are creating will meet my needs? How do I know I'm creating useful work products? Are they are being produced at the right time? Recognizing this complexity, BAE Systems has developed the Integrated Engineering Methodology (IEM), a model-based, end-to-end methodology that seeks to ensure that only the products that are needed are developed and that development occurs at the right time. How do you do all that and maintain the organization at CMMI Level 5? This presentation describes the IEM, highlights the software architecture and describes its relationship to the other elements of the methodology.

Debugging Software Architectures
Kyungsoo Im & John McGregor, Clemson University

As software architectures are used to describe larger and complex systems, it is increasingly difficult to find the cause of an error in the event of a failure. Debugging is commonly used in programming languages to effectively find the cause of a failure and locate the error to provide a fix. The same should be accomplished in software architectures to debug architecture failures.

As part of our work in debugging software architectures, we are identifying a classification of architectural defects. This provides a basis in forming a hypothesis on what has caused the defect in the architecture. In the debugging process, the chosen hypothesis is either confirmed or refuted. Once it is confirmed, a possible correction can be identified to correct the architecture.

The debugging process involves debugging at the structural level and execution level of the software architecture. Structural errors are debugged through static aspects of the architecture. Execution errors are debugged through the use of a simulator, for instance the ADeS simulator for AADL.

In this presentation, we introduce our approach to debugging software architectures and present preliminary results.

Current SEI SAT Initiative Technology Investigations
Phil Bianco & Andres Diaz-Pace, Software Engineering Institute

One of the axioms of the SEI's Software Architecture Technology (SAT) Initiative is that quality attribute requirements such as those for security, performance, modifiability, usability, and so forth have a dominant influence on a software architecture. Many people are familiar with our methods such as the SEI Architecture Tradeoff Analysis Method (ATAM) and SEI Quality Attribute Workshop (QAW) and would like to know more about some of the current research of the SAT Initiative.

In this talk, we will discuss two current research projects. First, we will provide a brief overview of our investigation into service-oriented architectures. Secondly, we will focus on SEI ArchE, which is an expert system that makes the design process more transparent and helps software architects to make appropriate decisions. Currently, ArchE can reason about modifiability and real-time performance. We have recently completed an interface that will allow collaborators to add additional quality attribute knowledge to enhance the capability of ArchE.

Lessons Learned from Deployment and Production Use of Architect's Workbench - An Architectural Thinking and Modeling Tool
Doug Kimelman, IBM J. Watson Research Center

Information technology (IT) architects know how hard it is to collect architectural information in an engagement and keep it all clear and organized in their minds. Transforming that information into the models of a viable architecture and keeping associated work products consistent and up-to-date is an even greater challenge. Despite this, model-centric architectural methods are not as widely adopted or as closely followed as they could be, partly due to a lack of appropriate tools.

Architects' Workbench (AWB) is prototype technology that addresses these problems and supports the creative process of architectural thinking and modeling.

We present key AWB innovations and discuss how their design was motivated by insights into architectural work and feedback from IT architects. We describe the design of AWB itself as a metamodel-driven and method-based tool, we report on experience from the use of AWB in production environments, we discuss productivity and quality gains arising out of the use of AWB, and we present lessons learned concerning tool support for IT architecture.

Some Perspectives in Teaching Software Architecture
Prabhakar T. V., Indian Institute of Technology

This report talks about the experiences that the authors faced in teaching software architecture to senior undergraduate and post-graduate students at IIT Kanpur over the last five years. The problem is one of teaching design and architecture to a community with a background only in programming (programming in the small)–a situation we sometimes face in the induction and training programs in the industry as well. We catalog the approaches that worked and point out some of the problems in teaching in a classroom setting, a domain which is perhaps best learned through an apprenticeship.