SATURN2015

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.

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.

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.

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?

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.

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.

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.

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.

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. 

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.

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.

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.

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.

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.

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.