May 7-11, 2012 | St. Petersburg, FL
T1: Software Architect 101
Peter Eeles, IBM Rational
This tutorial provides attendees with a solid grounding in all aspects of software architecture. Taking a process-centric approach, the tutorial will first examine some key concepts, including the role of the architect, approaches to managing risk and change, communication with stakeholders, and reuse. This is then followed by a “day in the life” of a software architect in terms of the tasks in which they are typically involved. The tutorial concludes with a consideration of the broader context, focusing on elements that are typically outside of the architect’s influence, but of which the architect should be aware. Attendees will leave with a framework on which they can build a deeper understanding of the role of the architect. Given the theme of the conference, the discussion will also place a focus on both Agile and collaboration and their relevance to software architects.
T2: Effective Stakeholder Collaboration
John Klein, Software Engineering Institute
A system may have hundreds or even thousands of requirements, but experienced architects know that just a handful of architecturally significant requirements, usually focused on quality attributes, drive the architecture design. A challenge for architects is to collaborate with stakeholders to develop actionable quality attribute requirements–to understand what stakeholders really mean when they say that the system must have “high availability” or “be very responsive.”
The SEI has developed several methods that address the challenges of eliciting and specifying actionable quality attribute requirements. These methods complement approaches such as use cases and business process models used to elicit and specify functional requirements, and are applicable for application, system, and enterprise architectures. These methods use concrete scenarios and specific business threads to help technical and non-technical stakeholders express their quality attribute requirements in a way that an architect can use those requirements to make design decisions and tradeoffs.
This tutorial is for architects, business analysts, systems engineers, product managers—anyone involved in defining system requirements. Attendees will learn
We will use examples drawn from industrial experience. Teaching will occur through lectures, individual exercises, and group exercises.
T3: Integrating Software Architecture-Centric Methods into Object-Oriented Analysis and Design
Raghu Sangwan, Penn State
The choice of methodology for the development of the architecture for software systems has a direct effect on the suitability of that architecture. If the development process is driven by the user’s functional requirements, we would expect the architecture to appropriately reflect those requirements. We would also expect other aspects not captured in the functional specification to be absent from the architecture. The same phenomenon occurs in development approaches that stress the importance of systemic quality attributes or other non-functional requirements; these requirements are prominent in the resulting architecture, while other requirement types not stressed by the approach are absent. In other words, the final architecture reflects the focus of the development approach. An ideal approach, therefore, is one that incorporates all goals, expectations, and requirements: both business and technical.
To accomplish this we have incorporated, into a single architectural development process, generalized Object-Oriented Analysis and Design (OOAD) methodologies with the software architecture-centric methods, the Quality Attribute Workshop (QAW) and Attribute Driven Design (ADD). OOAD focuses heavily on functional requirements and has the benefit of semantic closeness to the problem domain, making it an intuitive process with comprehensible results. Architecture-centric approaches, on the other hand, provide explicit and methodical guidance to an architect in creating systems with desirable qualities and goals. They provide minimal guidance in determining fine-grained architecture, however. The integrated approach described in this tutorial maximizes the benefits of the respective processes.
T4: Architectural Implications of Cloud Computing
Grace Lewis, Software Engineering Institute
As defined by National Institute of Standards and Technology (NIST), cloud computing is “a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” Cloud computing is being adopted by commercial, government, and DoD organization as a way to reduce the operational cost of information technology (IT) because resources are scalable and billed on a usage basis as opposed to acquired and maintained. However, for a software architect cloud computing means that elements of a system or solution may reside outside the organization and therefore systems have to be designed and architected to account for lack of full control over important quality attributes. This tutorial will start by briefly defining cloud computing, service models, deployment models, and drivers and barriers for cloud computing adoption. It will then focus on architecture and design decisions that are critical for the cloud, such as data location and synchronization, user authentication models, and multi-tenancy support. Finally, it will conclude with a discussion of architecture tactics for cloud computing environments.
T5: Architecturally Evident Coding Style
George Fairbanks, Rhino Research
Because of Eric Evans’ Domain Driven Design, software developers are already familiar with embedding their domain models in their code. But the architecture and design are usually hard to see from the code. How can you improve that? This tutorial describes an architecturally evident coding style that lets you drop hints to code readers so that they can correctly infer the design. You will learn why some design intent (the intentional part) is always lost between your design/architecture and your code. It builds on ideas such as Kent Beck’s Intention Revealing Method Name pattern and provides a set of lightweight coding patterns and idioms that let you express your design intent in the code.
T6: Strategic Management of Technical Debt
Rod Nord, Software Engineering Institute
Ipek Ozkaya, Software Engineering Institute
The "technical debt" metaphor acknowledges that development teams sometimes accept compromises in one dimension of a system (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises cause the system to incur a "debt." If not properly managed, the interest on this debt may continue to accrue, severely hampering system stability and quality and impacting the team's ability to deliver enhancements at a pace that satisfies business needs.
Although unmanaged debt can have disastrous results, strategically managed debt can help businesses and organizations take advantage of time-sensitive opportunities, fulfill market needs, and acquire stakeholder feedback. Because architecture has such significant leverage within the overall development life cycle, the strategic management of architectural debt is of primary importance.
This tutorial will
T7: Software Architecture Evolution and Improvement
Michael Stal, Siemens Corporate Research
The old Greek philosopher Heraklitus once said, "Nothing is permanent except change." This especially holds for software architecture design, which has to cope with changes of all kinds. For example, requirements change, or are better understood in later stages; technologies evolve; business strategies are subject to adaptation; bugs appear. Moreover, in an Agile development approach, dealing with change represents the karma of the process itself. Architects are facing the challenge of how to keep their design in good shape despite of all these modifications. The question is how to systematically cope with change. This tutorial will address architecture assessment, refactoring, reengineering, and rewriting as important means for dealing with change. Attendees will learn how to assess, evolve, and improve architecture quality.
T8: Designing Secure Architectures Using Security Patterns
Ed Fernandez, Florida Atlantic University
Patterns combine experience and good practices to develop basic models that can be used to build new systems and to evaluate existing systems. Security patterns join the extensive knowledge accumulated about security with the structure provided by patterns to provide guidelines for secure system design and evaluation. In this tutorial, we consider the structure and purpose of security patterns, show a variety of security patterns, and illustrate their use in the construction of secure systems. These patterns include among others Authentication, Authorization, Role-based Access Control, Firewalls, Secure Broker, and Web Services Security. We have built a catalog of 70 security patterns. We introduce patterns in a conceptual way, relating them to their purposes and to the functional parts of the architecture. We show how to apply these patterns through a secure system-development methodology. Example architectures include a financial system and a SCADA system. Patterns can be applied throughout the lifecycle and provide an ideal communication tool for the builders of the system. They are also useful to record design decisions. We compare our approach to approaches based on tactics. The patterns are shown using UML models and some examples are taken from my two books on security patterns.
SATURN 2012 Conference
May 7-11, 2012
Get the latest SATURN news, important dates, and announcements on our blog, signing up for our e-mail updates or following us on LinkedIn.
SEI Customer Relations
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.