SATURN 2014 Tutorials

The SATURN software architecture conference returns in May 2014 with another enlightening and engaging technical program.

Tutorials

See SATURN 2014 Tutorials Chair Neil Ernst's summary of tutorials

Use these links to go directly to each tutorial:

T1: Architecture Hoisting

George Fairbanks, Google

Tuesday, May 6, 8:30-12:00

Architecture hoisting is a design technique for achieving a non-local property. When developers want a system to achieve a non-local property like security, performance, or scalability, they can accomplish this either through vigilant coding throughout the program or by architectural hoisting. When they hoist a property, they hand the responsibility for achieving it to the architecture, reducing or eliminating the need for developer vigilance. Sometimes a property can be hoisted by following an architectural style, but more often there will be code devoted to the architecture and specifically to achieving that property, as is seen in examples such as application servers, garbage collectors, and map-reduce frameworks.

T2: Architecture-Centric Techniques for Reducing Deployment Cycle Time: Designing the Architecture Foundation to Support DevOps Goals

Stephany Bellomo and Rick Kazman, Carnegie Mellon Software Engineering Institute

Tuesday, May 6, 8:30-12:00

Growing pressure to reduce development cycle time and improve the reliability of incremental software delivery has driven collaboration between software and operational communities and motivated movements such as DevOps and Release Engineering (RELENG). The DevOps community emphasizes collaborative teaming, process streamlining, and tool automation. While these are important, architecture also plays a critical role in achieving reduced deployment cycle time. A common anti-pattern occurs when organizations rush to purchase the latest build and deployment-management tools and invest in cloud/virtualized environments, yet they fail to architect systems that enable continuous integration or shorten development cycle time. For example, short build time, which enables continuous integration, is often impeded by lack of attention to component dependencies, resulting in significant refactoring. The goal of this tutorial is to familiarize participants with pitfalls that impede DevOps goals and guide participants as they apply techniques. The tutorial is delivered in two modules. The first module addresses questions such as What is DevOps? What are examples of deployability goals and anti-patterns? How might cycle time goals vary by project type? The second module goes deeper into the technical aspects to apply architectural patterns and tactics that support deployability-related quality attribute scenarios derived from experiences of organizations that succeed in rapid deployment.

(NOTE: Tutorials T2 and T3 contain limited overlapping content--primarily brief, introductory material. They may be taken together or separately).

T3: System Design Consequences of Using DevOps Practices

Len Bass, NICTA

Tuesday, May 6, 1:00-4:30

DevOps is a collection of practices intended to smooth handoffs between developers and operations staff. Some of the practices are as simple as ensuring that operations has input into requirements for a system; others are as complicated as ensuring that a developer has a tool chain to enable automated deployment and monitoring of an application without the necessity for human intervention. One element of both of these practices is that they affect the design of the system being constructed. The requirements that come from the operations staff might affect the type and semantics of log messages. The requirements that come from using continuous deployment include ensuring that components are version-aware. This tutorial will cover the requirements/build/deploy/monitor life cycle affected by DevOps practices, identify system requirements created by the use of DevOps practices, and present architectural patterns that satisfy those requirements.

(NOTE: Tutorials T2 and T3 contain limited overlapping content--primarily brief, introductory material. They may be taken together or separately).

T4: All About NoSQL

Pradyumn Sharma, Pragati Software Pvt. Ltd.

Tuesday, May 6, 1:00-4:30

NoSQL database platforms have evolved and matured very well and are a good bet not only for public websites with enormous amounts of data but also for enterprise applications. With their flexible data models, high scalability, high availability, and relative ease of administration, they are a serious alternative to the relational database model for many—but not all—applications. This tutorial will provide a detailed understanding of the key concepts of NoSQL databases from an architect's perspective. It will include

  • fundamental principles of NoSQL databases
  • introduction to four types of NoSQL databases: Column Family, Key Value, Document Store, and Graph
  • architectural overview and key features of some of the leading NoSQL databases: Cassandra, MongoDb, Riak, and Neo4
  • comparison among the four types and understanding when a particular type of NoSQL database is suitable and when it is not
  • limitations of NoSQL databases
  • emergence of polyglot persistence
  • real-world examples of using the NoSQL databases

T5: Agile Solution Architecting

Eltjo Poort, CGI

Tuesday, May 6, 1:00-4:30

The secret of making architecting agile is to change your view of your main deliverable. An agile software development team delivers not a "big-bang" system but a continuous stream of improvements to a system. In the same way, an agile architect delivers not a big, up-front design but a continuous flow of architectural decisions, step by step gaining control of the uncertainties and risks surrounding complex IT solutions. In this tutorial, we will discuss and exercise key principles and practices for architects to accommodate the level of responsiveness needed in today's fast-moving world. These practices help architects embrace change and reconnect with their colleagues who have "gone agile." They can be applied in both agile (SCRUM, SAFe) and more conventional settings, without forcing teams to adopt a completely new process. The tutorial is based on Risk- and Cost-Driven Architecture (RCDA), an approach that has been developed by CGI and has proven to support solution architects globally in a lean and agile manner. RCDA's practices help architects to create "just-enough" architecture in tight time frames and explain their priorities and choices to business stakeholders. RCDA is a recognized architecture method in The Open Group's architect certification program.

T6: Being Agile About System Qualities

Rebecca Wirfs-Brock, Wirfs-Brock Associates

Friday, May 9, 8:30-12:00

Prioritizing and implementing necessary functionality keeps an agile project moving forward. But in a sprint to deliver features, agile teams can overlook software qualities. By focusing only on functionality, the security, scalability, performance, and reliability concerns can get shoved aside or wistfully imagined as emerging along with the architecture. But what if you need to pay more attention to system qualities? How can you interject quality specification, design, and testing efforts into your project and be more agile about it? This tutorial introduces agile techniques and practices that support the definition and delivery of system qualities. You'll practice writing agile quality scenarios and quality-related acceptance criteria. You'll see how an agile landing zone differs from a traditional product landing zone. You will learn techniques for weaving quality-related work into your product backlog and for making quality objectives visible and tangible. Features don't make a viable system; features accompanied by attention to system qualities do.

T7: Architecture Katas

Ted Neward, Neward Associates

Friday, May 9, 8:30-12:00 and 1:00-4:30

Fred Brooks said, "How do we get great designers? Great designers design, of course." So how do we get great architects? Great architects architect. But architecting a software system is a rare opportunity for the non-architect. The kata is an ancient tradition, born of the martial arts, designed to give students the opportunity to practice more than basics in a semi-realistic way. The coding kata, created by Dave Thomas, is an opportunity for developers to try a language or tool to solve a problem slightly more complex than "Hello world." The architectural kata, like the coding kata, is an opportunity for student-architects to practice architecting a software system. In this session, attendees will divide into small groups to consider a real-world business problem (the kata is available at http://archkatas.herokuapp.com). Attendees will formulate an architectural vision for the project, ask questions of the instructor to better understand the requirements, defend questions posed by both the instructor and their fellow attendees about their choices in technology and approach, and then evaluate others' efforts in a similar fashion. No equipment (other than one Internet-connected device to get the kata off the website above) is necessary to participate—great architects have no need of tools, just their minds and the customers' participation and feedback.

T8: Iteration Planning

Philippe Kruchten, University of British Columbia

Friday, May 9, 1:00-4:30

Iteration planning is the decision process by which we decide what we will do next in a software project, for the best of its stakeholders, and in the face of all the uncertainties inherent to such an endeavor. While a simple strategy can focus on delivering value, this rapidly becomes much more complicated when we consider dependencies, value and cost, software architecture work, defects, technical debt, the uncertainties of estimation, multiple stakeholders to satisfy, and the impact of time. This tutorial starts by playing a simulation game, Mission to Mars, to illustrate the concepts and issues in planning a project as a succession of iterations. In the second half of the tutorial, we draw lessons from the simulation and examine the various elements at play in planning iterations.


Stay Connected

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, #SATURN14), and join the SATURN LinkedIn Group.

SATURN Blog RSS Saturn - LinkedIn SATURN - TWITTER
SEI Customer Relations

Phone: +1 412-268-5800
Toll Free (within the USA):  +1 888-201-4479
FAX: +1 412-268-6257
E-mail:
info@sei.cmu.edu


Help us improve

Visitor feedback helps us continually improve our site.

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