January 27, 2020

Architecture and Design

  —What goodness do you want your architecture to provide?

I’m facing a challenge wherein I need to improve my team’s focus on architecture and design. My perspective on this is that their approach is ad-hoc. Team members complain that decisions are made without discussion. The results are suspect and limiting, or least don’t fit my definition of a successful outcome.

My team uses Scrum and struggles with design. My first experience with Scrum left me with one unanswered question: “Where is design occurring?”. I think the short answer to that question is that it wasn’t occurring in a way that promoted a shared understanding of the goals.

In taking on architecture and design I’ve had to rethink my position on how to approach it. Most of my thinking is around identifying what to focus on and how to communicate it so the team gets a shared understanding of the objective.

The first thing I did was look at the product requirements. There was an implicit notion of an architectural quality objective in many requirements. For example, people would talk about performance or reliability but often just use the word itself as if it’s presence conveyed something important. What was missing was an exploration of what performance or reliability really meant. What was missing was tangible activity around these objectives both in the form of requirements and in design.

I started presenting quality objectives as the “goodness” we wanted from the architecture. It was a cheap sales pitch. No one will sign up for badness. It was a good idea in that it created a focal point for discussion. I could ask questions like “Are we getting the goodness we need?” and even “How can we enhance the goodnes we need?”.

The funny thing is that people responded positively to “goodness” over “quality objectives”. People became engaged on finding and identifying “goodness”.

The most interesting thing about goodness is that it turned out to be a good communication tool for stakeholders. Those people outside of the Scrum and Development teams.

Using “goodness” provided a way forward and to begin a conversation about what it meant to have a reliable or performant product. It provided a way to change the perspective on our requirements elicitation that put architectural quality objectives in the same class as functional requirements.