You know what SOA is (an assumption I'm making, given the website you're currently visiting) but what's ABOS? Simply put, ABOS is A Bunch Of Services – overlapping and inconsistent services that have been implemented willy-nilly without foresight or any broader thought than immediately meeting the needs of a specific project. In other words, ABOS results when you apply Web services technology into siloed projects.
So what turns an SOA into ABOS? Here are five SOA anti-practices (or ABOS "worst practices" if you will) to keep in mind as you work on undermining your organization's SOA initiative:
1. Don't think about anyone but yourself: One of the best ways to produce an ABOS service is to put your blinders on and just start coding. Don't worry about other projects and the reality that they could possibly use your service if you spent a bit more time supporting one more parameter or one more operation. After all, you have a deadline to meet and if you stop and help someone else that means more work for you. And those architects who are always nagging you about business architecture and alignment? Well, they will go away if you ignore them long enough.
2. Just "Git r done!" (apologies to The Cable Guy): What's all this noise about design reviews, code reviews, test plan reviews, blah-blah-blah. And everyone knows that a WSDL is fully self-documenting and no one reads any of that sissy documentation, so you certainly don't want to bother with writing any of it – what a waste of time.
3. Backwards compatibility is for wimps: If someone else wants to use your Web service, it's at their own risk. Not your problem if you change an operation when you redeploy, after all you didn't ask those other guys to use your service in the first place. If you need to change it, that's your business (refer to worst practice number 1).
4. Don't tell anyone about your service, they might actually try to use it: This worst practice is a corollary to worst practice 3 – if you keep your service to yourself, you will prevent a lot of future headaches. This business about sharing services and "deploy once, call from anywhere" well… those guys never had to worry about keeping your boss happy – it's all about making your project look good. And if other projects look a bit worse because they had to write something themselves, which could have been avoided had they known about your service, that's all good too – we move up a notch or two on the pecking order!
5. Last but not least, use and forget: If by some strange chance of fate another project does manage to find, understand and/or use one of your services (fighting their way through worst practices 4, 2, and 1 respectively), of course we wouldn't want to track that fact, would we? After all, they'll find out soon enough when your new code drop gets deployed (see worst practice 3 again). It's great to get that adrenaline rush at 2am Sunday morning when the pager goes off because a bunch of apps stopped running. You now have one more war story to expound upon at the water cooler next week (but given the way your organization runs, there'll be plenty of competition).
On a more serious note, hopefully you've understand my meager attempts at humor (Steve Martin doesn't have to worry about competition from me, that's for sure!). Organizations that are serious about SOA should be thinking about and planning for architectural guidance and governance, cross-version compatibility of services and dissemination/traceability of services through a design-time repository/registry. Just getting the technology stack right won't cut it – the bigger (and in many ways harder) issues in delivering an enterprise-class SOA revolve around structuring the organization to enable cross-project alignment within IT and business/IT alignment between those that pay for IT and those that make it work.
About the author
Brent Carlson is the vice president of technology and co-founder, LogicLibrary Inc. A 17-year veteran of IBM, Carlson is well known for leading several key IBM initiatives. Most recently, he was the lead architect for the WebSphere Business Components project, providing the overall technical direction for the EJB-based component development product.
