Good architecture can respond to new requirements. It’s malleable where it needs to be.
A good leader trusts their team. And builds their team so they can trust them.
Architecture leads software, it defines the agility of the rest of the development, and it defines the fixed points that cannot be changed, that will always tend back to the initial conditions.
Get the architecture right. Decide as a team, and document the decisions as you go. Sometimes a decision is made on a proposition that is false. Sometimes the best solution yesterday is no longer the best solution today.
Everyone should be designing architecture of the system, and everyone should be reviewing it (pull requests on the written decision are great for capturing the discussion).
Your job as a leader is to make sure those discussions happen and are productive. Put the architecture decisions and the associated documentation next to the code, so they are as open for extensions and available for refactoring.
Democratise the architecture – get everyone to buy in, and you won’t come back to the project in 5 years and wonder when the monsters and hurricanes attacked.
Craig Nicol 
5 replies on “Embracing Agile Architecture”
Two distinct comments this time:
1) You seem to be using the word “architecture” when talking about “design”. As a quick example, years ago I was developing a large system. The client asked for a presentation on “The architecture of the database”. I asked if they wanted “Design”, but they said (repeatedly) “No, just the architecture”….So I showed up with one slide containing one word “Relational”….All the details after that were design (not architecture) choices.
2) “it defines the fixed points that cannot be changed” Agile welcomes change, and abhors the concept of “cannot be changed”. Emergent Design is very effective. It minimizes the upfront work [especially important since BRUF is often the leading cause of waste and unnecessary constraints].
LikeLiked by 1 person
I remember a talk (I can’t remember who by) that said that architecture is things that are hard to change, and design is the rest. For an architecture to be agile, there has to be as little of it as possible.
I agree that emergent design is good, but the key thing here about documenting the decisions, is that those documents become the architecture tests (i.e. the tests around the things that are harder to change) that make refactoring possible. If you can make refactoring easy, then the documentation can be embedded in the code, but for those that can’t, make sure the team agrees with the decisions, and the reasons, and is able to review them when the architecture starts getting in the way of the design.
LikeLike
I completely agree that documentation of design is critical. But putting it “in the code” ties it to the implementation and makes it virtually impossible to do cross-implementation design level reviews and analysis (or even discovery). I much prefer to use a strongly integrated ALM tool to tie all of the elements together while keeping them distinct.
Returning to Architecture. If one takes the view (as I and many others do) that an Architecture is identified by taking many (10’s, 100’s, 1000’s, more) of Designs and categorizing them based on common and differentiating traits, then Architectures are immutable (which could be view as the ultimate “hard to change”) though they can be refined and/or corrected.
When a new design if being contemplated [BRUF] or discovered [Emergent] it most likely fits into an existing architecture. If it is totally unique or even has a significant deviation from all existing architectures, then it really is “non-architectural”.
It is possible that at some point the design will be replicated enough that it becomes possible to form a set of common abstractions and the definition of a new architecture can be considered. I have been a software/systems architect for about 25 years [approx. 65% of my professional career] and have only been directly involved in an environment where a new (albeit niche to the military/space/aerospace industry) architecture was actually identified; All of the other work was either the study of architectures and the designs based on them, the categorization of designs into existing architectures, or the analysis of requirements/goals/objectives for a specific project to identify architecture(s) which may be suitable for basing the core designs.
LikeLiked by 1 person
Reflecting on that comment, I’m thinking that most of these decisions are design, but design that affects multiple codebases, because they share infrastructure or users, or other commonality that makes sense to Enforce consistency, but not enough to share a development and delivery pipeline. Thanks for helping me reevaluate. Plenty to think about.
LikeLike
Craig, I want you to know that I really enjoy our exchanges and your posts, they always give me something to think about also.
“Design” is a wide range ranging from strategic (macro) to tactical (micro). While consistency may be important across the scope, there are also times when differences are indicated – returning us back to the need for accessible and accurate information (documentation) so that there is proper understanding of the relationhips between all the parts.
LikeLike