I hoped and prayed SOA would fade into that dark place where all overused three-letter acronyms go for rehabilitation. Unfortunately, the popular computer press and the geek intelligentsia won't let it go away. Why is that? When service-oriented architecture first reared its ugly head, I figured it was just another name for something programmers and developers had been doing for years–as in reusable code, as in not having to reinvent the wheel every six months. Let's face it, a lot of code a developer writes today would be very difficult to write from scratch. In the golden days of coding (that is, pre-Windows, pre-semi-documented APIs), coding was fun and easy. Writing a C routine to search and index an extremely large list was fun and logical–as in Boolean logic extended out to its extreme limits. Coding to an object model that was created by a large team of developers whose goal was to make the API usable for internal consumption is not always logical. Even the best and most intuitive developers literally can spend hours trying to determine the exact code needed to access and use an object model.

I find it ironic that logic is not necessarily the most important thing on a developer's mind barely a half century into the age of computing. And that is why reusable code is so essential. Once I finally have figured out the best way to call NastyWidget.getdata_structure and do something useful with it, I most certainly am going to save that little (or maybe not so little) bit of code and share it around my shop. In fact, I may even wrap it up in a utility Dynamic Link Library (DLL) along with all the other utility code for the project.

That is what I thought SOA was going to be all about: taking a computational resource and promoting its reuse. In that respect SOA seemed old hat. So what if we now were going to expose code as a Web service? What if we were going to use industry standards to publish that code? It still was about code reuse. SOA also involved a concurrent movement to wrap up code in bigger chunks. If you had to write a routine to pull customer information from your CRM system, it made sense to create a unique, stand-alone object that wrapped up all the possibilities "pulling customer information from your CRM" could encompass. That object or DLL or Web service or whatever then would be shared throughout your enterprise for a multitude of applications. At least that is what I interpreted the SOA vision to be.