Mike Walker responded to my “Is Enterprise Architecture Declarative or Imperative” question with some great thoughts that I’d like to respond to and expand upon here.

For starters, Mike mentioned that he doesn’t really care for the terms declarative or imperative. I suspect, based on the tone in the rest of his post, that his dislike stems from the cold and mechanical way those terms may sound when used to represent people. In addition, I think that some would interpret, as Mike did, the declarative term as implying a command and control structure in the sense that EA is still telling teams “what” to do. I’d be willing to grant Mike that those are reasonable arguments,  but I will also say that the question was never about the choice between declarative or imperative. Rather, the terms ”declarative” and “imperative” represent the ”world view” an EA team adopts when sitting on one side or the other. In my mind, declarative teams foster a collaborative community, while imperative teams concern themselves with frameworks, governance, models and the “ROI of EA.” Not that these things aren’t important, it’s just that community and collaboration are more so (a la ”Individuals and interactions over processes and tools” in the Agile Manifesto).

Beyond the terms used to frame the debate, I am in complete agreement with the remainder of Mike’s post. The key, Mike says, is that EA is about “fostering community, providing the frameworks for decision making and providing assistance on mission critical projects.” I think that the real key word there is community. We know frameworks in EA (too well at times) and we know assistance (though we might know it by the word governance often), but I think we tend to shy away from community because it’s very contrary to most of the hierarchical organizations in which we find ourselves. But it is without that community that EA is “…viewed not only as Ivory Tower but as traffic cops” as Mike stated. With community, EA is able to voice the strategies of the business and speak from it’s unique vantage point, while at the same time empowering and trusting teams to take the expertise and input of EA and bring it to bear on their projects.

That being said, just saying that EA needs to foster a collaborative community is not enough. I have found that the EA/ SA (or Domain Architects as Mike calls them, a term I like quite a bit) interface can also foster confusion and generate conflict in many cases. I think that EA’s and SA’s could both function better in collaborative roles if they remember a few things about themselves and their comrades.

For Enterprise Architects:

1. People deserve the benefit of the doubt.
2. Coding or not, the people you serve (SA’s) are deeper in the code than you are.
3. Seek to serve, not command.
4. Even if you have the final say in a matter, help people understand your reasons and solicit their feedback early and often.
5. Respect their craft.
6. Keep up with technology and don’t lose your edge..

For Solution Architects:

1. People deserve the benefit of the doubt.
2. Learn to appreciate and understand the role of EA in your organization. Learn to appreciate the different perspectives which they bring.
3. If EA is acting “Ivory Tower,” have the courage to tell them.
4. Treat EA as an ally, not a roadblock.

Not necessarily a complete list, but the key is that EA and SA must learn to trust one another in order to foster the kind of collaborate community which Mike, myself and so many others speak of. If you don’t see a community like that taking shape in your organization, get one started. And if yours is floundering, ask yourself what you can be doing differently before you point to others or the woes of your organization as the cause of your troubles.