I whole-heartedly agree, and will offer something that I didn't see a lot of, in your article: suggestions for how to start going about correcting the problem :-)

First, EAs should consider looking at EA frameworks (i.e. TOGAF, Zachman, etc.) and EA-level tools (Volere, impact/gap/cost/benefits analysis, view/viewpoint definitions, etc.), which present a more comprehensive view of the EA process. If they did they'd realize that:

1) SOA is only a sliver of the entire EA process, and

2) Adopting SOA needs to be an enterprise principle, which is demonstratibly aligned with corporate principles. Without that, you'll never really get the solid buy-in you'll need, because the argument for doing SOA can't even be tied back to known company goals/strategies.

Second, you've got to take the keys away from the people who insist on driving, when they're "drunk" (or "high") on SOA. In that state, they're incapable of realizing that it's not a miracle drug for whatever ails the corporation. SOA can be like crack cocaine, to some people :-) Play it safe and combine SOA w/virtualization, complex-event processing, business processes, etc.

And lastly, just play the SOA hand you were dealt, and then only bet money you and the company can truly afford to lose. When it's gone, get up from the table, and walk away. What does that mean? It means, only invest in something to the degree that you can actually get a proven measureable profit, from doing so. Annual profits and Wall St. numbers, lie do not :-)

I think you have soooo hit the nail on the head. As the leader of the EA organization in a major federal agency, I found that moving this kind of change is very difficult, particularly if you care about continuing your career. It is very easy to fall back on point solutions that this project and that project want, and not get to the real core issues that are holding the organization back (often around data).