May 17 - 21, 2010 | Minneapolis, MN

Keynote. Tutorial and Presentation Abstracts

Keynote and IEEE Speaker Abstracts

Architects: Accelerators or Anchors to Organizational Agility?
Keynote Speaker: Jim Highsmith
Business Week article proclaims, “There is no more Normal.” A recent book examines, The Upside of Turbulence: Seizing Opportunity in an Uncertain World (by Donald Sull). In the throws of pervasive change the traditional emphasis on “following the plan with minimal changes,” needs to be superseded by “adapting successfully to inevitable changes.”

If the new stress is on agility, adaptability, and flexibility, then what is the role of architects and architecture in this environment? What is agility and should your organization have more of it? Are architecture and agile development compatible? How can architects accelerate agility in organizations?

Jim's talk in explores these questions through the lenses of business strategy, opportunity life cycles, how buildings learn, being agile and doing agile, spiders and starfish, the architecture of time, technical debt, legos© and erector sets, and the four components of responsiveness.

Managing scale and agility: Transformational Architecture for the Smart Grid
Keynote Speaker: Wayne Longcore

The world's largest machine is not a mining truck, a space shuttle or a luxury cruise ship -- and many of us interact with it every single day. The North American Power Grid, a magnificent achievement of the 20th century, was created back when carburetors were first put in cars. Today, much as a single hybrid vehicle has dozens of computers and sophisticated controls to optimize its energy usage, intelligently managing storage and navigation of the world's largest machine is becoming more efficient, capable, and intelligent. Wayne Longcore will speak on the use of the Agile Architecture methodology that his team employs to create the first true instantiation of a high-functioning Ultra-Large-Scale System -- the Smart Grid.  Wayne will also discuss the work of the national and international standards communities in the areas of systems theory, security, and controls, as he provides a truly thought-provoking vision of the future.

Software architecture and agility: a clash of two cultures?
IEEE Speaker: Philippe Kruchten
"Software architecture is taking a bad rap with the agilists. proponents of agile and lean software development approaches: “BUFD big up-front design”, “YAGNI You Ain’t Gonna Need It”, “massive documentation”, “smells of waterfall”, it is pictured as a typical non-agile practice. However, certain classes of system, ignoring architectural issues too long “hit a wall” and collapse by lack of an architectural focus. ‘Agile architecture’: a paradox, an oxymoron, two totally incompatible approaches? In this tutorial, we will review the real issues at stake, past the rhetoric and posturing, and show that the two cultures can coexist and support each other, where appropriate. We define heuristics to scope how much architecture a project really needs, to assign actual value to an otherwise invisible architecture; and we review management and development practices that do work in the circumstances where some significant architectural effort is needed, when you are actually going to need it."

The Architect as Change Agent
IEEE Speaker: Linda Rising
"Architects, like the rest of us, struggle to influence our teams or organizations to adopt good ideas--whether we want to move our department to a better development method or suggest a Friday night movie for the family. We develop great solutions but struggle to make something happen. How can we influence change? From her latest book Fearless Change: Patterns for Introducing New Ideas, Linda Rising will share stories of successful change agents including supporting research in social psychology-in particular, studies that focus on influence strategies. Even evolutionary biologists help shed light on why these patterns are so powerfully ingrained and hardwired in our brains that 'You can take a person out of the Stone Age, but you can't take the Stone Age out of a person!' Although we can't change our DNA, we can use this information to help improve our organizations."

Tutorial Abstracts

T1: The Pedigreed Attribute eLicitation Method (PALM)
Len Bass, Software Engineering Institute
Paul Clements, Software Engineering Institute

An architect’s primary duty is to design an architecture that achieves the system’s required quality attributes such as performance, availability, modifiability, security, and the like. Requirements specifications often do a poor job of capturing requirements for quality attributes, instead focusing on functionality; they do an even poorer job of capturing the business goals that lead to those quality attribute requirements. To help architects elicit and capture business goals and spot mismatches with existing quality attribute requirements, the SEI has developed the Pedigreed Attribute eLicitation Method (PALM), a seven-step facilitated stakeholder workshop. PALM can help architects spot missing quality attribute requirements, and help them push back against overly demanding requirements that are not grounded in any business goal. PALM empowers architects to ask the right questions at the right time, resulting in architectures more responsive to an organization’s needs. This tutorial will introduce PALM and, in a mock exercise, allow students to experience its application.

T2: Efficient Software Technology Evaluations Leveraging ADD
Karen Smiley, ABB
Elizabeth Kielzcewski, ABB

Some technology selections are easy: few choices, low impact of ‘wrong’ selections, a handful of decision factors, one stakeholder – deciders may just flip a coin. However, real-life software system technology evaluations can have many architecturally significant criteria, multiple alternatives, conflicting stakeholder priorities, biased (perhaps unknowingly) evaluators, and severe business consequences of poor selections. In this tutorial, participants learn via hands-on exercises to effectively apply the ADD-based AHEAD technology evaluation method on technology decisions that matter.

T3: Architectural Knowledge Management
Phillipe Kruchten, University of British Columbia

Software architecture is the manifestation the major early design decisions made for a software-intensive system. These architectural decisions in turn will determine much of the system’s design, development, deployment and evolution. Making better architectural design decisions is a key challenge in software engineering, made even more difficult by the complexity and heterogeneity of the systems we want to develop, and the distribution of the development teams. Great gains in efficiency and quality can be achieved when organizations can capture, capitalize and then transfer software (and system) architectural knowledge. This tutorial presents the challenges, introduces a conceptual framework for architectural knowledge management, and describes practices, methods, and tools for software architects to manage efficiently the vast amount of information necessary to make enlighten architectural design decisions.

T4: System of Systems Architecture-Centric Acquisition
Mike Gagliardi, Software Engineering Institute
William Wood, Software Engineering Institute

For large-scale systems of systems (SoS), severe integration and operational problems can arise due to inconsistencies, ambiguities, and gaps in how quality attributes (non-functional requirements such as availability, predictability, and security) are addressed in the architectures. This is exacerbated in contexts where major system and software elements of the SoS are developed concurrently and often times independently by different organizations. In addition, often some inconvenient considerations are swept under the table.

The SEI has developed and piloted a uniform approach to assist with these factors, especially for capturing the quality attribute requirements as augmentations to end-to-end mission threads early in the architecture development process and for analyzing SoS, system, and software architectures against these augmented mission threads. The elements of this approach include Acquisition Planning Workshop (APW) Architecture Fact Finding (AFF) Mission Thread Workshop (MTW) Architecture Challenges Workshop (ACW) SoS Architecture Evaluation (SoS ArchEval) System and Software Architecture Evaluation (ATAM), and Architecture Improvement Workshop (AIW). This ½ day tutorial will outline each of the workshops and present an architecture-centric acquisition approach, showing how they can be effectively integrated into the acquisition life-cycle and used over the lifespan of assets and products.

T5: Influence Strategies for Technical Leaders
Linda Rising

You've tried and tried to convince people of your position. You've laid out your logical arguments on impressive PowerPoint slides-but you are still not able to sway them. Cognitive scientists understand that the approach you are taking is rarely successful. Often you must speak to others' subconscious motivators rather than their rational, analytic side. Linda Rising shares influence strategies that you can use to more effectively convince others to see things your way. These strategies are based on a number of hardwired traits: "liking"-we like people who are like us; "reciprocity"-we repay in kind; "social proof"-we follow the lead of others similar to us; "consistency"-we align ourselves with our previous commitments; "authority"-we defer to authority figures; and "scarcity"-we want more of something when there is less to be had. Learn how to build on these traits as a way of improving your communication skills. Use this valuable toolkit in addition to the logical left-brain techniques on which we depend.

T6: Risk-Centric Software Architecture
George Fairbanks, Rhino Research

Architectural design is expensive, so how can you do “just enough” architecture? Today, you must rely upon your intuition. Smaller, simpler projects often thrive with agile processes and evolutionary design. Bigger, complex projects benefit from architectural planning. Between the two is a huge gap --- but little guidance on how to choose “just enough” architecture. This tutorial provides guidance via the Risk-Centric Model, inspired by Attribute Driven Design, Global Analysis, and the Spiral model.

Risks are central in the Risk-Centric Model, so developers:

  1. prioritize the risks they face,
  2. choose appropriate architecture techniques to mitigate those risks, and
  3. re-evaluate remaining risks.

It encourages “just enough” architecture by guiding developers to a prioritized subset of architecture activities. The mappings between risks and corresponding architecture techniques are explicit. Since it is not a full software development process, it can be used inside of a process such as XP or RUP.

T7: Recurring Architectural Decisions: A Context-Specific Guide through SOA and Cloud Design
Olaf Zimmermann, IBM Research GmbH

IIn this tutorial, we present excerpts from a Service-Oriented Architecture (SOA) and cloud computing decision guidance model harvested from large-scale enterprise applications which have been subject to change since they went live several years ago. This guidance model comprises of 600+ issues (design problems) commonly encountered in SOA and cloud design, 2000+  known solutions (design alternatives) to these design problems, and best practices recommendations when to select which solution. We also outline how to support architectural decision capturing and reuse in existing and emerging design tools.

The decisions in the guidance model deal with selection and adoption of architectural patterns, the selection and profiling of with technology standards, as well as with selection and configuration of vendor and open source assets. Examples of recurring SOA design issues featured in the tutorial are the selection of integration style and message exchange patterns, the definition of business and system transaction boundaries, as well as service and operation granularity issues. Recurring cloud design issues pertain to cloud virtualization layers (infrastructure vs. platform vs. software), workload type and application genre to be virtualized, and private vs. public cloud exposure.

Attendees of the tutorial will gain:

  • An understanding of the importance of architectural decision capturing and sharing.
  • The ability to identify required and recurring decisions in UML and other models, to make these decisions more consciously, and to enforce them adequately.
  • Familiarity with a decision-centric approach to architecture design which starts from software quality attributes and architectural patterns.

T8: The Art of Drawing People In
Ruth Malan, Bredemeyer Consulting

This tutorial explores the various kinds of visuals (graphic templates, sketches like rich pictures, informal and formal models) used in architecting, and their role in envisioning, collaborating, decision making, and communicating and persuading. Of course, we all recognize that architecting systems, much like architecting buildings, is a highly visual matter, since we need to communicate what we have in mind to others--telling the people who will build the system what it will look like. Specifying the solution. Explaining and defending the solution. Communicating our design. In this tutorial, we explore other roles of visualization--supporting reasoning, but also enhancing creativity and supporting thought experiments. Idioms like "drawing people in" and "drawing people out" speak to the power of visuals in collaborative work, creating a shared thought-space where others can contribute ideas, and building enthusiasm and buy-in because people see themselves in the picture. The tutorial uses a combination of stories; surveys of thinking on topics from neuroscience and creativity, collaboration, visual thinking, system modeling and agile architecting; and practice sessions, to gain an experiential sense of a number of visualization techniques and their role in architecting.

A Cooperative Learning Event: Hard Choices

Agile development methods continue to expand in popularity and are increasingly being applied to larger and more complex projects both in industry and government. This trend has created a corresponding urgency in the need to incorporate sound architectural principles within an agile software development environment.

The Cooperative Learning (COOL) Event on Agile Software Development and Software Architecture is an opportunity to collectively explore challenges and successes in architecting in agile software development environments, as well as how agile principles and practices can inform our approach towards architecting. We will base the discussion on an engaging technique used successfully in agile community, game play.

We expect the attendees will walk away with:

  • a technique for communicating the trade-off of architecting with agility to fellow colleagues and managers through our Hard Choices game
  • challenges and lessons learned from fellow practitioners in this emerging area of practice and research through the game debrief.

Presentation Abstracts

Agile Architect - Integrating Enterprise Architecture into Agile and Lean Software Development
Srini Penchikala, InfoQ

Agile and Lean frameworks like Scrum, eXtreme Programming (XP), and Kanban have been gaining a lot of interest and momentum in the enterprise software development spectrum in the recent years. These approaches promote agility in delivering software products iteratively and incrementally in shorter iterations (typically few weeks) compared to the traditional approaches. While an Agile development process does support the framework and best practices for faster delivery of the software product and the quality from a business and functional requirements stand-point, it could lead, if proper emphasis is not placed, to a situation where the software created is not of sufficient quality in terms of non-functional requirements like architecture and design.

Agile Architecting: Using Agile Principles to Agilitize the Architecting Process
Amine Chigani, Virginia Tech

Agile is a philosophy (or a way of thinking) rather than it is a set of practices (e.g., TDD, Pair-Programming) and methods (e.g. XP, Scrum, Lean, FDD). From an architecture perspective, there is value in incorporating agile principles (and some practices) into architecture-centric methods to accommodate changes in architectural drivers during the development of a large-scale system. In this talk, I briefly discuss the context of the architecture we are developing at Virginia Tech and the rationale that guided us to follow an agile approach to architecting. Then, I demonstrate through examples from this ongoing project how agile principles and some practices are readily well-suited as architecture practices. Particularly, three agile-like practices are adopted in the architecting process including: quality user stories, the “architecture wall” concept, and architectural refactoring. Finally, I list three lessons-learned from this effort and show how they can be applied in other development efforts.

An Architectural Decision Modeling Framework for SOA and Cloud Design
Olaf Zimmermann, IBM Research GmbH

In this presentation, we demonstrate how reusable architectural decision models can support Service-Oriented Architecture (SOA) and cloud design: We present an architectural decision modeling framework called SOA Decision Modeling (SOAD) which treats recurring architectural decision as first-class architecture design artifacts. SOAD provides a technique to systematically identify such recurring decisions. We also present a reusable architectural decision model for SOA that was created with SOAD. This model separates long lasting platform-independent decisions from rapidly changing platform-specific ones; the alternatives in a conceptual model level reference architectural patterns. SOAD has its roots in our industry projects conducted since 2001; it has been leveraged successfully by practitioners since 2006. SOAD is not only applicable to enterprise application, SOA, and cloud design, but also to other application genres and architectural styles. It supports use cases such as education, knowledge exchange, design method, review technique, governance instrument, and architecture change management.

Architecturally Focused Techniques for Managing System Evolution
William Koscho

Change is inevitable, beginning the moment a solution is conceived, and it is critical that we recognize and organize to embrace this idea. It may even increase, as users understand the system’s capabilities and future potential. Change is a sign the system provides value to someone, and any system providing value will generate change requests and be required to evolve and fulfill those requests.

Organizations, and specifically architects, need to provide ways of dealing with change that enable the organization to continue to meet their business and customer goals in the face of persistent change by planning for change, understanding the impact of change, and effective implementation.

This paper describes methods, tools, and lessons learned for gaining better insight to the customer’s goals, an ontology for understanding how changes may support or conflict with existing goals, and recasts policies from the accounting and audit industry to minimize the risk that design decisions (as a result of the change) negatively impact the architecture’s ability to satisfy its goals.

Architecture and Agile, friends or enemies?
Ger Schoeber, Sioux Embedded Systems B.V.

In this presentation we will learn the applied approach and the lessons learned during the development of a high tech consumer product. My presentation will show the marriage of a concrete architectural fundament and the agile development principles to come to a multidisciplinary and multisite development process. I will introduce how to come to a good balance between stability and agility. I will also explain how agility can be applied both in software development and in other disciplines like mechanical development and electronics development which are very typical for the development of embedded systems. Last, and surely not least, I will talk about the importance of focus on both the functional and non-functional requirements during the whole development life cycle. The presentation is illustrated by practices learned in a real life project where I was responsible as the overall system architect. From feasibility, development, system integration, production and market introduction.

Architecture Model Reconstruction towards Change Scenario Evaluation
Heiko Koziolek, ABB Corporate Research
Emanuel Kolb, ABB Corporate Research
Jens Doppelhamer, ABB Corporate Research

Software architecture reconstruction helps architects to redocument existing systems and to check code conformance. Existing method and tools for software architecture reconstruction do not support the structured evaluation of architectural change scenarios based on the reverse engineered models. We have applied the novel architecture reconstruction method and tools of the EU-project Q-ImPrESS on a large-scale ABB software system from the process automation domain. We have reconstructed a high-level component and connector model as well as component internal control flow from C++ source code. The resulting models can be altered to reflect change scenarios and be semi-automatically evaluated for performance, reliability, and cost properties. Therefore model-driven predictions for these quality attributes in certain changes scenarios shall be possible so that architectural trade-offs can be analyzed. Our presentation focuses on the architecture model reconstruction activities of Q-ImPrESS and describes our experiences when applying the tools on an existing large-scale system.

Assessing Commercial Off the Shelf Software in Industry Using ATAM® and RUP® Analysis
Marcel Derosier, Ameriprise Financial, Inc.

The use of commercial off the shelf (COTS) components enables more timely implementation of software projects in industry, but the time spent in evaluation of a single product, particularly when critical short comings are discovered late in the process, can often impact the business advantages of a faster time to market. Using a the Architectural Trade Off and Analysis Method (ATAM®) in conjunction with high level analysis artifacts based on modified Rational Unified Processes (RUP®)to manage scope and risk, teams are able to quickly evaluate COTS-based architectural solutions prior to contract finalization. This paper will discuss the method, outcomes, and lessons learned in a series of inter-related COTS based implementations using the aforementioned methods in industry. Learner objectives focus on sensitivity of quality requirements, progressive states of use cases, and component level use case realizations.

Cloud Computing Architecture
Gerald Kaefer, Siemens AG - Corporate Research and Technologies

The emerging field of cloud computing provides promising opportunities for saving cost and improving efficiency with enterprise applications. However, using cloud computing implies also new application architecture and brings new business models. And, it creates security concerns resulting from off-organisation hosting. These issues pose several challenges when building new cloud computing applications. Especially, cloud platforms will lessen the gap between software architecture and IT architecture and thereby increase the responsibility of software architecture. The result is that software architects must improve their knowledge and experience to this regard. In particular, we expect that future enterprise applications will involve hybrid clouds as a cornerstone in application architecture. This presentation will share software architectural aspects for cloud computing and lessons learned from projects.

Designing and Building Large Scale Systems in an Agile World
Stevie Borne, Thomson Reuters
Dave Hendricksen, Thomson Reuters

Many people believe that Agile software development is a fun, loosely defined approach allowing for continual requirements changes. A common misconception about Agile is that this approach stresses little or no upfront design. On large scale projects it is not feasible to design your system one iteration at a time, which may sound as if Agile is impossible in such scenarios. We have discovered that designing architecture in an Agile world is not only possible but leads to a better product for the customer. This presentation explores some pros and cons as well as successes and failures of using the Agile approach when designing large scale systems. This presentation also looks at approaches to doing the "right amount" of architectural design up front, while allowing room for inevitable changes as the system is being built.

Engineering Lessons for Systems of Systems Learned from Service-Oriented Systems
Soumya Simanta, Software Engineering Institute
Grace Lewis, Software Engineering Institiute
Dennis Smith, Software Engineering Institute
Ed Morris, Software Engineering Institute

There is an increasing trend towards interconnected systems of systems (SoS) that provide capabilities that are not available in a single system. Many organizations, including the DoD, are already implementing these SoSs. However, existing software and system engineering practices do not scale well to SoS. SoS engineering is still an open problem with significant challenges.

Understanding these challenges and providing engineering solutions will require a two pronged approach:

  • A top-down approach that deals with understanding SoS at an abstract level. This view is essential to understand the key concerns that exist in any SoS independent of the concrete technologies that are used to implement the SoS.
  • A bottom-up approach that focuses on abstracting the concepts and lessons learned from specific examples of engineering systems of systems.

Currently, the most common approaches for engineering software-intensive systems of systems are service-oriented architecture (SOA), grid computing, and cloud computing, all of which are distributed computing paradigms. In the future, newer technologies may replace or complement these existing engineering approaches.

This presentation focuses on the bottom up approach by exploring areas where lessons learned from implementation service-oriented systems are abstracted and applied to SoS.

Introducing Software Architecture Development Methods into a TSP-based Development Company
Humberto Cervantes, Universidad Autonoma Metropolitana - Iztapalapa
Isaac Martinez Aceves, Quarksoft
Jaime Castillo, Quarksoft
Carlos Montes de Oca, CIMAT

This presentation describes an ongoing project whose aim is to introduce software architecture development methods inside Quarksoft, a leading Mexican software development company certified at CMMi level 3. Software development inside Quarksoft is based on the Team Software Process (TSP). The architecture development methods that are being introduced are adaptations from SEI’s architectural methods but they also draw ideas from other sources. At the time of writing, the improvement project is at a stage where company-wide level deployment is being prepared.

The talk will provide an overview of the improvement project and discuss the challenges and lessons learned. It will focus particularly on the way the architecture development methods are adapted and introduced into the company’s TSP. Other relevant aspects associated to the improvement project will also be discussed, among them, the impacts of the improvement project in areas such as training, and the relationships with some CMMi process areas.

Lessons Learned Adapting an Existing Architecture in a Changing Business Landscape
Arthur Wright, Credit Suisse

This report briefly describes the Order Management and Routing System of a Major Swiss Bank, broaches some of the architectural changes that we made, and discusses the valuable lessons we learned as we faced up to a variety of people and technical challenges. Intended to replace an end of life mainframe based solution, the system had already been three years in the making when the assigned architect decided to move on, along with the entire user interface team. As a result, the majority of the team was fairly new (including its architect), and team collaboration was a crucial ingredient for a successful endeavor. We had to change the architecture to correct missed or partially implemented quality attribute requirements e.g. throughput, service times, and availability. At the same time we had to satisfy pressing business demand for new features, which also brought architectural changes in the form of new interfaces.

Enterprise Architecture for the Smart Grid: A Status Update
Elizabeth Sisley, University of Minnesota

The Smart Grid is the next generation of the energy grid, currently being designed to deliver significant improvements.  The necessary complexity involves many systems, products, and networks, all across many business and government entities.

The National Institute of Standards and Technology has "primary responsibility to coordinate development of a framework that includes protocols and model standards for information management to achieve interoperability of smart grid devices and systems..." under the Energy Independence and Security Act (EISA) of 2007.  NIST published their second draft of the NIST Interagency Report (NISTIR) in February, open for comments until June 1st.

Per Wikipedia, “An enterprise architecture (EA) is a rigorous description of the structure of an enterprise, its decomposition into subsystems, the relationships between the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise.”  Many of these aspects are included in the on-going Smart Grid efforts being led by NIST.  This presentation includes excerpts from the NISTIR, with discussion about their creation.

The next Minnesota Smart Grid event is also advertised.

Managing Software Interfaces of On-Board Automotive Controllers
Anthony Tsakiris, Ford Motor Company

This presentation describes an effort to commonize the software interfaces among embedded subsystem controllers in Ford Motor Company cars and trucks. We set out initially to reduce the variation in powertrain control system interfaces so that sharing hybrid and non-hybrid powertrains (engines, transmissions, and optionally electric machines and high voltage batteries) across vehicles, brands, and regions would be easier and faster. The scope expanded to include other domains as well -- chassis, body, climate, driver information, etc. The presentation provides a view of some challenges in re-architecting these control system interfaces within organizational and legacy-system constraints and some lessons learned on how to address those challenges.

Promoting Data-Centric Architectures
Michael Jaeger, Siemens AG
Uwe Hohenstein, Siemens AG
Gerald Kaefer, Siemens AG
Ravi Madipadaga, Siemens Software Laboratories India

We see the trend that applications keep on becoming more and more data intensive: the Internet keeps growing, applications process more data, and wired and wireless connections continue to provide more bandwidth. Technologies like cloud computing seem to confirm this trend. However, on the other hand, we see that current state-or-the-art paradigms like SOA focus on interfaces and their operations. Engineers start with modeling components or services and their operations. The design of the architecture is primarily influenced by functionality.

Our suggestion is that for data intensive problems, neglecting the data view is harmful. Thus, our aim is to promote the data view in order to design data-centric architectures. A software architect must 1) understand the implications from data modeling on the architectural design 2) know patterns of data centric architectures and 3) know existing technologies for implementing data centric architectures for building appropriate systems.

Quality Attribute Workshop Experiences and Reflections
Pia Stoll
Roland Weiss
Anders Wall

This presentation describes experiences and reflections we have made from performing Quality Attribute Workshops (QAW). at three different business units within ABB. All three systems are industrial software intensive systems. The cases we report from include both evolutionary development of a product and revolutionary development.

The findings are mainly related to the voting process in which scenarios are prioritized, but also the scenario generation process. Moreover, we have made observations concerning maturity of the organization in which the QAW is performed, the dynamics in the group of participants and management’s perception and acceptance of the outcome from the QAW. Our conclusion is that the different objectives and different set-ups of the QAW participants and their relation to each other have a direct relation to the outcome of the QAW voting procedure and to the management’s acceptance of the outcome.

The Use of Change Cases in Software System Architecting
J.D. Baker, Armstrong Process Group

Change cases were introduced in the book Designing Hard Software by Douglas W. Bennett. Bennett does a good job of identifying categories of change cases. Even if some of the specific examples seem a little out-dated, the concepts translate quite readily into problems being faced by systems under development today. What's missing is any indication of what the content of the change case should be, and how they should then be used in the evaluation of a software system architecture and design. This presentation is based on the author's experiences in multiple consulting engagements. It answers the question of what the content of a change case should be and how that content can be used throughout the course of architecture development. It discusses how change cases relate to the ATAM growth scenarios and how they can be employed in the development and assessment of software system architectures.

Using the Attribute-Driven Design for Automated Preventive Maintenance and Diagnosis of Complex Software Systems
Aldo Dagnino, ABB

The objective of this presentation is to discuss how mining historical data that contains key performance indicators associated with the health of a large-scale system can help in its architecture configuration. By analyzing trends in changes in the key performance indicators (KPI’s) knowledge about the health of the system can be determined. This system health knowledge used in conjunction with the principles of Attribute Driven Design (ADD) provides guidelines to make architectural changes into the configuration of a system. This presentation will outline how both the system health knowledge derived from data mining of KPIs and the ADD principles can contribute to finding new ways to configure the architecture of a system by paying special attention to key software qualities.

SATURN 2010 News

Sign up for a webinar on Agile development and software architecture
Nanette Brown will speak on Agile development and software architecture on April 22

Watch a video from SATURN 2009 at the SATURN Network Blog

Wayne Longcore, Chief Architect at Consumers Energy, to Keynote at SATURN 2010

SATURN 2010 Technical Program blog post
Conference technical chair Ipek Ozkaya talks about the SATURN 2010 technical program

Presentation by Len Bass linked on the SATURN Network Blog
Read about software architecture for acquisition people

Architecture certification track to be included in SATURN 2010

Jim Highsmith, Leader of the Agile Movement, to Keynote at SATURN 2010

Minneapolis Hilton chosen as conference site

Learn about the architecture of ultra-large-scale systems
Review the recent presentation given by SEI staffer Len Bass.

Watch a webinar on how to effectively evaluate software architecture and identify risks
This webinar was led by SEI staffer Felix Bachmann.

SATURN 2010 will be presented in collaboration with IEEE Software

SATURN 2010 For More Information
SATURN Call for Proposals
SEI Members receive 15% off conference fees. Click to join!

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.