SOAP/WS-* vs. REST and The Art of Politecture

Those of you who've worked on very large scale enterprise-wide architectures know that it's always the people and politics that are the biggest hurdles. I came across the term "politecture" in Nick Malik's blog here. You can follow the link for the definition, but it's essentially an architecture that's been designed with the influence of political factors. Some may say this isn't right, but I think it's perfectly fine, even necessary when you're designing a large scale architecture that has to be adopted by many people and organizations.

So what's this have to do with the SOAP/WS-* vs. REST debate? I tend to agree that there are very many scenarios in large scale distributed systems in which a simpler RESTful approach is a technically superior solution. However, IBM, Microsoft, OASIS et al. have done such a good job touting the power of standards in the WS-* world that most folks within large enterprises are sold on the WS-*-based architecture. Whether or not those standards actually help you is a topic for another discussion, but the point is that within most large enterprises you're going to have a much better chance of getting people to adopt your WS-* "standards-based" architecture than you will with a "maverick" REST-based architecture. Is this a problem? Maybe, but from what I've seen usually not. So what if you end up with a technically more complex solution? I can solve the technical problems that result from the added complexity of WS-*. Like I said at the beginning of this post, it's the people and political issues that are the biggest hurdles. From my experience, it's usually the people and politics that cause projects to fail or be canceled. If I can't get people to adopt my architecture because I'm going with a "non-standards-based RESTful architecture", I'm not even going to have a project to worry about it failing because WS-* is more complex, less interoperable, etc.

As an architect, you're not implementing, but you need to get everybody to agree to what you've defined so that they will implement it. If this means making some compromises that perhaps result in a less technically superior solution, but will allow you to achieve consensus then go ahead and do it. As I've painfully realized in my transition from developer to architect over the past few years, things are not so black and white with architecture, i.e. you can't always just go with the solution that makes the most technical sense. If you fail to see this or cannot adapt to this, then you will not be a successful architect.