SATURN 2007 Presentations

This file contains presentations from the third program of Software Architecture Technology User Network Workshop (SATURN 2007) event (May 14-16, 2007) in Pittsburgh, Pennsylvania.

Sessions and presentations included:

*A Case Study in Applying Architecture Evaluation Methods, Opal Perry
*A Light-Weight Architecture Trade Off Process Based on ATAM, A Panel Presentation: Sharing Experiences with ATAM, Jon S. Edmondson, Charles G. Kille, and Edwin W. Lee
*An Architecture Journey (Keynote), Jeromy Carrière
*A Product Line Architecture for Army Aviation Diagnostics and Maintenance: Views and Evolution, Ken Capolongo and Sholom G. Cohen 
*Architecting Security In, Jon R. Ramsey
*Automated Requirements Processing Overview, David  L. Curry
*Common ATAM Errors, Dave Mason
*Evaluating a Service-Oriented Architecture, Philip Bianco and Paulo Merson 
*How the QAW Helped our Enterprise Architecture Effort, Stephen T. Le Tourneau
*Improving Software Architecture Competence, Paul C. Clements
*Integrated City Operation Center: An Architecture Case Study with ADD & Data Flow Analysis, Bae Changhyun
*Introducing Scenario-Based Architecture Reviews, Opal Perry
*Neglected Aspects of Software Architecture, G. Todd  Kaiser 
*SEI Architecture Techniques complementary to the RUP, S.  Kerrigan
*Software Architecture Technology Initiative, Mark H. Klein
*System of Systems Architecture Evaluation with Concurrent Development, Michael J. Gagliardi and William G. Wood 
*Technology Evolution – Impact on Architecture of a Complex Medical Product, Pramod Chandrasekhar and Ajay Nitin
*The Negative Impacts of Ignoring Stakeholder Quality Attributes: Joint Fire Support (FS) Command and Control (C2) Case Study, John A. Landmesser
*Tools for Making Better Architecture Decisions (Keynote), Ian Gorton



A Case Study in Applying Architecture Evaluation Methods, Opal Perry

This presentation will discuss our efforts to introduce scenario-based architectural evaluation methods for new systems development efforts within a division of Wells Fargo and Company, a diversified financial services company providing banking, insurance, investments, mortgage and consumer finance for more than 23 million customers through 6,100 stores, the Internet and other distribution channels across North America and elsewhere internationally.



A Light-Weight Architecture Trade Off Process Based on ATAM, A Panel Presentation: Sharing Experiences with ATAM, Jon S. Edmondson, Charles G. Kille, and Edwin W. Lee

This presentation presents the creation and application of a process named "ATO Lite" (Architecture Tradeoff Lite), derived from the SEI ATAM. Transformation of ATAM to "ATO Lite" created a front-end tool that assists architects with development of robust, focused architecture in a time- and cost-effective manner.



An Architecture Journey (Keynote), Jeromy Carrière

This talk is a retrospective, journaling experiences practicing architecture in environments as varied as telecommunications, academia, dot com and post-dot com era startups, a large (very!) independent software vendor and enterprises in media and financial services. Each environment provided many lessons that served to shape and guide the approaches to the discipline-the art and the science-of architecture: building on the base skills of software engineering, adding a structural modeling perspective for architecture definition, achieving an appreciation of the fundamental nature of architectural quality, and accumulating a deep respect for the human dynamics that drive organizations.



A Product Line Architecture for Army Aviation Diagnostics and Maintenance: Views and Evolution, Ken Capolongo and Sholom G. Cohen

Army Aviation vehicles are complex systems of systems and require many resources to operate and sustain, especially in a combat environment where aircraft availability and readiness are essential to the successful completion of battlefield missions. The Communications-Electronics Lifecycle Management Command (C-E LCMC) Software Engineering Center (SEC) is responsible for providing diagnostic products to support these aircraft in the field and is facing the challenge of producing more products with similar or fewer resources, brought on by the current business environment and operational tempo (OPTEMPO). This presentation discusses how the C-E LCMC SEC is meeting the challenge through the adoption of software product line engineering practices, especially that of Architecture Definition, for the Advanced Multiplex Test System (AMTS) product line. A key factor in the success of this product line is the software architecture. This presentation focuses on that architecture and its evolution from supporting a single system to an architecture that supports a product line of diagnostic tools. These tools are currently used to support diagnostics/maintenance of the AH-64A Apache Attack Helicopter with other product line products in development for the Armed Reconnaissance (ARH-70A), Kiowa Warrior Scout/Attack (OH-58D), Chinook Cargo (CH-47F), and Black Hawk Utility (UH-60M) helicopters. The architecture will continue to evolve to support new features, including tele-maintenance, condition-based maintenance, and service-oriented  diagnostics/maintenance. The development of a flexible software product line architecture will be used to facilitate production of avionics maintenance software products that improve avionics field maintenance practices, reduce sustainment costs, and increase aircraft readiness.



Architecting Security In, Jon R. Ramsey

The Internet Security problem is thriving on the lack of secure software.  The CERT® Coordination Center (www.cert.org) reported a 35% increase in the number of software vulnerabilities discovered in 2006 over 2005. As the world has become interconnected, the gains from hacking and the number of hackers are increasing. Ideally software would be built securely from the start. Like other nonfunctional requirements such as quality, reusability, and maintainability, security is greatly determined by the architecture of a system.



Automated Requirements Processing Overview, David  L. Curry

The Automated Requirements Processor (ARP) is a tool currently being developed at NAWS China Lake in support of the Navy Unmanned Air Systems Support Activity. ARP's goal is to introduce, automate, and augment the software architecture discipline by isolating individual requirements presented in plain text, providing reports on the quality of the requirements and generating an XML file that can be directly imported by the SEI OSATE tool for further adornment and analysis. ARP provides software architects, requirements developers, proposal analysts, and standards analysts with the ability to judge the quality of what they are writing and reading, reconcile mismatches in terminology, produce drop-in reusable component models, and develop reference models quickly, inexpensively, accurately, and repeatably, with no data entry beyond converting the target documentation to plain text.



Common ATAM Errors, Dave Mason

This SATURN 2007 presentation teaches how to be a part of an ATAM evaluation, either as an evaluator or an evaluatee, depending on the audience.



Evaluating a Service-Oriented Architecture, Philip Bianco and Paulo Merson 

This presentation was delivered by Philip Bianco and Paulo Merson at the SATURN 2007 conference.



How the QAW Helped our Enterprise Architecture Effort, Stephen T. Le Tourneau

This presentation will describe our experiences of applying the SEI Quality Attribute Workshop to enterprise-level application projects and how it (unexpectedly) played a key role in uncovering architectural elements for a larger Enterprise Architecture effort.



Improving Software Architecture Competence, Paul C. Clements

At the last SATURN workshop, participants heard about a new project in the SEI Software Architecture Technology Initiative titled "Improving Architecture Competence." The goal of this work is to be able to help a software-producing organization measure and improve its ability to predictably and reliably turn out high-quality architectures that align with the organization's business goals and requirements. This talk will discuss the project, its approach and strategies and summarize results so far. In particular, different models of competence will be discussed, along with how they contribute to the goals of measurement and improvement.



Integrated City Operation Center: An Architecture Case Study with ADD & Data Flow Analysis, Bae Changhyun

Integrated City Operation Center (ICOC) is the operating and control center for the ubiquitous city (U-city), where virtually everything is linked to an information system through various u-services and u-devices across the whole city. Since the ICOC is an emerging concept, it is expected to play a vital role in the success of U-city. With this given major business driver, the ICOC system was started, but it wasn't clear how to build the architecture for it. It was expected to be a software-intensive system that combines the various COTS components including GIS products, rule engines, and 3-D modeling engines and databases. Also, since the concept was new to every stakeholder, it was very difficult to identify the clear requirements as well. To solve this problem, we decided to define a conceptual architecture that can present the high-level concerns of stakeholders. Therefore, we tailored the SDS architecting process in order to apply SEI Attribute Driven Design (ADD) and data flow analysis. At first, we defined a specific business case from existing city planning data and several assumptions. Then we analyzed I/O data in the u-city environment. Data flow analysis was the key activity in this process; thus, we could define the architectural elements and their relationship to ICOC. This case study will show the following: 

    *how ADD could help to define the architectural elements and their relations 
    *how the SDS architecting process was applied within this process 
    *how data flow analysis helped define this process 

In this session, we will introduce the case study of the ICOC architecture of Samsung SDS and describe the architecture process with ADD, data flow, and I/O analysis.



Introducing Scenario-Based Architecture Reviews, Opal Perry

Presentation for the 2007 SATURN workshop, held in Pittsburgh.



Neglected Aspects of Software Architecture, G. Todd  Kaiser

In our zest to tackle the hardest problems in the software industry, software architects apply the latest techniques, processes, tools, and technology to create the best software architecture for the systems they are working on. We apply service-oriented approaches, we claim that the architecture is going to be developed using agile methods, and we use architectural documentation to communicate our brilliant ideas. Our architectures rigorously examine the structure, data, and behavior of the software that we are going to build. We examine the quality attributes of performance, reliability, and so forth. For all the work we do to ensure the best architecture that we can devise, we often doom our architectures to failure because we neglect the aspects of the architecture that end up being the most important. Schedules, budgets, team agreements, workshare, and so forth, are very important aspects that affect and are affected by our architectures. This presentation will discuss how these aspects can (and should) affect software architectures and why the "best" architecture from a technology standpoint is not always the "optimum" architecture.




SEI Architecture Techniques complementary to the RUP, S.  Kerrigan

The Rational Unified Process (RUP) is a software engineering process framework. It provides a disciplined customer-focused approach to assigning and managing tasks and responsibilities in a software development process. The RUP guides software practitioners in effectively applying modern best practices for software, such as developing iteratively and incrementally, taking an architecture-centric approach, mitigating risk at every stage in the process, and continuously verifying the quality of the software. Although the RUP is quite comprehensive, enhancements are required, specifically in the areas of Architecture, Project Management, and Product Development.  The Software Engineering Institute (SEI) leads in the architecture field, specifically in the areas of architecture definition, architecture documentation, architecture evaluation, and the software product line approach. These approaches, along with others, can be used and integrated into the RUP. The flexibility of the RUP allows these additional approaches to be integrated into a robust process framework. This presentation gives an overview of the enhancements we made to the RUP,specifically in the area of architecture,and how we use the techniques from the SEI to help overcome these issues. It will highlight the areas where the techniques where used, how effective they were, were we differed in approaches, and some of the challenges we were faced with as we introduced the changes.




Software Architecture Technology Initiative, Mark H. Klein

Presentation made by Mark Klein at the Third Annual SATURN Workshop, May 2007.




System of Systems Architecture Evaluation with Concurrent Development, Michael J. Gagliardi and William G. Wood

Large-scale software-intensive widely distributed battlefield systems of systems (SoSs), such as FCS, have some challenging characteristics. There are software elements being developed concurrently by different contractors that will (1) be installed in different weapons, sensor, and command and control platforms, (2) be the basis for providing a shared view of the battlespace across platforms, and (3)  allow for distributed planning, decision making, and remote engagements. The development is usually done in a number of phases, with roughly 18 months to 2 years between phases. Each phase typically demonstrates the capability to provide the planned functionality and performance for the phase and may spin off some of these capabilities to the field. There are a number of mission threads that are used to describe the inter-platform and inter-element operations of the system. Mission threads can describe tactical operations, logistical operations, support operations, and maintenance, training, test and development operations. Mission threads serve as drivers for developing the architecture and as the basis for test cases during a verification cycle. The major software elements being developed for the SoS may each have its own software architecture design documentation (SADD), perhaps built with diverse tools and using diverse notations. This makes it difficult to evaluate whether the integrated architecture composed of many of these shared elements will satisfy the mission threads. Moreover, since the architecture is driven primarily by the quality attributes, the mission threads need to be augmented with quality attribute considerations for architecture development and evaluation activities. This presentation will describe an approach to integrating all of these factors in such a way that successful evaluation of the SoS architecture against the mission threads can take place.




Technology Evolution – Impact on Architecture of a Complex Medical Product, Pramod Chandrasekhar and Ajay Nitin

In the history of complex systems, a recurring development process pattern exists in which a new approach, design, or architecture is introduced to partly replace existing functionality that is attaining obsolescence. The reason for this partial line of attack is that a complete replacement of existing functionality is deemed too invasive and risky. The intention is that, at the next occasion (typically a development cycle), the remains of the obsolete implementation will be fully replaced by the new approach. It is not until this time that the functional and architectural benefits of the new method can be reaped. The practice is that, when the next project emerges, great emphasis is placed on a few new functional features that must enter the market in the shortest time possible. Promises or agreements that the old hat must be gotten rid of are quickly traded for seemingly more attractive short-term goals. What seems to be overlooked is that each time a new dual-track is entered, maintenance costs rise. What is much worse is that future development is curtailed because whatever is developed in the new design must remain compatible with the old implementation with which the new line is condemned to cohabitate in the same or similar applications. When this cohabitation is forced to go on for an extended time, the new implementation starts to suffer from its (potentially advantageous) adaptability and starts to adopt the idiosyncrasies of the components it was designed to replace. In our product, an MR scanner, this was evident from the striking fact that there evolved two distinct ways in which the scanner could be operated. In order to facilitate ease of use and thereby increase throughput, a solution evolved that automated a lot of tasks that were inherently performed by the operator. This new path, termed ExamCards, however could not provide the complete functionality that was present in the old way of operating the system,the ScanList environment as it was termed. This led to the fact that the operator had to switch between these environments in order to exercise the complete set of options provided. Architecturally this was a nightmare, since solutions or software that had to be built into the system (for the introduction of new functionalities that the market demanded) had to support both of these worlds. Moreover, as in typically large software systems, there exists a lot of history and legacy that must be carried forward. The presentation will focus on experiences in dealing with the architectural challenges of the described system.




The Negative Impacts of Ignoring Stakeholder Quality Attributes: Joint Fire Support (FS) Command and Control (C2) Case Study, John A. Landmesser

This presentation, after providing an overview of the collaborative coordination of the mission execution problem space, will focus on the attempted replacement solution and the current system evolution solutions for the coordination of joint operated deep operations. The presentation will describe the business drivers and key quality attributes of Army Battle Command Systems (ABCS) and lessons learned for future ABCS migration to Net-Enabled Command Capability (NECC).



Tools for Making Better Architecture Decisions (Keynote), Ian Gorton

Tools are essential to support software architecture design and evaluation methods. In this talk, I'll describe some novel, prototype tools for architecture knowledge management, collaborative architecture design and decision making, and performance analysis of COTS-based architectures. A brief overview of the aims and major features of each tool will be presented, and their use in industrial projects will be discussed.
