I think this is a valid point, but I wonder if it this reflects a very practical consideration: IT wants to know that it can deliver on the technology end first - and to do that, it's got to figure out which approach to invest in, in terms of staff training and hiring.
Of course, this probably reflects the age-old IT practice of trying to figure out the technology first. Can't say I blame them - can you really see the business being very patient if, after a long debate about business needs and working out a plan of action, IT said, "Great, now we have to figure out how to actually build it. We'll get back to you in a few months!"
Just something I've been mulling over.
Richard Watson says there is too much hand wringing over service protocols and standards (REST, WS-*, etc.), and not enough thought given to why a service may be needed by the business in the first place. In a new post, he states that while “debates about whether to use REST or WS-* interface styles are seductive. But, these are the wrong questions to ask first.”
Instead, Watson urges the creation of services using a service model that will provide the business context to projects.
This is the essence of service oriented architecture, he says. “If context is not driving you to create the right services, then they are most likely not adding value to your applications architecture, they are making it worse.”
Build services that add value, he says. Forget about the protocol issues:
“Should I use WS-* or REST? Should a service provide access over HTTP, MOM, or XMPP? These are the wrong questions for architects to ask when first conceiving a service. By concentrating on how to build, we lose focus on what to build.”
Watson points out that when he talks about service modeling, he isn’t talking about things such as formalism, notation, and tools.
Service modeling is a smart idea for SOA environments because it encourages that services be mapped to business requirements, and not take on a life of their own as technology for technology’s sake.
