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.
Technorati Tags: SOA, Service Architecture
2 comments:
I think I agree with you on this, Steve. I've met vendors that promised me to deliver complete business solutions from scratch in a quarter of the time it would normally take. And what they did was just mention BPM, SOA and ESB. With their wonderful tools it would all be a peace of cake. Mind you: tools that are new, leveraging new immature technologies, no installed base, no educated developers around (neither educated in new technologies nor educated in the new tools).
And I've met (naive) managers that believed them...
And when the vendors didn't meet their targets it was because "the requirements were not specified well enough" or "the infrastructure was not properly deployed". And they told our managers AFTER the contracts were signed, not before...
In current days we not only have to cope with new technology and architectures, but also with sneaky vendors and ignorant IT-managers who tend to believe vendors in stead of their own architects. Why? Because vendors are selling beautiful solutions and architects mention the pitfalls to be aware off.
I'd only mention that the post you reference is written by an enterprise architect working in Microsoft's internal IT "department". He is not involved in any part of the sale of said technologies to customers. To top it off, as a blogger he only represents his own views.
Other than that, I totally agree with you :)
Post a Comment