I’ve already discussed in an article and a blog post the difference between the Agile enterprise architecture I write about in my book, The Agile Architecture Revolution, and the Agile software architecture that many people think of when they hear the phrase Agile Architecture. Yes, it makes sense to apply Agile software development best practices to software architecture, and yes, such software won’t necessarily make your organization any more agile. But maybe there’s a way to connect the dots here. Can we simply expand the scope of Agile principles beyond software development to software architecture, and again to enterprise architecture?

At a high level, yes, but the devil is in the details. The problem with this extension centers on how teams work. Teams, of course, are made up of individuals, and each individual has his or her own strengths and weaknesses. For each development team, you have a mix of skill sets, levels of experience, and fundamentally, levels of competence. To squeeze the best possible software out of such inherently diverse teams, Agile approaches include techniques like pair programming and team ownership of code. We don’t like talking about it much, but team ownership of code is a great way to deal with the fact that while some of your coders likely crank out great code, others likely crank out code that is, well, less than great.

Extending Agile principles to software architecture runs into even greater competence problems, because now you’re expecting everyone on the team to contribute to the software architecture – even though many members of the team really aren’t architects, or at best, they’re unseasoned architects. If you have one or two good architects on your Agile team, you don’t want someone else on the team going into the architectural artifacts and mucking them up. This uneven architectural competence is why Agile software architecture approaches typically call for an owner of the architecture – a true architect who can keep the non-architects on the team from making matters worse.

Fair enough. But taking the next step – extending the Agile approach entirely beyond the software project to the Enterprise Architecture – exacerbates this competence problem further. EA skills are quite different from software architecture skills, and we could also argue that EA is more different from software architecture than software architecture is from software development. A seasoned systems developer will necessarily learn many software architecture techniques and best practices simply through the process of getting code to work properly in a distributed systems environment. But software architects used to working entirely in a technical context will find EA to be an alien endeavor. After all, true EAs spend very little time thinking about software.

Don’t let the architect title fool you. Expecting a software development team to share ownership of the enterprise architecture is almost always a fool’s errand. Agile enterprise architecture requires a different way of thinking. Want to learn more? Read my book.