SOA is a Concept, not a Goal

Actually, it is possible to transition a massive business application from a monolithic chunk into a sleek, SOA machine. It's a pretty expensive undertaking, and it requires that all the parts be actively maintained. In fact, it requires that a large and actively developed codebase is the core of your business. The major advantage isn't mashability, it's separation of concerns, failure isolation and clearer component ownership. It means that I can operate and maintain my part of the system without affecting your part any more than I have to. I can scale my service independently of yours. That kind of thing.

It's definitely a large amount of effort. Whether the benefits outweigh the costs depends entirely on your specific circumstances. I specifically used "business" instead of "application", because unless your business utterly relies on your application, it's unlikely to be important enough to justify the cost. Your concerns about ownership are misplaced, I think. In the old world of the monolithic app, you had teams responsible for bits of the app. In the SOA world, each team is responsible for a service in its entirety. There are obviously still dependencies and interactions, but they tend to be a little more clearly defined, since you're not sharing codebase, memory space or even machines with others anymore. Fault isolation is a trickier one. While you're not going to break all dependencies, it does mean that the only way an external service can break you is to (a) not be there or (b) behave badly. You can fail or degrade gracefully in (a) and try to mitigate (b). In no case (barring your own bugs) will an external service chew up all your resources or segfault your process. Assuming decent logging and auditing, without which debugging /anything/ is a nightmare, it doesn't become any harder to track down where stuff broke. It also makes dealing with scaling a little easier, in that you only need to worry about your own service rather than having to scale out prematurely because someone else's library needs a lot more resources. It also means that you don't need to care if someone else's service needs to grow to deal with load from other sources. You do need to standardise your interfaces, or you're in for a world of pain. For your own services, this isn't that hard. If you rely on external services, you'll either have to deal with them or stick thin proxy/translation services in between. If you're using a lot of other peoples' stuff, this can be a killer. You still need decent integration testing and you still need all your teams to talk to each other about design and feature set. Some services will be very specific and only have one consumer. Others will be broad and have to balance the needs of many. SOA isn't a silver bullet, of course. It takes more resources to run lots of little applications than one big one. All the packing and unpacking of little chunks of data between services can add up. Specialisation and ensilofication can cause inefficiency. I do think it's the best model currently available for massive, highly available systems.