“SOA is not something you buy. SOA is an architectural approach, not a product. Anyone saying anything differently either hasn’t thought the whole thing through or has something to sell you.”
If you have heard my talks on SOA before, you have heard that line. Yes, I admit, I reuse lines occasionally during my talks. I occasionally do prepare, it’s not all off-the-cuff improv. I say that line nearly every time I talk about services, which is a LOT. I talk to people who don’t know much about the Microsoft platform, architects with little exposure to Microsoft technologies. I get it… they are bombarded regularly from other vendors claiming to be able to sell them “SOA”.
That’s why it is such a breath of fresh air to find articles like the ones that were posted recently at Redmondmag.com. The first article that you should absolutely go read is an interview with Steven Martin, Director of Product Management for Microsoft’s Connected Services Division. My favorite quote in there:
What makes Microsoft’s service-oriented strategy different from your major competitors, such as IBM Corp. and Oracle Corp.?
A couple of things. As I said, we’ve always talked about SOA as a how, not a what. So the first guidance we give users is that SOA for SOA’s sake is probably doomed. You need to be able to articulate in 30 seconds the business problem you’re trying to solve. If you can’t do that, then you’re already in a hole. You must be very pragmatic about what you’re going to do and how you’re going to use SOA to solve a particular problem. Within that pragmatism we coach people to take a “middle-out approach.” Don’t assume everything that goes into your organization must be services-oriented. Make good use of service orientation where it makes sense for either cost savings through reuse or in places where you’re truly going to differentiate the business.
To understand the concept of “middle-out”, you should read Nick Malik’s post on “What You Need to Make Middle Out SOA Architecture Work.” In that post, Nick proposes that a central group is responsible for identifying services to be created, determining the set of standards for naming and message exchange protocols, and then getting the enterprise to buy into it. The key is that the central group writes no code. That’s right: the central group is a political entity that sets the agenda for an organization and convinces others to join in the good fight. Identify the things that need to be services, set up the standards for getting services to easily share data, and build pragmatically.
In other words, if you hear someone in your organization saying, “We need to implement a SOA”, then that either means:
- They were reading industry trade mags on a recent airplane flight, or
- They just got out of a meeting with a vendor trying to sell them “SOA”.
This may seem like common sense, but I hear fairly often how companies are evaluating or building a services repository despite having to readily-identifiable services. I see enterprise companies that are proliferating XML web services around the enterprise without any view of managing or integrating these services later. One group decides to use “CustomerID”, another one “FID”, another one “Ani”, another “TN”, and they all end up meaning the same thing… within a single company. Proliferation of services will lead to complexity in mapping and translation, which will become a nightmare when considering versioning. Governance. It really is about governance.
Of course, there are those who still don’t get it.
Gardner and other industry observers charge that Microsoft’s business model too strictly requires users to buy into its bread-and-butter operating systems, applications, run-time environment and tools before they can start piecing together a customized SOA that best serves their needs.
How are you reading this post? Are you reading through IE on Windows, Firefox on Linux, are you on a Mac or a mobile device? Are you using a desktop aggregator written with Windows Forms or Java applets? Who cares! It doesn’t matter if I store the data in SQL Server and process requests using IIS7 and ASP.NET or if I chose to implement the back end using EJBs and JSPs with DB2 for storage. It doesn’t matter if I wrote my entire blog engine using C#, Java, or PHP. What matters to you, dear reader, is that you can issue an HTTP GET that returns back XML in the form of Atom or RSS. You don’t care what’s behind the server, you just care that you are able to get the data that you requested. Just as you don’t care how I store data and process your request for data, I don’t care how you present that data. Standards at the edge! There’s nothing there that required Microsoft technologies, nothing that requires anything of Microsoft technologies.
That’s the beauty of focusing on standards at the edge, and that’s a huge benefit behind standardizing on protocols such as WS-* within the enterprise. By leveraging standardized protocols over ubiquitous transports, you truly can begin to enable a plug-and-play architecture. If you are focused on standards at the edge, then you avoid single-vendor lock-in. If I have a set of services exposed and you are able to consume them, then we have a contract. If someone else abides by that contract, then it really is as simple as switching out what’s behind the service contract with another implementation.
Take, for instance, the StockTrader case study. Sure, it’s a benchmark where Microsoft beat WebSphere (yet again), but the really interesting part is that the StockTrader case study completely validates the notion of a plug and play architecture based on services at the edge. This case study shows how you truly can replace IBM’s front end with Microsofts, having a Microsoft UI call a WebSphere back end. Then change the configuration, and you can have an IBM-based front end talking with a Microsoft back-end. Just as easy as it is to switch out web page UIs, you can use a smart-client application that talks to services at the back end. Fire up Excel to talk to the back end services, be they Microsoft-based or IBM-based. It doesn’t matter, the UI can talk to either through a common contract. That’s because of standards at the edge.
Microsoft focused very hard on making SOA real and not just a shiny marketing term used to sell more servers. From XML to SOAP to WS-* to REST, Microsoft has been a vocal advocate and a driving force behind making interoperable services real.
It’s refreshing to see that the message is being heard, but more importantly, understood. At least, it’s being understood by those who have thought it through or don’t have an alternate agenda.