What I Learned at Bredemeyer Consulting's Software Architecture Workshop

I've become increasingly interested in software architecture and visual modeling as I've progressed in my career. I chanced upon a Bredemeyer Consulting article, "What is Software Architecture?", which put the idea of becoming an architect within my reach. When Bredemeyer Consulting announced an open-enrollment workshop I immediately signed up.

I attended four days of architecture training hosted by Ruth Malan (@visarch). The course was easily worth 2-3x the amount that I paid, and I walked away with over 20 pages of written notes (not including annotated slides which are covered in scribbles and dog-eared pages).

Course Structure

The four-day course follows a structure which iterates across the design space, refining architecture views:

  1. What is software architecture? What do architects do?
  2. Understanding the high-level strategy, business needs, and user needs
  3. Setting design direction: explore value and set the scope of the project
  4. System Structuring Pass 1: create the architectural strategy and set technical direction
  5. Validation Pass 1: validate the architecture strategy
  6. Design system capabilities & qualities
  7. System Structuring Pass 2: create the conceptual architecture (focusing on identifying components, responsibilities and relationships)
  8. Reflect on Pass 2: find weaknesses in the conceptual architecture
  9. System Structuring Pass 3: create the logical architecture (explore system behavior and define interfaces)
  10. Reflect on Pass 3: reflect on and improve the logical architecture
  11. Design Pass 4: create execution architecture requirements
  12. System Structuring Pass 4: create the execution architecture
  13. Using and evolving the architecture (considerations in varying organizational contexts)

We started the four-day workshop with an in-depth discussion about what software architecture is and what software architects do. Ruth illustrated her concepts with stories pulled from all over the world: we heard about Madison's orchestration of the Continental Congress, how the Federalist papers helped make the Constitution a reality, Chuang-tzu's parable about butchering an ox (slow down at the tricky spots!), and how Walt Disney used specific rooms for brainstorming, evaluating, and criticizing ideas.

In order to ground our software architecture discussions, Ruth had the group select a software product idea that we would design over the duration of the course. Our class decided to work on a supply chain management and traceability system for agriculture.

We started our architecture efforts by exploring the business value of the system. We performed a variety of high-level exercises, such as Competitive Landscape Maps, Rich Pictures, evaluating stakeholder goals, and creating stakeholder empathy maps. Ruth emphasized that architects are important members of these business-level meetings, and stressed that we do have perspective on the industry and what technology makes possible (though we may need to suppress our technologist’s tendency to focus on flaws too early).

The results of the business-level analysis served as a starting point for brainstorming our system's initial requirements, responsibilities, and non-functional qualities. We continued iterating, guided by the architecture decision model, with each new piece of information feeding into later steps. For example:

  • Our initial list of responsibilities was used to generate our initial set of components
  • Our initial set of components fed into the first-pass high-level structuring for the system
  • Our business values and initial structuring was used to generate qualities and principles to guide our architecture & development teams
  • Our stakeholder analyses were used to generate use cases and user stories, and non-functional qualities were tied to the use cases
  • We used our use cases, qualities, principles, and responsibilities to review our architecture and fill in missing pieces
  • Our architecture and use cases were used to generate activity diagrams, sequence diagrams, and communication diagrams
  • An "outside architect" reviewed our design, evaluating whether or not the architecture sufficiently addressed the responsibilities, qualities, principles, use cases, and user stories

At each step in the process, the class noted two common experiences:

  1. When we looked at the examples, we thought "this will be easy". Putting the ideas onto paper in a sensible way was harder than it looked, and usually required 2-3 drafts before we settled on a reasonable approach
  2. Each new analysis caused us to refine our design in some way. We always found an aspect of the system or design that was missing in another view.

At the end of the workshop, you will have a well-supplied architectural toolkit, but you need to continue to practice and apply the concepts on your own. We were exposed to a wide array of diagrams, exercises, and exploratory concepts that can be used during the architectural process. But the self-study must continue, especially in identifying patterns, models, and processes that are most valuable to your software domain.

Lessons Learned

The following lessons stood out over the course of the workshop:

  1. Architecture can be quick and light-weight.
  2. Visual modeling skills have atrophied, but are the best tool to quickly communicate and identify problems
  3. Architects are the bridge between the business team and the development team (others can be too, but the architect must be)
  4. You must understand the system in context to make effective decisions
  5. Inspiration, wisdom, and design lessons can be drawn from a wide variety of fields
  6. We are limited by our cognition and biases - take a different view and invite outside opinions
  7. We need to continually move up-and-down the architectural hierarchy, adjusting our learnings as we go

Architecture Can Be Lightweight

Outside of the defense industry, I have never worked on a team that performed any real architecture work. With Agile, the industry has largely moved away from any sort of architecture or up-front design work.

We don't have to convert to waterfall to gain value from architecture efforts. We can produce a "minimum viable architecture": tackle the riskiest areas first, and think about how to properly organize behaviors that reach across the system. We can fill in the minor details later, but it's much harder to rework the keystones in our design.

Visual Modeling

Our visual modeling skills have atrophied greatly. In the past ten years, I haven't seen a single UML or SysML diagram used in any company that I've worked with. I've even admitted to myself and others that I am a purely verbal thinker, as I spend most of my time writing and programming.

I was repeatedly struck by how many problems jumped out at us when we looked at a picture - coupling, god classes, big ball of mud architecture. Had we started with the code, these properties would have emerged and we would not notice the problem until it was too late.

We can also communicate more clearly with a picture than we can with words. Complex interactions can be grasped at a glance. Parallel processes can be more easily understood when drawn. Our words leave so much room for interpretation, missing details, and force a sequential analysis (you read word-by-word).

Architects Are the Bridge

Architects are the primary bridge between the business team and the development team. Architects must understand the business needs and translate them into system requirements and developer actions. Architects also need to translate technical challenges into business-speak so that issues and risks are clearly communicated.

The job is highly personable, and you must understand how to deal with people and communicate value appropriately. Understand the business tools. Understand how to identify and draw out value. Understand how to translate that value to the development team.

Understand the Context

You cannot make proper decisions unless you are armed with all of the necessary information, including overall business strategy. We need to write down all of the decisions, alternatives that were considered, and why we choose our specific path. That information should be on record for ourselves and for our team.

The context for our decisions is more important than the details of the code. It's hard to recreate the context from the source code. Don't skip the documentation step.

Be Widely Read

We can draw architectural insights from all over. Many wide-ranging examples are used during the course:

  • The Articles of Confederation & the Federalist Papers
  • Chuang-tzu's Parable of Butchering an Ox
  • Using metaphors and patterns evident in nature
  • Applying concepts from other engineering disciplines
  • Take visual notes like XKCD's Thing Explainer
  • We can find clues in surprising places:
    • Sift for principles and heuristics like Bud did in the children’s story "Bud not Buddy"
    • The children’s story “The Wheel on the School” covers the creation of a shared team vision and dynamic teaming
  • Cognitive biases

Keep learning - but don't just focus on the technical side. Develop your communication abilities. Understand our cognitive limitations as humans. Study philosophy. Explore nature. Learn about the world. Anything can be a source of inspiration for our designs.

We Need Different Perspectives

As human beings, we are limited by our cognition and biases. Work on taking different perspectives (the dreamer, the critic, the realist), and be sure to share your ideas and invite outside reviews. We are all subject to biases and blind spots, so we must rely on others to evaluate our designs and help us identify what we missed.

Architecture is an Iterative Process

We need to continually move up-and-down the architectural hierarchy, adjusting our learnings as we go. A new detail from one form of analysis will expose a hole in a different model. By adjusting our architectural view and creating different types of diagrams, we are forcing ourselves to take a different perspective in looking at the system. Just be sure to capture these new learnings and adjust your designs as you identify flaws.

The course structure mirrors this iterative point. As we dived into behavioral views and mappings to the physical system topology, we identified problems with the previous views that required adjustments. The higher-level adjustments then drove further changes in the lower-level models. We were continually learning and adapting as we explored the architecture.

In Conclusion

I thoroughly enjoyed Bredemeyer's architecture workshop and would recommend it to anyone with an interest in software architecture. You will gain exposure to the full architectural lifecycle. You will be armed with a wide array of diagrams, exercises, and techniques. You will be actively applying these techniques throughout the workshop while brainstorming, modeling, and creating an architecture.

You will need to continue to practice these concepts on your own once you leave, and you will need to explore the architectural areas appropriate to your own software domain. And don't forget to stay curious, keep learning, and draw inspiration from everything you encounter.

Further Reading