Replies

I have heard of ZERO count 'em ZERO successes in offshoring, with the sole exception of banks

And even then would you know if there was a failure? My interaction with WaMu is to make sure that my direct deposit payroll check goes in and that's about it, which isn't too hard to maintain. Granted they manage to have their website fail about 4 times a year and were hit by the SQL Slammer worm hard, which makes me wonder about their internal security.

I believe the banks have had success in offshoring as banks are all about process. Money goes in, money goes out, and you better account for it every step along the way. They know exactly what they're doing and they know how to measure sucess.

Juxtapose that with a firm that never really knew what they were doing in that industry anyway and didn't know how they were failing. For example, SprintPCS my cell phone provider. I see they're going through Yet Another Outsourcing of their billing department. Those clowns can never send me a correct bill, nor can they keep a website up. Will that change by turning it over to another company? Why would a bad car run better if you give it to a race car driver?

As for XML / SOAP I'm really intrigued about it -- saw a demo of Sun's RAVE IDE (I think its now called Sun One Something) where you made a GUI that checked everyone's schedule by doing SOAP queries to different database. All drag and drop.

So now you're freed from writting thousands of lines of code and can concentrate on delivering apps to further the business along. Ithink that's the only way to combat offshoring of IT jobs -- make it so that there's no reason to export a $100/hr programmer as he gets 10x more stuff done in an hour that anyone else could home to do.

[As for XML / SOAP I'm really intrigued about it -- saw a demo of Sun's RAVE IDE (I think its now called Sun One Something) where you made a GUI that checked everyone's schedule by doing SOAP queries to different database. All drag and drop.]

XML and SOAP are two different things. XML stands for eXtensivable Markup Language, or something like that. What it really is, is an agreed upon means of exchanging data in a vendor neutral manner (text). SOAP means simple object access protocol, or something like that. SOAP used XML as a means to send messages to a server somewhere on the network. the SOAP servlet or service can read the message, process the request and maybe send a response if need be. Pretty cool, but all that has been done countless times before. RPC, smtp, COM, DCOM, http. etc. etc,. etc. Also some programmer has to build the SOAP service before anyone can use it. Where SOAP and XML shine is that everyone is willing to support it, and SOAP services can run on port 80 which most sys admin types will keep open since http run on port 80. So yea, it's good stuff, but what makes it good stuff is that it has become an accepted standard, not the underlying technology. Cure all? No, standard upon which to build web application? yea, for the moment. until the next new standard arrives.

If you want to play with SOAP let me know, my Web server is also a SOAP service.