A while back, when I was a platform architect, our team hired a "certified" architect, who, on paper, looked amazing. When I met him, he was a genuine yet ambitious guy who has worked hard consistently over some years to get where he was. He was accomplished and knew his stuff. His architectural documentation and processes were impeccable and pristine. But there was a problem. Apparently, it was the first time he's ever had an implementation problem. He simply couldn't get anyone on his development team to follow his architecture. No one. When he confided in me, I didn't understand why the teams wouldn't implement his architecture. Any developer could see that his architecture was solid, met all the requirements, and exceeded what everyone wanted from the project. So I started asking the team, and they simply said something like, "I am not here to take orders."
Historically, having finally achieved a milestone in their career, many architects declare edicts, directions, plans, and strategies from "on high" or some ivory tower as a czar or dictator of sorts, sometimes even without meaning to do so. Sadly, some of the worst offenders I've seen are "certified architects"—though I don't necessarily believe this to be representative of the certification (it's likely "those architects" become certified in order to tell people what to do). Regardless, I cannot and will not work this way as an architect or even as a developer. To me, it is embarrassing that architects are even viewed this way by some.
Sitting in a conference room with this "certified" architect, he asks me, "How do you do it?" Umm, what!? As a developer who learned to develop from Google (does that make me a Google developer?), I wasn't the best or the most experienced developer in the room. I just became an architect myself a year before. Frankly, I wouldn't have hired me to join the architecture team. I was never taught how to do architecture. I never had a course on architecture or system design. I never received instructions or guidance or even advice. In my ignorance, arrogance, naïvety, or even all three, I never even thought to ask someone for help, which was foolish! I was just excited to be in the room as an architect!
Yet, there I was an equal with this certified architect, and he's waiting for my answer. It was there that I started to describe what I call Grassroots Agile Architecture.
What is Grassroots Agile Architecture?
Merriam-Webster defines grassroots as:
- basic, fundamental.
- the very foundation or source.
- the basic level of society or of an organization especially as viewed in relation to higher or more centralized positions of power.
Grassroots Agile Architecture is foundational using the very basic level of a team to create the architecture. It is agile in that it seeks only to provide enough architecture to get the project started and keep it going.
Grassroots Agile Architecture emphasizes two SOLID architectural principles (definitions from Clean Architecture):
- Open-Closed Principle - objects should be open for extension but closed for modification; more specifically, Uncle Bob's Polymorphic Open-Closed Principle.
- Liskov Substitution Principle - build systems from interchangeable parts that adhere to a contract
Additionally, this approach embraces the notion of deferring decisions and keeping options open. Many developers are very detail-oriented people and desire those details up front before development begins, sometimes rightly so. Grassroots Agile Architecture can cause these sorts of developers various levels of distress. Knowing what decisions to defer is a critical skill, and because of this, architects must have the ability to alleviate the stress and angst of the developers who want everything up front.
Grassroots Agile Architecture is collaborative.
Being foundational and collaborative, it starts with the developers. The architect, whether a member of the development team or a centralized architecture team, is simply a developer among developers, a first among equals. The architecture is not declared or announced or dictated. He/She does not present an architecture (or even an initial architecture) and discuss/debate it though he/she may have a general idea or a starting point. Instead the architect facilitates the collaboration and the architecture with design workshops (or whatever you may call them).
It starts with design workshops where:
- The problem is clearly defined.
- Requirements are listed but not prioritized (something is better than nothing).
- Architectural principles affirmed or established (starting with the enterprise architectural principles if those exist).
- The design of the initial architecture is created.
A key difference is that these design workshops are collaborative, and depending on the team size, the workshop is comprised of a product person, a designer, an architect, and either the entire development team, the team’s technical leaders or the most senior developers.
Grassroots Agile Architecture seeks consensus, promotes debate, enhances the culture, encourages collaboration, and pushes development forward. However, it is also not architecture by committee or even consensus. While architecture is owned by the whole team, only one is responsible (otherwise our project managers would hate us and RACI charts break), and it is the job of that one to ensure something (an implementation, approach, etc) is not debated ad nauseum. Sometimes decisions need to be made so work can move forward. The key is knowing and being able discern whether a conversation is a rathole or determine if a decision can be deferred. During the facilitation and conversation, in order to help know whether a decision or a conversation/discussion can be deferred, suspended, dumped, postponed or parked, it helps to pause and ask yourself these questions:
- Are we still on-task, on topic, and on agenda?
- What happens if we don't make this decision or have this discussion right now?
- How is this conversation getting us closer to our goal, needs, or initial architecture?
- What is the goal of this conversation? What are we debating/discussing?
- Is this premature over-optimization or generalization?
- Considering the Polymorphic Open-Closed and Liskov Substitution Principles, what is the simplest decision we can agree on that works within these principles?
Grassroots Agile Architecture is intentional (and organized).
To some, this Grassroots Agile Architecture can feel haphazard, chaotic, disorganized, "entrepreneurial" (in the immature, negative stereotype), and/or like a free-for-all. However, the opposite is actually true This approach does not give permission for anyone and everyone to practice architecture alone. Instead it does give permission for all to join in the collaborative process of creating an initial architecture. In this initial architecture development, the team should intentionally plan, organize, and even build a variety of POCs or reference implementations to ensure that the entire team is aligned, an approach and direction determined, and the adopted process is outlined.
Additionally, Grassroots Agile Architecture is not permission to reject enterprise architecture completely. Teams should still adhere to enterprise architectural principles (if they exist) or even help create these architectural principles, especially on large, complex projects. Enterprise architects can engage in Grassroots Agile Architecture in how they engage and lead teams (with or without embedded architects) to want to follow those principles, governance and rigor. It is about how they communicate the principles, required documentation (flexible and not requiring for requirements sake, which is an easy trap to succumb), and potential checkpoints and/or gates.
Grassroots Agile Architecture is practical.
Because the architecture starts at the lowest level incorporating both product and engineering, the architecture becomes practical almost immediately. The team building the application or system constrains the architecture with their skillsets. For example, if the team is a team of nodejs developers, it would be very hard to convince them to write the system in Java; however, it is the responsibility of the architect (or the one assuming the role of architect) to ensure that programming language constraint will not cause future issues or prevent achieving the requirements. Sometimes a project may need to pivot technologies, and if so, consensus is needed or enough air coverage or time needs to be allowed to ramp up the team's skills. Assuming there is a dedicated or provided architect, the architect is someone intimately involved in the development of the sprint deliverables as a developer, whether that is developing on some tasks, performing code reviews, enhancing tests, or whatever to ensure code quality and standards being met. As a result, the architect can speak familiarly with the various ins-and-outs of the application or system.
Grassroots Agile Architecture also encourages reprioritization at any time, so if a backlog item is created during a sprint, it can be injected into that sprint, or if a backlog item is suddenly deemed important, it can be moved into the sprint immediately.
Grassroots Agile Architecture is efficient (and lean).
Grassroots Agile Architecture promotes efficiency over completeness, which often results or even stems from lean teams. Starting with the design workshops, first, these design workshops should be limited in size, which probably should not exceed eight people (the amount of slices in a single pizza). Second, the workshops should be time-boxed (or limited in time), whether to a single meeting, one day, a few days, or a sprint. The architecture will be iterated upon in the coming weeks and sprints.
Please note, the goal of the design sessions is not to complete the architecture entirely, list and fully describe all the requirements, determine every single architecture principle, attempt to know all the unknowns or anticipate the unexpected. Instead, the primary goals are to define the problem and to get enough initial architecture completed and prepared so the developers can start development. Then the architecture can continue to grow accordingly just in time for the next task or sprint and so on. It is important to avoid over optimizing from the start; knowing what to optimize and what not to optimize is a critical skill that someone on the team should be considering.
The problem is clearly defined.
Requirements are listed but not prioritized (something is better than nothing).
Architectural principles affirmed or established (starting with the enterprise architectural principles if those exist).
The design of the initial architecture is created.
Third, the architect can be a dedicated or embedded architect, a loaned architect (from another team or some centralized team), the technical leader, or a very senior software engineer. However, the more complex (either in scope or in team size or involving multiple teams), the more greenfield, or even the more visible or critical the project, the more you want a seasoned/experienced, dedicated architect, someone who has “been there, done that” and understands failure.
Fourth, Grassroots Agile Architecture discourages the preparation of a ton of architectural documents. It does not discourage documentation but limits the documentation to the right amount so as not to require constant updating. Grassroots Agile Architecture favors and prioritizes architectural documents that are readable and communicate the kernel of the architectural principles or high level design/approach over diagrams that meet common industry standards and/or use rigorous tools (so this approach makes getting an architectural certification a pain). One helpful It is from this architecture that as many tasks as possible to be created and backlogged appropriately including architectural tasks and deliverables.
Summary
So having explained my approach to my colleague, he seemed to understand this entrepreneurial approach to architecture and even seemed to be excited about it. However, even after observing him with the team and eventually assuming his facilitation responsibilities, I watched him leave the company because he simply could not adapt his approach nor could he really relate to his team. Good architecture skills (or any technical skill for that matter) cannot be achieved with certification or title. It can only be achieved, refined, or built with hands-on experience.
Grassroots Agile Architecture is foundational and EPIC—efficient, practical, intentional, and collaborative. I attribute much of my success to how I do architecture. It may not work for everyone, and it may not even be the best architectural approach. But regardless, for The Weather Company, it has worked exceptionally well time and time again producing high quality applications and systems that are highly available and resilient, highly scalable and highly successful.
Before my time on weather.com, every hurricane season, the team would gather at HQ and pray the system wouldn't break, which it did, often apparently, or enough to cause the kind of trauma where everyone was required to be in the office 24x7. Since my architecture was deployed on weather.com (using my approach), it allowed us to roll out the architecture bit by bit, and weather.com has only gone down a handful of times due to hosting problems or a bad CDN configuration (which is another fun story).