You don't say...?

The road to SOA success is replete with potholes. With this in mind, ZapThink's Jason Bloomberg offers this list of 7 things you "shouldn't say" during your enterprise architecture team meetings:     

• Let's get our SOA from our preferred vendor. [Y]ou can't get SOA from software, because SOA consists of best practices. Since architecture is something you do, not something you buy, you must hammer out an architectural plan before selecting software.
• Where's the (insert three-letter acronym here)? There's a good chance you already have sufficient middleware -- so looking for an ESB (or any other three-letter acronym, for that matter) is often the wrong place to begin. Instead, start with the architecture, determine the best approach to implementing loosely coupled, distributed, composable Services, and only then hammer out the best infrastructure to make that happen.
• We don't talk to the people in that department. [I]t's critical to have a big-picture view of your enterprise architecture to drive your SOA planning from the top down. By not including networking folks, security experts, application designers, IT specialists, or line-of-business experts in your architectural planning sessions, you are needlessly constraining the value and scope of your SOA efforts.
• You're full of it. For your SOA initiative to be successful, you'll need to assemble cross-functional, cross-departmental teams. This mixing and matching of different people with different priorities is a recipe for politics, conflict, and even chaos. The best approach to addressing these issues is to take them one step at a time, and the first step is for everyone to be willing to listen to the others on the team and respect and value their opinions. It's healthy to approach SOA with a dose of skepticism, but never do so without respecting the opinions of the other groups and realizing that SOA will indeed challenge the way you think today.
• You do SOA your way, I'll do it mine. If architects succumb to the organization's tendency to silo itself, then the resulting architectures will never live up to the promise of SOA. So, it's OK to have many different Services, contracts, policies, and processes. But it's not OK to have different, competing visions for enterprise architecture in the organization.
• Let's consider an alternative to SOA.  While SOA will certainly evolve over time, it's important to realize that SOA represents an opportunity to focus on enterprise architecture more so than an excuse to debate some alternative approach. Rather than spending fruitless hours arguing, it's far better to discuss how to do SOA right and figure out the next steps on your roadmap.
• SOA is too hard. The fact that SOA is hard is an indication that you're finally tackling something of value. After all, it's trivial to buy some new piece of software, but that won't solve your acute integration and agility problems alone.

As Bloomberg concludes, "[T]he simple action of bringing together enterprise architects from across the organization to get everyone on the same page with respect to SOA is itself an important and significant step in moving an SOA implementation forward...One of the most significant purposes that these groups have is to formulate a single SOA story for the team to take to senior management. Developing a single SOA business case and roadmap is a huge win for the company, and groups like these must rise to the challenge."