On your projects, are you working directly with an enterprise architect? Do you receive documentation from an enterprise architect (EA)? Is the enterprise architect a bottleneck for your project design and estimating activities? Are you, like me, more than a little confused about the role of the enterprise architect?

A little Googling will have you convinced that the EA is some kind of organizational wizard who sees all and knows all. Whether she lives in a tower and keeps a raven as a familiar is up for debate.

Definitions are hard to come by. There are many, mostly sounding like they were generated by a obfuscation machine. But there seem to be several distinct flavors:

1. The IT- Business Bridge – The Bridge is responsible for understanding the current business strategy and translating that into IT projects which enable that strategy.
2. The Integration Guru – The Guru is knowledgeable about the total ecosystem – applications, databases, services – and how they interface with each other. She provides documentation and guidance to IT project teams to ensure they understand the impacts of ecosystem changes and constraints.
3. The Ecosystem Designer – The Designer is the top-level technical analyst in the organization who makes system design decisions that project teams are responsible for elaborating and delivering.
4. The Enforcer – The Enforcer sets software standards for the organization and ensures that all project teams are educated about and adhere to those standards.
5. The Innovator – The Innovator is tasked with looking ahead at industry trends and cutting edge technology to ensure that her organization is competitive.

Of course, EA, like PM or PdM, is not a role that fits easily into any box. What an EA does is partly dependent on the organization in which she operates and her own area of expertise. She may do some of all of these roles, depending on the situation. I’ve worked with different EAs in the same company who had very different approaches. Some were of the “here’s an architecture diagram to inform your technical design” variety. Some were of the “invite me to every meeting and let me vet all of your requirements” variety. Which can make it hard, when you move to different projects or jobs, to know what you should expect.

The Enterprise Architect in an Agile World

This confusion is even more pronounced in the Agile world. Most models I’ve seen illustrating team responsibilities put a very top-heavy emphasis on EA activities, showing actual software teams as mere deliverers of capabilities imagined and designed by the EA team, and sometimes leaving business analysis out of the picture altogether. That doesn’t really sync with the reality of Agile software development. So how do organizations integrate the EA into Agile?

So much of our focus in Agile is on the user story, a request to provide a software capability to deliver a business value, usually very small in scope. Whether you consider a user story a break-down of a bigger feature or as a stand-alone request, the focus is all on the user. But if the user story is the WHOLE story, you’ve got a problem. It’s fine to build a Lego castle one tower at a time, but if you don’t start with a big enough base plate, you’re going to end up tearing it down and starting over.

I asked an EA that I’ve worked with for some insights on doing architecture right in an Agile organization. He explained his ideal way of working with Agile teams. I’m going to use this as a roadmap on my next project to ensure I’m engaging the architect team effectively.