The fact is, the Total Gym isn't going to do much for me, in and of itself. For the equipment to be effective, I need to learn proper technique for each exercise. I need to create an effective workout plan. I need to execute the workout plan. I need to rest and to allow my body to rebuild muscle tissue. Oh, and I need to stop eating entire bags of M&Ms while I code and learn to gulp down a green leafy vegetable or two. A little more sleep wouldn't hurt, either.

To get to my point...I have to change my lifestyle if I want to lose those extra pounds.

Adopting SOA Isn't Enough

Service-oriented architecture is among the latest "Total Gyms" trumpeted in software development circles. SOA promises tons of benefits and is certain to provide positive results for your IT organization.

But the purchase of a Total Gym will not make you as tough as Chuck Norris or as nice-looking as Christie Brinkley. And simply adopting SOA will not trim the fat from your architecture designs; nor will it instantly improve the way you develop and deliver software. Far from it, in fact.

Adopting SOA is lifestyle change that has to become integrated into all aspects of your culture, including business processes, software requirements development, software architecture, software development lifecycle, project management, and hardware and software purchases.

Total SOA Gym: Strategies for SOA Success

SOA is a great strategy but you have to exercise discipline and patience to experience its benefits. The following is my "Total SOA Gym." If you follow these strategies, you are guaranteed a higher SOA adoption level than someone who didn't read this article. This is a money-back guarantee...You can't lose!

1. Stop thinking in terms of applications (and Assess Your Current Health): In SOA, the S stands for service. Services typically represent steps in your existing business processes. Traditional development practices have sought to automate processes into a single application boundary exemplified by accounting, CRM and ERP applications. In each of these, processes overlap—causing unnecessary duplication of logic and data.

When you start with SOA, a good method for mapping your strategy is to audit your existing applications. Map the features in the software with your business processes. Once done, you will have a good idea of what you have and where you can start building services that are boundary free.

2. Make it simple "enough"— and not one bit simpler (Create A Workout Plan): There is an art to deciding how much of a feature's logic should be available to other services and how much should be stuffed in a black box, obfuscated for simplicity. I would err on the side of obfuscation and try to make a service as simple as possible. Don't fret too much over whether a certain method should be exposed. In general, if I can find a way to obfuscate it, I will. If I determine later that a benefit exists in exposing a method, I can always refactor.