SATURN 2010 Presentations

This file contains presentations from the SEI Software Architecture Technology User Network Workshop (SATURN 2010) event (May 17-21, 2010, in Minneapolis, Minnesota).

Sessions and presentations included:

*Agile Architecting: Using Agile Principles to Agilitize the Architecting Process, Amine Chigani
*An Architectural Decision Modeling Framework for SOA and Cloud Design, Olaf Zimmermann
*Architects: Accelerators or Anchors to Organizational Agility?, Jim Highsmith
*Architecturally Focused Techniques for Managing System Evolution, William Koscho
*Architecture and Agile, Friends or Enemies?, Ger Schoeber
*Architecture Certification Panel: SATURN 2010, Mark H. Klein
*Architecture Model Reconstruction Towards Change Scenario Evaluation, Heiko Koziolek, Emanuel Kolb, and Jens Doppelhamer
*Assessing Commercial Off-the-Shelf Software in Industry Using ATAM and RUP Analysis, Marcel Derosier
*Cloud Computing Architecture, Gerald Kaefer
*Designing and Building Large-Scale Systems in an Agile World, Stevie Borne and Dave Hendricksen
*Enterprise Architecture for the Smart Grid: A Status Update, Elizabeth Sisley
*Introducing Software Architecture Development Methods into a TSP-Based Development Company, Isaac M. Aceves, Jaime Castillo, Humberto Cervantes, and Carlos M. de Oca
*Lessons Learned Adapting an Existing Architecture in a Changing Business Landscape, Arthur Wright
*Lessons Learned from Service-Oriented Systems for Engineering Systems of Systems, Grace Lewis
*Managing Scale and Agility: Transformational Architecture for the Smart Grid (Keynote), Wayne Longcore
*Managing Software Interfaces of On-Board Automotive Controllers, Anthony Tsakiris
*Promoting Data-Centric Architectures, Uwe Hohenstein, Michael Jaeger, Gerald Kaefer, and Ravi Madipadaga
*Quality Attribute Workshop Experiences and Reflections, Pia Stoll, Anders Wall, and Roland Weiss
*Software Architecture and Agility: A Clash of Two Cultures?, Philippe Kruchten
*The Architect as Change Agent, Linda Rising
*The Use of Change Cases in Software System Architecting, J.D. Baker
*Using the Attribute-Driven Design for Automated Predictive Maintenance and Diagnostics of Complex Software Systems, Aldo Dagnino








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

Agile is a philosophy (or a way of thinking) rather than 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 eadily 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

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





Architects: Accelerators or Anchors to Organizational Agility?, Jim Highsmith

A 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 throes 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 from SATURN 2010 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.





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 and 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

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 foundation and the agile development principles to come to a multi-disciplinary and multisite development process. I will introduce how to arrive at a good balance between stability and agility, and I will explain how agility can be applied in software development, as well as 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 Certification Panel: SATURN 2010, Mark H. Klein

SATURN 2010 included a panel discussion on architecture certification. We see the panel as an opportunity to explore the state of practice in architecture certification. This includes organizations that offer their internal certificate programs as part of a career ladder (e.g., Siemens, Raytheon), organizations with extensive architecture training and know-how, like the SEI, and external organizations like IASA.




Architecture Model Reconstruction Towards Change Scenario Evaluation, Heiko Koziolek, Emanuel Kolb, and Jens Doppelhamer

Software architecture reconstruction helps architects to redocument existing systems and to check code conformance. Existing methods 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 change scenarios shall be possible so that architectural tradeoffs 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

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 shortcomings are discovered late in the process, can often impact the business advantages of a faster time-to-market. Using the Architecture Tradeoff Analysis Method (ATAM) in conjunction with high-level analysis artifacts based on modified Rational Unified Processes (RUPs) 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

The emerging field of cloud computing provides promising opportunities for saving cost and improving efficiency with enterprise applications. However, using cloud computing also implies new application architecture and brings new business models, and it creates security concerns resulting from off-organization hosting. These issues pose several challenges when building new cloud computing applications. Most especially, cloud platforms will lessen the gap between software architecture and IT architecture and will thereby increase the responsibility of software architecture. The result is that software architects must improve their knowledge and experience in 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 and Dave Hendricksen

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





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

The Smart Grid is the next generation of the energy grid, which is 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 1.

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






Introducing Software Architecture Development Methods into a TSP-Based Development Company, Isaac M. Aceves, Jaime Castillo, Humberto Cervantes, and Carlos M. de Oca

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 being introduced are adaptations from the 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 companywide 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 with 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

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. 




Lessons Learned from Service-Oriented Systems for Engineering Systems of Systems, Grace Lewis

There is an increasing trend towards interconnected systems of systems (SoSs) 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 SoSs. 

Currently, the most common approaches for engineering software-intensive SoSs 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 of service-oriented systems are abstracted and applied to SoS.





Managing Scale and Agility: Transformational Architecture for the Smart Grid (Keynote), 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.





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

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, Uwe Hohenstein, Michael Jaeger, Gerald Kaefer, and Ravi Madipadaga

Applications keep becoming more and more data-intensive: the Internet keeps growing, applications process more data, wired and wireless connections continue to provide more bandwidth, and technologies like cloud computing seem to confirm this trend. However, on the other hand, we see that current state-of-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 datacentric architectures. A software architect must understand the implications from data modeling on the architectural design, know patterns of data-centric architectures, and know existing technologies for implementing data-centric architectures for building appropriate systems.





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

This presentation describes experiences and reflections we have made from performing Quality Attribute Workshops (QAWs) at three different business units within ABB. All three systems are industrial software-intensive systems. The cases we report on 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 can also relate to 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.





Software Architecture and Agility: A Clash of Two Cultures?, Philippe Kruchten

Software architecture is taking a bad rap with the agilists and other 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;” these are common claims made about software architecture when it is portrayed as a typical nonagile practice. However, in certain classes of systems, ignoring architectural issues for too long causes teams to “hit a wall” and collapse from a lack of architectural focus. But isn’t “Agile architecture” a paradox or an oxymoron? Aren’t they two totally incompatible approaches?

In this lecture, we will review the real issues at stake, move 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, attempt to assign actual value to an otherwise invisible architecture, and 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, 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.




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

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 outdated, 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 Predictive Maintenance and Diagnostics of Complex Software Systems, Aldo Dagnino

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 (KPIs), knowledge about the health of the system can be obtained. 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.
