All Posts in Technology

|In: Industry Commentary|Last Updated:

Alfred Hitchcock promoted one of his movies with the slogan, “The Birds is coming.” He got tremendous free publicity through debates about his grammar. Pedestrian grammarians complained about the lack of agreement between subject (birds) and verb (is). The more insightful recognized that The Birds was a movie title, and therefore singular.

So what should we make of “web services.” Is it singular — the name of an architecture — or plural? Let’s use the phrase in some sentences and see how it comes out. So …

What is “web services”? The core concept is that you’ll build applications out of pre-built components scattered about the web using standard protocols that enable runtime binding. According to its advocates, the result(s) will be dramatic reductions in development time and orders-of-magnitude improvements in quality.

Unfortunately, web services contains huge, fundamental flaws. While not insurmountable, they’re not easily solved. Neal Goldman of the Yankee Group brought one to my attention: Version control.

Imagine your company uses a web-services application, and the provider of a key component changes its behavior. The new component runs fine, of course — that’s built into the protocols — but sadly, it no longer does what you expect it to do. So surprise! Payroll tax withholding suddenly changes, and there’s nothing you can do about it — you don’t control the code and you don’t control the versioning, either. It’s like DLL hell, only the application doesn’t crash. You just wish it had, instead of creating business chaos by doing the wrong thing.

A second big problem is latency. When you run an application on your own computers, components communicate with latencies measured in microseconds. With web services they communicate across the Internet, which means latencies measured in tens, hundreds, or even thousands of milliseconds. Do you seriously think you can solve this with service level agreements? Me neither. Imagine a component that computes daily interest for a million customers. Even an excellent service level — 10 msec — adds nearly 3 hours just from Internet latency. That’s a lot of run time to add for just one component … and your entire application is built out of components like this. Web services could easily change overnight batch to over-year batch.

You might think you can solve this through the miracle of caching. Maybe you can … but next week we’ll see how a third major, entirely non-technical issue with web services could eliminate caching as an option.

Comments

|In: Organizational Effectiveness|Last Updated:

To get my PDA working properly I had to change my e-mail address. It’s an irritating story.

I’ve been using CompuServe 2000, an IMAP e-mail platform, with Outlook as my e-mail client. Everything worked fine … most of the time, anyway … until my recent change in employment, which moved my calendar from my office copy of Outlook, which was attached to Microsoft Exchange. My PDA (a Palm device) synced just fine to that, but not to my home copy of Outlook. The problem: I’d installed Outlook using the “Internet only” installation option, but synchronization requires “Corporate/Workgroup” installation instead.

So I switched over to Corporate/Workgroup and voilà! … CompuServe 2000 stopped working. Some genius at Microsoft decided IMAP e-mail should only work in Internet only mode. Which means CompuServe 2000 (along with all other IMAP e-mail services) and PDA synchronization are incompatible.

Please note my new e-mail address.

While annoying, the experience was also timely, because I was in the throes of helping a client select an e-commerce vendor. As with most vendor evaluations, we asked questions, made note of the answer, and compared the vendors on the basis of their responses.

Were I to evaluate PDAs and e-mail systems this way, I’d have easily reached the conclusion that my PDA, e-mail provider and e-mail client would work together in perfect harmony. The incompatibilities were, after all, buried pretty deep.

Which leads to a suggestion: Follow all vendor selections with a pilot implementation. The ideal pilot is simultaneously technically challenging, small in scale, and politically simple. You’re looking for a relatively small group that’s enthusiastic about the new technology — you’ll have plenty to worry about without dealing with resistance to change –that will exercise it hard to test as many complexities as possible.

This should be obvious, but for one reason or another … go-for-broke schedules are a common culprit … companies often skip the pilot. They invariably lose more time than they ever hoped to gain, because problems are easier to fix under controlled circumstances.

That’s one tip. Want a few more?

Tip #2: Be balanced. I divide evaluation criteria into four categories: Technology, Services, Business/Marketplace, and Pricing. With technology, don’t try to design the vendor’s product. You’re watching out for bad architecture, reliance on immature or fringe platforms, and obsolescence, and checking whether the vendor will commit to service levels. To define the others: Services covers features and functionality; Business/Marketplace helps you predict whether your vendor will in business next year; and Pricing covers not just the price itself but the pricing structure.

Tip #3: If you can make your decision from the numbers, somebody rigged the evaluation. Use a three-point weighting factor for the evaluation criteria, where 1=Useful, 2=Important, and 3=Crucial. Score responses on a five point scale (with no fractions!). When you tote everything up, scores within 5 percent are a tie. If one vendor is the clear winner, you either compared the preferred vendor to only its weakest competitors, the preferred vendor provided the evaluation criteria, or both. The numbers screen out clearly inferior choices. Use the details of a vendor’s responses, and the tone of each conversation (I prefer interviews to written responses) to differentiate among the remainder.

Tip #4: Watch out for second-stage selling. Every losing vendor will ask you where they came up short. If you answer the question you’re in for an argument. Your correct response is something like this: “You didn’t lose on any single question. We were confident your solution would have worked, but in balance it wasn’t as good a fit for our needs as our first choice. To give you any more detail I’d have to violate the confidentiality of the other vendors we talked to, so I’m afraid that’s a much information as I can provide.”

Tip #5: Don’t worry. Be happy. You’ll never know if you picked the best solution, even after you’re operational. No matter how good an evaluation you performed, you’ll run into gotchas during the pilot, and more during the full roll-out. If they aren’t insurmountable you made a good choice, so don’t fall into the grass-is-greener mentality.

Remember token ring vs Ethernet? Both led to headaches during implementation, but in the end, either net worked. That may be a wisecrack, but I doubt it.

Comments