SATURN 2008 Presentations

This file contains presentations from the fourth SEI Software Architecture Technology User Network Workshop (SATURN 2008) event (April 30-May 1, 2008, in Pittsburgh, Pennsylvania).

Sessions and presentations included:

*Applying SEI Architecture Tradeoff Analysis Method (ATAM) as Part of Formal Software Architecture Review, Ioannis Kyratzoglou 
*Architecture Curve, New Formatted SEI ATAM Report Shaped in a Single Graph, Hearen Youn
*Architecture Empowerment - A Quality Attribute of Software Architecture Realms to Build Empowered Organizations, I. Eldo
*Architecture Evaluation: Experiences in Using SEI's ATAM, Fernando Enobi and Reginaldo Arakak 
*Architecture From a Manager’s Perspective, Linda M. Northrop
*Architects' Workbench ("AWB") - A Tool for Architectural Thinking and Modeling, Steve Abrams, Steven Tang, John Vlissides, Bard Bloom, Paul Keyser, D. Kimelman (IBM J. Watson Research Center), Eric Nelson, Wendy Neuberger, Tova Roth, Ian Simmonds, Carl Spencer
*Challenges and Observations of Applying the SEI ATAM to a Software Testing Automation Solution, F. Enobi and  R. Arakaki 
*Current SAT Work in Architecture Evolution, Rick Kazman
*Current SEI SAT Initiative Technology Investigations, Philip Bianco and Andres Diaz-Pace
*Debugging Software Architectures, Kyungsoo Im and John McGregor
*Defining Composite Critical Scenarios for the Development of Large Scale System Architecture Using an SEI's ADD-based Framework, Aldo Dagnino
*Evaluating Distributed Systems Architectures for Fault-Tolerant Applications, James Scott
*Identifying and Documenting Primary Concerns in Industrial Software Systems, Pia Stoll and Roland Weiss
*Inexpensive ATAM-Peer Review Detects and Fixes Architecture Problems Early, H. Forstrom
*Lessons Learned from Deployment and Production Use of Architects' Workbench - An Architectural Thinking and Modeling Tool, D. Kimelman
*On ADLs and Tool Support for Documenting View-Based Architectural Descriptions, Alexander Helleboogh and Danny Weyns
*On Software Architecture, Agile Development, Value and Cost, Philippe Kruchten
*Putting Software Architecture in its Place (Keynote), Eoin Woods
*Quality Attributes and Requirement Traceability, A. LeClerc
*Realizing the Business Value of IT: An Approach for Architecture Evaluation, Opal Perry
*Reconstructing the Architecture Model for a Sustainable Software System, Pia Stoll
*Reducing Uncertainty In Architecture Plans, David Sharp
*Software Architecture in an Integrated Engineering Methodology, J. D. Baker 
*Some Perspectives in Teaching Software Architecture, Kiran Kumar











Applying SEI Architecture Tradeoff Analysis Method (ATAM) as Part of Formal Software Architecture Review, Ioannis Kyratzoglou 

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.



Architecture Curve, New Formatted SEI ATAM Report Shaped in a Single Graph, Hearen Youn

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 the tailored QAW and ATAM process at Samsung Electronics. 2) Introduce an additional ATAM report shaped in a single graph: we call it an "architecture curve." 3) Present case studies in applying the tailored ATAM and QAW.



Architecture Empowerment - A Quality Attribute of Software Architecture Realms to Build Empowered Organizations, I. Eldo

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 requirements, which lies in architecture and design. 4) Customers need to understand how a product's architecture will fit into their enterprises. 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 that fit 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.




Architecture Evaluation: Experiences in Using SEI's ATAM, Fernando Enobi and Reginaldo Arakak

The automated testing solution was implemented to speed up the 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 successful results. Evaluating and measuring the nonfunctional requirements became very critical to evaluating 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 levels 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 From a Manager’s Perspective, Linda Northrop

No abstract available. 



Architects' Workbench ("AWB") - A Tool for Architectural Thinking and Modeling, Steve Abrams, Steven Tang, John Vlissides, Bard Bloom, Paul Keyser, D. Kimelman (IBM J. Watson Research Center), Eric Nelson, Wendy Neuberger, Tova Roth, Ian Simmonds, Carl Spencer

No abstract available.



Challenges and Observations of Applying the SEI ATAM to a Software Testing Automation Solution, F. Enobi and  R. Arakaki 

The automated testing solution was implemented to speed up the 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 successful results. Evaluating and measuring the nonfunctional requirements became very critical to evaluating 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 levels 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




Current SAT Work in Architecture Evolution, Rick Kazman

Architecture evolution is the process of designing an architecture to meet today's and tomorrow's business goals, while maximizing expected value, in the face of uncertainty. Architecture evolution therefore has two foundations: 1) architecture design, which allows us to reason about the quality attribute consequences of design decisions with respect to trajectories of evolutionary steps and 2) software engineering economics, which looks at the consequences of design decisions as investments and gives us techniques to reason about the value of such investments given future uncertainty. In this talk, I will sketch our approaches to both aspects of evolution.




Current SEI SAT Initiative Technology Investigations, Philip Bianco and Andres Diaz-Pace

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.




Debugging Software Architectures, Kyungsoo Im and John McGregor

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.




Defining Composite Critical Scenarios for the Development of Large Scale System Architecture Using an SEI's ADD-based Framework, Aldo Dagnino

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.





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

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 - The processing model - Interprocess Communication - Redundancy Model - Fault Management and Recovery - Graceful Degradation Under Load - Operational Management and Maintenance - System Debugging Environment 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, there will be discussion about how these topics and patterns can be applied within the context of the SEI Architecture Tradeoff Analysis Method (ATAM) of software architecture evaluation.




Identifying and Documenting Primary Concerns in Industrial Software Systems, Pia Stoll and Roland Weiss

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 they include 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:    

* ABB's global business structure generally requires a distributed approach to gathering use cases and quality attribute scenarios, mandating an effecting strategy for running these distributed interviews (both in location and time) and merging the information.    

* Combining use cases and quality attribute scenarios provides an excellent methodology for capturing system characteristics and for discussing the system's primary concerns with the different stakeholders.    

* Some system characteristics were not covered by use cases and quality attribute scenarios. Therefore, we added project and domain-specific mechanisms to get a complete picture of the system for making sound architecture and design decisions. The second project made the following observations:    

* Stakeholders voted with a specific mind-set in the QAW. Instead of voting on the legacy primary scenarios, e.g., 'Implement same performance as today,' they voted on what new functionality they considered to be the most important for the next-generation products based on the common platform.    

* The QAW did not cover all primary concerns with positive impact on the prioritized business goal. Therefore, the ABB-developed IF method was used to prioritize these concerns based on use cases, QAW, and interviews.    

* The identification of commonalities and variation points according to the SEI methodology simplified the first sketch of the architecture. 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 the deriving of system architectures and service interfaces. Augmenting this approach with the IF method allows identifying the systems' primary concerns and prioritizing them inline with the business goal. Finally, idiosyncrasies of the application domain have to be taken care of with specific techniques. Download PDF >> Quality Attributes and Requirements Traceability Andre LeClerc, Unisys Corporation Presentation Abstract: 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.




Inexpensive ATAM-Peer Review Detects and Fixes Architecture Problems Early, H. Forstrom

ITT has pioneered a procedure for adapting the 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 mini 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 four hours. In piloting this method, ITT succeeded in finding over eight 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.





Lessons Learned from Deployment and Production Use of Architects' Workbench - An Architectural Thinking and Modeling Tool, D. Kimelman

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.





On ADLs and Tool Support for Documenting View-Based Architectural Descriptions, Alexander Helleboogh and Danny Weyns

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

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




On Software Architecture, Agile Development, Value and Cost, Philippe Kruchten

For many proponents of an agile approach to software development, software architecture is often seen as BUFD = Big Up-Front Design, and therefore as pure evil. But for novel, large system development, a decent architecture is not likely to simply emerge out of weekly refactorings, and we've witnessed such projects "hit a wall," like marathon runners, after a few months of agile euphoria. They tried to do the right thing from an agile perspective: deliver value to the end user at each iteration. But we notice that they often confuse cost with value, and they have decided that software architecture has no value whatsoever. By clarifying the concepts of value and being able to attribute some value to architectural design and implementation, we would allow agile projects to be reconciled with BUFD and exploit the richness of the SEI Cost Benefit Analysis Method (CBAM).





Putting Software Architecture in its Place (Keynote), Eoin Woods

This keynote presentation was given at SATURN 2008, which took place in Pittsburgh, PA on April 28-May 1, 2008.

As you navigate a software technology-oriented organisation, as either an end user or a vendor, you often encounter many quite senior people with the word "architect" in their job title. Software architects, enterprise architects, data architects, systems architects, solutions architects, infrastructure architects…the list goes on and on. You quickly realise that these people can't all be doing the same job, and this realisation is reinforced as you meet the people concerned and often find that they have quite different skills, responsibilities, and interests.

In this talk, I hope to shed some light on this confusing landscape by sharing my thoughts on the fundamental types of architectural activity that are found in the modern enterprise. I will identify the main types of architects that you encounter in different organisations in terms of their responsibilities, the tasks they undertake, the tools and techniques they are likely to find useful in their work, and the way their roles typically relate to one another. Identifying those things should make the situation a little clearer and improve communication between practitioners and researchers, as we aim to refine and improve the state of software architecture practice.




Quality Attributes and Requirement Traceability, A. LeClerc

Quality attributes are requirements 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.





Realizing the Business Value of IT: An Approach for Architecture Evaluation, Opal Perry

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 prework and the approach taken for conducting sessions in early 2008. We will share our observations and plans for future activities and discuss the challenges of extending architecture evaluation methods within a culture not previously familiar with scenario-based methods as well as the challenges associated with 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.




Reconstructing the Architecture Model for a Sustainable Software System, Pia Stoll

Sustainable software architecture, which has evolved over more than 10 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.



Reducing Uncertainty In Architecture Plans, David Sharp

Presented: April 2008 at the SEI SATURN workshop.



Software Architecture in an Integrated Engineering Methodology, J. D. Baker 

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




Some Perspectives in Teaching Software Architecture, Kiran Kumar

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.