Keeping Architecture out of the Ivory Tower

There is no such thing as a “one right” right architecture. This statement is true both for systems architecture as well as for architecture functions in organizations. In both cases, what is “good” is rather a question on whether it is fit for purpose in the given context. Luckily, over time we have collected patterns and anti-patterns that help us design robust architectures and avoid common pitfalls. Whereas most of these patterns relate to systems architecture, organizational setups also have some well-known pitfalls. For central architecture teams, that would be the drift into the ivory tower.

The proverbial ivory tower denotes the state when a central architecture team deals only with abstract topics, losing touch with reality. It gets worse when these architects set binding guidelines that don’t help anyone but actually cause projects to slow down or system performance to suffer. As there is little feedback back into the ivory tower, this undesirable state often remains undetected by the ivory tower residents who revel in the purported beauty of their designs while the developers start building workarounds or ignore the guidelines altogether. Ignorance is not bliss in this case.

Why is this anti-pattern so common?  Central architecture teams have to cover a broad scope, so it’s difficult for them to stay close to the details. Following a city planning metaphor, it’s also accepted that the folks doing the “big” planning don’t have to worry about the placement of the street lights and trash cans. This is largely true in an environment that has a fairly stable set of building blocks and tools. For example, when the trams became popular or when self-driving cars will become pervasive, city planners may want to change their designs based on this relatively low-level innovation.

With IT undergoing rapid innovation, it’s equally helpful to keep the “big” architects out of the ivory tower and close to the action. I personally steer against the ivory tower by remaining hands-on – I occasionally sit down and pair program. I also built a compact architecture team that covers all levels of abstraction, including IT strategy, enterprise architecture, application architecture, infrastructure architecture, automation, and application development.  I built a team that covers all floors of the architect elevator .

This setup grounds our team in reality and also gives us the ability to execute: when our team setup a new type of application platform, the existing operations team was doubtful whether “the architects” would be able to handle operations. We did, and ordered each team member an “ArchOps” cap to brag about it. Working at all levels also gives us much needed transparency into our projects.

Such a diverse skill set makes managing it as a single team challenging. We therefore emphasize communication within the team so folks working on implementation understand our overall strategy and vice versa. On top of mixing skills, we also have no written hierarchy, which allows us to reorganize the team at will without having to reflect it in any org charts. This requires extra effort to make clear who is in charge for what topic, though. Lastly, as our team is intended to remain small, we routinely hand over our projects into regular development or operations teams. Trailblazer architects have to be content with letting go of their “babies”.

Your newfound power to execute with a “vertical” architecture team may not just find admiration. You also run the risk that existing teams feel sidelined or surpassed. This setup is therefore most suitable when you have to drive drastic change into the organization. Still, I’d take it any day over drawing pictures for management “alignment”.

Learn 37 more things that one chief architect knows about IT transformation:

• e-Book on LeanPub (PDF, iPad, Android, Kindle)
• Print book on Amazon