SATURN 2015 Presentations

This file contains presentations from the SEI Software Architecture Technology User Network Workshop (SATURN 2015) event (April 27-30, 2015, in Baltimore, Maryland).

Sessions and presentations included:

*ADD 3.0: Rethinking Drivers and Decisions in the Design Process, Humberto Cervantes and Rick Kazman
*Agilizing the Architecture Department, Eltjo Poort
*A Partner Is Good to Have, but Difficult to Be, David Kane and Dave Dikel
*Architecting Hybrid Cloud Solutions with Watson Developer Cloud, Will Chaparro
*Architecting Public-Facing Website Software for High Concurrent User Load, Derrick Lau
*Cost-Benefit Analysis in Technical Debt Reduction, Andriy Shapochka
*Design Thinking Is for You, Ariadna Font Llitjós, Jeff Patton, and Jonathan Berger
*DevOps Essentials for Software Architects, Len Bass 
*Does Your Cloud Solution Look Like a Mushroom?, Kim Carter 
*Enterprise Applications Health Improvement Program, Eswaran Thandi 
*Exploiting Fast and Slow Thinking, Rebecca Wirfs-Brock
*From Monolith to Microservices: A Leadership Perspective on Legacy Application Modernization, Einar Landre, Jørn Ølmheim, and Harald Wesenberg
*Improving Architectural Refactoring Using Kanban and the Mikado Method, Paul Boos
*Injection, Modularity, and Testing: An Architecturally Interesting Intersection, George Fairbanks
*Introduction to Architecture-Centric Design Thinking, Michael Keeling
*Keeping the Beat: Rhythm and Trust in Architecture, David Kane
*(Keynote) Progress Toward an Engineering Discipline of Software, Mary Shaw
*Leading Change: Engaging Critical Stakeholders for Project Success (Presentation and spreadsheet), Marisa Sanchez 
*Living a Nightmare, Dreaming a Dream: A Drupal Deployment Dilemma, Gail E. Harris
*Locating the Architectural Roots of Technical Debt, Rick Kazman, Yuanfang Cai, Serhiy Haziyev, and Volodymyr Fedak 
*Making Better Architectural Choices with the Architecture Valuation Framework, Voytek Janisz
*Maturing Agile Teams and Driving Quality Through Architecture Principles, Amine Chigani and Yun Freund
*Maximize Your Business Impact as an Architect, Eltjo Poort
*My Silver Toolbox, Michael Keeling
*Never Again Offline?! Experiences in the Outstanding Role of Data in a Large-Scale Mobile App Ecosystem, Matthias Naab, Ralf Carbon, and Susanne Braun
*Open Medical Record System Plus (OpenMRS+): OpenMRS for Non-Communicable Diseases, Gloria Ingabire
*Open Systems Architecture: Progress and Challenges, Douglas Schmidt 
*Programming in the 1960s: A Personal History, Len Bass
*QA to AQ: Shifting from Quality Assurance to Agile Quality, Joseph Yoder and Rebecca Wirfs-Brock
*Quality Requirements on a Shoestring, Thijmen de Gooijer
*Smart Decisions: An Architecture Design Game, Serhiy Haziyev, Olha Hrytsay, Rick Kazman, and Humberto Cervantes 
*Software Architecture as Code, Simon Brown
*Sustainably Supporting Data Variability, Atzmon Hen-Tov, Jordan Menzin, and Joseph Yoder 
*Systems Characterization: An Approach to Modernizing Disparate Legacy Systems, Jane Orsulak and Julie Kent
*Systems of Action: A Stack Model for Capability Classification, Einar Landre and Jørn Ølmheim
*Taming Big Balls of Mud with Agile, Diligence, and Hard Work, Joseph Yoder
*The Architectural Analysis for Security (AAFS) Method, Jungwoo Ryoo and Rick Kazman
*The Business Side of a Software Architect, Tomer Peretz
*The Value of Architecture and Architects, Shrikant Palkar
*Using Hazard Analysis to Make Early Architecture Decisions for an Autonomous Automotive Application, Joakim Fröberg
*Understanding Quality Goals, David Gelperin
*What Coderetreats Have Taught Us About Design, Jim Hurne and Joseph Kramer
*When and Where to Apply the Family of Architecture-Centric Methods, Timothy Morrow, Michael J. Gagliardi, and William G. Wood
*Why They Just Don't Get It: Communicating Architecture to Business Stakeholders, Jochem Schulenklopper and Eelco Rommes









ADD 3.0: Rethinking Drivers and Decisions in the Design Process, Humberto Cervantes and Rick Kazman

Attribute Driven Design (ADD)—a method for designing software architectures—was developed by the Carnegie Mellon Software Engineering Institute. The first version of ADD was published in January 2000, and the second version was published in November 2006. Recently we have made some improvements to the method to increase its adoption by the software architecture community. ADD 2.0 focused on a conceptual architecture design and promoted the use of Patterns and Tactics as key concepts that drive the design process. Our experience, however, has shown that other important design concepts, including reference architectures and frameworks, are used in architectural design by practitioners. Furthermore, when ADD 2.0 was created, agile methods were not widespread. As a consequence, the method does not provide insights on how to use it in a more agile setting. To address these issues, we have created a new version of the method that we call ADD 3.0.

In this tutorial, we will introduce ADD 3.0 and explain the key changes that we made to its previous version. We will also present a detailed case study and walk the participants through a few iterations of the method, showing how the steps are performed. We will place particular emphasis on the design decisions that are made in the different design iterations. Finally, we will make a brief comparison of ADD to other design methods and close with a general discussion.






Agilizing the Architecture Department, Eltjo Poort

The secret to making architecting agile is to change your view of the main deliverable. An agile software development team does not deliver a “big-bang system,” but a continuous stream of improvements to a system. In the same way, an agile architect does not deliver 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. This view of architecture is the basis of Risk- and Cost-Driven Architecture (RCDA), an approach that has been developed by CGI and has been proven to support solution architects globally in a lean and agile manner.

In this session, I will report our experiences implementing RCDA at a major European transportation infrastructure organization. We used RCDA’s principles and practices to help the organization’s architects reconnect with their colleagues who had “gone agile.” The experience shows how to transform an approval- and compliance-oriented architecture department into a collaborative team that helps projects create “just-enough architecture” in tight time frames and explain their priorities and choices to business stakeholders.





A Partner Is Good to Have, but Difficult to Be, David Kane and Dave Dikel

This workshop will help participants build partnering skills and avoid pitfalls through games, examples, and discussion and show how these skills can produce better results for the architecture team and its customers. Architecture efforts can be sidelined without the engagement and trust of software developers and project managers, yet architects do not always see collaboration and service as part of their role. Lack of collaboration and service on the part of an architect can result in an architect's

uncertainty about whether and how well products are being used or delivering value
products and guidance being "worked around" rather than incorporated
rigid and less-than-effective use of stakeholder-related architecture practices
We will illustrate the importance of partnering in the context of architecture. We define partnering as "the extent to which architecture stakeholders maintain clear, cooperative roles and maximize the value that they deliver and receive." We will also share and facilitate a discussion using hands-on ideas and examples of how to build on existing partner relationships to increase engagement and trust.





Architecting Hybrid Cloud Solutions with Watson Developer Cloud, Will Chaparro

There is no question that cloud-based computing solutions can provide businesses with big value. IBM, Amazon, Microsoft, and Google all deliver cloud-based solutions that offer unique access to capabilities that on-premise solutions cannot provide. IT teams within the enterprise are constantly focusing on driving more of their solutions to the cloud, and there are really good reasons for doing so. However, certain enterprise solutions that favor an on-premise approach also present architectural constraints. How do you bring those cloud services capabilities into your on-premise solution? You go with a hybrid cloud environment.

In this presentation, we will describe the various hybrid cloud solutions that we created using the Watson cognitive services from IBM; share the architectural patterns, code, and tutorials on GitHub that we created; and discuss the pros and cons of the hybrid approach. We’ll also talk about the challenges that we encountered during our investigation.

By the end of the presentation, attendees will have the knowledge necessary to determine why they would want to take a hybrid approach to a cloud-based solution, the quality attributes to be concerned about, what architecture patterns could be used, and how they could use the samples on GitHub to deploy an actual integration of their own.





Architecting Public-Facing Website Software for High Concurrent User Load, Derrick Lau

It’s always important to architect public-facing websites to be responsive under high concurrent user load. Although part of this can be achieved using hardware infrastructure upgrades, nowadays performance is more heavily influenced by the software architecture, as noted in Dan Kegel’s C10K problem. This session will cover some lessons learned through experience and research about analyzing the problems of an existing public-facing website, and it will use the lessons learned from the analysis to develop some suggested enterprise architectural patterns to resolve them. The lessons learned include

web content management (WCM) content delivery architecture: the decoupled content delivery pattern
architecting online real-time features: the web real-time communication pattern
Upon completion, the audience will have two architectural patterns to help with architecting public-facing websites as well as an understanding of how I came to these theorems. This subject matter is mostly focused on architecting for two specific engineering paradigms that will be part of SATURN 2015:

SOAs and concurrent/event-driven systems
high-scale, high-volume web applications






Cost-Benefit Analysis in Technical Debt Reduction, Andriy Shapochka

A software project is so burdened with technical debt that it can hardly move forward with new features. As an architect, how will you set goals for reducing technical debt, calculate their relative costs and benefits, and develop an executable road map? This report proposes a practical approach proven by a real-world case study

using quality attribute scenarios to analyze technical debt
using cost-benefit analysis for reducing technical debt 
building a road map for reducing technical debt
A professional software engineer or an architect understands very well what technical debt is and how it burdens product development. However, coming up with a case that will convince management to allocate time and resources to its reduction often proves difficult when there is a full stack of functional must-have features on the table.

The presentation provides a case study for a practical approach to cost-benefit analysis of technical debt based on eliciting quality attribute scenarios and employing the SEI Cost Benefit Analysis Method (CBAM). This approach was successfully applied in an architectural assessment conducted by a team of SoftServe consultants including the author for a major international networking hardware and software vendor, and it resulted in building and executing a roadmap to optimize technical debt reduction for the assessed product.





Design Thinking Is for You, Ariadna Font Llitjós, Jeff Patton, and Jonathan Berger

User Experience and Design is not an isolated function or a step in the software development process anymore. It has evolved from a specialty to a way of working that puts users at the center and permeates most development activities throughout the release cycle.

There is a clear shift away from design just as a product (i.e., specific deliverables and artifacts such as high-fidelity mockups to throw over the wall to developers) that continues to gain momentum as the activity of design that focuses on understanding and solving a specific problem for a specific set of users.

Jeff Patton, one of the fathers of modern User Experience and bringing UX into Agile, will share his insights from the perspective of a developer who has moved into design. On the other hand, Jonathan Berger, an agile design practitioner and speaker, will tell us about his experience as a designer who has ventured in the world of coding and software development.






DevOps Essentials for Software Architects, Len Bass 

Software architects tend to think in terms of “code complete.” But “code complete” is not “code in production.” There are potentially long delays between the time that code is complete and the time that code is placed into production. These delays are caused by the necessity for coordination among all of the various stakeholders to achieve consistency in both the developed code and the supporting technologies and libraries.

DevOps is a set of practices intended to reduce the time between committing a change to a system and placing that change into normal production, while ensuring high quality. That is, the goal of DevOps is to reduce the time between code complete and code in production. One important technique is to have a tool chain that automatically places code into production after a commit. This is called continuous deployment. Continuous deployment is most effective when coupled with the use of a microservice architecture.

In this session, three experts in DevOps will lead you through a discussion of “What is DevOps?” “What is continuous deployment?” and “What is microservice architecture?” You will come away not only with an appreciation of the reasons for the time between code complete and code in production but also with a collection of techniques that will enable you to reduce that time in your organization.






Does Your Cloud Solution Look Like a Mushroom?, Kim Carter

This presentation draws from my recent blog post “Journey to Self Hosting” and many more resources for some high-level ideas about cloud solutions. I'll discuss what's good and what's not good about "The Cloud." I’ll provide an overview of the many security issues that entities need to think about when deciding whether to use the cloud or to build in-house infrastructure. Owning the technical expertise isn't always necessary. On the other hand, in-house solutions can provide finer grained customized solutions with potential for greater visibility and control than can cloud offerings that are more generic. I'll also discuss my personal journey and what I've discovered along the way, including how you can make the right decisions based on others’ experiences and learn from their mistakes rather than your own.





Enterprise Applications Health Improvement Program, Eswaran Thandi

An application's stability and longevity must be strengthened and extended to support business continuity and agility without increasing the cost of IT and human capital. This presentation introduces a program called the Application Wellness Clinic that organizations can use to address this business concern. The clinic is owned and initiated by an architecture team, and collaboration is the key to its success. This presentation will describe the new method, its framework, and the set of tools and guidelines required to run the clinic.

For the Application Wellness Clinic, a few key parameters are selected to assess an application's health. The clinic provides a 360° focus on the application and will make its health more transparent to business and senior management teams. Each application will have a different execution path based on its position in the development and sustainment life cycle, and each execution path will be unique in nature and duration. During the execution process, the clinic produces a quality attribute-level and application-level health index called the Enterprise Application Health Index (EAHI). At the end of the clinic, each application will have regular cycles for diagnosis and recovery.

Improving the health of the application to an acceptable level is the primary objective of the Application Wellness Clinic. The clinic will also develop time and cost estimations for improving and maintaining the application's health. This clinic not only recovers the health of an application, it also helps reveal the level of operational efficiency in the business and reduce operational costs.






Exploiting Fast and Slow Thinking, Rebecca Wirfs-Brock

As team leaders or architects, we can benefit from knowing more about how we think, deliberate, and decide. Thinking, Fast and Slow, by Daniel Kahneman, explains two systems that drive how we think. System 1 thinking is fast, intuitive, and emotional; System 2 is slow, deliberate, and logical.

In this session, you will learn how fast and slow thinking affects your decision making. You’ll explore how common development practices, with an emphasis on agile practices, can amplify your thinking abilities and how they might lead you astray. For example, Given-When-Then behavior-driven development (BDD) scenarios are concrete and specific. They prevent us from leaping to conclusions about expected results. Those same BDD specs can also lead you to believe that’s all there is. The Pomodoro Technique helps block work into manageable chunks, making time for uninterrupted slow thinking. But what else might you do?

Fast thinking works well in familiar contexts. You save time when you don’t have to deliberate over details to make informed decisions. But fast thinking can lead to poor decisions. You might jump to conclusions, be wildly optimistic, or under-assess risks and rewards. You need to exploit both fast and slow thinking on agile projects. And you need to be aware of when fast thinking is tripping you up.

During this session, you will explore some impacts of fast and slow thinking and share where you might need to slow down or speed up. You will practice reframing questions about specific situations in terms of fast and slow thinking. And you’ll identify specific situations where your thinking needs to shift and explore how to make those shifts.






From Monolith to Microservices: A Leadership Perspective on Legacy Application Modernization, Einar Landre, Jørn Ølmheim, and Harald Wesenberg

In this presentation, we will share some thoughts on the leadership challenges that come with modernizing legacy systems. Our reference case is an ongoing modernization of a 20-year-old custom-made client/server application consisting of about 3.5 million lines of code. The modernization effort is driven by a need to reduce cost of ownership, position the system for new deployment models such as cloud, and facilitate shorter time to market for new business features. It is also about reducing vulnerability, as there are more developers in the market who are masters of JavaScript than of PowerBuilder.

From an architectural perspective, the aim is twofold. First, consolidate on fewer but more up-to-date technologies. Second, create a more loosely coupled architecture by introducing functional separation through horizontal and vertical slicing, in many ways moving toward what today is called "microservices," and do this in line with the principles in our management system, adhering to natural business process boundaries.

From a leadership perspective, the challenge is to effect the cultural and organizational changes needed to create architecture in line with modern principles, seizing the opportunities offered by new technology. We need to break the mindset incurred by the relational database—that everything has to be interconnected in a global model—and replace this by a mindset and technology that support deployment of smaller but cohesive functional services or modules. A major challenge here is technologically outdated domain experts, key stakeholders who are stuck in the possibilities of yesterday's technology.





Improving Architectural Refactoring Using Kanban and the Mikado Method, Paul Boos

Have you ever found yourself making a change to a system only to have dozens of bugs or other issues pop up? Then you make some more changes trying to solve those and, yikes, more are found! You're on the software spelunking trip from hell with the cavern walls collapsing...

Embrace the Zen of the Mikado Method. This powerful approach allows you to discover, visualize, and safely make all the changes you need without losing your mind by giving you input into dependencies that can drive your work priorities. Since it contains a visualization technique, it can help your teams understand legacy code and its impacts and then communicate these to stakeholders. Combine this with a Kanban board to help you visualize your progress, and now you can easily see how well you are making progress.

This 30-minute presentation will step you through the following topics:

What is the Mikado Method?
How does it work?  
Exploring the issues and populating the Kanban backlog  
Why is Kanban a good fit for maintenance?





Injection, Modularity, and Testing: An Architecturally Interesting Intersection, George Fairbanks

Dependency injection, code modularity, and testing often seem like staid, even boring, topics, but there are surprises when you put all three together. Seemingly independent decisions about each influence the others. Making rational development decisions each day can still lead you into a thicket of complexity and loss of maintainability. So when should you give it your “architectural attention”? This talk discusses the problem and suggests some limited solutions.




Introduction to Architecture-Centric Design Thinking, Michael Keeling

Designing the architecture for software-intensive systems can be difficult, even for experienced architects, let alone developers transitioning into an architect’s role. While the prevailing literature does a great job of describing core software architecture concepts, it does a relatively poor job of sharing practical advice for how to actually “do” design. As a result we, as a software architecture community, know a lot about software architecture but have a hard time teaching new architects how to apply this knowledge.

Design Thinking is a framework for understanding and creatively resolving problems. Design Thinking practices are often human-centered and encourage designers to build empathy with stakeholders who experience the problem and will ultimately benefit from a solution. While Design Thinking has roots in industrial design and urban planning, it has only recently been applied within the software industry and only then within the relatively narrow scope of user interface design. This is too bad as I’ve found Design Thinking to be a useful tool in the context of software architecture as well.

During this talk I will share my experiences adapting practices from the user experience community for use in architecture-centric design. I will first establish a foundation for user-focused design theory and then describe practical methods for applying design thinking in the context of software architecture with examples from my direct experience.





Keeping the Beat: Rhythm and Trust in Architecture, David Kane

Maintaining an effective rhythm has long been recognized as an attribute of successful architecture. It is easier for the many organizations involved with the architecture if there is a predictable tempo, content, and quality associated with the architecture. Rhythm is also an important quality of many agile software development methods. I define rhythm in this context as “the recurring, predictable exchange of work products within an architecture group and across its customers and suppliers.” This talk will argue that rhythm is important for establishing trust in architecture and architects. The talk will also present some ideas on how architects can establish and sustain an effective rhythm.





(Keynote) Progress Toward an Engineering Discipline of Software, Mary Shaw

Is “software engineering” really engineering? The term was coined in 1968 to call attention to problems with software production. Both theory and practice for software have evolved since then, but do we yet have a true engineering discipline? Classical engineering disciplines have emerged from craft practice and commercialization through the infusion of codified knowledge and science. Using this emergence pattern as a point of reference, I will sketch the evolution of software engineering, drawing on civil engineering and software architecture for examples that show the progressive codification of informal knowledge toward rigorous models and tools. This will provide the basis for assessing the maturity of the field and identifying our next challenges.





Leading Change: Engaging Critical Stakeholders for Project Success (Presentation and spreadsheet), Marisa Sanchez

Software architects, development managers, and other technical managers are change leaders—they have a role to champion change in their organizations. Often technical leaders focus solely on building a great technical solution. In fact, what we know about organizational change is that adoption is based on a variety of factors, of which only one is the quality of the solution. And quality may not even be among the top reasons for change adoption! An essential skill in leading change is stakeholder engagement—identifying stakeholders (those individuals who can affect or be affected by your project), assessing stakeholder influence and support, and engaging your most critical stakeholders for maximum impact.

So how do you get started, and what are the tactics? In this 90-minute hands-on session, participants will use a one-page template to guide them through a three-step process for stakeholder engagement. In the course of completing their own stakeholder engagement plans for a project in which they are currently involved, participants will learn how to identify, assess, and engage stakeholders to increase the likelihood of technical change adoption. What are the major types of stakeholders? Which important stakeholders are often overlooked? Who already supports the change, and who needs to support the change? What are the various engagement strategies that can be employed? Who should engage which stakeholders? The one-page template is available electronically so participants can save their work and be ready to put their plans into action when they get back to the office.




Living a Nightmare, Dreaming a Dream: A Drupal Deployment Dilemma, Gail E. Harris

Two and a half years ago, I started a new job. I was very excited, and I looked forward to making my mark in the first 90 days before tackling any big issues. A few weeks into this new job, the system administrator began complaining about having to explain yet again the steps to deploy a release. I started asking questions. What I discovered shocked and appalled me, and it spurred me to dream a dream. This sys admin described a process for deploying a release to production, for even tiny code changes, that involved three repetitions of manual regression tests, putting the entire site into maintenance mode, working between midnight and 4:00 a.m., and other nightmarish procedures. I embarked on a quest to bring this organization into the 21st century of infrastructure and development best practices. In broad strokes, this involved organizational changes in the department by creating new roles and reporting relationships, motivating key individuals, introducing new development practices, and, of course, introducing new technologies. Our experiences show three key results: motivational changes are tightly aligned with organizational changes, ops and dev working collaboratively is mandatory, and technology choice matters least of all.





Locating the Architectural Roots of Technical Debt, Rick Kazman, Yuanfang Cai, Serhiy Haziyev, and Volodymyr Fedak

In our studies of many large-scale software systems, we have observed that defective files seldom exist alone. They are usually architecturally connected, and their architectural structures exhibit significant design flaws that propagate bugginess among files. We call these flawed structures the architecture roots, a type of technical debt that incurs high maintenance penalties. Removing the architecture roots of bugginess requires refactoring, but the benefits of refactoring have historically been difficult for architects to quantify or justify. In this talk, we present a case study of identifying and quantifying such architecture debts in a large-scale industrial software project. Our approach is to model and analyze software architecture as a set of design rule spaces (DRSpaces). Using data extracted from the project’s development artifacts, we were able to identify the files implicated in architecture flaws and suggest refactorings based on removing these flaws. Then we built economic models of the before and (predicted) after states, which gave the organization confidence that doing the refactorings made business sense, in terms of a handsome return on investment.






Making Better Architectural Choices with the Architecture Valuation Framework, Voytek Janisz

In an era when generating business value is the principle consideration of what enterprise architecture (EA) does, many EA organizations face the challenge of demonstrating the value of a specific architecture choice. The challenge is further compounded by the fact that the value of architecture is often demonstrable only long after the architecture has been put in place. Even then, the ability to assign value to architecture—as opposed to a specific tool, process, or organizational change—is difficult. Departing from the "I told you so" approach for measuring the value of architecture, the Architecture Valuation Framework aims to quantify value of architecture choices at the time when those choices are being made. Expressed in business terms and echoing the concerns of cost, speed, and quality, the Architecture Valuation Framework is a technique that provides pertinent data, in the form of quantitative measures, to decision makers to aid in selecting an optimal architecture choice among alternatives.

This session discusses the structure of the framework; the approach to implementing it; and its applicability to the target architecture definition process, solution reviews, and the strategy definition.





Maturing Agile Teams and Driving Quality Through Architecture Principles, Amine Chigani and Yun Freund

The architect’s effectiveness to drive sound architectural decisions and reconcile tradeoffs that positively impact the quality of software solutions can be inhibited when development teams are immature and appropriate quality assurance process and tools are lacking. Teams that must adapt their agile software engineering approach to fit non-agile organizational structures and business contexts find this challenge particularly apparent.

This experience report shares insights and lessons learned from a yearlong effort to work with newly formed agile teams to standardize on quality assurance practices and tools across projects for a customer who is new to agile development. It presents a set of process, skill set, and infrastructure changes driven by architecture quality attributes that enabled our teams to become more productive and more effective in engaging with the customer. While challenges remain, our teams today are better equipped not only to map quality attributes such as performance and integrate-ability to specific development activities but also to manage and measure these attributes.

In presenting these lessons learned, we structure the talk into three sections. First, we briefly describe our business context and development environment for teams working directly on several customer solutions. We then provide details of the quality initiative that introduced new quality practices, infrastructure, and development skills to the teams, while highlighting several of the challenges we faced. Finally, we share insights and tactics, from an architect’s perspective, that can help with these challenges, particularly the ones related to agile, architecture, and driving quality attributes for a non-agile customer.





Maximize Your Business Impact as an Architect, Eltjo Poort

How can architects be most effective? What concerns and decisions should they focus on? And what should they postpone or leave to designers and coders? Practicing architects are often under pressure from stakeholders such as project and program managers and product owners to address the “concern of the day” or to finish deliverables according to fixed schedules and rigid methodologies. Blindly giving in to such pressure leaves key risks unaddressed and delays high-impact decisions, which threaten project success and product quality.

In this participatory session, we will discuss and exercise key principles for architects to prioritize architectural concerns based on economic aspects:

how to prioritize architectural concerns and decisions based on objective, economic arguments
how to justify your priorities to business stakeholders and increase your business impact  
how to prevent high-impact architectural concerns from remaining unaddressed due to schedule pressure
The principles can be applied in both agile (Scrum, SAFe) and more conventional settings. They help architects not only to maximize their economic impact by identifying the most important concerns and decisions to spend time and energy on but also to explain the rationale behind their priorities to stakeholders in business terms. The session is based on Risk- and Cost-Driven Architecture (RCDA), an approach that has been developed by CGI and has proven to support architects globally in a lean and agile manner. RCDA’s practices help architects create “just-enough architecture” in tight time frames. RCDA is a recognized architecture method in The Open Group’s architect certification program.






My Silver Toolbox, Michael Keeling

A few years ago, I started ending my presentations and workshops with the phrase "I hope that this is another tool you can put in your silver toolbox." The idea of the "silver toolbox" comes from a 2009 quote from Mel Rosso-Llopart of Carnegie Mellon University: "I can’t give you a silver bullet, but I can give you a silver toolbox!" I doubt Mel even remembers saying this. It was in the middle of a random lecture during the TSPi course he teaches—but I do remember. And that simple phrase concisely describes my entire approach to adopting and teaching software engineering methods and practices.

When I travel on-site with a customer, I always bring a "coach’s bag"—a cheap Vivisimo handbag filled with various tools I nearly always need to facilitate workshops, enhance ad hoc design sessions, create documentation, or generally improve discussions. In my mind, I keep a tool kit of experiences—methods, bits of knowledge, nuggets of wisdom, strategies, and catch phrases.

These are the tools I have in my "Silver Toolbox." What’s in yours? Join me along with Simon Brown, Will Chaparro, George Fairbanks, Ari Font, and Gail Harris as we explore some of the tools of the trade and learn what it takes to be a software architect.






Never Again Offline?! Experiences in the Outstanding Role of Data in a Large-Scale Mobile App Ecosystem, Matthias Naab, Ralf Carbon, and Susanne Braun

Data is key in information systems. Nevertheless, explicit design of data is often neglected in architecture design because of the focus on components, decisions, or technology selection. We want to change this and put data in the center of the story.

We will share our experiences from an innovation and development project of John Deere and Fraunhofer IESE. We developed a mobile app ecosystem with several apps and its own cloud backend. During the course of the project, we learned that we had to pay more and more attention to the role of data due to its impact on the quality attributes performance, scalability, user experience, and security.

Our entertaining story starts with data on a single mobile device that spreads over multiple apps, users, devices, companies, tenants in our cloud backend, even data exchanged with agricultural machines. We report on security aspects, multi-tenancy, offline capability and synchronization, internationalization, and the different treatment of master data, job planning data, and high-frequency near-real-time data for the localization of vehicles in the field. All this is presented with a strong focus on data, elaborating step by step the challenges and our decisions in the system design.

Our audience will learn about many recurring architectural challenges and solution patterns around data in mobile app ecosystems, they will learn how recent patterns like Command Query Responsibility Segregation (CQRS) and many others helped us, and they will learn how technologically innovative today’s farming practices are.






Open Medical Record System Plus (OpenMRS+): OpenMRS for Non-Communicable Diseases, Gloria Ingabire

In developing countries where the health-care industry continues to experience significant challenges that hamper the provision of health-care services, interoperability and the connection of medical records are still an unrealized goal. Even though different types of medical record systems have been adopted, the journey continues due to environment, infrastructure, and financial issues. With the growth of information technology, the health-care sector has significantly improved, adopting various web- and mobile-based electronic medical records. A significant achievement has been the use of the Open-Source Medical Record System (OpenMRS) for HIV/AIDS and tuberculosis health-care services in developing countries such as Kenya and Rwanda. This system has proven to be more reliable and efficient for patient follow-up and allows for better health-care services in general.

In this presentation, I will describe the role that OpenMRS has played in the Rwandan health-care sector, why and how to expand its use to the treatment of noncommunicable diseases, and the process that should be followed in order to develop a new and complete module strictly designed for these diseases.






Open Systems Architecture: Progress and Challenges, Douglas Schmidt

Open systems architecture (OSA), an approach that integrates business and technical practices to create systems with interoperable and reusable components, has outstanding potential for creating resilient and adaptable systems, but the associated challenges make OSA one of the most ambitious endeavors in software architecture today. This panel discussion will focus on the progress made so far, the remaining challenges, and strategies for addressing those challenges.

Panel members will speak about OSA from several perspectives, including technical engineering, policy, contracting, and science and technology research. Participants will discuss their experiences with the practical trials of OSA and offer multiple perspectives—which might challenge one another—related to the technical, organizational, and business aspects of making it a reality.

Audience members from many different backgrounds will benefit from this discussion. OSA is a growing area of interest for the Department of Defense (DoD) as important DoD stakeholders recognize its significant potential. Federal workers who attend this panel will take away an understanding of where things really stand with OSA: How much is hype and how much is reality? General practitioners will also benefit from the lessons learned from the OSA adoption push, such as how software architecture can support reconfigurability, recomposability, and other -ilities.

OSA is a promising and important undertaking that deserves a broad, realistic treatment of what has been accomplished so far, how much of the underpinning is technical (especially architectural) versus organizational or business related, and how far we really have to go before its potential becomes reality.







Programming in the 1960s: A Personal History, Len Bass

This talk is for those who would like to visit the computer museum but haven't yet had the time. I was hired as a programmer in 1964, and I’ll tell some stories about what life was like then for programmers. If you attend, you will learn

why it wasn't my fault
why the difference in size between an IBM 360/67 and a CDC 6600 mattered  
what the IBM repairman did to warrant being treated as a terrorist  
why hairstyles were much shorter in the '70s than in the '60s





QA to AQ: Shifting from Quality Assurance to Agile Quality, Joseph Yoder and Rebecca Wirfs-Brock

As organizations transition to agile processes, quality assurance (QA) activities and roles need to evolve. Traditionally, QA activities occur late in the development process, after the software is fully functioning. As a consequence, QA departments have been "quality gatekeepers" rather than actively engaged in the ongoing development and delivery of quality software. Since agile teams incrementally deliver working software, this provides an opportunity to engage in QA activities much earlier, ensuring that both functionality and system qualities are addressed just in time. Agile teams embrace a "whole team" approach. Even though special skills may be required to perform certain development and QA tasks, everyone on the team is focused on the delivery of quality software.

Prioritizing and implementing necessary functionality keeps an agile project moving forward. However, it is also important to focus on system quality at the same time. Otherwise, qualities can get shoved aside or wistfully imagined as emerging along with the architecture. This session will show you how you can interject quality specification, design, and testing efforts into your project and be more agile about it. We will introduce agile techniques and patterns of practices that support the definition and delivery of system qualities. We will also discuss the role of QA and architects in agile teams and how they ensure that important qualities are addressed in an agile manner that emphasizes architecture capabilities such as usability, security, performance, scalability, internationalization, availability, and accessibility.






Quality Requirements on a Shoestring, Thijmen de Gooijer

Traditional Quality Attribute Workshops (QAWs) are costly and cumbersome to organize for large and/or geographically dispersed organizations. Yet good quality requirements are key to making the right architectural decisions in the design process. At SATURN 2014, Chaparro and Keeling presented the mini-QAW, proposing a way to pare down the QAW activities and do part of the work offline. We extend their format with a stakeholder empathy exercise to fill in for absent stakeholders. During the exercise, participants brainstorm to create a list of stakeholders for the system. Each participant chooses a stakeholder from the list to empathize with and create scenarios for, before listing his or her own concerns. In addition, we propose the use of UI mockups as a method to support quality attribute scenario generation. The method is an alternative to quality attribute taxonomies or unstructured brainstorming. Finally, we report how we used the Microsoft Lync online meeting tool to include remote stakeholders via its annotation feature. With our changes, we successfully ran two QAWs of 2 and 3.5 hours at ABB. We can now rely on a smaller set of stakeholders and do not need all stakeholders to travel to the same location. This contributes to a lower time investment for the QAW and reduced travel cost for participants. A workshop according to the mini-QAW format will not give results of the same depth and breadth as a traditional QAW but should be used as a tool for smaller, low-risk, or iterative projects.






Smart Decisions: An Architecture Design Game, Serhiy Haziyev, Olha Hrytsay, Rick Kazman, and Humberto Cervantes 

In this participatory session, you'll have fun and learn about the challenging process of designing an architecture for a Big Data Analytics System by playing a game called Smart Decisions, which simulates the architecture design process through a series of iterations. The game can be played individually or as a group of architects, and the players compete against each other in a simulated architecture design activity for a complex Big Data Analytics System. In each iteration, the players must solve a challenge associated with an iteration goal and a set of architectural drivers including quality attributes and constraints. Solving this challenge requires making design decisions that, in the game, are the selection of one or more design concepts such as tactics, patterns, or externally developed components such as frameworks. Players are scored according to the choices they make, and the player who completes the challenge and gets the highest score wins.

The game is followed by a discussion with the participants in which we review several principles illustrated in the game, including these points:

Architecture design can be performed systematically in an iterative way.
Each iteration has a goal and a set of associated drivers or concerns.
Quality attributes can have different meanings.
There exist different types of design concepts and a wide variety of each type.
Selection of design concepts needs to be made by taking into account several aspects including the iteration goal, concerns, drivers, and prior decisions.





Software Architecture as Code, Simon Brown

Over the past few years, I’ve been distilling software architecture down to its essence, helping organizations adopt a lightweight style of software architecture that complements agile approaches. This includes doing "just enough" up-front design to understand the significant structural elements of the software, making some lightweight sketches to communicate that vision to the team, identifying the highest priority risks, and mitigating them with concrete experiments. Software architecture is inherently about technical leadership, stacking the odds of success in your favor and ensuring that everybody is heading in the same direction.

But it’s 2015 and, with so much technology at our disposal, we’re still manually drawing software architecture diagrams in tools like Microsoft Visio. Furthermore, these diagrams often don’t reflect the implementation in code, and vice versa. This session will look at why this happens and how to resolve the conflict between software architecture and code through the use of architecturally evident coding styles and the representation of software architecture models as code.






Sustainably Supporting Data Variability, Atzmon Hen-Tov, Jordan Menzin, and Joseph Yoder

A big challenge in building complex, data-intensive systems is how to sustainably support data variation, schema, and feature evolution. In this session, three speakers—Atzmon Hen-Tov, a senior architect of a highly adaptable Telco platform; Jordan Menzin, architect of a Boston Health Economics’ health-care analytics system; and Joseph Yoder of The Refactory—share their experiences and hard-fought wisdom gained from building complex, data-intensive systems.

Invited Talk: Data Upgrade as a First-Class Citizen

Atzmon Hen-Tov explains how the ModelTalk system addresses data upgrade as an integral part of its product line architecture. Complex, large-scale business support systems in the telecommunication industry require high dependability while market pressures demand frequent releases. One aspect that hampers agility in a highly dependable system is data migration. In Pontis’ ModelTalk, an executable modeling framework, upgrades are first-class citizens, allowing for rapid evolution, agility, and reuse while at the same time supporting multiple persistency technologies.

Invited Talk: High-Performance Dynamic Health-Care Analytics

Jordan Menzin of Boston Health Economics (BHE) reviews the core architecture and key decisions that went into the creation of Instant Health Data, a highly performant health-care analytics system. Leveraging distributed computing and domain modeling, BHE has created an extensible platform that enables researchers to complete analytics projects using diverse data sources without the need for custom programming. This enables them to process large health-care data sets an order of magnitude faster than with legacy technologies.

Invited Talk: Keeping Core Components Clean While Dealing with Data Variability

Joseph Yoder of The Refactory examines strategies, practices, and patterns drawn from real experiences that support new and evolving data-processing requirements while keeping the core architecture clean. As complex systems evolve to meet varying data formats, they can devolve into poorly architected Big Balls of Mud filled with special-case logic and one-off processing. Alternatively, you can isolate core components of your system and protect them from entanglements and unnecessary complexity by designing them to operate on common data formats while providing extension mechanisms that enable processing variations.







Systems Characterization: An Approach to Modernizing Disparate Legacy Systems, Jane Orsulak and Julie Kent

The authors are engaged in long-term operations and maintenance of multiple large-scale systems with fluctuating operational requirements. To find the most cost-effective means to update and upgrade these systems, we used a systems architecture view to create a consistent method. The process stresses the importance and value of data-driven assessment of an as-is architecture to guide evolution of the to-be architecture. This process results in knowledge with supporting data that can be transferred to customers, including the U.S. government, to create substantiated purchase requests with measurable return on investment.






Systems of Action: A Stack Model for Capability Classification, Einar Landre and Jørn Ølmheim

For almost 10 years, Statoil’s IT has worked on how to best develop and deploy what we have called systems of action, systems that are described by three key capabilities: First, they can observe a phenomena, process, or machine. Second, they process their observations in search of anomalies and deviations that must be dealt with. Third, they identify and execute the best possible actions to bring the observed phenomena, process, or machine back to its desired state. In parallel they monitor the effects of their actions and re-plan and adapt their actions based on observed effects.

Systems of action will operate with some level of autonomy; they will interact with human operators in trust-based collaborations, and they can be tasked with missions. They build heavily on the theory and concepts of rational agents and multi-agent systems as defined by Shoham and Leyton-Brown: “a combination of multiple autonomous entities, each having divergent interests or different information, or both.”

Their development involves use of cybernetics and AI technologies, including decision theory, learning, and belief representation. Architecturally they have a lot in common with what is called microservices. To ease development of systems of action, we have developed a stack model defining a capability hierarchy that we used to position applicable technologies.





Taming Big Balls of Mud with Agile, Diligence, and Hard Work, Joseph Yoder

Big Ball of Mud (BBoM) architectures are viewed as the culmination of many design decisions that, over time, result in a system that is a hodgepodge of steaming and smelly anti-patterns. It can be arguably claimed that one of the reasons for the growth and popularity of agile practices is partially because the state of the art of software architectures is not that good. Agile methods, with their focus on extensive testing and frequent integration, have been shown to make it easier to deal with evolving (possibly muddy) architectures and to keep systems working while making significant improvements and adding functionality. Time has also shown that agile practices are not sufficient to prevent or eliminate Mud.

This session will examine the paradoxes that underlie BBoMs, what causes them, and why they are so prominent. I'll also explain why continuous delivery and test-driven development with refactoring are not enough to ensure clean architecture. Additionally, I'll talk about some practices and patterns that help keep the code clean. Some of these include Testing, Divide & Conquer, Gentrification, Demolition, Quarantine, Refactoring, Craftmanship, and the like. The original BBoM paper described some best practices such as Shearing Layers and Sweeping It Under the Rug as ways to help deal with muddy architectures. Additionally, other practices such as Paving over the Wagon Trail and Wiping Your Feet at the Door can make code more habitable.





The Architectural Analysis for Security (AAFS) Method, Jungwoo Ryoo and Rick Kazman

Security is a quality attribute that has both architectural and coding implications—it is necessary to get both right to create and maintain secure systems. But most of the existing research on making systems secure has focused on coding, and there is little direction or insight into how to create a secure architecture. In this talk we propose several ways to analyze and evaluate the security readiness of an architecture: vulnerability-based (VoAA), tactics-based (ToAA), and pattern-based architectural analysis (PoAA) techniques. We first compare the strengths and weaknesses of each approach. Next, we show that these different approaches are complementary to each other. Finally, we describe how to combine these analysis techniques in a single analysis method to obtain the best outcomes. We employ our blended analysis technique in a case study to demonstrate the feasibility of our architectural-security analysis method.






The Business Side of a Software Architect, Tomer Peretz

One of a software architect's roles is to translate business needs into software and to verify that a running software satisfies business needs. It is obvious that in order to translate between two different languages, one must know both languages to a satisfying level. Is this also the case with software architects? As most software architects rose from the software world, how important is it that those architects also speak “business” fluently? When building the software architecture group in my company, we had to answer this question while considering the required knowledge, experience, and training program for software architects.

One challenge that we frequently face is how to efficiently translate business needs to running software, specifically in projects that involve many nontechnical stakeholders. The software architects’ ability to understand the business environment and to identify lacks in the alignments between software requirements and business drivers is essential. This ability requires extracting business-related information and using it as part of software architecture processes, such as QAWs and ATAMs.

When facing the business world, the software architect meets new terms, models, and mindsets. The ability of a software architect to understand models such as strategic differentiation, levels of product, and segment invasion strategy helped us bridge the gap between those two worlds. In this presentation, we share these experiences and ideas, through which understanding business terms, models, and methodologies can assist software architects to achieve their goals more effectively.






The Value of Architecture and Architects, Shrikant Palkar

IT departments and architects are increasingly called on to drive real business value. Frequently architects work hard on delivering the design of a solution, details of an infrastructure, usage of information, and goals and capabilities of an enterprise. During this process, they use frameworks, appropriate tools, and patterns. However, the majority of software, solution, and enterprise architects are constantly challenged in industry to prove the value of architecture to business.

In this presentation, we review how architects can achieve value through both design decisions and strategic involvement. We will discuss the value contribution categories, or roles that architects can play, to make architecture and architects successful. I will focus on sharing techniques and lessons learned from being part of and managing large teams of architects. Ultimately these techniques will enable immediate and long-term impact as we wear the hats of Evangelist, Collaborator, Counselor, and Subject-Matter Expert.






Using Hazard Analysis to Make Early Architecture Decisions for an Autonomous Automotive Application, Joakim Fröberg

Developing a producible autonomous vehicle requires addressing functional safety compliance, an effort that can be considerable. The computer system has a much larger scope than does a traditional automotive system, and many of the functions are critical to avoiding hazardous events, which increases the design and development effort. Some architectural decisions must be made early in the design process and include issues of redundancy, system separation, and functionality limitations. These decisions could greatly influence the effort to achieve the required level of safety at a later stage, and an early analysis of their effects can help avoid unexpected compliance problems later.
We performed systems engineering tasks on a case of an autonomous hauler for quarry-type work sites. We defined system use cases, developed an overview functional architecture, and performed a preliminary hazard analysis for the intended application. Our proposed method combines common systems and safety engineering tasks that can be conducted early in the life cycle, and we illustrate how the outcome can be analyzed to inform early design decisions.  

Issues of system partitioning and redundancy have a potentially high impact on the effort to achieve functional safety compliance, and some of those decisions are highly architectural and need addressing relatively early in a design process. Use cases, activity diagrams, and overview function block diagrams can be defined early and act as input to a preliminary hazard analysis, which in turn provides valuable input to early decisions about partitioning and redundancy.






Understanding Quality Goals, David Gelperin

Many developers have a shallow understanding of how to achieve quality goals such as safety, security, and availability. Even when architects have a deep understanding of this, developers' lack of awareness can still endanger product quality. The challenge is to help developers achieve an understanding of quality attributes adequate for project needs. Quality Assumption Reviews help to meet this challenge. Their goal is to synchronize understanding of quality attributes, how they differ from functions, and how they "work" by making quality assumptions visible. When such reviews precede quality goal identification (e.g., QAWs), they make it more effective. They are tactics to address what should be a short-term understanding deficit.

A "quality champion," such as an architect, lists a set of basic assumptions about qualities and their achievement. The list is distributed to the project team prior to review. Assumption discussions prior to review should be encouraged. During the review, the team discusses various assumptions and asks questions. Participants identify problems with assumptions or their statements. Team member experience and understanding of quality goals determines which assumptions need discussion.

This session will model a review of a comprehensive set of quality assumptions. A strategy for demonstrating the subsequent degree of quality understanding will also be described.






What Coderetreats Have Taught Us About Design, Jim Hurne and Joseph Kramer

Coderetreats are daylong, intensive practice events that focus on software development and design fundamentals. The coderetreat format provides developers with an opportunity for focused practice and skills development away from day-to-day job pressures. During a coderetreat, participants work in pairs to implement Conway's Game of Life in any programming language of their choice. A brief reflection discussion follows each development session, after which participants delete their code, find a new pair, and repeat the exercise with a new set of design constraints chosen by the facilitator.

Practicing basic software development principles (such as object-oriented design, functional programming design, and design simplicity) improves developer mastery and awareness of important architectural principles, including designing for specific quality attributes such as modifiability, maintainability, testability, and extensibility. Coderetreat participants explore many alternative designs and architectures throughout the day with the goal of discovering designs with a low cost of change.

During this presentation, we will share our story about using coderetreats at IBM as a means of knowledge sharing, team building, and fostering a sense of craftsmanship across organizational boundaries. We will share what we have learned about software design and architecture after facilitating and observing five years of coderetreats, both publicly and within IBM.






When and Where to Apply the Family of Architecture-Centric Methods, Timothy Morrow, Michael J. Gagliardi, and William G. Wood

In this presentation, we discuss architecture-centric methods that have been developed and used with DoD, federal, and commercial customers. The architecture-centric methods include the Quality Attribute Workshop (QAW), Mission Thread Workshop (MTW), Architecture Tradeoff Analysis Method (ATAM), System ATAM, and System of Systems (SoS) Architecture Evaluation. The conceptual flow of each method with its inputs and outputs is presented to provide a foundation for the participants. We demonstrate how the methods are used to support requirements elicitation, evaluate architectures, and identify potential risks. The methods, especially when used together, provide lightweight, flexible processes to address systems, SoS, and software architectures. We discuss examples that show how the methods have been combined and where variations can be made to support different situations. Applying these methods early in a program’s life cycle to clarify requirements and identify potential risks enables the program to address and mitigate potential issues before finalizing designs.





Why They Just Don't Get It: Communicating Architecture to Business Stakeholders, Jochem Schulenklopper and Eelco Rommes

Communicating about architecture is hard, especially with stakeholders who do not have technical backgrounds. Many architects use standardized languages like UML or ArchiMate as their weapon of choice, because of their universal applicability and formalized semantics. But often, such diagrams do more harm than good. They confuse the stakeholders, or they are dismissed as being “just for techies.” Using these diagrams to explain your architecture to nontechnical stakeholders can feel like teaching someone how to drive a car by handing over the technical design schematics—frustrating to everyone and not effective at all.

We present practices and techniques for creating architecture visualizations that are attractive, informative, and easy to understand for nontechnical audiences. We have developed and applied these techniques in all kinds of organizations as architecture consultants and trainers. Throughout the talk, we will show examples from actual practice of great and not-so-great attempts in visualizing architecture. We offer techniques and practices that help you sell your architecture proposal, communicate the current and desired state of an organization’s architecture, or create that much-craved sense of urgency, even when faced with the pointiest haired of bosses.

After our presentation, attendees will have learned

why communication about architecture should be done in a language that is tailored to the audience’s needs
creative ways to effectively communicate about IT architecture with nonarchitects  
how to incorporate business aspects in descriptions/visualizations of IT architectures  
how to deal with business people's different backgrounds, interests, and skills