The challenge is what the view is of what the "top" does and what constitutes direction.
Middle out - central group provides key elements of the interface, including numbering schemes, message exchange patterns, standard communication mechanisms, and monitoring infrastructure, and encourages the dev teams to use it to build services that can be shared.
Now these are all laudable elements, and things that should indeed be standardised on, but fundamentally they are about the technology and delivery of SOA, and not about its architecture and definition. There is nothing here about understanding the business or laying down the governance approach, its all just about the technology.
This is the big challenge when it comes to talking to any vendor about SOA, because they don't have the challenges of operating in a business environment and are focused purely on the technology delivery side it is practically impossible for them to put their products in a broader context, so they just pretend there is no broader context.
Remember this when you talk to vendors, put out an RFI for SOA or ask for some project delivery help. For a vendor every problem has a technology solution, one that requires license fees, any problem that doesn't have a technology solution will result in them pretending that there is a technology solution or ignoring that problem completely.
The post I've referred to is, as I said, not a bad view of the world from a product and technology perspective, but it is firmly constrained to that domain.