April 29 to May 3, 2013
SATURN 2010 took place from May 17-21, 2010 in Minneapolis, MN. 160 attendees enjoyed tutorials, presentations, and keynote speeches on the SATURN 2010 theme of "Architecting for Change."
Architects: Accelerators or Anchors to Organizational Agility?
Jim Highsmith, Cutter Consortium
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.
Managing Scale and Agility: Transformational Architecture for the Smart Grid
Wayne Longcore, Consumers Energy
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?
Philippe Kruchten, University of British Columbia
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
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.
Architecture Certification Panel: SATURN 2010
Mark Klein, Software Engineering Institute
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.Download this presentation now.
Architecturally Focused Techniques for Managing System Evolution
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.
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.
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.Download this presentation now.
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 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.
Designing and Building Large-Scale Systems in an Agile World
Stevie Borne, Thomson Reuters
Dave Henricksen, 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 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.
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 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 easily 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.
Architecture Model Reconstruction Towards Change Scenario Evaluation
Heiko Koziolek, ABB Corporate Research
Emanuel Kolb, ABB Corporate Research
Jens Doppelhammer, ABB Corporate Research
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.
Promoting Data-Centric Architectures
Michael C. Jaeger, Siemens AG
Uwe Hohenstein, Siemens AG
Gerald Kaefer, Siemens AG
Ravi Madipadaga, Siemens Software Laboratories India
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.
Using the Attribute-Driven Design for Automated Predictive Maintenance and Diagnostics 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 (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.
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 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.
Engineering Lessons for Systems of Systems Learned from Service-Oriented Systems
Grace Lewis, Software Engineering Institute
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
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.
An Architectural Decision Modeling Framework for SOA and Cloud Design
Olaf Zimmermann, IMB 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 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.
Quality Attribute Workshop Experiences and Reflections
Pia Stoll, ABB
Roland Weiss, ABB
Anders Wall, ABB
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.
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 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.
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 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.
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 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.
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, 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.
April 29 – May 3, 2013
Get the latest SATURN news, important dates, and announcements on the SATURN Network blog, sign up for our email updates, follow us on Twitter (@SATURN_News, #SATURN2013), and join the SATURN LinkedIn Group.
Phone: +1 412-268-5800
Toll Free (within the USA): +1 888-201-4479
FAX: +1 412-268-6257
Please tell us what you
think with this short
(< 5 minute) survey.