Bear with me a moment as I introduce this topic by QQing about things like QQ. First, let me define my terms. QQ, for the uninitiated, is a pejorative term meaning to complain or cry about something, ostensibly because (given the right font) the two letters look like eyes with tears. The expression "pew pew" is derived from the sound of a laser, and means to take aggressive action. Those familiar with forum-speak and adolescent texting should be familiar with these and other terms, most of which rank high on my list of pet peeves.

While I'm on the subject, it ranks even higher on my list if u type like a tard coz ur lazy. L2type complete words, kthxbai. Ah, but at the top of my list, I favor the death penalty for pEoPLe wHo tYpE liEk tHis. And there must be a punishment worse than death for the rampant rudeness, ignorance, and abuse of Internet memes that pervades Internet commenting. There must be.

Anyway, in short, "Less QQ, More Pew Pew" roughly translates to, "Stop whining and bitching and get off your keister and do something." As much as the expression irks me, QQ is an appropriate description of what many people seem to be doing about service-oriented architecture (SOA). "It's too expensive. There's too much of a learning curve. It's too much of a culture shock. We have to retrain our developers. We have to hire a squad of mercenary consultants. Studies have shown that SOA causes dreaded combination skin."

Grow a pair, people. There's money to be made with SOA. More important, you can save 50-gallon drums of money with SOA. But you can't realize those savings by QQing. You have to take the first step and start implementing SOA.

Granted, the QQs listed above and more may be realistic complaints if your goal is to rewire your entire IT infrastructure for SOA. But while that may be necessary in some cases, it isn't always. Test the water with SOA. It isn't nearly as hard as many people presume. The path has been cleared by a decade of work in object-oriented development and networked services. In truth, the foundation for SOA was laid long before that, but the most significant progress began at the dawn of the Internet age.

Take Java, for example. Knowingly or not, Java was designed to be SOA-friendly. Many of you probably already have some business processes coded in Java. Did you know that you don't have to rewrite these programs from the ground up to SOA-ize them? You don't even have to rewrite or encapsulate your Plan Old Java Objects (POJO) of business logic within enterprise Java beans (EJBs). You can use an open-source framework called Spring to wrap some XML around existing Java code and turn that code into the embryo of an SOA service.

Spring is free and open source, which makes it an ideal gateway into SOA. Just as some of your developers snuck Linux into your company on the sly, your developers can use Spring to sneak a few of your Java-based business processes and data access code into services. Spring is designed to be inobtrusive, so they may not even have to change a single line of Java code. With very little effort and training, you can use an experiment like this to get a real-world idea of the benefits of reusability, and what it might be like to graduate these services into full-fledged SOA. There's nothing like a little success to take the fear out of change.

Spring isn't the only useful tool to help you migrate existing code to a more service-oriented environment. Keep your eyes on our SOA drilldown. We'll introduce you to as many ways as possible to ease into an SOA transition.

The bottom line is that you can't discover the benefits of SOA by QQing about how difficult it may be. A lot less QQ and a little more Pew Pew may be all it takes to get your company on the road to realizing the benefits of SOA.