Web Services Strategies

Beyond the technology, IT strategies for implementation of Web services by Doug Kaye.

Suddenly Seeking SLAs. Today we use software components. Tomorrow we'll use Web Services. Today we depend on warranties and support contracts. Tomorrow we're going to need service level agreements. If the SLAs for Web Services are anything like today's SLAs for connectivity and web hosting, we're in trouble. I see two problems. First, the typical SLA in entirely insufficient as an expression of an acceptable business relationship. It's a long story; buy my book and read Chapter 10. Second, as mentioned in the Icebergs Ahead! posting below, we're going to be receiving our services from vendors who have never done this before. I predict the emergence of a new business: third-party monitoring of Web Service service levels. Companies like Keynote could play this role, but I think it's more likely to come from new players. Posted Monday, March 04, 2002 7:27:52 PM

Icebergs Ahead! The biggest challenges of Web Services facing CIOs and CTOs won't be the technology; it's fairly simple. But the migration from software components to Web Services brings with it some implications that few have yet considered. For example: today, your B2C e-commerce application computes sales taxes using code/data modules licensed from a third party. Your tax calculation process is relatively stable. Once it's working, it tends not to break. The worst thing that happens is that updates don't get to you on time or they contain errors, but these are relatively simple to fix and the system doesn't tent to work/fail/work on a minute-to-minute basis. In the Web Services world, however, you'll compute sales taxes by making real-time requests over the wire. Your sales tax vendor will then have a whole new set of challenges. Does the vendor (today a supplier of software and data) have the experience, staff and infrastructure necessary to keep a Web Service up and running 24x7? Most software companies don't know how to do this; they only know how to write, deliver and maintain code. Suddenly, a feature that broke only occasionally is likely to fail more frequently even if for shorter periods of time. In Web Services, the MTTR increases, but the MTBF drops dramatically. Furthermore, if your e-commerce application requires multiple Web Services to complete the checkout process, your likelihood of failure increases for each service upon which you depend. To mitigate these increased failure rates, you'll need to plan to utilize multiple tax calculation Web Services, in turn supported by your own failover logic. Hmmm...this is starting to sound a lot harder than the way it works today! You're going to be planning for Web Service single points of failure just as you do today for hardware. And this is just the tip of the iceberg. If you intend to be a Web Service Provider yourself, are you up to that task? Are you prepared to deliver your service to meet high-availability requirements? Do you have a track record of doing so? Posted Monday, March 04, 2002 6:20:24 PM

March 2002
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31
Feb   Apr