It may be that services were the wrong way to go for your organization. My experiences are almost completely opposite to yours. Bear in mind that I've done this

It may be that services were the wrong way to go for your organization. My experiences are almost completely opposite to yours. Bear in mind that I've done this mostly for larger organizations, so I think there may be an economy of scale effect going on. * Testing is fast. Rather than trying to test a monolithic application you can break your system into small reusable chunks that can be tested independently. * We implemented the basics once (or used a library) and reused them extensively. And then we created native libraries for others to use so they don't have to think about those pieces. * Security became more robust. Rather than accepting the built in security we actually thought about security and developed a plan to secure everything in a consistent manner. * Performance was about the same, although it required a bit more thought. Not only are we able to cache web pages, but now we cache data separately. Just because one piece of data on the page has expired there's no reason to go fetch everything from the db again, and in a large organization it is shocking how often the same data gets requested over and over again. * Reliability is rock solid. Yes, if your database server goes down you're screwed. If your site goes down, you're screwed. But these are known issues and aren't particular to SOA. Now we have separate, multiple instances of our site and services, we're more fault tolerant. I'm still trying to convince management that geographic tolerance should be considered too. * We re-invent fewer wheels. We have a very solid separation of concerns. The services have the business logic, and the UI doesn't matter. You want an IOS app? No problem, we create a UI that calls the service. You want a web app? No problem, we create a UI that calls the service. Having said all of that, I do not like the term SOA. I think it puts the emphasis in the wrong place. It's not about writing services, it's about solving problems. I prefer to think of it as service enabled architecture, and then I try to remind myself that just because I have this awesome hammer that I love, it doesn't magically turn every problem into a nail.