When pontificating on subjects like SOA, one has usually has to decide which side of the fence to stand on:
- Unqualified, wild-eyed, bandwagon-riding enthusiasm. This usually involves pronouncements that the new paradigm will make computing infinitely easier and more fun, that it should universally and immediately be adopted for all new development and most if not all legacy systems should immediately be re-written because the new paradigm renders them hopelessly obsolete. In addition any developer who cares about his career had better start learning and using the new paradigm, and any tools that do not facilitate the new paradigm should immediately be discarded, while any tools that do support it are worth it, no matter how much they cost because of the ensuing productivity, efficiency, 'robustness“, flexibility, and general bliss.
- Cool sophisticated skepticism. I love David Ing's post on this: “Unlike the word 'Objects', which found it's mindshare reality place in language constructs and the long winding road of design concepts through modeling languages ... 'Services' is a bit of an unbounded chimera at the moment. I can't think of a single architectural concept that is left behind. Reuse, Integration, Business Process Management, Macro-componentisation, Distributed Systems, Asynchronous Messaging all join the clowns and elephants of the SOA Circus Parade as it rumbles into town. ...This is a fantastic industry to work in as we get to watch a lot of these parades; they come every couple of years. The downside is that we often end up with elephant sh** on the street that needs to be cleared up by someone (certainly never the clowns in the parade, they're long gone...). “ LOL.
The problem is the tendency for people to take a specific paradigm for solving a specific set of problems and to generalize and extrapolate it out to the full universe of computing problems. I try to take a different approach:
There is a time for every paradigm,
and a season for every trick under heaven:
a time to in-line and a time to abstract ,
a time to inherit and a time to aggregate,
a time to build and a time to buy,
a time to refactor and a time to patch,
a time to design and a time to ship,
a place for Remoting and a place for SOAP,
a time for indirection and a time to hard code,
a time to use a pattern and a time to refrain,
a time to accommodate feature requests and a time to push back,
a time to push hard to met a deadline and a time to give up,
a time to train and a time to fire,
a time to scale and a time to simplify,
a time to architect and a time to hack,
a time to document and a time to run to the next project.
(sung to the tune of Turn, Turn, Turn, by the Byrds).
To me, architecting a system is finding the right solution for the given set of constraints. Those constraints involve the technical and functional requirements of the system being built, but also include a whole host of other business and cultural realities of the organization for which the system is being designed. This is so obvious that I don't want to expound on it, but surprisingly I hear and read so much along the line of “best practices” that does not make this clear. For example, in a web app, should you use session variables or should you keep things completely “stateless“? It depends. Are you are building Amazon.com, or an intranet application? Will you ever scale beyond a single web server? How much simpler or faster will your app be if you use some session state? But I often hear people state categorically that they always make web apps completely stateless because “you never know when it might need to scale“. There is of course some truth to that, but sometimes you do know it will never need to scale.
While a big proponent of SOA (I actually invented SOA, but that is for a future post ;-) ), I recently architected and built a large system that used .NET Remoting extensively - very little XML and not a web service in sight at a time when the conventional wisdom is “don't use Remoting, its not the future of the platform“. Why? Because while it was an extremely large and complex system, there were no requirements to integrate with other platforms, and the performance and simplicity of .NET Remoting outweighed any advantage of being ready for interoperability in case the need arises in the future. Shortsighted? Maybe, but in my opinion the right choice given the requirements, time line, budget, team expertise, etc. Besides, SOA is Just a Facade (another post to come soon), so we can always create an SOA interface to this system when needed.
On another project, the salesman at my previous consulting company had sold a project as using BizTalk Server 2004, a technology we were very eager to use. However, after some initial proof of concept work in BizTalk, I was asking some questions about the development staff at the client company. It turned out they had mostly SQL Server experience, which a couple of developers who had dabbled in VB6. No .NET experience. No XML experience. No BizTalk experience. What the heck were they going to do with the system after we left? It turned out the need was easily handled by some slightly complex DTS packages. Not quite as “elegant” as using BizTalk, but a much better fit for the situation.
It's tougher to take this approach to architecture and design because you have to be more aware of the various ways of solving a given problem, and the strengths and weaknesses of each solution. You have to really dig into all the requirements, including business and cultural, and you have to make value judgments. You can't just repeat the current industry mantra. You have to be willing to prescribe what fits the situation, not just what is cool and exciting for you as a technologist. It's more work, but its what we owe to those we serve. I don't want a mechanic who always changes the break pads at a certain mileage whether they need it or not. I don't want an architect who has designed skyscrapers to blindly use the same techniques on the new addition to my house.
Hopefully I don't sound like I am on the skeptical side of the fence when it comes to SOA. My job is to manage and grow a consulting practice around Enterprise Integration. I see SOA as an important paradigm with very real benefits that should be embraced, and I think it is actually underutilized in the industry. I just think we have to be careful not to oversell it because then we lose credibility.