I've spoken a bit recently about Enterprise Architecture as a collaborative tool, rather than a command and control structure. Talking about collaboration is good, but it takes more than a desire to collaborate to move EA in that direction. In reality, collaboration is an intentional effort, not just something you do by getting a group of people together and talking about architecture. While that's a key first step, and one you can do right now to improve your current landscape, collaboration is a culture which must be encouraged and fostered and which requires stronger leadership than any command and control structure ever does. But I don't want to talk about the soft skills of leadership today. Instead, I'd rather talk in this and another post or two about tools that make EA Collaboration a richer and deeper experience. By tools, I don't mean modeling tools, repositories or frameworks. Those things have their place, but EA is also about people, and the tools of which I speak are tools that help people work together. These are common, simple tools that don't cost an EA team much, but which can add a good bit of value to your efforts.

The first is a communication tool called a RACI Chart. A RACI chart is a simple device used to describe  the roles and responsibilities of a group of people in completing certain tasks or deliverables. An example of a RACI chart from Wikipedia is depicted on the left and illustrates tasks or deliverables as rows (what is being worked on) and roles as columns (who is working on it). At the intersection of each task and role is a letter (R, A, C or I) to represent a role's level of involvement in a task. Here is the meaning of each letter:

• Responsible - The person who does the work. (There can be multiple)
• Accountable - The person accountable for the completion of a task, or the "single wringable neck." (There can only be one)
• Consulted - A person or people with input into the task. Their expertise is needed.
• Informed - A person or people who "need to know" the outcome, but who need not be consulted during the process.

So why is this valuable to EA? For me, the reason is because it removes assumptions and brings clarity to collaboration. RACI charts enable a group to go into a process or task with a clear understanding of everyone's role. Differences of opinion over the level of involvement are resolved up front, which makes it that much easier for a group to move forward on the "same sheet of music" so to speak. Without clarity, you usually create conflict around contribution (bad), rather than conflict around content (good).

Here's an example of a RACI chart that lists some common Architecture deliverables (both Enterprise- and Solution-level):

I won't go to deep into the content here because the deliverables and roles don't apply to every organization. For that matter, neither do the structural and cultural issues that play into "correctness" of this particular chart. The key is to recognize that the chart clearly identifies Rs, an A, Cs and Is for each deliverable listed as they relate to various roles in the organization. On the occasions where I have leveraged this method in the past, I was encouraged by the clarity it brought to the teams with which I was working. On one occasion, I was told that this model helped one individual put his finger on some past frustrations he had around certain deliverables and also understand with clarity how he "fit" into these cross-functional decisions.

Of course, these charts are no substitute for open and honest discussion and they should never be used as a way to manipulate people. They are intended to bring clarity and should be used only to obtain it. Once you've got it, it's time to move on to the task art hand, which you'll do with a lot more clarity than you would have otherwise.

• Never Email Anyone Over 30 - I've seen many enterprises that think that Email + IM = collaboration needs met and I find it pleasantly surprising to see that IM as a collaboration tool is diminishing in the eyes of the younger generation of workers in favor of things like SMS, Wikis and Blogs (Twitter is probably just about in its own category). What that means however is that the enterprises who are just now getting IM in the Enterprise are still behind the curve... so what's your strategy for embracing the next generation of collaboration tools? Does an Enterprise vendor have to offer it before we'll buy it?
• Practical Enterprise Architecture - Some good tips on creating valuable Enterprise Architecture.
• What is Enterprise 2.0 - As much as I don't like the phrase, or "concept versioning" in any form, I like what the idea represents in terms of driving information access, interconnected applications and devices and collaborative and open work.
• SubSonic - This looks to be a very nice ASP.NET scaffolding framework that parallels much of the project start-up scripts that makes Ruby on Rails such a nice environment to work in. (via Ken Scott)
• Should people adapt to computers? - Agreed Scott. I think that people have adapted enough... it's time to set them free, and I don't mean by turning their coffee table into a computer either.
• Enterprise Architects versus Business Architects - While I certainly don't think that the role of EA is to create services within an Enterprise SOA, I do think that EA has a responsibility in handing valuable business process knowledge to an SOA team that then knows which services are needed. Otherwise, services end up being created to wrap whatever database entities a given project needs next. In any case, the key is that EA has a responsibility to be relevant to SOA efforts, not the other way around.
• Enterprise Architecture is like Herding Cats - Don't know what I could possibly add here...
• Is Serendipity the Heart of the WS-*/REST Debate? Serendipity is probably a large part of the discussion, but I think a key to Nick Gall's General Principle of Serendipity ("Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.") is that one can rarely (even in an enterprise) plan for explicit reuse of a service. As such, you plan for serendipity.

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.