Disclaimer

This book is still being written. The topics in the table of content will probably change over time. Also, I’m writing following a slicing strategy: instead of writing whole chapters or sections, I’m constantly adding text everywhere, trying to cover a wider range first, then going deeper in each topic, in an organic fashion. I can’t guarantee the results, but I’m having fun!

Please feel free to provide feedback to me as you want. The easier way to contact me is via Twitter at @MartinSalias. And don’t forget to visit us at Kleer!

Thanks for reading!

Overview

Software Architecture is a wide and complex discipline, full of different perspectives, opinions and definitions. If there is something in which most practitioners agree is in its importance, and how the lack of thought on the subject -even while it should be proportional to the problem at hand- tends to produce poor or downright deficient results.

The main idea behind this work is that, as fundamental as software architecture is, it shouldn’t be considered a separate activity on the whole software life cycle, either to be performed by an isolated group or individual, or to be conceived in a separate phase from the majority of the construction process.

Following the main ideas of iterative and incremental development on the Agile paradigm, my thesis is that the best software architecture for a given project emerges as the rest of the projects goes on, and that there are concrete practices and techniques that support the incremental design of the architecture together with the rest of the application, allowing for late but safe refinement whenever needed.

The main ideas in this book come mostly from other people, mixed and matched by me within a few different initiatives, including an early Software Architecture Seminar; a few years teaching Software Architecture at Universidad de Palermo, in Buenos Aires; a paper written together with my friend Diego Fontdevila for the late Architecture Journal; and the Agile Architecture Workshop I frequently facilitate at Kleer, my current company, which is constantly evolving, probably more than ever during the writing of this book.

Beside all this theoretical or conceptual sources, this work tries to distill the experience of a couple decades designing architectures from different types of applications on heterogeneous technologies and platforms, in several different industries, either as the main architect, part of a team, or as an external consultant or advisor. As usual, the most interesting ideas came from committing horrible mistakes.

Chapter 1: Agile & Software Architecture

Software development is a pretty new discipline. It started in theory with Charles Babbage and his Differential Engine, and Lady Augusta Ada Byron, Countess of Lovelace, becoming the first programmer in history, although she never had the actual computer to execute her programs!

From these early days to Word War II, computing turned from theory to a mean to push mathemathics to a larger scale, and remained as an academic endeavor until the early 50’s, with the Univac. Later that decade IBM starts producing their first commercials computers and programmers start spreading from mathematicians to engineers, and a new species was born: the homo-nerdus, also known as “computer programmer”.

Early programming methods were pretty much ad-hoc, and the cycle between coding and compilation could be measured in weeks, from punching the cards (which sometimes the coder could not do on her own) to submitting the batch of cards to the Computer’s Administrators and wait days to receive back a paper listing with the result run or just pages of error information.

As computers became popular in the corporate world and software applications got more complex, the need to stronger engineering practices appeared, and from 70’s to 90’s our industry exported ideas and processes from the previous engineering fields, from electronics to civil construction. The result introduced several problems, basically because programmers got subjected to controls and environments closer to blue-collar workers than designers, most of the time restricting innovation and creativity.

Agile software development crystalized at the start of the XXI century as a reaction to these prescriptive processes, putting the focus back in the non-repetitive side of programming, fostering relationships, team dynamics, collaboration outside of the technical roles, and maximizing feedback loops everywhere.

In the first part of this book I want to provide a short recap of its main topics, just to set expectations, boundaries and terminology I will use in the rest of the book, and as a pivot for further discussion.

First I will review the Agile paradigm from the values and principles and the practices in he most common frameworks like Scrum and Extreme Programming, its Lean cousin Kanban, and then what I understand as the meta-model behind Agile.

Then I will do the same with Software Architecture, focusing mostly in the type of Architecture I will refer to in this book, and pointing to connected disciplines.

Lastly I want to present my view of the main challenges Software Architecture face on Agile teams, projects and organizations, and provide a short overview of the different approaches I present about this topic during the rest of the book.

Acknowledgements

This book is still a work in progress, but luckily I’m not alone. I want to thank several friends who helped me come to the ideas I’m compiling here, and also the ones helping me during writing, by providing feedback about concepts, grammar even my style and humor (or lack of thereof).

I have to thank first Diego Fontdevila who wrote with me the paper where I started writing down the ideas and experiences I gathered over the previous ten years (Software Architecture in the Agile Life Cycle, Architecture Journal #23).

Several years before the paper, I worked and taught Software Architecture with Diego González and Juan Ladetto, whose insights and ideas were really influential in many of my choices and research.

Also, I feel in debt with Ted Neward, whose book “Effective Enterprise Java” had a huge impact in the way I see the field beyond any technology, and of course, because he started the idea of Architectural Katas, which I later adopted and customized to run in several events and also as part of my workshops.

I also need to thank the whole Southworks crew, in special Johnny Halife, Matias Woloski and my old-time friend Angel “Java” López. I always miss the awesome discussions we had, full of ideas and practical wisdom. Also, I enjoyed working and discussing with the team at Microsoft Patterns & Practices, one of Southworks most important customers, in particular Eugenio Pace and Scott Densmore.

As I joined Kleer and designed my Agile Architecture Workshop, I had great input from several of my colleagues at Kleer, especially Juan Gabardini, Luis Mulato and Yamit Cárdenas, and colleagues from other companies like Raúl de Villa Cano, Marcelo Oks, Andrés Joaquín, Adrián Anacleto, Santiago Blanco and many more I’m probably forgetting.

Lastly, I want to thank the first reviewers of this book, Nico Páez and Scott Baldwin.

Agile Recap

As Agile Methodologies decreases focus on written documentation in favor of oral and visual communication, I will start using my colleague Pablitux’s poster to review the Agile Manifesto:

The text of the Manifesto says:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Let’s re-read these values from an architectural viewpoint, and ask some questions:

• Who are the Individuals in this case?
• Isn’t architecture mostly about processes and tool?
• Can we build working architecture without comprehensive documentation?
• Who are our customers when we build (or install) architecture components?
• Do we have a contract?
• Are we capable of changing our architecture when needed, instead of sticking to our prescribed model?

My personal view on Agile

After almost 20 years working under the agile paradigm, starting with the early XP days by the late 90s, as you might expect, I have some strong opinions about this model and its impact in the industry and the community.

I don’t think my ideas are particularly original or important, but as the book moves into the model I found to put them to work into software architecture, I think it is important to tell you about some of them, even if this serves to set some disagreement early on.

So here I go:

Agile is a cultural approach

I find the frequent usage of “Agile Methodologies” somewhat unfortunate. Some people still thinks that Agile is just a different way to run projects, but it is way beyond this. As Kent Beck used to say about XP, it is about social change.

As pretentious as social change might sound, Agile is mostly about moving from centralized decision-making and high-specialization to an environment of shared decision-making and high-collaboration. This is somehow subversive in the sense of potentially breaking chain of commands, which quickly push for a different distribution of money, power, knowledge and so on.

Of course, this is an ideal, but it is there, and I believe that continuous improvement only can get you close to that. Otherwise, improvement will slow down and probably stale.

Agility requires Quality

Quality in execution comes from avoiding shortcuts and being transparent about what you do, without looking for someone to blame when things fail, but looking for underlying problem and fixing root causes.

Transparency, introspection and improvement are core values of Agile, and that’s what one things brings to the other.

Moreover, Technical Excellence is one of the principles stated in the Manifesto, and is one of the distinctive traits one consistently finds in succeeding Agile teams. Indeed, many teams adopting Agile can get great results at first, but quickly get in trouble when neglecting technical improvement. This pattern was so common that even Ken Schwaber (one of the fathers of Scrum) started using the term “Flaccid Scrum” to describe the problem.

Software Architecture Recap

Software Development is a Complex human activity.

Angel “Java” López

Of course I won’t dare to define Software Architecture on my own, as this is an often debated topic, and I’m not planning to add a lot of heat to this.

Instead, I will try to present some commonly used definitions from several recognized authors, and try to get some basic ideas to build upon during the rest of the book.

First, a meta-discussion on the topic from Luke Hohmann’s “Beyond Software Architecture” (Addison Wesley, 2003):

Software architecture is a complex topic. Because of its complexity, our profession has produced a variety of definitions, each more or less useful depending on your point of view. Here is a definition from my first book, Journey of the Software Professional:

A system architecture defines the basic ‘‘structure” of the system (e.g., the high-level modules comprising the major functions of the system, the management and distribution of data, the kind and style of its user interface, what platform(s) will it run on, and so forth).

This definition is pretty consistent with many others for example, [Bass], [Lerman], and [POSA]. However, it lacks some important elements, such as specific technology choices and the required capabilities of the desired system. A colleague of mine, Myron Ahn, created the following definition of software architecture. It is a bit more expansive and covers a bit more ground than my original (2002, personal communication):

Software architecture is the sum of the nontrivial modules, processes, and data of the system, their structure and exact relationships to each other, how they can be and are expected to be extended and modified, and on which technologies they depend, from which one can deduce the exact capabilities and flexibilities of the system, and from which one can form a plan for the implementation or modification of the system.

We could extend these definitions from the technical point of view, but this wouldn’t provide a lot of value. More than any other aspect of the system, architecture deals with the ‘‘big picture.” The real key to understanding it is to adopt this big picture point of view.

Another meta-vision comes from Ian Gorton’s “Essential Software Architecture” (Springer, 2006):

1.2 Definitions of Software Architecture

Trying to define a term such as software architecture is always a potentially dangerous activity. There really is no widely accepted definition by the industry. To understand the diversity in views, have a browse through the list maintained by the Software Engineering Institute2. There’s a lot. Reading these reminds me of an anonymous quote I heard on a satirical radio program recently, which went something along the lines of ‘the reason academic debate is so vigorous is that there is so little at stake’. I’ve no intention of adding to this debate. Instead, let’s examine three definitions. As an IEEE member, I of course naturally start with the definition adopted by my professional body:

“Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” [ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]

This lays the foundations for an understanding of the discipline. Architecture captures system structure in terms of components and how they interact. It also defines system-wide design rules and considers how a system may change. Next, it’s always worth getting the latest perspective from some of the leading thinkers in the field.

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.” [L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edition), Addison-Wesley 2003]

This builds somewhat on the above ANSI/IEEE definition, especially as it makes the role of abstraction (i.e. externally visible properties) in an architecture and multiple architecture views (structures of the system) explicit. Compare this with another, from Garlan and Shaw’s early influential work:

“[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.” [D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]

It’s interesting to look at these, as there is much commonality. I include the third mainly as it’s again explicit about certain issues, such as scalability and distribution, which are implicit in the first two. Regardless, analyzing these a little makes it possible to draw out some of the fundamental characteristics of software architectures.

Finally, Stephen Albin comes to his own terms in “The Art of Software Architecture” (Wiley, 2003):

Software architecture involves the integration of software development methodologies and models, which distinguishes it from particular analysis and design methodologies. The structure of complex software solutions departs from the description of the problem, adding to the complexity of software development. Software architecture is a body of methods and techniques that helps us to manage the complexities of software development.

Software architecture is a natural extension of the software engineering discipline. In early literature it was simply referred to as programming in the large. Software architecture presents a view of a software system as components and connectors. Components encapsulate some coherent set of functionality. Connectors realize the runtime interaction between components. The system design achieves certain qualities based on its composition from components and connectors. The architecture of a software system can be specified in a document called the architectural description. Software architecture design is not entirely different from existing software design methodologies. Rather it complements them with additional views of a system that have not been traditionally handled by methodologies like object-oriented design. We will learn that software architecture fits within a larger enterprise architecture that also encompasses business architecture, information technology architecture, and data architecture.

Agile Architecture Challenges

Now that I discussed the Agile paradigm and Software Architecture, let’s talk about the intersection between the two.

Even while agile methodologies are getting widely accepted in the development world, there is still a lot of debate about how to apply them to the architectural space. One of the most conflictive issues stems around “big design upfront,” which is strongly discouraged by agile practitioners, and the traditional approach to architectural design.

In our original paper from 2010 ¹, Diego Fontdevila and I proposed a set of team dynamics, conceptual practices, and specific technologies to embed software architecture within the agile approach—keeping up the shared goals of technical excellence, streamlined development practices, and a constant and ever- increasing flow of business.

Architectural Dynamics in Agile Teams

One of the 12 principles of the Agile Manifesto states that “the best architectures, requirements, and designs emerge from self-organizing teams.” We took this to heart —especially, the reference to our shared specialization.

While architecture is an activity that is historically performed with an emphasis on the early stages of a project, the main focus of agile development is on emergent design and iterative production— creating a series of interesting challenges down the road.

First of all, agile makes a big push toward shared responsibility and, thus, dilutes the traditional role of the architect as the one who “defines” the higher-level design of a solution. In this new approach, architecture (as most other development activities) is something that is performed by the whole team -—preserving its multidisciplinary nature. This does not imply that the architect profile goes away, as with all the other roles; it means that while someone contributes with a broader and probably more experienced perspective (usually leading in this aspect), the whole team participates and understands the implications of the design decisions that it makes, and continuously evaluates them.

In our experience, key considerations —-such as the modularity strategy, how communication is handled within and outside the application, and how data and services are accessed and abstracted—- are successfully defined and implemented when the whole development team establishes a consensus about these issues. In this way, team members fully understand the consequences of the selected alternatives, remain aware of their initial assumptions throughout the solution life cycle, and quickly raise concerns when their validity is affected.

Most of these challenges are usually tackled by folding architectural discussion and revision into the regular meetings that take place over the course of an iteration—such as planning and review meetings, and frequent sync-ups and design meetings with plenty of white boarding and open talk. It is also worthwhile to have the most important guidelines permanently exposed in an informative space, including diagrams, checklists or reference charts around the walls, and semipermanent flip charts that are used as posters.

This article does not cover in detail specific techniques that apply to coordinating several subteams; mainly, it mirrors the standard guidelines about “Scrum of Scrums”. The addition to such activities is a stronger focus on the preservation of conceptual integrity—thus, planning frequent high-level design meetings between teams. Again, these meetings should avoid becoming architect meetings; while the contribution of team members who have a stronger architectural background is obviously important, it is very important for other members to participate. Even the less experienced team members can provide a somewhat naïve perspective to some discussion—promptly flagging complexity excesses that are a professional malady among us architects.

To close on the team dynamics, as the agile perspective goes over the standard view of the development team and extends to customers, operations personnel, and other stakeholders, expectation management is a big deal also for the solution architecture. In the strategy I present in this book there is a strong emphasis on mapping the needs and goals of these actors to the architectural constraints and converting the most important ones into strong metrics to be evaluated.

Chapter 2: Architecture Flow

The traditional approach to Software Architecture has been to work for quite a long time defining the scope, laying out components, archetypes or layers, and sometimes even building parts of the architecture blocks before the actual solution starts.

Of course this is a mismatch to the idea of adaptive design that Agile brought us. If we are supposed to discover the details of the product we are building during the project itself, and following Lean principles, deferring decisions to last responsible moment, then Big Design Upfront can’t apply to Architecture either.

Indeed, what we know now is that every time we defer some of those technical decisions to the moment we learned more about the problem domain, our stakeholder’s expectations and also about our own solution, we are creating more possibilities. Every time we take a decision and start working on its premise we bound ourselves a little to that. Over time, hard technical decisions are hard to change, as we always knew in Architecture, but instead of trying to take them right, we will start to take them late. Sometimes late means that we might get lucky and might never have to decide about it at all.

Another turn we take from the traditional approach is that instead of trying to figure out the “right” architecture with our stakeholders in the beginning, we typically discuss the basics, but then we don’t press them with details they don’t know, or they can’t never be sure enough. As we are supposed to discover the product features in detail over time, and release early versions to be used in production and learn from them, the architecture would probably need to be discussed and evaluated from actual data from the design process and runtime.

Most than anything else, my strategy is to keep the conversation about architecture (mostly discussing quality attributes) open and intertwined with functional discussions, as both things go along in the system development and usage. To do that, I will explore some lightweight alternative practices that can be added to standard planning and review meetings, as well as how much to advance at product’s inception.

Emergent vs. Adaptive

Even while this book’s title is Agile Architecture to try to convey the main ideas from which my model arises, I like to use the term Adaptive Architecture also, as there are a lot of ideas that could be used even in the context of not-so agile projects.

Emergent behavior

In Complex System Theory, emergence is the process where a system composed by several smaller entities shows properties that are not explicitly present in its parts. In Software Development, we used the idea of Emergent Behavior quite a few times, trying to explain how smaller functions, objects or components build up to a system exhibiting some features that are beyond the sum of its parts.

While the metaphor is nice and powerful, most software systems (with the exception of some Artificial Intelligence approaches) have not real emergent properties, because causality is too high on them, as we design components and the way they interact with a very specific purpose.

Growth of software projects and products is better explained by looking at Complex Adaptive Systems, which -although usually based on emergent behavior- have a difference in purpose and specialization (typically to foster survival). Adaptive Systems are complex in the dynamics of their interactions, and they don’t just happen, but self-organize to achieve a goal.

Adaptive Systems

In the highly multidisciplinary realm of Complexity Theory we as software developers or architects join economists, politicians, ethologists, entomologists, and a plethora of other professions dealing with loosely coupled relations and varying contexts.

Software is adaptive both from the development perspective, as development teams are comprised of humans dealing with a creative process, surrounded by changing conditions, subject to volatile restrictions and with unpredictable input (from other humans).

The Agile paradigm recognizes these factors and thus applies an empiric process where all this factors are constantly observed, following the scientific method of formulating hypothesis, trying to prove or discard them, then building on that learning to formulate further hypothesis.

In that sense, Architecture should follow the same principle, and to that end, I prefer to come up with architectural hypothesis when there are concrete experiments to run in order to prove them. And this hardly appears before actual functionality is built.

Quality-Driven Architecture

Beyond the different definitions found for Software Architecture, Quality Attributes (also mentioned as non-funtional requirements) are always at the core of the field.

This is completely independent of the Agile approach, as seen in many different formal approaches used over time to base architectural decisions on this attributes.

In particular, I always liked the “Quality Attribute Workshop” (or QAW) from SEI’s Software Architecture in Practice ². The QAW follows an eight-step approach to discuss about the Quality Attributes for a system during a Workshop event at project’s inception, where business and technical people discuss these matters. The steps are the following:

1. QAW Presentation and Introductions
2. Business/Mission Presentation
3. Architectural Plan Presentation
4. Identification of Architectural Drivers
5. Scenario Brainstorming
6. Scenario Consolidation
7. Scenario Prioritization
8. Scenario Refinement

What I like from this approach is it pays attention to the business goal first, and then focus on scenarios discussed among business and technical people.

The main problem I found, as you can easily imagine, is that the workshop is an activity designed to be run at the start of the project, when all involved people know very little about the actual system being built, beyond the conceptual model and it assumptions. For the most part, little to nothing has been built, and no single feature has been used yet.

Iterative approach to Quality Attributes

Taken the previous idea and breaking it down to smaller, frequent discussions best fit to an Agile team, I came up with a lighter plan to achieve the same effect:.

First, we might have a brief discussion about high-level Architecture and Quality Attribute prioritization as part of the Agile Inception Workshop (more on this later in the “Practices” chapter). But we won’t try to define anything about this too much, but having an overall idea and a starting strategy instead.

Then, we will have some time to discuss about Quality Attributes in every Iteration (or Sprint) Planning meeting; not as an aside, but potentially around every User Story (or Backlog Item). So, for each small feature (or the bigger feature it is included in) the team will review what the quality expectations are.

For example, given a User Story relating to a Book Purchase, they will analyze (after the functional details) with the stakeholders:

• Is there any specific performance or security consideration?
• Is this something we will need to change frequently, where maintainability will be important?
• Is there any specific regional or accessibility concerns?

Of course, some of these concerns might have appeared previously (in previous User Stories), and some of them might have become part of the Team’s Definition of Done ³.

Whenever one of this issues appears the Team (together with the involved stakeholders) might take note in some artifact like this:

Response Time

Context:

Once a Purchase is confirmed, the user should not wait for confirmation.

Metric:

After confirmation, “Keep shopping” page should take no more than 0.4 seconds to render.

Strategy:

Operations are queued, and eventual failure will be informed by email and site notifications.

Notice that in the example above the decision is generalized from Book Purchase to “Purchase operations” in general. This card should be ideally pasted on a board in the Team Room (instead of going to die on a Wiki Page) to be frequently seen. It might also generate some specific technical tasks under the Book Purchase user story that will later be re-used, but this decision and the corresponding implementation are directly tied to a feature, and will be tested and reviewed in this context, rather than in a conceptual model.

The “Metric” field in the card should become an automated test which can be executed either continually (in every commit) or in a nightly profile (for load or performance testing requiring long-running or heavy processes which you don’t want to compromise your network during the day).

Business Value

As we recognize that delivering value early and often is what makes agility attractive to our customers, then we have to be able to justify our technical decisions following the same principle.

In that sense, non-functional requirements should be derived from the same kind of experimentation we use to build the most appropriate product over time, by staying lean and refusing to include features “just in case” some possible event happens.

We strive to make architectural discussion with stakeholders, and the corresponding design decisions and implementation continuous tasks, the same way as analysis, functional design, coding, testing and deployment.

We want to have a permanent relationship between stakeholders and architecture (represented by the team, not necessary “architects”).

To do this, we have to develop a common language accessible to everyone like other pattern languages. Among other ways to encourage this, I developed over time a deck of cards which finally became the “Architectural Tarot” (you can see the whole deck in Appendix I). The cards provide a visual approach that better engage non-technical stakeholders in architectural discussions.

We do this by using the deck not only during an Agile Inception or other kind of kick-start workshop, but frequently in iteration planning meetings, as we keep finding about the non-functional requirements as we develop the product and start using it.

Architecture in an Agile development cycle

To better illustrate how architectural discussion gets integrated as part of the expected “osmotic communication” of an agile environment, I will use the Scrum diagram drawn by my friend and colleague Martin Alaimo:

Even if you are not following Scrum, this diagram shows high level view of most iterative flows. Below I list the Scrum names and then the generic description which can apply to any other agile approach.

• Product Backlog - a dynamic list of prioritized work to do
• Sprint - an iteration (usually of fixed lenght)
• Planning - session at the start of each iteration
• Definition of Done - shared agreement on when an item is “Done”
• Review - session to evaluate the product increment at the end of the iteration
• Retrospective - continuous improvement session (usually on every iteration)

How can we mix architectural stuff all over there?

Planning and Reviews

While discussing every item with stakeholders, the team can use the Architectural Tarot (or any other technique) to better understand the quality attributes involved.

Based on the expected behavior, the team might come up with some quality metrics which may become either (a) Acceptance Criteria for this particular item or (b) something to be added to the Definition of Done, as it will be expected on several different contexts.

Retrospectives

As part of the focus on improvement, the team can review how the architecture is doing so far, trying to figure out potential problems and spot common excesses on time.

Some inductive reasoning questions I use for that are:

• What we feel is too fragile so far?
• What is being to hard to do?
• What can be simpler in our current architecture?

A few recommendations before closing this section:

• Keep architectural ideas coming from the retrospectives on the lookout for next planning
• Beware of polluting the Definition of Done
• Remember the Definition of Done should be understood and agreed with the customers/stakeholders

Chapter 3: Agile Architecture Practices

Architectural Inception

Agile Inception is currently a widely used technique used to create a shared vision among the Development Team and the rest of the stakeholders for a given product. First documented by Jonathan Rasmusson in “The Agile Samurai” (Pragmatic Bookshelf, 2010), it involves 10 activities which can be run in a single workshop, sometimes picking some of them or complementing them with other, depending on the project/product at hand.

I facilitated dozens of these workshops over the years, for organizations ranging from small startups to corporations in different industries, and they have always been key to creating an collaborative context among all involved parties.

In short, the 10 activities I run are:

1. Why are we here?

A check-in round with a twist, were every participants states not only their name and role, but what they understand it is their involvement with the product.

2. Elevator Pitch

The group design a very short phrase explaining what the product is, whom its users are, its main features, its competitive advantage and some other relevant detail. As an alternative I can use a Product Vision Board (PVB) instead, depending on the audience.

3. Vision Box

We use a physical box (cereal-type) to design a fictitious box for their product, thinking about it as a retail product (even if its not).

4. In/Out/Maybe

The group creates a simple chart about the very high-level scope of the product, stating what it should have, deciding what it shouldn’t, and leaving some features in a group to be reconsidered later.

5. Community

This is a diagram about the different groups which need to be involved in the product development, and their different levels of participation, in a visual way.

6. The Solution

This is the activity were we talk about the high-level technical decisions we can define up-front to build the product. As some architectural discussion takes place here, I will expand on it later in this section.

7. Fears

We chart all the important risks related to product development and delivery from all the perspectives represented in the workshop such as Technology, Market, Cost, Team, Legal issues, Security and others.

8. Size

Here the group discuss the perceived size of the project from several angles: Team Size, including if the is a need for several teams; estimated duration or deadline, sometimes including an expected release plan.

9. Trade-Off

This activity involves prioritizing the main non-functional concerns of the project, debating which ones will take precedence in situations where some design decision targeting one of them conflicts with others. This is the other activity related to architecture strategy, so I will expand on it later in this section, too.

10. How much?

At this point the group makes a shopping list of all the important expected costs, including salaries and fees, hardware and software, services, facilities and anything else that can have an impact in the total cost, and perhaps when or how the cost will impact (initial investment, weekly or monthly, tied to releases, etc). We don’t typically try to include the actual cost, but have a clear list to produce an actual budget later.

As you can expect, there is a lot more involved in this workshop, but my goal in this section is to provide you with a general idea and get slightly deeper in the two highlighted activities:

The Solution

While the technical participants will be leading this activity, the main purpose is for them to clearly explain to the rest of the group several things that they better understand and agree on as soon as possible. For example:

• Types of clients for the application (web, mobile, desktop, APIs, special devices)
• Supported platforms (browsers, desktop or mobile OS, form factors)
• Integration (with services, corporate applications, databases, sensors or networks)
• Dependencies (with other products, projects, technologies)
• Expected behavior for particular scenarios (should the mobile apps support offline usage? are there some kind of distributed transactions? there are some extreme load situations? some critical time-sensitive operations?)

What we try to achieve here is a shared understanding about implementation/architectural details and how they will support the main business requirements. As the group sketches diagrams and talk about the implications of different parts, a lot of assumptions from the different participant areas come to light and new ideas retrofit this early draft of the architecture.

Trade-Off

The starting point for this activity is to agree on a set of 5 to 8 attributes representing the main non-functional concerns about the product. Most of these are the typical Quality Attributes we use in Software Architecture, but I often let the group add some they find important. For example, I find these in real-life Inceptions I facilitated: Total Cost of Ownership, Time-to-Market, and even Team Life Quality⁴.

As I like to run this, once we agreed on list, I make the group write each one on a sheet of paper (big block letters filling the whole page) and then I make one person for each attribute to hold the paper, showing the name to the others. Then they stand in line, one next to the others, like in a police suspect line (which is a fun moment) and we discuss the relative positions, from left to right (choosing which side means MOST important). The group keeps discussing and swapping the people in the line to reflect the priorities. As a facilitator I help them come up with some potential conflict scenarios between most attribute pairs, so everyone understands they can’t make the cake and eat it, too.

Once there is an agreement that the line represent their best bet, I usually ask the people in the line to slightly turn so I can snap a picture of them where faces and signs are clearly seen, in order. I found over time this picture showing what I call the “Quality Strategy” for the product, with faces the actual team members building the product (and most stakeholders) can recognize, is way more powerful to align decisions than any standard document.

Slicing

The concept of slicing or breaking down User Stories (although the general idea can be applied to any other unit of work you use) into smaller ones is one of the most important aspects of Agile Software Development.

As a community, we agree that the smaller (but valuable) a User Story is, the better, for several reasons:

• More understandable
• Simpler to prioritize (or re-prioritize)
• Easier to estimate
• Easier to decompose in implementation tasks
• Fewer acceptance criteria; easier to test

Above anything else, when we break down a User Story into several smaller ones, we have more chances to find less valuable items that can be deferred for later, and eventually discarded if they are not valuable enough as the development goes on. This is exactly the Agile Principle of Simplicity, defined as “the art of maximizing the amount of work not done”.

Functional Splitting Patterns

One of my favorite resources to help teams to slice (or split) User Stories is Richard Lawrence’s guide “Patterns for Splitting User Stories” ⁵.

The guide proposes a three-step approach:

1. Check the User Story quality and fix other problems before splitting
2. Try a series of patterns to find ways to split it
3. Evaluate the resulting User Stories to be sure everything is fine

What’s most important for us now are the patterns themselves. I recommend you to read the original post and even find out some additional patterns based on your experience, but let’s list the 9 original patterns before extending them.

1. Workflow Steps
2. Business Rule Variation
3. Major Effort
4. Simple / Complex
5. Variations in Data
6. Data Entry Methods
7. Defer Performance
8. Operations
9. Break Out a Spike

Even without getting into details you can see the focus is to try to break down functionality in more granular parts, trying to be able to take the most valuable and ideally thinner part of each need, and provide the earliest and more valuable implementation, trying to prove or discard the hypothesis behind each User Story and also leveraging all the learning from this early delivery to better select what’s next, the best approach to implement it, and even what’s not needed at all.

Architectural Splitting Patterns

Once you broke down your User Stories into smaller ones, you can still apply slicing strategies based on architectural concerns.

You may have smelled some architectural patterns in the list above. For example: Variations in Data can be considered also as “Variations in protocols, message format, encoding, and other messaging attributes”. Also, “Defer Performance”, which tries to solve first the functional aspects of a User Story and leave a potential optimization as a later Story, can be applied to several other Quality Attributes.

Then, you can apply further splitting patterns when breaking each User Story down to its Tasks. What’s important is to reflect in the resulting User Stories this restriction, and keep being explicit about the remaining value.

Some of the extended Splitting Patterns I found useful from experience are:

User Experience level

This approach is actually a huge topic in itself, but basically focus in providing the simpler UX approach first, iteratively test it with real users and keep refining for as long as needed, depending on the product.

The UX field is so large and important right now that I prefer to point you elsewhere, probably starting with the books “Lean UX”, by Jeff Gothelf and Josh Seiden, and “User Story Mapping”, by Jeff Patton.

Reliability Constraints

User Stories related to reliability (when properly analyzed) tend to have strong acceptance criteria about accurate data input and data transformations, error-free state management, and non-corrupting recovery from detected failure condition.

This is not typically the kind of User Stories you get at first, but they appear through Backlog Refinement and usually come from observed behavior after the application is already in use (or under specific testing conditions).

The different constraints related to this normally have a highly different business value and implementation costs, so separating each constraint base on its calculated Return of Investment can be a smart move, and just doing this analysis can provide many insights for both the involved stakeholders and development team members.

Manageability / Security levels

Configuration aspects can be split over time, deferring complexity from (hopefully short-term) hard-coded values, config files/resources, admin dashboards, cold or hot reconfiguration mechanics, and more.

In a similar way, Security can be split along different axis like internal/external, authentication/authorization, user-level, api-level, component-level, code-access-level, resource-level (like DB and services accounts) and much more. Security is always a complex and sometimes very restrictive, so the ability to spread various security concerns over a long period tends to be a good idea. In very sensitive scenarios, each User Story can have very specific Security Acceptance Criteria, or can be checked against a specific set of Security concerns gradually added to the Definition of Done.

Defer Performance / Availability / Efficiency / Scalability

As important as these factors can be in different scenarios, they are usually pretty difficult to plan ahead without over-engineering. As we will see in other sections, a recurring pattern is to agree on some baseline value as part of the User Story Acceptance Criteria and build an automated test to verify this. Of course such tests are not always trivial, and that encourage good conversation with stakeholders about the real importance of these attributes in a given context.

It should be also noted that building the first few testing scenarios for these Quality Attributes take more effort, but the required environments and tools and scripts used tend to stabilize over time and further automation effort usually decrease.

Staged Portability / Interoperability / Internationalization

For every User Story dealing with these attributes tend to be breath goals like:

• target platforms
• systems, protocols, messaging, data sources
• languages or locales to support

But each of these dimensions have also depth goals:

• versions (or version ranges) within each platform
• versions, encodings, message formats
• static text, dynamic text, localized media, date and currency formats, calendars

In many cases there can be a complex matrix for each of this Quality Attribute that can be split over time. Staging this changes usually break down functional and technical implementation.

Taking / Paying Technical Debt

I like to take this as a separate pattern that can encompass any of the previous attributes, and it uses the Technical Debt metaphor coined by Ward Cunningham⁶.

Following the initial idea, when the team takes Technical Debt, it should be explicit and managed. This is very different than implementing “just what is needed”. If you write clean code without extensibility points that you don’t need yet, this is not Debt at all. You will just have to spend a bit more refactoring whenever (and if) the extensibility is needed later on. This kind of decision is not incurring on any interest.

Now, if the team is explicitly leaving a substandard or partial implementation of a component (one with known risks and issues) then they have to track this, and my favorite way to do it is by thinking what is the problem/risk it generates for the users, discussing it with the stakeholders, and then coming up with a User Story expressing that need: not the technical detail, but the need to prevent the unwanted circumstance the current implementation leaves open.

Design and Validation Levels

Symmetry and Integral Consistency

Validation Techniques

Validation Technologies

Quality Stream Mapping

DevOps

Chapter 4: Architectural Styles

The Monolyth

Microservices

Actors

The Cloud

Chapter 5: Architecture Stages

Greenfield Projects

Brownfield Projects

Legacy Systems

Especially, core systems.

See Fowler’s StranglerApps.

Chapter 6: The Agile Architect

Facilitator

Communicator

Designer

Innovator

Appendixes

Architectural Tarot

Architectural Radiators

Notes