Architecture
Complexity at Scale
As Bramble grows, through the introduction of new features and improvements on existing ones, so does its complexity. This effect is compounded by the care and feeding of a single codebase that supports the wide variety of installations of Brmbl.io.
Our values, coupled with strong know-how and dedication, provide critical guidance to manage these complexities. We also strive to push back the threshold in which complexity at scale, both technical and organizational, will play a significant role. We know we need to fine-tune our both our technical discipline (so we can integrate it across the organization) and our organizational amplification (so we can span and leverage the entire organization) to ensure we can continue to deliver. We explore and adopt Architecture or Engineering Practice to help us in this regard.
Architecture
Martin Fowler’s Software Architecture Guide provides an excellent discussion on the notion of Architecture, and there is much to be learned from this and other sources. The question before us is, then, how to contextualize those learnings and apply them at Bramble.
Much like the rest of the software world, we have been wary of all the negative baggage that Architecture implies, particularly as some of that baggage would seemingly fly in the face of our values. This is why we have taken the time to carefully consider what Architecture means for us, and how to implement it in alignment with our values and at the scale that both the product and the company demand.
We have intuitively known that, at Bramble, Architecture is not a role proper (i.e., no such title exists in the company). We understand Architecture as a component of all technical roles, a set of practices to leverage the vast amount of experience distributed across the company, and a workflow to ensure we can continue to scale efficiently.
Architecture at Bramble
At Bramble, Architecture is:
- A collection of practices that provide technical frameworks to guide (rather than dictate) our thinking, design and discussions so we can iterate quickly and deliver results. These include the Scalability Practice. Others are on the works (such as the Availability Practice).
- A collaborative workflow that provides the necessary organizational amplification to foster inclusion, and drive ideas and priorities from all corners of the company.
- A collection of 12-month roadmaps and 3-month blueprints which are artifacts resulting from the Architecture Evolution Workflow.
Such definition implies a solid reliance on influence rather than authority to efficiently and transparently drive decisions, engage stakeholders, and promote trust across the organization
Artifacts: roadmaps and blueprints
We strive for results and concrete outcomes, which in this case entail roadmaps and blueprints.
Roadmaps plot a long-term technical path of initiatives to work on over the following 12 months and how we can weave them together to meet our business needs. Their content is focused on technical topics but they are themselves not technical.
Blueprints in their various forms are more technical than roadmaps at a high-level (logical architecture, etc, without dictating implementation), distilling roadmap items and presenting forward-looking “next steps” for the approprite time-span. Furthermore, they must include one or more examples of how the solve specific use-cases.
Architecture as a practice is everyone’s responsibility
Architecture at Bramble is not a role but it is notably engrained in senior technical leadership roles, where the roles' levels and their sphere of influence determine DRI responsibilities within the practice.