Trusty Plan Not So Trustworthy

One reader sees fatal flaws in the logic presented in June's Guest Opinion, and fears less discerning readers will run out and start implementing SOA using the untrustworthy plan.

• By Readers of Visual Studio Magazine
• 09/01/2004

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Trusty Plan Not So Trustworthy
During the first couple paragraphs of A. Nicklas Malik's Guest Opinion, "Teach Your Apps to Trust" [June 2004], I was laughing out loud thinking it was a satire. Then I was confused when I got down to the part about IAP, and by the end I was just irritated.

The funny part: "... a key feature of paper-based office processes: trust." (I'm still laughing.)

I dare you to poll the readers of this magazine and find out how many believe that the HR/insurance departments in their respective companies are "... independently scalable, completely reliable, and proven over time." No offense to HR. If you ask HR departments the same question about IT, I'm sure the results will be about the same (although HR comments will be more politically correct).

The confusing part: Paper-based systems are notoriously inefficient and error-prone, so why would you try to replicate them? In reality, I want to know if there is a holdup in processing my insurance forms. "No one calls her back if the filing cabinet in the HR department is locked, or if someone has taken a vacation" is too much detail; however, knowing that the changes to my insurance were completed/not completed is important.

A more likely scenario is as follows: I give an insurance change form to my secretary, she sends it via interoffice mail, it is delivered to someone who is on vacation, and it sits on that person's desk providing no meaningful feedback. I go merrily on my way, "trusting" the system, and a couple days later break my arm while patting myself on the back. Six hours later in the emergency room, I find out that the update didn't happen and I'll need to charge $5,000 to my credit card.

Basically, the rule should be, "If you have a vested interest in the outcome, validate and verify!" I'll bet one large pepperoni pizza that most people follow this rule whether they know it or not (including Mr. Malik). Don't believe me? I'll provide examples:

• Your child's report card shows up in the mailbox. He has already told you his grades, so you don't even open the envelope?
• You delegate the creation of a critical business analysis and upon completion, you hand it directly to the CEO without even taking a peek?
• You just returned from a business trip and have more than 20 receipts. You fill out the paperwork and send the original receipts (as required) without keeping any copies for yourself?
• You never verify the amount of vacation time HR says you have remaining?
• You never verify that your bonus was calculated correctly?
• You propose to the CIO that the company can save piles of cash by eliminating QA and detailed specs and just trust the developer to do the right thing?
• Auditors, we don't need no stinkin' auditors! (Wasn't this Enron's mission statement?)
• You write an article for a magazine, send in the copy, approve the final draft, and never read the printed version?

I could go on, but you get the idea.

I can't figure out which is most irritating: Discerning readers will see the fatal flaws in this logic and think, "If this is SOA, I want no part of it!" or less discerning readers will read this and start implementing SOA using the trusting IAP plan.

Travis R. Rogers, Jackson, N.J.