Enterprise Architects

I’ve been exploring my discomfort with the notion of enterprise architects, recently. After serious consideration, I think it comes down to this:

“It is not enough to do your best; you must know what to do, and then do your best.” -Deming

Enterprise Architects seem to fall broadly into 2 camps.

Those who write code. They know how the system works and how the pieces fit together; they know how it should work; they understand the benefits of new technologies and how they fit with existing tech stacks; and they know how to move from where we are today to where we want to be tomorrow. When they introduce change to a team, they do it from inside, and work with the team to make it happen. I love working with these folks because, while we come at things from different angles, we both see the system and can anticipate the impact of changes on the system.

Those who do not write code. They spend much of their time researching new technologies and how things could be; they can see the future, and it is a utopia; they have a partial understanding of the systems that currently exist; more often than not, they don’t understand how to get from today’s problems to tomorrow’s solutions. They tell people where they want to go, but cannot help them get there.

The effects of the second group are twofold:

1. Disillusionment — most people doing the work know it could be better. The problem is having the time and knowledge to make them better.

2. More noise in the system. Because they don’t do the work themselves, they often are forced to persuade or coerce (see: technical governance) people into change. Because they don’t fully understand the current system, they can’t articulate how to get from here to there; they are often ineffective and are seen as distractions by people who are trying to meet customer needs.

When people don’t appear to respond to these EAs, they often seek more and more draconian methods of ensuring their goals are met — project gates, technical governance, etc. This level of enforcement helps management feel like someone is in control, but the end result is that projects either get delayed, or these groups get ignored/bypassed/routed around.

If you want to hire an enterprise architect, try to find one that falls into the first camp. Nowadays they're often referred to as staff engineers, or coding architects.