Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
On August 8th I facilitated a workshop at Agile 2018 that focused on agile architecture. I promised everyone, we had over 150 people in the workshop, that I would post the pictures of their strategy canvases online so that they could have copies of it. So here’s my promised blog!
How architecture fits into agile ways of working (WoW) has been an important topic from the very beginning. As with all other aspects of agile, the Disciplined Agile (DA) toolkit provides you with choices – because every team is unique and faces a unique situation, they need to choose their WoW to reflect this (we like to say that context counts). To enable teams to effectively choose their WoW they need to know what choices they have available to them (we also believe that choice is good) and what the trade-offs of those choices are (because there’s no such thing as a best practice).
So in this workshop we worked through twelve agile architecture strategies. Granted, there’s a lot more than this, but we only had 75 minutes so I lead everyone through some of the key strategies. This blog overviews each strategy and then shares the strategy canvases that the class developed. Our approach was to assign each strategy to several tables and then ask each group to discuss the advantages of the strategy, the disadvantages, and when you would use it. There are pictures below of each strategy canvas – it’s important to note that I don’t agree with all of the sticky notes, but for the most part it’s solid stuff. Our upcoming book, trending to arrive in October 2018, explores these strategies (and more).
During the workshop we explored three fundamental questions:
- How Do You Explore Your Initial Architecture Strategy?
- How Do You Bring Architecture Skills Into the Team?
- How Do You Evolve Your Architecture?
How Do You Explore Your Initial Architecture Strategy?
Each group was given one of three initial architecture strategies to discuss:
No modeling
At the beginning of our project/endeavor we will perform no architecture modeling or exploration at all. We believe that all aspects of the architecture will emerge over time during Construction.
Lightweight modeling
At the beginning of our project/endeavor we will invest a bit of time, potentially several hours or even a few days, to perform some lightweight agile architecture modeling. We believe that we should think through the high-level architectural issues now but that the design details will emerge over time. Our “models” will be created using inclusive modeling tools such as whiteboards, paper or sticky notes. We’re likely to create one or more high-level sketches, each of which explores an architectural view (such as the technical architecture, the data architecture, the communications architecture, and so on).
Heavy modeling
At the beginning of our project/endeavor we will invest a fair bit of time, potentially several weeks or even a few months, to work through the architecture of our solution. We believe that we need to think through most, if not all, aspects of the architecture in detail before we can safely proceed with Construction. Our models may be either visual (i.e. UML component diagrams, Free-form architecture diagrams, Data Models, …) or textual (e.g. white papers) in nature. Our visual models will be supported by sufficient documentation to capture the details overviewed by the diagrams. Our models will be captured with software-based diagramming tools (e.g. Visio, OmniGraffle), documentation tools (e.g. Word processors or Wikis), or modeling tools (e.g. Enterprise Architect).
How Do You Bring Architecture Skills Into the Team?
Each group was given one of five architecture skills/roles strategies to explore:
No architect
On our project/endeavor we do not have anyone on the team responsible for architecture work nor do we have anyone with sufficient architecture skills to do so. Luckily we are a group of smart, experienced developers and we believe that we will be able to evolve the architecture of our solution through teamwork and experimentation.
Part-time architect
On our project/endeavor we have someone on our team acting as a part-time architect. This person is very experienced and is a member of our corporate architecture team, supporting several solution delivery teams including our own. The part-time architect guides our team in architecture decisions, providing advice, educating us in any existing corporate architecture guidance, and reviewing any work that we do on our own.
Modeler architect
On our project/endeavor we have someone with deep architecture experience and skills. In the past they were a developer but over time they worked their way out of that role to become an architect. Their job is to work through the architectural strategy for the team, describe that architecture strategy to us, and develop and maintain sufficient architecture models and documentation throughout the lifecycle. Although they are technically adept and well versed in the domain, they do not have technical experience with some of the platforms and technologies that the team is likely to work with.
Developer architect
On our project/endeavor we have someone who is a full-time member of our team who has deep architecture experience as well as development skills. They are responsible for formulating the architecture strategy for the team although will often work with other team members to get their input into architecture decisions. When they are not doing architecture work they are an active developer on the team.
Architecture owner
On our project/endeavor we have someone in the role of Architecture Owner (AO). This is a full-time team member who has architecture experience, is well versed in our corporate architecture guidance/strategies, and also has development skills. The AO:
- Guides/facilitates the team through architectural strategy and related work
- Mentors/coaches team members in architecture thinking and skills
- Work with our corporate architecture team as needed to ensure that our team is following, to the extent appropriate, the overall architectural vision
- Is an active developer on the team when they are not performing their other responsibilities
How Do You Evolve Your Architecture?
Each group was given one of four architecture evolution strategies to explore:
Architectural Guidance
One of the approaches that our team uses to evolve our architecture is refer to our organization’s existing architectural guidance. We typically do this by talking with someone on our team familiar with that guidance, such as an Architecture Owner (AO). This person may decide to look up the current version of the architecture guidance as needed (hopefully this is captured in an agile, lightweight manner). Such architecture guidance may include:
- Technologies we’re moving towards
- Technologies we’re moving away from
- Technologies that we mustn’t use
- Previously identified architecture experiments to run (important in multi-team environments to coordinate learning efforts)
- Results from architecture spikes performed by other teams
Architecture Spikes
One of the approaches that our team uses to evolve our architecture is to run architecture spikes (or simply called spikes). Whenever we run into an architectural issue, such as how a technology works within our environment or how a combination of technologies work together, we write a bit of code to explore the issue. This is typically throwaway prototyping code because we want to quickly experiment to gather sufficient data to make a better-informed decision. Spikes typically take a few hours to a few days. A spike can be thought of as a very small proof of concept (PoC).
Walking Skeletons
One of the approaches that our team uses to evolve our architecture is to develop a walking skeleton, also known as a working skeleton or steel frame, of our solution early in Construction. We do this by focusing on a small collection of requirements early in the lifecycle that implement sufficient functionality to address our highest-risk items so as to show that our architectural strategy works in practice. Once the walking skeleton is in place we spend the rest of Construction putting the functional flesh onto it.
Just-in-time (JIT) Model Storming
One of the approaches that our team uses to evolve our architecture is to explore requirement and design details at the last most responsible moment. We do this via light-weight agile modeling (sketching, sticky notes, …). Model storming sessions are often impromptu and last for several minutes, often starting with a request along the lines of “Hey, can you help me work through this…”.
Parting Thoughts
After the workshop I received a lot of great feedback from attendees. It really resonated with people and seemed to provide them with a lot of value. I was glad to hear that.
Further Reading
- Architecture Owner
- Identify Initial Architecture Strategy
- Enterprise Architecture
- Agile Architecture Strategies
Posted
by Scott Ambler
on: August 10, 2018 09:34 AM |
Permalink