We, developers, often lack the nuances of a large vocabulary. Our world is made of functions, objects, components, pipes, and many TLAs. The latest addition to our vocabulary is the word "service". This word is interesting because everybody (customers, marketers, CEOs, users...) can relate to it. After all, isn't our society so "service oriented" already?
What we often forget is that the words we use represent concepts and only concepts. This is why neologisms come to life. Most developers think of a class, an interface, polymorphism, inheritance, just as very flexible programming constructs. And yes, sometimes "objects" do end up mapping really well to some "physical objects", but this would be a very naive rule if applied blindly.
"Service" and "Service Orientation" are both new concepts, new ways to think about programming, but we did not really create a neologism for it, we just used an old word to describe them. And for the better or the worse, developers have caught the imagination of lots of people.
What is so new about it? at their foundation is the fact that most systems we build today need to be connected to lots of other systems to perform their operations. Services and service orientation, as abstract programming concepts, are specifically designed to build connected systems made up of any arbitrary number of autonomous software agents performing a unit of work together. In order to work cooperatively these agents must expose interfaces and the unit of definition of an agent interface is called (abstractly) a "service". We needed a "new" word, as developers, because this concept had no other equivalent.
More specifically, the principles of service orientation enable us to package functionality in a way that make it more easily extended and composed: it enables us to build process-centric composite applications, without technical boundaries.
Oh.. and yes, we could also build cool "utility" services with it: wouldn't an "Address" service be really nice? when you spot any address anywhere (web page, report,...) you could with a click invoke operations like: map, drivingDirections, or pointsOfInterest? If would be a bit harder but equally nice to click on an event definition (a show, a movie,...) and automatically add it to your calendar, including a pointer to the address of this event... Ultimately the boundaries and functionality of these "utility" services will be defined by the inherent price you pay for invoking a service and for a high degree of availability of services versus the cost hosting these services in-house.
Incidentally, service orientation is not really about enabling "outsourcing", i.e. make entire systems or applications available when you need it and hosted outside the boundaries of your organization. We have known how to do that for a long time and it did not dramatically change the business landscape.
Service Orientation is rather about enabling "right-sourcing", i.e. move (or keep) arbitrary small or large elements of functionality wherever it is the most cost effective to operate them, not just entire systems like it is the case when they are outsourced. Economically, "right-sourcing" is far more efficient than "outsourcing".
So what about Microsoft's Strategy? well Microsoft's strategy is only focused on the word "service" and the familiar concept it represents. Microsoft strategy is only about finding its next business model where upgrades (and revenue) are "seamless" as growth is predicted to level off. What I find really interesting is that "service orientation" is precisely, and more so than ever, about enabling you, the enterprise, innovate at the business model level, not just us the vendors... this is what ESA is all about.
