I’ve been spending some very enjoyable time recently with our architecture team working through some of the complexities that we’ll be facing in our next planning iteration. Many of those topics make for interesting posts in their own right, but what I want to discuss in this post is the architecture team itself.
Why? Because I’m pretty happy with how we’ve evolved to “do” architecture here.
And why is that noteworthy? Because too many of the software architecture teams I’ve worked in, with or around have had operating models that sucked. In the worst cases, the teams have been “ivory tower” prima donna chokepoints creating pretty diagrams with methodological purity and bestowing them upon the engineering teams. At the other end of the scale, I’ve seen agile organizations run in a purely organic more with little or no architectural influence until they ran up against a tangled knot of incompatible systems and technologies burdened with massive architectural debt. And everything in between.
So, how do we “do” architecture at Bonial? I think it helps to start with the big picture, so I brainstormed with Al Vilegas (our chief architect) and we came up with the following ten principals that we think clearly and concisely articulate what’s important when it comes to architecture teams:
- Architects/teams should think strategically but operate tactically. They should think about future requirements and ensure there is a reasonable path to get there. On the flip side, only just enough should be developed iteratively to meet the current requirements while leaving a reasonable runway.
- Architects/teams should have deep domain expertise, deep technical expertise, and deep business context. Yes, that’s a lot, but without all three it’s difficult to give smart guidance in the face of ambiguity – which is where architects need to shine. It takes time to earn this experience and the battle scars that come with it; as such, I generally call BS when I hear about “architects” with only a few years of experience.
- Architects must be team players. They should be confident but humble. Arrogance has no place in architecture. They should recognize that the engineering teams are their customers, not their servants and approach problems with a service-oriented mindset. They should listen a lot.
- Architects/teams should be flexible. Because of their skills and potential for impact, they’ll be assigned to the most important and toughest projects, and those change on a regular basis.
- Architects/teams should be independent and entrepreneurial. They should always be on the lookout for and seize opportunities to add value. They shouldn’t need much daily or weekly guidance outside of the mission goals and the existing/target enterprise architecture. They should ask lots of questions and keep their finger on the pulse of the flow of technical information.
- Architects must practice Extreme Ownership. The should embrace accountability for the end result and expect to be involved in projects from start to finish. This means more often than not that they will operate as part of the specific team for the duration of the project. They may also assist with the implementation, especially the most complex or most strategic elements. “You architect it, you own it.”
- Architects/teams should be solid communicators. They need to be able, through words, pictures and sometimes code, to communicate complex concepts in a manner that is understood by technical and non-technical people alike.
- Architects/teams should be practical. They need to be pragmatic and put the needs of the business above technical elegance or individual taste. “Done is better than perfect.”
- Architects/teams should be mentors. They should embrace the fact that they are not only building systems but also the next generation of senior engineers and architects.
- Architects/teams must earn credibility and demonstrate influence. An architect that has no impact is in the wrong role. By doing the above this should come naturally.
If you take the principles above and squint a little bit, you’ll see more than a few analogs to how military special forces teams structure themselves and operate, as illustrated below:
| High-performing Architecture Teams | Military Special Forces Teams |
| Small | Small |
| Technical experts and domain specialists | Military experts and domain specialists |
| Extensive experience, gained by years of practice implementing, fixing and maintaining complex systems | Extensive experience, gained by years of learning through intense training and combat |
| Flexibly re-structure according to the mission | Flexibly re-structure according to the mission |
| High degree of autonomy under the canopy of the business goals and enterprise architecture | High degree of autonomy under the canopy of the mission and rules of engagement |
| Often join other teams to lead, support, mentor and/or be a force multiplier | Often embed with other units to lead, support, mentor and/or be a force multiplier |
| Accountable for the end results | Accountable for the mission success |
Hence the nickname I coined for this model (and the title of this post): “Special Forces Architecture.”
How does this work in practice?
At Bonial, our 120 person engineering team has two people with “architect” titles, but another half dozen or so that are working in architecture roles and are considered part of the “architecture team.“ An even broader set of people, primarily senior engineers, regularly attend a weekly “architecture board” where we share plans and communicate changes to the architecture, generally on a weekly basis. We recognize that almost everyone has a hand in developing and executing our architectural runway, so context is critical. To paraphrase Forest Gump: “Architect is as architect does,” so we try to be as expansive and inclusive as possible in communicating.
The members of the architecture team are usually attached to other teams to support major initiatives, but we re-assess this on a quarterly basis to make sure the right support is provided in the right areas. In some cases, the architecture team itself self-organizes into a project team to develop a complex framework or evaluate a critical new capability.
Obviously there’s a lot going on – we typically have 8-10 primary work streams each with multiple projects – so the core architecture team can’t be closely involved with every project. To manage the focus, we use a scoring system from 1-5 (1 = aware, 3 = consulting, 5 = leading) for what level of support or involvement is provided to each team or initiative. In all cases, the architects need to ensure there’s a “big picture” available (including runway) and communicated to all of the engineers responsible for implementing.
For example, right now we have team members embedded in our critical new content management and publishing platform and our Kraken data platform. We have one person working on a design and PoC updating the core user model. Several members of the team are also designing and prototyping a new framework for managing machine learning algorithm lifecycles and testing. And a few people have individual assignments to research or prepare for future runway topics. In this way we expect to stay just far enough in front of the rest of the team to create runway without wasting time on phantom requirements.
Is this model perfect? No. But perfection isn’t our goal, so we optimize for the principles above – adaptability, autonomy, expertise, ownership, impact – and build around that. Under this model, the Bonial platform has gone from a somewhat organic collection of monolithic apps running on a few dozen servers to a coherent set of domains consisting of APIs, micro-services, legacy systems and complex data stores running on hundreds of cloud instances across multiple continents. I have my doubts that this would have happened in some of the more traditional models.
I’m happy to answer questions about this model and talk about the good and the bad. I’d also love to hear from you – what models have worked well in your experience?