A great interview with Amazon's CTO Werner Vogels appeared in ACM's Queue magazine. A must read if you care about how to run a modern IT organization.
The SOA acronym has been abused to the point of becoming a dirty buzzword for many. The interview shows how Amazon applies service-orientation concepts with a very pragmatic approach.
WV: ...The services model has been a key enabler in creating teams that can innovate quickly with a strong customer focus. Each service has a team associated with it, and that team is completely responsible for the service from scoping out the functionality, to architecting it, to building it, and operating it.
Excellent! That's what I ment with "Project-Oriented-IT". I'm glad Amazon has been doing that successfully.
Here's why it works:
WV: ...Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations, and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.
He obviously explained it much better than I did, and with real-world experience to support it.
It shows that the cultural and organizational aspect of a SOA initiative is more important that the technologies used. SOA is not just about building "software architectures". If done right, it is a better way of organizing IT operations.
You don't even need to standardize on specific technologies/tools to run an organization with a service model:
WV: I think part of the chaotic nature the emerging nature of Amazon's platform is that there are many tools available, and we try not to impose too many constraints on our engineers. [...] Developers are like artists; they produce their best work if they have the freedom to do so, but they need good tools. As a result of this principle, we have many support tools that are of a self-help nature. The support environment around the service development should never get in the way of the development itself.
Don't force tools down the developers throat. (Any manager reading?)