Software Architecture, Design, and Modeling

Complex software always has an architecture, even if it isn't intentional. Being agile isn't enough. It isn't prudent to just keep your code clean and hope that good architecture will simply emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques for incorporating architectural activities into complex agile projects and explains how an agile architect's role differs from traditional software architects.

The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn't require ongoing attention. But it isn't always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.

So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.

Complex software always has an architecture, even if it isn’t intentional. But being agile isn’t enough to enough guarantee a sustainable architecture. It isn’t prudent to just keep your code clean and hope that good architecture will just emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques and architectural activities that are useful on agile projects and explains how an agile architect’s role can and should differ from that of a traditional software architect.

Complex software always has an architecture, even if it isn’t intentional. But being agile isn’t enough to enough guarantee a sustainable architecture. It isn’t prudent to just keep your code clean and hope that good architecture will just emerge. Especially when there is a lot of technical risk, interdependencies, and conflicting priorities. Good architecture requires ongoing attention and stewardship. This talk presents several techniques and architectural activities that are useful on agile projects and explains how an agile architect’s role can and should differ from that of a traditional software architect.

Many organizations struggle with efficient architecture decision-making approaches. Often, the decision-making approaches are not articulated or understood. This problem is particularly evident in large, globally distributed organizations with multiple large products and systems. The significant architecture decisions of a system are a critical organization knowledge asset, as well as a determinant of success. However, the environment in which decisions get made, recorded, and followed-up on often confounds rather than helps articulation and execution of architecture decisions. This paper looks at aspects of architecture decision-making, drawing from an industry-based case study. The data represents findings from a qualitative case study involving a survey and three focus groups across multiple organizations in a global technology company. Architects in this organization are responsible for multiple products and systems, where individual products can include up to 50+ teams. The impact is not just on others in the system; architecture decisions also impact other decisions and other architects. The findings suggest recommendations for organizations to improve how they make and manage architecture decisions. In particular, this paper notes the relevance of group decision-making, decision scope, and social factors such as trust in effective architecture decision-making.

Pattern authors intentionally create waypoints—points of interests along a design trail they hope others can traverse. While designers may read others’ design advice—be it patterns or stack overflow replies, the heuristics they’ve personally discovered are equally important. Patterns are just a small part of a much larger body of our design know how. Heuristics, like patterns, can be expressed at various levels. Some are small, simple acts. Others are bigger steps, taken at the beginning of a design journey. This essay explores ways we can grow as designers by becoming more aware of our heuristics, acknowledging the inherent uncertainty in the design process, and learning better ways to articulate and share our heuristics with each other.

Architects always make decisions in some context. That context shifts and changes dynamically. Different decision-making strategies are appropriate in different contexts. Architecture decisions are at times made under conditions of time pressure, high stakes, uncertainty, and with too little information. At other times, decision-makers have sufficient time to reflect on the decision and consider alternatives. Understanding context is critical to choosing appropriate approaches to architecture decision making. Naturalistic Decision Making (NDM) explains how people make decisions under real-world conditions. This paper investigates NDM in software architecture and studies architecture decisions in their environment and decision-making context. The research approach includes a case study of large technology organizations consisting of a survey, multiple focus groups, and participant observation. Previous studies that touch on NDM in software architecture have mainly focused on decision-making processes or tools or developing decision models. This paper provides three contributions. First, we build on previous studies by other researchers to produce an in-depth exploration of NDM in the context of software architecture. We focus on Recognition-Primed Decision (RPD) making as an implementation of NDM. Second, we present an examination of the decisions made by experienced architects under conditions that can be considered naturalistic. Third, we provide examples and recommendations that help software architects determine when an NDM approach is appropriate for their context.

Pattern authors ostensibly are experts on the topic their patterns address. Since most software developers don’t share those experts’ underlying design values, practices, and principles—let alone their design context—there’s a disconnect between what is said in pattern descriptions and that which is perceived and understood by pattern readers. As pattern readers, we will be better equipped to grasp the significance of these software patterns if we also gain insights into the design principles and values that they are based on and some reasons why they “work” the way they do. But it is through experience, practice, and reflection, that we deepen the connections between new-to-us patterns and our existing knowledge, and expand our design umwelt.

In the USA, to legally purchase alcohol, you must be over the age of 21. On some websites, before proceeding, the user is asked, “Are you 21 or older?” If they answer in the affirmative, they can proceed. But is that truly a rigorous design? Of course not! It’s rigor theater. We can lull ourselves in believing we’ve designed sufficiently rigorous systems when we have not. We can cause unexpected behaviors when we enforce rigor and it is too constraining.

Design and modeling rigor is desired when a precise, exact, definitive answer to a question should determine and constrain future actions. Rigor isn’t arbitrary when our software deals with physical laws, or physics and mathematical formulas. But it often seems arbitrary with other system behaviors. When do we need strict precision in answers? When is it a bad idea to enforce precision? What should we do when it’s too hard to enforce seemingly necessary rigor? Those are some questions we’ll explore in this talk.