SATURN 2014 Program

May 5, 2014

7:30 AM - 5:00 PM Registration
7:30 AM - 8:30 AM Morning Beverages *
Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.
8:30 AM - 5:00 PM Course: Software Architecture Design and Analysis, Day 1 of 2

Software Architecture Design and Analysis, Day 1 of 2 

This two-day course provides in-depth coverage of the concepts needed to effectively design and analyze a software architecture. The essential considerations for defining any architecture are carefully examined and then illustrated through application of SEI methods. Through multiple exercises, participants study an application of these methods and get a chance to apply them to sample problems.

Robert Wojcik

Robert Wojcik
Carnegie Mellon University, Software Engineering Institute

8:30 AM - 5:00 PM Course: Advanced Software Architecture Workshop

Advanced Software Architecture Workshop

You can now directly put into practice your knowledge of successful architecture principles through the Advanced Software Architecture Workshop. In this workshop, you will apply what you've learned in other architecture courses offered by the Software Engineering Institute (SEI) to a concrete architecture problem.

Despite consensus among SEI course participants that architecture-centric engineering skills are valuable, the chance to incorporate these skills is not always available. Organizational infrastructure, culture, and deadline pressures that don't leave time for introducing process change can impede adoption of new practices. Decisions on what architecture-centric tasks to perform to what level of detail are always project dependent and difficult to make.

Many organizations have embraced architecture-centric engineering methods and specifically software architecture practices to mitigate risk. The Advanced Software Architecture Workshop is designed to expedite the adoption of architecture-centric practices for all organizations. The goals of the course are for participants to become comfortable with the SEI architecture-centric engineering methods and able to use those methods effectively in their organizations. Course content is based on the SEI books Software Architecture in Practice, 3rd Edition, and Documenting Software Architectures: Views and Beyond, 2nd Edition.

SEI-trained software architects practice their skills in a concrete and practical setting. Using an actual architecture as an example, participants select a problematic scenario for the system, examine the possible weak points of the software architecture, decide on appropriate mitigations, review their proposed changes in groups, and revise the architecture as required.

Felix Bachmann

Felix Bachmann
Carnegie Mellon Software Engineering Institute

10:00 AM - 10:30 AM Morning Break
12:00 PM - 1:00 PM Lunch
3:00 PM - 3:30 PM Afternoon Break
7:00 PM - 9:00 PM Presentation: Open Systems: What's Old Is New Again

Portland Software Process Improvement Network (SPIN) meeting co-located with SATURN. SATURN attendees invited.

Organization executives and managers continue to be challenged to achieve greater acquisition efficiency and cost savings, while understanding a myriad of issues and promoting smart system decision making. The use of an open systems approach is coming back to help with today's realities and tomorrow's possibilities. To adapt to changing circumstances, executives and managers need practical definitions, the basics of an open systems approach, and an understanding of the issues, as well as things to look for in programs as they transition to an open systems approach. This presentation will discuss the definitions, approach, and basics of open systems. It will relate the concepts to current technology trends and the implications of disruptive technologies and provide attendees with high-level understanding and appreciation of what it means to transition to an open systems approach for system acquisition.

Patricia Oberndorf

Patricia Oberndorf
Carnegie Mellon Software Engineering Institute


* Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.

May 6, 2014

7:30 AM - 5:00 PM Registration
7:30 AM - 8:30 AM Morning Beverages *
Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.
8:30 AM - 5:00 PM Course: Software Architecture Design and Analysis, Day 2 of 2

Software Architecture Design and Analysis, Day 2 of 2

This two-day course provides in-depth coverage of the concepts needed to effectively design and analyze a software architecture. The essential considerations for defining any architecture are carefully examined and then illustrated through application of SEI methods. Through multiple exercises, participants study an application of these methods and get a chance to apply them to sample problems.

Robert Wojcik

Robert Wojcik
Carnegie Mellon University, Software Engineering Institute

8:30 AM - 5:00 PM Course: Big Data - Architectures and Technologies

Big Data – Architectures and Technologies

Participants will learn

  • the major elements of big-data software architectures
  • the different types and major features of NoSQL databases
  • patterns for designing data models that support high performance and scalability
  • an introduction to the LEAP4BD method for rigorous evaluation of big-data technologies and architectures approaches

This one-day course is designed for architects and technical stakeholders such as product managers, development managers, and systems engineers involved in the development of big-data applications. It focuses on the relationship among application software, data models, and deployment architectures and how specific technology selection relates to all of these.

Ian Gorton

Ian Gorton
Carnegie Mellon Software Engineering Institute

John Klein

John Klein
Carnegie Mellon Software Engineering Institute

8:30 AM - 12:00 PM
Half-Day Tutorials, Morning Sessions
T1: Architecture Hoisting

T1: Architecture Hoisting

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

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

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 modules 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).

Stephany Bellomo

Stephany Bellomo
Carnegie Mellon Software Engineering Institute

Rick Kazman

Rick Kazman
Carnegie Mellon Software Engineering Institute

10:00 AM - 10:30 AM Morning Break
12:00 PM - 1:00 PM Lunch
1:00 PM - 4:30 PM
Half-Day Tutorials, Afternoon Sessions
T3: System Design Consequences of Using DevOps Practices

T3: System Design Consequences of Using DevOps Practices

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

Len Bass

Len Bass
NICTA

T4: All About NoSQL

T4: All About NoSQL

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 Neo4j
  • 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
Pradyumn Sharma

Pradyumn Sharma
Pragati Software Pvt. Ltd.

T5: Agile Solution Architecting

T5: Agile Solution Architecting

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.

3:00 PM - 3:30 PM Afternoon Break
6:30 PM - 9:30 PM Open Space Night: Sticky Situations in Software Architecture: Dealing with Hard Problems

Sticky Situations in Software Architecture: Dealing with Hard Problems

Post-conference surveys and informal feedback have indicated that SATURN attendees value the opportunity to network and to share experiences with peers and colleagues each year at SATURN. In response, the program committee has built into the program an Open Space event, which will run concurrently with the rest of the conference. Open Space at SATURN 2014 begins with this kickoff event, facilitated by Diana Larsen of FutureWorks Consulting, an experienced facilitator of Open Space events. The theme of Open Space at SATURN 2014 is "Sticky Situations in Software Architecture: Dealing with Hard Problems." Open Space has no set program; participants will bring what excites them. It might be a recurring problem, an innovative solution, or any topic of interest to software architects on this year's theme. Open Space will allow participants to create and attend sessions on topics of their own choosing, even topics that arise at the conference itself.

Diana Larsen

Diana Larsen
FutureWorks Consulting, LLC


* Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.

May 7, 2014

7:30 AM - 5:00 PM Registration
7:30 AM - 8:30 AM Morning Beverages *

Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant. 

8:30 AM - 9:00 AM Welcome and Opening Address
9:00 AM - 10:00 AM Keynote Address: Refactoring, Reuse, and Reality--Revisited

Refactoring, Reuse, and Reality-Revisited

What are the four key reasons why software developers might be reluctant to refactor their code-even if they think refactoring is, at least in the abstract, a good idea? How might one effectively address those concerns?

These four concerns, and the means for addressing them, have applicability far beyond refactoring. In this talk, I'll discuss these lessons learned in a refactoring context and how they subsequently helped me as an architect and in other roles.

Bill Opdyke

Bill Opdyke
JPMorgan Chase

10:00 AM - 10:30 AM Morning Break
10:30 AM - 12:00 PM Sessions
Insights in Evolution

Pradyumn Sharma

Moderated by: Pradyumn Sharma
Pragati Software Pvt. Ltd.

technology
Past, Present, and Future of APIs for Mobile and Web Apps

Past, Present and Future of APIs for Mobile and Web Apps

Download PDF

Many companies today are moving Web application programming interfaces (APIs) to the core of their technology and business strategies, requiring them to build APIs that are both highly competitive and appealing to consumers. Given the rapid evolution of API technologies and consumer expectations, making the right choices when building and consuming these APIs is no easy task. Chief Architect Ole Lensmar digs into the diverse mix of historic, current, and upcoming technology trends in APIs for Web and mobile apps-including CORBA, Thrift, XML-RPC, and WebSockets-and gives hands-on advice about making the right technology and implementation choices for both API providers and consumers.

Ole Lensmar

Ole Lensmar
SmartBear Software

technology
Making a Language Switch: Moving from Sawzall to Go for Search Logs Analysis at Google

Making a Language Switch: Moving from Sawzall to Go for Search Logs Analysis at Google

We recently moved from a domain-specific language for logs processing (Sawzall) to a general-purpose language (Go). Any decision to rewrite lots of code should not be taken lightly. A key goal was to move to a new design paradigm for how logs analysis code at Google was written. The decision process forced us to evaluate what abstractions were valuable, how those abstractions changed the ways that engineers and analysts thought about the problem, and what we hoped to gain by the change. Many concerns surfaced, including security, efficiency, developer velocity, developer learning curves, and future adaptability. In this talk, I'll describe how we surfaced these concerns and worked through the ways that our architectural choices and the features of the language would affect our final outcome. Not to give away the punch line, but we're quite pleased with the move and believe that the experience provides a good model for others to follow. Learning outcomes of this session include understanding an example of successful technology evaluation in a business setting, with a few lessons learned for doing similar technology evaluations in other forms.

Patrick Riley

Patrick Riley
Google

technology
JavaScript, the Cloud, and the New Virtual Machine

JavaScript, the Cloud, and the New Virtual Machine

How does the rise of JavaScript change how we architect large systems? How does a pervasive elastic cloud change how we build web systems? How might we build large systems today if we could ignore the last 20 years and focus on fundamentals? Join Scott Hanselman in this "edutaining" talk as he juxtaposes yesterday's web with tomorrow's.

Scott Hanselman

Scott Hanselman
Microsoft

Customer Collaboration

Rebecca Wirfs-Brock

Moderated by: Rebecca Wirfs-Brock
Wirfs-Brock Associates

Methods & tools
Software Architecture in the Presales Process

Software Architecture in the Presales Process

Download PDF

Watch video

Quarksoft is a Mexican software-development company at Capability Maturity Model Integration Level 5 and develops custom software for government and private sectors in diverse domains using the Personal Software Process and Team Software Process. Although Quarksoft uses architecture practices during the development of software systems, we have found another moment in the life cycle of a project when these practices provide great value-the presales process. The presales process occurs when a customer requests a technical and economic proposal for developing a software system. The customer's acceptance of the proposal results in building the software system. The technical proposal is developed in a short time, so usually only high-level requirements can be gathered. A software architect uses these high-level requirements to produce an initial architecture that, along with historical data, is used to estimate the project. Developing this initial architecture involves important decisions, such as selecting reference architecture, technologies, and the method of deploying the application. Furthermore, the estimate provided to the customer is typically fixed, so there is great interest in producing a good solution in a short time. In the last year, we worked to adapt architectural practices that are currently used in a development project to produce the initial architecture for the presales process. In this talk, we discuss these practices and our encouraging results.

Humberto Cervantes

Humberto Cervantes
Universidad Autonoma Metropolitana-Iztapalapa

Methods & tools
Facilitating the Mini-Quality Attributes Workshop

Facilitating the Mini-Quality Attributes Workshop

Download PDF

Watch video

What if you could reduce cost for a Quality Attributes Workshop (QAW) without sacrificing results? For software-development teams that need an effective yet inexpensive method for eliciting quality requirements with stakeholders, the mini-QAW is a lean workshop that quickly and cost-effectively helps teams identify and prioritize quality attribute scenarios. Unlike the traditional QAW, the mini-QAW substitutes time-consuming, ceremonial activities with equally effective group activities that better promote collaboration and understanding as quickly and cheaply as possible. The mini-QAW achieves this through a quality attributes taxonomy, a clearly defined subset of quality attributes tuned to the presumptive concerns of your stakeholders. The mini-QAW leverages this taxonomy in three primary ways:

  1. Quality attributes defined in the taxonomy form the basis for a structured brainstorming activity called the System Properties Web.
  2. The taxonomy enables an informative visualization that allows stakeholders to see the "quality signature" of their system.
  3. A taxonomy-based questionnaire (TBQ) allows facilitators to reliably and predictably elicit good quality attribute concerns from stakeholders.

In this presentation, we describe the mini-QAW, provide concrete examples, and share advice for facilitating workshops based on our experiences conducting mini-QAWs. Attendees will gain the knowledge necessary to facilitate a mini-QAW, tailor a quality attributes taxonomy, and create a TBQ to fit their specific needs.

Methods & tools
Experience of Combining the QAW and Social Listening for Better Architecture

Experience of Combining the QAW and Social Listening for Better Architecture

The Quality Attribute Workshop (QAW) is a facilitated method of engaging stakeholders to discover driving quality attributes (QAs). To avoid missing important QAs, we would need to have all stakeholders in the QAW. For Samsung, a consumer electronics maker, consumers are our crucial stakeholders, but we could not invite them all to our QAW in the product-development phase. To mitigate the risk of not having the customers in our QAW, we introduced the social-listening technique to our QAW method and built a data analysis system for a social network service. Our system gathers Twitter users' tweets, analyzes them, and generates reports on keywords related to our products. Instead of hearing from real customers in person, we could hear their voices through Twitter very efficiently and turn them into significant QAs. We could not only identify the QAs that customers are most interested in but also capture new QAs that were not elicited by QAW participants. In this presentation, we present our system's details and real project data to discuss the strengths and weaknesses of our QAW combined with the social-listening method.

Seung Ho Nam

Seung Ho Nam
Samsung Korea

Architectural Modeling

Raghvinder Sangwan

Moderated by: Raghvinder Sangwan
Pennsylvania State University

Methods & tools
Expanding Legacy Systems Using Model Driven Engineering (MDE)

Expanding Legacy Systems Using Model-Driven Engineering (MDE)

Download PDF

Watch video

Applying model-driven engineering (MDE) to develop software architecture for a new project is challenging. Using the same technique for an existing project is even harder. Add the complexity of developing on top of an existing legacy avionics software system, and it seems like moving a mountain. However, it is achievable! Many software systems do not have existing models. Furthermore, a legacy system may be huge, and building a model for it is not a realistic goal. In a time of financial belt-tightening, customers want to be involved in all parts of the design and development process to ensure that their money is spent wisely. They often require a company to use the MDE approach to develop the architecture of their product because it is easy to understand. Thus, they can monitor the progress of the project to make sure it is on target before development begins. So how can projects being built on top of colossal legacy software systems adopt the MDE approach? We will cover 

  • managing technical debt while expanding the capabilities of an existing system
  • using MDE to reflect the combined architecture of both legacy and new functionality to satisfy customers' requirements
  • personal experience, pitfalls encountered, and results
William Smith

William Smith
Northrop Grumman

Kevin Nguyen

Kevin Nguyen
Northrop Grumman

Methods & tools
Identifying and Protecting Architecturally Significant Code

Identifying and Protecting Architecturally Significant Code

Download PDF

Watch video

As a software system grows in size, it becomes progressively difficult for programmers to understand the underlying architectural intent and to extract the architectural knowledge they need to implement changes successfully. Unfortunately, anecdotal evidence has shown that such knowledge tends to be tacit, stored in people's heads, and scattered across software artifacts and repositories. Furthermore, architectural knowledge has a tendency to vaporize over time. Given the size, complexity, and longevity of many projects, developers often lack a comprehensive knowledge of architectural design decisions and make changes in the code that inadvertently degrade the underlying design. In this talk, I present the Archie tool suite, initially funded by the National Science Foundation and further developed under sponsorship of the Department of Homeland Security (DHS). Archie is designed to detect architectural design decisions in code, monitor them during long-term maintenance activities, keep developers informed as they make changes, and help protect critical areas of the code from potential architecture degradation. Archie is a smart integrated-development environment, and several of its components are designed for integration into the DHS's Software Assurance Market Place (SWAMP). This talk demonstrates how software-development organizations can utilize Archie to integrate architecture awareness into their developers' daily programming and testing activities. Through a large-scale case study, I demonstrate Archie's use in practice.

Mehdi Mirakhorli

Mehdi Mirakhorli
DePaul University

Jane Cleland-Huang

Jane Cleland-Huang
DePaul University

Methods & tools
Large-Scale Service-Oriented Architecture with a Central Service Repository: Success, Learning, and Challenges

Large-Scale Service-Oriented Architecture with a Central Service Repository: Success, Learning, and Challenges

Credit Suisse's central service-oriented architecture (SOA) repository counts nearly 4,000 interface versions, including Web Service operation versions. Managing a SOA of this magnitude on a global scale requires overcoming a number of challenges, such as limited support by vendors for service design and governance. Credit Suisse had to implement its own solution to manage such a large and complicated SOA. The resulting tool adds benefit by basing code generators on its metamodel. Moving to a new tool met with resistance, as expected, but the organization now acknowledges the benefits of more code generation, including model-driven architecture, and the number of generated artifacts is impressive. An inefficient user interface and implementation, on the other hand, was a major hurdle to full adoption. Furthermore, code generators need to have a good business case, which is difficult to make in IT domains that use a diverse set of tools and technologies. Lessons include the following: small changes to a big SOA have huge impacts, sometimes changes are still necessary, and an attractive offering can help ensure adoption. A current challenge is to make major inroads outside of Switzerland and offer more benefit to projects in early phases of SOA adoption.

Georg Huettenegger

Georg Huettenegger
Credit Suisse

10:30 AM - 12:00 PM Open Space
12:00 PM - 1:15 PM Lunch
1:15 PM - 2:15 PM Keynote Address: For Maximum Awesome

For Maximum Awesome

Download PDF

Watch video

Team WIKISPEED is an Agile hardware and engineering company, using Test First development practices run by Scrum teams to produce road-legal cars, microhouses, and social good projects. Joe leads WIKISPEED, a team of 500 volunteers in 20 countries, and walks us through how their 100-MPG road car was made possible in just three months through object-oriented design, iterative development, and Agile project management. Joe worked with the team at Scrum, Inc., to share these learnings, and now he shares his experience report on exactly how Agile from software projects is applied to physical engineering and manufacture, and how cross-functional software team members can blow up the constraints we imagine around traditional manufacturing. Joe will use the example of the design and development of their ultra-efficient, modular cars and clients' projects in satellites, laboratory equipment, missile systems, radio systems, medical devices, and others.

Joe Justice

Joe Justice
Scrum, Inc., and Team Wikispeed

2:15 PM - 3:45 PM Sessions
Growing Great Architects

Amine Chigani

Moderated by: Amine Chigani
GE Software

Methods & tools
Metrics for Simplifying and Standardizing Enterprise Architecture: An Experience Report for an Oil and Gas Organization

Metrics for Simplifying and Standardizing Enterprise Architecture: An Experience Report for an Oil and Gas Organization

Download PDF

Watch video

The concept of "software quality" is often hard to capture for an organization. Quality models aim to make the concept more operational by refining the quality of software-development products and processes into subconcepts to the level of concrete metrics and indicators. In practice, it is difficult for an organization to produce a reliable quality model because quality depends on numerous organizational context factors, and the model, metrics, and indicators must be tailored specifically to the organization. This is a presentation of the Software Product Quality Model, with emphasis on architecture metrics, developed for Ecopetrol and its application and visualization on real software systems of Ecopetrol's enterprise architecture. The model contains metrics helpful for analyzing the external dependencies and structure of an application based on its modeled relationships to other applications as well as the used and provided interfaces according to the interface integration type. Equally advanced visualization of the models has been created for illustrating the coupling and complexity of the enterprise architecture. The model was rolled out in 2012 and has been helpful for architects to set baselines and monitor evolution toward the organizational IT strategy as they sought to simplify and standardize the IT landscape. The model specially tailored for Ecopetrol offers architects a common language for software quality, increasing model acceptance and improving communication.

Alexis Ocampo

Alexis Ocampo
Ecopetrol

Jens Heidrich

Jens Heidrich
Fraunhofer IESE

Constanza Lampasona

Constanza Lampasona
Fraunhofer IESE

Victor Basili

Victor Basili
University of Maryland and Fraunhofer CESE

Methods & tools
Combining Architectural Methods to Build a Reference Architecture for Ground Radar Monitoring Systems

Combining Architectural Methods to Build a Reference Architecture for Ground Radar Monitoring Systems

Download PDF

Watch video

A reference software architecture (RSA) enables systematic reuse of domain knowledge and components when developing concrete architectures and systems, leading to reduced development cycles, increased quality, and conceptual integrity. However, creating an RSA is challenging because it requires an initial investment and should ensure adequacy of the RSA for the organization. In this presentation, we report the experiences of creating an RSA for an Argentine R&D company in the domain of ground radar monitoring (GRM) systems. This was a brown-field development: we departed from an existing system for processing telemetry from radars, and we evolved it toward a more general architecture. We aimed to adjust the development estimates for GRM products using the RSA as the baseline. Our architecture-centric approach was driven by the company's business goals and the corresponding quality attributes for the product family. We captured these quality attributes through a Quality Attribute Workshop, then engineered them into an RSA blueprint following a three-iteration Attribute-Driven Design process. We documented key design decisions and architectural views, and evaluated the RSA using the Architecture Tradeoff Analysis Method. Along this path, the architectural vision defined an iterative and prototype-based development strategy and infused architecture-based techniques into the software division of the company. The resulting RSA successfully articulated the main elements and business rules of the GRM domain via a set of architectural mechanisms and practices.

Alejandro Bianchi

Alejandro Bianchi
LIVEWARE IS S.A.

J. Andres Diaz-Pace

J. Andres Diaz-Pace
UNICEN University

Leonardo Seminara

Leonardo Seminara
LIVEWARE IS S.A.

Gustavo De Souza
INVAP S.E.

Methods & tools
Teaching Architecture Metamodel-First

Teaching Architecture Metamodel-First

Download PDF

Watch video

Despite software architecture being recognized as a discipline for about two decades, it is not commonly taught in universities or to practitioners. One potential obstacle is the highly abstract nature of the subject: Less experienced students quickly forget the abstract lessons and experienced students feel that software architecture is disconnected from their daily work. In this talk, I discuss a novel approach to teaching software architecture based on metamodels. Students start by sketching a simple system. I then discuss typical flaws (e.g., showing a runtime "box" talking to a compile-time "box") and build their understanding of the metamodel behind the diagram, including views for compile time, runtime, and allocation. I provide a standard palette (i.e., metamodel) for each view, and students learn why the constrained metamodel aids their reasoning. The overall message is that a diagram is really a model, and models elide details, so it is essential to know what question a model should answer so you can reveal (and elide) the right details. Then the students repeat the same exercise of sketching a simple system, with improved results. I have applied this approach with about 50 software engineers at my current company with good results: students stay engaged and report that the lessons are directly relevant to their daily work.

The Business of Software Architecture

Bett Correa

Moderated by: Bett Correa
Verizon

Methods & tools
Under N: Acceptance to Delivery in N Hours

Under N: Acceptance to Delivery in N Hours

Download PDF

Watch video

How about delivering a business need from acceptance to production in less than 12 hours? Or delivering in the absolute time it would actually take-not an hour more and not an hour less? Under-N methodology provides a framework to uncover hidden capabilities within IT applications and IT application teams and then to use the capabilities to deliver a business need, change, or want in under N hours, where N is the absolute time it takes to deliver. It also elicits capabilities that may not yet be present but that are possible, while outlining four atomic change capabilities that, when implemented, will enable IT applications to deliver changes in an under-N fashion by mixing and matching. The presentation outlines a template to frame these capabilities by asking the right questions to procure all the answers that will be needed to execute the capability and to engage the correct stakeholders. In addition, the presenter proposes ways to scale the capabilities across an enterprise by means of a challenge process and by celebrating the best.

Umashankar Velusamy

Umashankar Velusamy
Verizon Communications, Inc.

leadership & Business
The Costing View of Architecture

The Costing View of Architecture

Download PDF

Watch video

All modern architecture documentation practices promote the use of multiple views to document how the architecture addresses various concerns of different stakeholders. So far, little attention has been paid to an important business concern: that of costing a solution. At CGI, we often have to architect and cost a solution in a very limited time frame, usually when answering a Request for Proposal within a hard deadline. One of the key objectives of Risk- and Cost-Driven Architecture (RCDA), CGI's agile solution-architecting approach, is to focus the architect's attention on economic aspects. In this context, we have developed a viewpoint that helps architects document their architectures in a way that lets them quickly establish the cost parameters: the Delivery Breakdown View. By combining guidance from the ISO 42010 Architecture Documentation standard with the Product Breakdown Structure known from project management methods, the Delivery Breakdown View helps architects address important cost-related concerns and communicate the resolution of these concerns to stakeholders. In this presentation, we will discuss the importance of costing in architecting, present the Delivery Breakdown View that we developed, and demonstrate its use in an architecture documentation template from CGI.

leadership & Business
How to Incorporate Software Architecture into Your Business Model

How to Incorporate Software Architecture into Your Business Model

Download PDF

Watch video

The size and complexity of new software applications is increasing exponentially. Yesterday's software applications may have been written in a single programming language to run on a single computing platform. The task was readily handled by software engineers. Many of today's software applications might be written in multiple programming languages and distributed across multiple disparate computing platforms and operating systems. They may also use commercial off-the-shelf or open-source software products and integrate into very large and complex systems. The engineering may need to accommodate the common aspects of an entire product line. No longer is a software engineer trained or prepared for the complexities of this task. This is where new software architecture knowledge, skills, and abilities are needed, and this is where the software architect is born. But the rest of the organization also must recognize the need for software architects, new software-architecture processes, and the impact to the business model to be effective. This presentation provides an overview of the experiences and lessons learned as Raytheon, a technology leader and the fourth largest defense contractor in the world, takes on the challenge of incorporating software architecture into the business model of the organization.

Tim Kertis

Tim Kertis
Raytheon

Participatory Session
Methods & tools
Software Architecture and Design Decay

Software Architecture and Design Decay

Often, software projects are extensions of existing code or face other limiting factors that restrict the architectural or design approaches that teams can take to successfully complete the project. However, in other situations a team finds itself in the position of being able to develop a solution virtually from scratch. While not subject to the same factors that constrain developing in a legacy environment, green-field architecture and design face their own set of unique challenges. Examining these challenges can shed light on why many software projects fail to fulfill their original goals. Software architecture, design, and development for new projects can involve making thousands of decisions, and the probability of making these decisions correctly, consistently, and at the right time has to be at or close to zero. In this participatory session, we will examine the decision-making process surrounding how decisions are made, captured, maintained, and refined. No one wakes up and decides that today is the day they are going to create a piece of software that will be held up in the future as an example of how not to do something, yet many examples of troubled software exist. The decision-making process, especially early in a project's life cycle, seems to be particularly vulnerable and once compromised can lead to further architectural and design decay.

Benjamin Pope

Benjamin Pope
Medtronic

Kurt Noltensmeyer

Kurt Noltensmeyer
Medtronic

2:15 PM - 3:45 PM Open Space
3:45 PM - 4:15 PM Afternoon Break
4:15 PM - 5:45 PM Sessions
The Art and Science of Scalability

Rick Kazman

Moderated by: Rick Kazman
Carnegie Mellon Software Engineering Institute

technology
BI/Big Data Reference Architectures and Case Studies

BI/Big Data Reference Architectures and Case Studies

Download PDF

Watch video

If data were equated to temperature in physical analogy, according to the second law of thermodynamics its accumulation would lead to the heat death of the universe. In fact, 90% of the world's data has been generated during the last two years. Fortunately, business intelligence (BI) architectures and technologies are evolving rapidly to keep up with the exponential rise of data and project complexity. An almost 30-year era of dominance for the relational database management system (RDBMS) ended, and there is no one-size-fits-all solution that solves all of today's Big Data challenges. BI architecture drivers must change to satisfy new requirements in format, volume, latency, hosting, analysis, reporting, and visualization. In this session, we expose a number of reference architectures that address these challenges and speed up the design and implementation process, making it more predictable and economical:

  • traditional architecture based on an RDMBS data warehouse but modernized with column-based storage to handle a high load and capacity
  • NoSQL-based architectures that address Big Data batch and stream-based processing and use popular NoSQL and complex event-processing solutions
  • hybrid architecture that combines traditional and NoSQL approaches to achieve completeness that would not be possible with either alone

The architectures are accompanied by real-life projects and case studies that the presenters have performed for multiple companies, including Fortune 100 and start-ups.

Serhiy Haziyev

Serhiy Haziyev
SoftServe, Inc.

Olha Hrytsay

Olha Hrytsay
SoftServe, Inc.

technology
MapReduce over a Petabyte Is the Easy Part: Some Important Big-Data Practicalities

MapReduce over a Petabyte Is the Easy Part: Some Important Big-Data Practicalities

Watch video

Being able to run a MapReduce over a petabyte is a huge accomplishment, in all kinds of ways. Moreover, the algorithmic innovations in the Big Data community are hugely impactful. However, practical issues enabling repeatable application of this ongoing innovation get too little attention. This talk will address some of the infrastructural developments that have enabled much of the progress to date: reliable workflow, efficient (and accounted-for) large-scale data movement, and ease of use for developers. We'll talk about both open-source solutions and some of the specific techniques that Google has applied to the problem.

technology
Service Variability in Multi-Tenant Engineering: A Systematic Literature Review on the State of Practice, Limitations, and Prospects

Service Variability in Multi-Tenant Engineering: A Systematic Literature Review on the State of Practice, Limitations, and Prospects

Download PDF

Watch video

Service variability is the degree of actual variability from the service provider over the variability required by the tenants for the service. With a growing number of tenants, the likelihood of facing more diverse tenants' requirements will increase. We conducted a study of how choices regarding service architecture affect service variability and the cost of supporting a service. We identified positive and negative impacts of service architectural choices on service variability. We conducted workshops with industry service providers to validate our choices and their experiences on multi-tenant engineering. Knowledge of this information can assist participants with making more informed decisions regarding multi-tenant engineering.

Ouh Eng Lieh

Ouh Eng Lieh
National University of Singapore

Building a Community of Practice

Eltjo Poort

Moderated by: Eltjo Poort
CGI

leadership & Business
Creating a Sustainable Architecture Organization

Creating a Sustainable Architecture Organization

Download PDF

Watch video

Our clients have asked us to help them to create or mature their architecture organizations, which are typically part of an Information Technology (IT) department. Through helping our clients, we developed a framework that we have used successfully with over 20 clients. The framework addresses the following aspects of what an architecture organization should be concerned with in order to be sustainable:

  • charter that includes mission and vision, roles, and organization
  • governance
  • service catalog
  • service delivery management

After reviewing the framework, we will present lessons learned from working with the various clients. After the session, the audience will be aware of the importance of defining the mission and vision of an architecture organization and of understanding the need for change management. With this awareness, the audience will be able assess how well an architecture organization understands its environment and determine if it is meeting the needs of the organization.

leadership & Business
Software Architecture Community of Practice at Raytheon

Software Architecture Community of Practice at Raytheon

Download PDF

Watch video

Four years ago, Raytheon established its Software Architect Training and Development Program (SWAP) to ensure that a standardized, repeatable approach to software architecting is deployed across the company. The SWAP complements our Raytheon Certified Architect Program (RCAP) and fills a gap that existed in providing skills for software architects entering the middle phase of their careers. A key component of the program is establishing and cultivating software architecture community of practices (CoPs). CoPs facilitate sharing architecture best practices, lessons learned, patterns, strategies, styles, and heuristics among architects working on a variety of programs across our businesses. We found that the most effective CoPs are those that are self-organized as opposed to management directed. Key to the CoPs is an effective collaboration environment providing the latest news, brown bags, roadmaps, architecture process, tools, and reference material needed to educate aspiring architects. This presentation provides a case study of our motivation for establishing the program and lessons learned that apply to other organizations deploying a similar approach. We examine the dynamics of establishing a new training program and creating an environment in which CoPs effectively form and flourish. We discuss our approach, including the structure of the program, how the SWAP compares to the RCAP, and what communication approaches worked in deploying CoPs across our business.

Sunitha Vallabhaneni

Sunitha Vallabhaneni
Raytheon Intelligence

Doug Dusseau

Doug Dusseau
Raytheon

Keith Nolan

Keith Nolan
Raytheon

leadership & Business
Growing an Architecture Community of Practice

Growing an Architecture Community of Practice

You know you have more architecture work than you or your team can handle. The likelihood of getting more resources is pretty slim. At the same time, lead developers are busy working on projects and not always using the best architectural style. How do we reach out to them, mentor them, and bring them in to the fold? Mark describes several approaches being used at Travelers Insurance to grow a community of practicing architects, recognizing that not all those doing architecture work have "architect" in their job titles.

Mark Stofferahn

Mark Stofferahn
Travelers Insurance

Participatory Session
Methods & tools
Rapid Software Architecture Exploration

Rapid Software Architecture Exploration

For teams who desire effective yet lean software engineering practices, Rapid Software Architecture Exploration is a set of structured, lightweight architecture design, discovery, and description practices for efficiently exploring the design space and articulating a working solution. Unlike prevailing architecture-centric tools such as the Quality Attribute Workshop, Rapid Software Architecture Exploration practices allow your team to maximize design-discovery speed and increase agility without sacrificing engineering effectiveness. This is accomplished by focusing on essential architectural information, encouraging team and customer collaboration, emphasizing systemic thinking throughout the team, and working to design solutions and understand the problem as quickly as possible without sacrificing effectiveness. In this session, I will summarize the theory behind enabling Rapid Software Architecture Exploration and describe four methods regularly used by my team at IBM as a part of our rapid exploration practice-stakeholder maps, round-robin design, system properties web, and rose-bud-thorn risk analysis. The majority of the session will be dedicated to practicing these methods in small groups. By the end of this session, you will have learned four rapid architecture-centric practices that can be applied directly with your teams back home.

4:15 PM - 5:45 PM Open Space
6:00 PM - 9:00 PM Reception


* Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.

May 8, 2014

7:30 AM - 5:00 PM Registration
7:30 AM - 8:45 AM Morning Beverages *

Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant. 

8:45 AM - 9:00 AM Welcome and Opening Address: Day 2 Welcome
9:00 AM - 10:00 AM Keynote Address: Engineering Velocity: Continuous Delivery at Netflix

Download PDF

Watch video

At Netflix, we realize that there's a tension between the availability of our service and our speed of innovation. If we move slowly, we can be very available-but that's not a good business proposition. If we move super fast, we risk downtime-and that might annoy our customers. But what if we could increase our velocity without significantly impacting availability? How can we shift that curve so that we're moving faster without dropping any of those coveted 9s?

How can we engineer velocity by weaving together tooling and culture with software development to expose and elevate highly effective practices? This talk describes various components of Netflix's continuous delivery platform-much of which is available in open source. I'll show how these pieces fit together and allow us to build scaffolding so that we're comfortable with software developers making the decision to push the button for prod deployment-and to help them recover if necessary. As a result, we can run fast, trusting our tooling and our culture.

I'll also describe how we test our resiliency through simulating failure, unleashing the monkeys (Simian Army) on our production environment. Because if you're afraid of cute little monkeys, imagine how afraid you'll be of a production environment that offers those same risks but doesn't give you an opportunity to test your response to those dangers.

Throughout this talk, I hope that you will challenge yourself to consider how your company can "shift the curve" through tooling and achieve a high-velocity environment without negatively impacting reliability.

Dianne Marsh

Dianne Marsh
Netflix

10:00 AM - 10:30 AM Morning Break
10:30 AM - 12:00 PM Sessions
DevOps and Delivery

Len Bass

Moderated by: Len Bass
NICTA

technology
Impact of Architecture on Continuous Delivery

Impact of Architecture on Continuous Delivery

Download PDF

Watch video

The speaker has been leading the construction of a SaaS application. Guided by lean principles and the need to release small, experimental changes, continuous delivery was a prerequisite. When the project began, we knew that DevOps practices would be required to achieve continuous delivery-that is, full automation of building, testing, configuration, and deployment. But we did not fully appreciate the need for an architecture that lends itself to small batches. Lean principles state that batch size impacts the ability to flow from concept to delivery. A greater up-front appreciation for the impact of architecture on batch size-and, in turn, flow-would have led us to make deeper investments in certain parts of the architecture sooner. This presentation highlights key lessons learned in the following areas:

  • aspects of architecture and design that impact batch size
  • strategies for minimizing batch size in an evolving architecture
  • other related design techniques that impact flow

It is not enough to have great DevOps. Architecture significantly impacts the likelihood of achieving continuous delivery goals. This session explains how specific investments in the architecture and design can decrease batch size. Smaller batch size increases flow. And the goal of lean, continuous delivery is the predictable, fast flow of improvements into user hands.

Russell Miller

Russell Miller
SunView Software, Inc.

technology
The New Era of Integrated Software Delivery with DevOps

The New Era of Integrated Software Delivery with DevOps

Download PDF

Watch video

To succeed in the technology trinity of the new era-Big Data, cloud computing, and mobile technologies-we must embrace new and innovative methods of software delivery. Traditional development and deployment methods are too slow to cater to current fast-paced market trends and too expensive and manual for the present economic context. It is time to bring innovation to the forefront again and change the approach and pace of software delivery through development and operations integration, an incremental approach to delivery, automation throughout the delivery life cycle, and continuous delivery and monitoring of systems. These approaches require leveraging a company's existing investments while introducing new ones to their IT infrastructure. The presenter will discuss the approaches now available to software-delivery teams and explain IBM's approaches and solutions. Additionally, she will discuss the need for seamless synchronization of business and IT strategies and goals. The presenter will also cover how software delivery can enable the development and maintenance of multiplatform applications for cloud and mobile technologies. Finally, she will describe how the DevOps approach provides cost efficiencies while allowing software-delivery teams to maintain control of the quality and efficiency of the delivery.

technology
Is Your Team Instrument Rated (Or: Deploying 89,000 Times a Day)

Is Your Team Instrument Rated (Or: Deploying 89,000 Times a Day)

Download PDF

As DevOps matures from craft, through trade, to a science, we are starting to work on distilling out how we can make DevOps' implementation and the organizational transformation repeatable and predictable, across all kinds of environments. As part of that search, it is time to start looking at humanity's other "operational" endeavors and see what is applicable to DevOps. This talk examines one of the largest operational systems built to date: the national airspace system. We will look at specific aspects of how controllers (operations teams) work with pilots (developers) to safely move millions of passengers (customers) every year, with an incident rate that would make any development shop jealous. In aviation, harsher, more crowded, and inclement conditions all require additional training: an instrument rating. Similarly, developers and operations teams buying in to "DevOps culture" is a great start, but it's often hard to nail down what that actually means. We'll examine the specific behavioral and operational elements of this other complex system that has been tamed and look at what's applicable to implementing a DevOps culture within our own industry. Finally, we'll examine some of aviation's hard-learned lessons and look at ways we can leverage this knowledge and avoid those classes of pitfalls.

J. Paul Reed

J. Paul Reed
Release Engineering Approaches

Team Collaboration

Christopher Armstrong

Moderated by: Christopher Armstrong
Armstrong Process Group, Inc.

Methods & tools
Transparency: An Architecture Principle for Socio-Technical Ecosystems

Transparency: An Architecture Principle for Socio-Technical Ecosystems

Download PDF

Watch video

The Extreme Science and Engineering Discovery Environment (XSEDE) Project is a large multi-institution effort to help scientists in multiple disciplines access and share a network of supercomputer resources, code, and data. XSEDE is a socio-technical ecosystem; it provides a computational infrastructure that helps scientists access many different supercomputing sites that have different policies and software infrastructures; the users come from different scientific and university communities with different priorities; and the developers and architects come from different institutions and subcommunities with local priorities. An SEI team has worked with XSEDE to establish sound architecture-centric engineering practices across the distributed architecture and development teams. However, productivity is not yet acceptable. An underlying cause is lack of transparency into the process and artifacts. Three factors contribute to transparency deficiencies:

  1. Many groups do things differently, using different tools. That makes information disappear or appear when it crosses the boundary to other groups.
  2. People desire to keep unfinished changes private, allowing them to become externally visible only when they reach a publishable state.
  3. The sheer volume of concurrent activities and artifacts requires more time for reviews and decisions. 

We report on efforts to increase transparency using automated support from collaborative development environments, online deliberation, information flow analysis, and machine learning tools.

Felix Bachmann

Felix Bachmann
Carnegie Mellon Software Engineering Institute

Linda Northrop

Linda Northrop
Carnegie Mellon Software Engineering Institute

leadership & Business
What Happens When You Break All the Rules?

What Happens When You Break All the Rules?

Download PDF

Watch video

In 2013 Statoil launched a public ocean observatory service outside Lofoten and Vesteralen, Norway. The key parts of the portal were developed in four months on a budget of 200K USD, but continuous development is under way to fulfill oceanographic and environmental research needs. All large organizations have rules to follow. In combination with other factors such as organizational structure, sourcing model, software architectures, and development approach, rules can increase project cost and slow development. The authors' experience has provided a keen sense of what makes software projects successful and possible pitfalls to watch out for. Even in large organizations with comprehensive rule books, it is possible to run successful software-development projects without huge investments in time and money, but often a few rules have to be stretched. We address some questions facing software architects and use project experience to illustrate the learnings: 

  • What are the most important software-development rules in today's dynamic business environment? 
  • How can you use the software architecture and development team structure to compensate for organizational and procedural failings? 
  • Faced with a thick rule book, how do you know which rules to break, and how do you handle breaking them?
  • How can you use models such as the Dreyfus model of skills acquisition to evaluate the team maturity and determine how strictly to follow the rules?
Harald Wesenberg

Harald Wesenberg
Statoil ASA

Jørn Ølmheim

Jørn Ølmheim
Statoil ASA

Einar Landre

Einar Landre
Statoil ASA

Methods & tools
Archinotes: A Global Agile Architecture Design Tool

Archinotes: A Global Agile Architecture Design Tool

Download PDF

Currently, many software-development organizations have adopted a work methodology around global software development in which the members of a geographically dispersed team can coordinate their activities through collaboration tools. These tools focus primarily on the construction process rather than on concrete design. This kind of organization usually has teams in which members are located in different cities or even in different countries. As a result, architects must attend face-to-face meetings where they can define the architecture together. To tackle this challenge, we developed Archinotes, a tool to support approaches to global agile-architecture design. Using this tool, architects can coordinate, communicate, and control an agile software-architecture design process while being geographically separated. In this presentation, we demonstrate the main features of Archinotes and present its main benefits for an organization with geographically dispersed teams.

Juan Urrego

Juan Urrego
Universidad de los Andes

Dario Correal

Dario Correal
Universidad de los Andes

Participatory Session
leadership & Business
IT Project Estimation Techniques

IT Project Estimation Techniques

The IT industry wastes millions on projects that are too expensive and don't deliver their expected value. A McKinsey study showed that 45% of large IT projects overrun their projected budgets, costing the industry up to $66 billion dollars. Most software architects dread giving estimates, yet it is an unavoidable and important part of the job. The dread is understandable. Much rides on these estimates in terms of both the company's investment and the architect's reputation, while many factors that impact the timeline are out of the architect's control: requirements will change, and each project uses new technology. More importantly, most architects have not received meaningful training on how to estimate. As architects, our inability to accurately predict the cost and benefits of a project impacts the business in the following ways:

  • lower than expected return on investment
  • delayed or canceled projects
  • rushed or error-filled products
  • opportunity cost of wasted time
  • negative reputation

This session will cover the importance of estimating and will help attendees reduce the associated dread of estimating by teaching them to think differently about the process and by equipping them with a toolbox of estimation techniques.

Bett Correa

Bett Correa
Verizon

10:30 AM - 12:00 PM Open Space
12:00 PM - 1:15 PM Lunch
1:15 PM - 2:45 PM Sessions
Promoting Quality Attributes: Lessons from the Trenches

Linda Northrop

Moderated by: Linda Northrop
Carnegie Mellon Software Engineering Institute

technology
Can You Hear Me Now? The Art of Applying Communication Protocols When Architecting Real-Time Control Systems

Can You Hear Me Now? The Art of Applying Communication Protocols When Architecting Real-Time Control Systems

When architecting a distributed real-time control system, selection of appropriate communication protocols is essential to ensure that performance objectives can be achieved within system constraints. An open-system solution based on the Internet Protocol seems obvious, but the proper implementation of connection-oriented and connectionless protocols is often left to the implementer without regard for the potential overall system impacts. This session draws on the author's decades of experience in data communications and software development and is based on lessons learned in the successful implementation of a large-scale, real-time weapon control system. The author will present guidelines for identifying where the Transmission Control Protocol and User Datagram Protocol are best applied in such a system along with the impacts of making inappropriate choices. A real-world example of the additional architectural benefits derived through appropriate communication design is provided through a description of multicast datagrams in the example system. The example includes a detailed description of implementation of the multicast group join/leave for selected compute nodes within the system.

Todd Farley

Todd Farley
BAE Systems, Inc.

technology
Sink or Swim: Enhancing Pipe-and-Filter Diagrams

Sink or Swim: Enhancing Pipe-and-Filter Diagrams

Download PDF

Watch video

Sink or Swim is a specialization of the pipe-and-filter architectural style. It enables developers to reason about hard problems in distributed systems and data processing by focusing attention on the push or pull nature of the filter coupling. This is accomplished by creating two connector subtypes (push and pull) and elaborating the filters with synchronous (active) or asynchronous (passive) ports. It is then possible to name and characterize eight subtypes of filters, one for each combination of {sync/async, input/output, middle/terminal}. This lighthearted talk covers how the style was invented, how it works, how it helps developers reason about hard problems, and how it was successfully applied to yield orders-of-magnitude performance improvements to existing systems. This style has several advantages over the regular pipe-and-filter style: 

  • The style makes problems easy to spot through a graphical notation that enables and encourages visual reasoning. 
  • The style makes anti-patterns visible by highlighting resource implications of given usage patterns.
  • A small catalog of rewrite rules guides developers to refactor designs at the style level to avoid performance (and other) problems.
Ivan Gevirtz

Ivan Gevirtz
Google

technology
Approaching Security from an "Architecture First" Perspective

Approaching Security from an "Architecture First" Perspective

Download PDF

Watch video

While software security is an increasing concern for software and system architects, few architects approach this quality concern strategically. Architects and developers typically focus on functionality, and they often apply security as a Band-Aid solution after developing an application. In this presentation, we report on three case studies of real-world projects-two industrial and one open source-for which we attempted to measure the consequences of three architectural approaches to security. These architectural approaches differ on the degree of adoption of security frameworks for the development projects: "no adoption," where no security frameworks are used; "partial adoption," where security frameworks are introduced in the middle of the lifetime of a software application; and "full adoption," where one or more security frameworks are adopted from the beginning of the development process. We conducted the case studies by interviewing architects about the security tactics implemented in their projects and by scanning the systems to identify their vulnerabilities using a commercial security scanner (IBM's AppScan). The results of our case studies indicate that a strategic, system-wide, architectural approach to security, implemented through the partial or full adoption of security frameworks, results in the best outcome from both security and maintenance cost perspectives.

Rick Kazman

Rick Kazman
Carnegie Mellon Software Engineering Institute

Jungwoo Ryoo

Jungwoo Ryoo
Pennsylvania State University

Humberto Cervantes

Humberto Cervantes
Universidad Autonoma Metropolitana–Iztapalapa

Architecting in the Enterprise

Stephany Bellomo

Moderated by: Stephany Bellomo
Carnegie Mellon Software Engineering Institute

Methods & tools
CORBA to Web Services Migration Using Model-Driven Approaches and Offshoring

CORBA to Web Services Migration Using Model-Driven Approaches and Offshoring

How does a large corporation migrate a large-scale service-oriented architecture with more than 2,500 service operations and more than 20 million invocations per day? What were the relevant drivers? How does the journey begin? What initial obstacles and challenges had to be overcome (e.g., the need for a suitable target technology)? How does an organization handle tradeoffs among architectural goals, feasibility, and affordability of migration approaches? What technology can help (e.g., model-driven architecture)? How does an organization approach the significant amount of work to be done (e.g., how can offshoring be used to reduce cost)? How does an organization plan for pushing a full migration through? How does this work occur in a big corporation with a huge number of stakeholders who change jobs frequently? This session will answer these questions for the Common Object Request Broker Architecture (CORBA) to Web Services migration of Credit Suisse that is currently in full swing.

Georg Huettenegger

Georg Huettenegger
Credit Suisse

Methods & tools
Understanding Reference Models and Reference Architectures

Understanding Reference Models and Reference Architectures

Download PDF

Watch video

The notion of reference models and reference architectures are used pervasively in the architecture profession. However, when applying these concepts in practice, there is often confusion as to how they are different, yet related. The speaker will present industry-standard best practices regarding how to use reference models for categorizing architecture content for different purposes (such as planning, life-cycle management, gap analysis, and enterprise-wide alignment) and how they relate to architecture and solution building blocks (per TOGAF). The presentation continues with a discussion of how reference architectures are similarly used but also how they can be used to represent architecture patterns, design patterns, and best practices.

Christopher Armstrong

Christopher Armstrong
Armstrong Process Group, Inc.

Methods & tools
Integrating Enterprise Architecture

Integrating Enterprise Architecture

Download PDF

Watch video

In the era when contributing to business value is the principal consideration of IT, large and distributed organizations face a challenge of understanding how their capabilities are realized and how they can synchronously evolve them in alignment with business strategy. Structured information coupled with efficient architecture processes sets the foundation by addressing several issues: 

  • Complex interdependent systems that evolved independently increase technical debt. 
  • Nonexistent, inconsistent, or scattered architecture descriptions make planning difficult and extend the delivery time of solutions. 
  • Unclear dependencies of business capabilities on technology lead to weak commitment to business goals. 

The TOGAF, ArchiMate, and Sparx EA tools are cornerstones of Progressive's approach to integrated enterprise architecture. By leveraging existing systems-development life-cycle processes and architecture-governance structures, Progressive implemented elements of the TOGAF Architecture Development Method and established consistency in defining and reviewing target architectures. Investing in modeling skills and introducing standard building blocks for architecture models allow architects to describe the systems and capabilities in a uniform way that produces an overall view of the current and future states of the enterprise. This presentation presents a practical approach to implementing integrated enterprise architecture at a large organization. Specific tools, frameworks, and languages serve only as a context for this experience-based story.

Voytek Janisz

Voytek Janisz
Progressive Insurance

Participatory Session
Methods & tools
Embracing an Architecture-Focused Approach for Monitoring Technical Debt

Embracing an Architecture-Focused Approach for Monitoring Technical Debt

Achieving sustainable delivery of value in any iterative, incremental development paradigm has always been a challenge for the software engineering community. This challenge manifests itself as a struggle to balance the desire to deliver value to the customer as early as possible with the desire to reduce rework due to architectural refactoring. The metaphor of technical debt is a way to understand and characterize this optimization problem. Knowing how much technical debt a project has accumulated and the right time to pay it back is difficult since the debt remains hidden until the project begins to experience the symptomatic slowdown. In this session, we examine techniques for architecture visualization that provide information relevant to assessing and managing technical debt. We explore measures based on design (dependency) structure matrices and graph-theoretic approaches that can be automatically generated from the source code of a system and identify shortcomings of these visualization techniques. We describe categories of architecture-level dependencies and show how to use the documentation of an architecture and its quality attribute scenarios to capture these dependencies. Finally, we demonstrate how visualizations generated from architecture-level dependencies can provide insights that would otherwise be missed. Participants will create architecture-relevant technical debt visualizations of an open-source system using a commercial tool called Lattix. We will also provide demonstrations for creating visualizations using other tools such as Structure101, SonarQube, and R.

If you would like to follow along the structural analysis example we will demonstrate during this session, please bring your laptop. You can find the downloads and setup information for the example system and software packages we will use here. Preparing these in advance will help with time management. We will also be available during the Open Space session at 10:30-12:00 AM on Thursday, May 8, for those who may need help setting up.

Robert L. Nord

Robert L. Nord
Carnegie Mellon Software Engineering Institute

Ipek Ozkaya

Ipek Ozkaya
Carnegie Mellon Software Engineering Institute

Raghvinder Sangwan

Raghvinder Sangwan
Pennsylvania State University

1:15 PM - 2:00 PM Open Space
2:00 PM - 2:45 PM Open Space: Closing
2:45 PM - 3:45 PM Panel Discussion : Technical Debt

Plenary Session: Technical Debt

Watch video

Technical debt is a metaphor in software engineering that helps us understand and deal with those decisions that result in poorer quality code. Whether it is through ignorance, accident, or strategy, all software-intensive systems carry some technical debt. During this panel, we will explore the topic of technical debt as it relates to software architecture. This practitioner-focused discussion features leading experts in technical debt and software architecture. They will explore the following questions and more:

  • How does technical debt manifest in software architecture?
  • When and how should I "pay down" debt?
  • What do developers, managers, architects, and customers need to know about technical debt?
  • Is architecture-level debt qualitatively different?
  • How can I measure and/or manage debt effectively?
  • What are the limits of the technical debt metaphor?

George Fairbanks

Moderated by: George Fairbanks
Google

Philippe Kruchten

Philippe Kruchten
University of British Columbia

Robert L. Nord

Robert L. Nord
Carnegie Mellon Software Engineering Institute

Rebecca Wirfs-Brock

Rebecca Wirfs-Brock
Wirfs-Brock Associates

May 9, 2014

7:30 AM - 8:30 AM Morning Beverages *

Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant. 

8:30 AM - 12:00 PM
Half-Day Tutorials, Morning Sessions
T6: Being Agile About System Qualities

T6: Being Agile About System Qualities

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.

Rebecca Wirfs-Brock

Rebecca Wirfs-Brock
Wirfs-Brock Associates

T7: Architecture Katas (Part 1 of 2)

T7: Architecture Katas (Part 1 of 2)

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.

Ted Neward

Ted Neward
Neward Associates

10:00 AM - 10:30 AM Morning Break
12:00 PM - 1:00 PM Lunch
1:00 PM - 4:30 PM
Half-Day Tutorials, Afternoon Sessions
T7: Architecture Katas (Part 2 of 2)

T7: Architecture Katas (Part 2 of 2)

Part 2 of Ted Neward's tutorial, Architecture Kata

Ted Neward

Ted Neward
Neward Associates

T8: Iteration Planning

T8: Iteration Planning

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.

Philippe Kruchten

Philippe Kruchten
University of British Columbia

3:00 PM - 3:30 PM Afternoon Break


* Attendees staying within the SATURN hotel-room block receive a voucher good for breakfast each day of their stay in the hotel restaurant.

Help us improve

Visitor feedback helps us continually improve our site.

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