When all are responsible, nobody is

Democracy doesn't fit well with software development, committees don't work for software development. Individual accountability works. Ask few good individuals for commitment and give them the power to act.
I'm trying to recall what the context usually is when things go wrong and what are the conditions when a project succeed. If I look back to my experience most of the successful software development projects I've been involved succeeded exactly when the decision chain was very short and decision taken promptly, especially the unpopular ones.

I think it was Fred Allen who said, "A committee is a group of men who individually can do nothing, but as a group decide that nothing can be done."

This is known also as a variant of the bystander effect. "The bystander effect (also known as bystander apathy, Genovese syndrome, diffused responsibility or bystander intervention) is a psychological phenomenon in which someone is less likely to intervene in an emergency situation when other people are present and able to help than when he or she is alone."

Really big distributed projects, say Linux and the Python language, have clear leadership expressed by few or even one person. Linux has Linus, Python has Guido. Are really our projects any bigger or more complex?

Now integration is organizationally harder than application development because integration is cross-department and under control of different ownership domains. If you leave the execution control to a committee than you can be pretty sure it is not going to deliver: distributed responsibility means almost no responsibility.

"A good plan violently executed now is better than a perfect plan executed next week."
- George S. Patton

If the team is big the Scrum agile project management process is something which could help splitting the team into smaller teams, each one with a local leader who reports to the top team leader (or top Scrum Master). The team leaders (local and top) are responsible to deliver the solution, the Time & Resource Manager is in charge to check time and budget, while the QA Manager is responsible to provide testing and validation. That's it.
If you think you can deliver any SOA or EAI project by creating a committee made of members of all IT department involved in the integration effort then you are doomed, you'll end into analysis-paralisys very soon because everybody want to say something. The next common mistake is adding developers to a late project: as Tom DeMarco taught, adding manpower to a late project actually makes it later.

“Craziness is doing the same thing and expecting a different result.”
- Tom DeMarco

We are convinced that software development management is hard, but too many times I'm experiencing self-handicapping management, when consultants or end customers are scared of taking any decision and just start blaming the tools they are using and start opening support incident without relying on what, if they, know. Then a two-months integration flow takes three years and twenty times the estimated budget.
If you have a problem, fix it now. When a better solution comes, refactor to integrate it to your fix.

"Anticipate the difficult by managing the easy."
- Lao Tzu

Java CAPS 6 Tutorials and Sample Projects

Recent tutorials and screencasts about JavaCAPS 6 can be found here. Version 6 of JavaCAPS introduces many new and additional features, so it usually takes some time to figure out the whole thing. The Grok JavaCAPS Wiki is another complete source of updated information.