Fog Creek Software
Discussion Board

Doubts on Web Services

I read the current Robert X. Cringely essay and thought about this comment he wrote --

"In this retail context, XML replaces an earlier standard called Electronic Data Interchange (EDI). EDI failed because it was too big and slow, requiring too much bandwidth. XML requires four times the bandwidth of EDI. What do you think is going to happen?"

Now you can say that there is currenly more bandwidth but we all know the law of computing -- Given more resources developers will use it all up.  What do people think about the idea of web services as a whole failing?  Will people use it if it becomes slow?

Chris Woodruff
Sunday, August 25, 2002

Thanks for the link Chris... I have never heard of this guy before... but I liked the reading.  In particular, I liked this:

"Giving up control to a trusted business partner makes a lot more sense than turning your business over to a staff of employees who may not have your best interest at heart. When you consider that the greatest security issue is 'sabotage by employees', why not eliminate it entirely by eliminating employees?"

All those that need their own private office to (ahem) "be productive"... please stand up and be counted... for the employment line.

Sorry for the tangent.

First of all, I think I would disagree that "EDI has failed".  My current project involves transmitting data in an ANSI/EDI 835 format.  No, it doesn't involve a "VAN"... which I think is a good thing.  Standard formats for data exchange are a good thing in themselves... and they don't need all of the extra cost overhead to succeed.  Personally, I think (e.g. VANS, etc) is just other "added cost" (notice I didn't say value) middlemen trying to get a cut for themselves.

Personally, I like XML.  If that was as far as it went, I think things would be good.  But all of the other things... like XSLT and all of the other third party "stuffies" packed on top of it... well, I think it will die of the weight.  Having to have so many extra "specialists" involved for a simple concept of self-defining data... well, that's kind of like an oxymoron... but the reality is additional costs, and costs do drive the adoption of technology.

I'm not sure that I agree that XML will slow the world down.  Will people use things if it is too slow?  Well, you would have to define "too slow"... as in comparison to what. 

I don't believe people use something... e.g a software application, because of the super fast response time... I believe they use it because of the time it saves them.

So... if it takes me an hour to do something now, but though some magic it only takes me a half hour but seems slow on response time... would I use it? 


But if doing that same hour thingie takes an hour and a half online would I use it?

Probably not.

Joe AA
Sunday, August 25, 2002

Depends on many factors, including price and marketing.  I use webmail for instance, which is the slowest possible method without getting silly.  Response times are terrible, but it has so few dependencies.

Aren't things compressed when they're transmitted around?  I compress my xml if I'm sending it between apps.  There's a lot of juicy entropy in there to squish.  Would xml then require 4X the bandwidth of EDS?

BTW, did anyone look at the website Bob talked about?  The site sets off my scam-radar, though I'm disturbed that it probably seems more trustworthy to most users than slick websites.

Greg Neumann
Sunday, August 25, 2002

I liked this quote, "the good shopkeeper who always kept his inventory pretty much in his head does have a choice. And more often than not he'd be wiser to stick with his head and forget the computer. " 

A sane view of technology.  Sometimes tech takes away information from the user, especially when it's not usable.

I just read a Symbolics post-mortem (entertaining despite its long-winded title).  It's pretty much about about what happens when technology is raised higher than everything else.

Sunday, August 25, 2002

First, I think the focus on XML is a mistake. It is simply a data exchange standard. XML will become more popular since the setup of connections is much easier than is EDI. It was not common to see a company use EDI to pump data from a mainframe computer to a Excel spread sheet. With XML you can do this. Hence, while both EDI and XML is a means to exchange data, the XML standard is, and will be used for a much larger variety of tasks.

Remember, that most of the technology that runs the internet today existed 10 years ago. The only thing new about XML today is that it is more of a standard, and more connections between computers are adopting it then are EDI. We should not get any more excited about XML then http. However, they both enable a lot of things to happen. http is valuable today since so many computers use it. The same will be true of XML.

EDI was too proprietary, and a effort was not made to use EDI for general data exchange (boy...did those folks screw this one up...what a lost opportunity!).

EDI is primarily used to invoice/PO/funds stuff. XML can be used for this, and also a lot more. Regardless, don’t get caught up in the technology, as it is not important.

When you got a sec, all can read Joel’s article about getting caught up in the technology, and forgetting about solving a problem.

Now, as for that issue between a Web based service, or a non based web services....what will happen?

Lets take payroll. As a “farm out” service, payroll in the late 70’s and even the 80’s was OFTEN contract out of a company. In the 90’s and beyond we still find a LOT of companies actually farm out their payroll. This was due to the fact that it is a pain to try and run payroll software. In addition, the cost of updating and maintaining payroll systems was a lot of money for a small company. A good computer to run payroll in 1970’s could $30,000-200,000 grand easy...and that does not include the high yearly maintenance cost. Those high maintenance costs were actually higher then perhaps they should have been. This “higher” cost can occur since it was difficult to break into the into the payroll processing business (computing was not a dirt cheap commodity like it is today). Payroll certainly does sound like a perfect business for a ASP provider does it not?

Why then is the ASP business for payroll not booming right now?

The biggest problem or “fallacy” of a ASP is based on the fact that a small business can not, or should not maintain that “expense” of a huge computer system such as payroll.

The problem here is that cheap computers came along, and they are easy to use (I don’t need a raised floor with 2 people in white lab coats to run the payroll system). In addition, updating of software has even become easier. Hence, there are some very small business today that run a accounting package and use that package for payroll. The payroll service industry as result lost out big time here. More companies do their payroll in-house. This is despite the internet, and the INCREADED EASE at which payroll services can be delivered over the net.

A lot of restaurants I eat at (and it is lot!) are independently owned. I make it habit to get to know the owners. Most of these small mom and pop operations still farm out their payroll to one of the large payroll providers. Why do they do this? Because they don’t have a computer, or a person in the office that can use one (and also, those payroll providers are VERY cheap today...usually about $1 per employee per pay period now). Or in fact, the restaurant don’t have a small computer in the back office setup to run a payroll system. Sometimes they might have a computer, but no one does payroll on it. In fact, in general no one does much on that forgotten computer.

What happens when a ASP provider comes along, and says...why don’t you install a computer system and connect to my payroll service?

What happens is now is that a person from the restaurant has to be trained to use the computer, and they now must have and maintain a PC. They are now required to “train” some staff member to enter the timesheets. They now must have someone with computer skills. Hence, they now stop Faxing a old hand scribbled timesheet to the old payroll provider. Golly jeepers, once they get the hang of running a computer, it is a trivial step to purchase some payroll software and dump the ASP. Hence, to *USE* a ASP, you still have to buy into using some hardware system. Once the company buys into using hardware and some software, then the need to use the ASP diminishes rapidly.

Thus, for much of the market that ASP providers are chasing, most of it can be done cheaper in house. The fact that the software is on your pc, or on a ASP’s pc is moot. It is not important! What is important here is that the company is GOING to USE SOFTWARE. Are you going to use software or not? If you use a ASP, then you are using software! That is the question here!

The problem with much of the ASP concept is that is goes back to the old time share mainframe idea of 25 years ago. The problem here is that computers and software is now cheap. Back then, it was expensive.

We had computers 30 years ago. The problem back then was they were not easy, cheap and reliable. Today computers are easy, cheap, and reliable.

Albert’s ASP law:
“when it becomes cheap...companies will do it in house.”

9 out of 10 times the business will choose independence from a another company, EVEN if it requires more trust in a employee. This is because most companies want to control aspects of their business if it is worth the cost of doing so. It is all about control.

Ask a company today if they could dump the power company, and purchase a small generator for electricity for the SAME COST. 9 out 10 business will purchase the small generator *if* it is reliable and trouble free. When photo copiers came out, business used a copy service (those photo copiers were huge, and very expensive, and where NOT trouble free!). Today, most business have their own photo copier. However, they still use some copy centers for color copying, and use of neat binding equipment. Even now, that binding equipment, and color printing is moving to in-house, and thus not to a service provider. This is because the cost of color printing is dropping.

The moral of the story here is that technology makes these services cheaper, and allows a business to do them in-house. Given this...the future for ASP is over hyped.

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Sunday, August 25, 2002

Paul Graham has a great article in defence of ASPs at

Matthew Lock
Monday, August 26, 2002

Matthew, that is a superb link.

I think it is a must read to all developers.

Thank you very much!

I must say, that Paul’s article (in the above link) opened up a long list as to why ASP’s are attractive. The “just good enough” argument he has is very compelling.

It is late right now..but there are number of reasons why I think ASP's will not yet fly. I'll post my thoughts on this tomorrow.

Albert D. Kallal
Monday, August 26, 2002

Web services do not have to be sourced from an outside party. You could just as easily use them internally within your ogranization to centralize services. For instance, you could wrap one of your business rules, such as shipping, into a exposed web service then have all your internal applications consume that service. Since the standard is there you could consume it from a variety of platforms. This could be useful across large networks.

Ian Stallings
Monday, August 26, 2002

My $0.02.
The data does not live here will be a big hang up for almost every suit in the board room. They will say, "We own the data, it is an asset and assets do not live in someone else's building".
What happens when the ASP goes belly up? How do you get your records?
What about having the SEC or FBI looking at your records without your knowledge?
I can not see anything other than Mom and Pop businesses using an ASP. The services would work for a store front or EBay sort of thing, but not for accounting or payroll.

Doug Withau
Monday, August 26, 2002

Doug, I believe ASPs often sell the application at a higher price if customers want their own servers to carry the load.  At least that's how it works at my company.

Monday, August 26, 2002

Owning your servers is the solution.
Once the "customer" owns the servers the ASP model breaks. Many of the great advantages Paul boasted about are gone. Will your company allow the service proivder to update the system daily, track users, and keep the backup tapes?
If the customer is running the server, it is just shrink wrapped software, same as everybody. Maybe they pay for a subscription, not a one time charge and upgrade fees. You can call it an ASP, but the advantages are lost.

Doug Withau
Monday, August 26, 2002

I will only add, that this whole thing comes down to cost. If a ASP can deliver software with lower cost and hassles than what a company can run “in house”, then ASP's will win the day.

I am a huge fan of thin client, and have stated so many times here. The question still begs, should my software run on my company server, or at some ASP?

The idea of hosting your own web services (which most companies will have to do with .net) is course implied here. In other words, if I come up with a web based accounting package, there is no reason why I would not run it on my own server?

A good many people in this thread rightly just pointed this out, and I also agree.

Hosting your own web service again means the ASP is cut out.

The other thing here is not to confuse connectivity with a ASP. Should I purchase Quicken Accounting that runs on my company server, or a version from a far away ASP? Heck, there is no reason why my personal version of Quicken on my desktop should not allow me to create a store front and expose it to the web?

Again, the problem here is that more and more companies are going to run their own web server, not the other way around.

If I can install quicken, and have it create a store front for me with a few clicks...I will.

Millions of people were willing to share a folder from their computer and expose it to the web via Napster, or now Morphaus, WinMx or whatever the heck they use today. All I need is a connection to the web, and not necessary a ASP. Hence one must not confuse the issue of connectivity Vs a ASP.

The big bonus of running Quicken (that has a built in store front) on my desktop is now my store front is integrated into my accounting package. This is real hard to do with a ASP. Further, my accounting data is on my own pc. Even more important is that the client database is also on my pc, and other applications can use this data.

Web based email is great for email, but it does not integrate with other software packages. Word or excel does not integrate with web based email. Even a web based version of Excel would not work with a web based version of Email!

Running Quicken on my desktop with a “web store” module is again going to be cheaper then the web based solution. I only have to pay for my internet connection (and boy is that a commonidfy or what!)

Even more important is that I can integrate other custom applications into the accounting package. Integration will not work with a pure web based system right now (unless my SINGLE provider integrates everything for me, or all the providers allow applications to talk to each other...ya right.. fat chance!!).

Remote desktop support and software that updates itself means that the cost, and ease of running a desktop computer is still dropping. Just about all new software from Morphous to the new version of office XP has some auto update, and the end user does not have to worry about or even care updating software anymore. (we don’t update software every year, we update it as patches and fixes become available).

As mentioned, each company can still run their own web server for peanuts right now.

At the end of the day, a easy to use, and reliable system will win the day. If the desktop pc was not cheap, and as reliable as it is, then we would all still be using dumb green screen terminals.

The only reason why every windows desktop does not have web services built in is due to security concerns. Napster showed that people have little problem or concern of exposing part of their computer to the web.

Also, don’t get me wrong. I am a very big believer in thin client. I also do belive in a market for ASP’s, but lets just not over hype it. Also, if you *CAN* get all your clients to use a web based applction, and make them pay for it..then it is no doublt the way to go!!. The only trick here will be getting people to go down that route!

Perhaps the next version of City Desk will include a built-in web server? (Joel...are you reading this???)

Would hot mail be as popular as it is if you had to pay to use it?

Albert D. Kallal
Edmonton, Alberta Canada

Albert D. Kallal
Monday, August 26, 2002

>> (unless my SINGLE provider integrates everything for me, or all the providers allow applications to talk to each other...ya right.. fat chance!!).

Key point (among many great ones!). The whole soap idea is to make it easy for software services to talk to each other. But is the problem really technical? Is the word format too technical for people to understand, or is it proprietary for business reasons? What about AIM? Both of these are good for business, bad for customers. They are also at the top of their category.

The problem with web services is they have to interoperate to be sucessful, and they won't. You can be sure that once your data is in AOL or MS's hands, you are their life long hostage - look at the trouble you had switching from AOL (email, adresses, webaddress', freinds etc), or office. So now I'm going to put all my data in their hands? No chance.

I made a web service to obfuscate swf files a while back, just to try it out. The obfu code is protected on the server, its cross platform, and you can charge per use - which is all good. However everyone wants a desktop version. It also struck me, as I was adding features, if this was just a peice of a large interconnected program, how would new features be integrated with all the other clients? It is easy to say it would be modular enough that it wouldn't matter, but then are the services to supply thier own interfaces? If so, does every menu item bring up a different looking dialog?

It is an interesting subject, but I don't think it will fly anytime soon... For example there isn't even a standard syntax for making UI's, nor standards for broadcasting changes, nor for payment, nor user info, or users wanting to switch services, or even standard privacy policies - worse, what if one comapnay goes out of business, or gets in legal trouble over their code? So how can we make standard programs that depend on each other without essentially being like a single company of 12 that talks to each other an awful lot.

Robin Debreuil
Monday, August 26, 2002

The issue is not really of integration or these other things that Sun/Microsoft hawks.  ASPs hide knowledge from the user.  How many customers want to configure a server, or pay their ISP to run proprietary software they don't know how to admin?

Sure, some may want to run it on their own servers.  But that locks them into a support contract, for scalability tweaks or whatever.  Perfect.  Even if you didn't get all the advantages that Graham enumerates, these companies probably account for less than 1% of customers.

People are willing to give up some control, if it helps them do their work.  People don't trust their own Windows PCs for storing data.  Information-hiding is a principle where desktop machines don't deliver that well.  Everyone pays each other for abstracting away knowledge all the time.

Monday, August 26, 2002

Wow Albert!

You make some really lucid points. Excellant analysis.


I think the interest in web services mainly comes from the budding web service provider. This interest is made in the absence of a credible business case that takes into account whether the customer is being provided better quality or lower cost.

The analysis goes as follows:

1. Hey, if we run our program off the web instead of off the client's computer we can force them to pay for it every month and ensure a steady source of income. The analysts like that. Also it gets rid of the pesky problem where the customers fail to upgrade.

2. Hoo boy, yeah -- and think of the issue of lock in! We will OWN the customer's data and if they stop paying us, they'll lose their data! They'll *have* to pay us forever then. We'll own them, they'll be our slaves!

3. Man, this is a great idea -- it will eliminate piracy because the customer will have no access to the actual app. Since there are 9 copies of pirated software for every licensed copy, our customer base will increase by 10 right there!

4. All right! Now you're talking! And check it out -- we no longer have to write a version for NT, one for 95, one for XP, one for 3.1, one for Mac, and three for Linux. We just write once and run anywhere through the web!

5. So we don't have to write it in C/C++ as a single executable. We can use perl for part of it, python for other parts, C, assembler, etc -- whatever works and we don't have to worry about the customer's RAM size or excessive hard disk space needed for giant run-time environments or any of that stuff.

6. Yeah and we'll run it all on one server computer with bare bones installation. No more conflicts with rogue DLLs!

Wow this is great! Let's do it! But wait, we have to sell it to the customer how can we do that?

1. Tell him it's only $50/month instead of $800/seat. See, it's a cost savings!

2. Tell him he needs no more trouble and time spent installing software that comes with a poor installer and conflicts with other software.

3. Tell him it will run on any computer.

4. Tell him that when bugs are found he won't have to get an update, we'll fix them automatically and transparently.


OK, so this is what I think is really going on in this scene. The service provider sees some really compelling reasons to push this scenario, and it does have some minor advantages, but they are not enough to fool the customer.

However, exceptions exist. Plenty of businesses are running on yahoo and ebay and amazon selling herbs and junk and self-published books by paying the big company a cut of each sale. Also, ISPs will continue to fit the model of providing service since it is too much of a hassle to keep up with all the latest security problems. Better to hand that over to someone else for a minute monthly fee that is less than the cost of 1 hour's time of a competant system administrator. The thing about these services is they didn't exist at all before. Was there some way for a small craftswoman in Podunk to sell her goat-milk soap directly to soap enthusiasts in Santa Fe? Not easily, and yahooshops/ebay/amazon stores fit the bill. Notice that all these service providers are really providing the same service -- none of them are selling payroll services.

X. J. Scott
Monday, August 26, 2002

A point which people have made indirectly and should be emphasised: you may not trust your employees, but you should trust your business partners even less (and why should you trust their employees, anyway?).

(Of course, the recent round of business scandals suggest that the employees who are least trustworthy are the ones making decisions about payroll, not the clerks doing the payroll runs themselves...)

Rodger Donaldson
Tuesday, August 27, 2002

Actually, you probably want to trust your employees less than your business partners.  I've worked these jobs.  People don't give a damn because they've never seen the owner, and even if you have, you still likely steal a bit.  Even otherwise honorable people do this, for interesting reasons; perhaps they have an abusive spouse who has them steal large quantities of food or some supplies.  Theft is really the default, not the exception, management or grunt.

Theft is a cost of business.  5% (revenue? profit? I forget) is a large problem.  1% is grumbled about, but tolerable.  It's higher in urban areas, but most often by those who feel more entitiled.  So if I were to be un-PC, it's probably whites and wealthy non-minorities who do it more often, though poor minorities are more suspected.

Tuesday, August 27, 2002

Let me get this straight:

1. A business should not trust its employees, but
a business should trust its business partners, so it should outsource.
2. A business partner has employees it should not trust, but it trusts its business partners, so it should outsource the work outsourced outsourced to it.
3. goto 2

In this infinite outsoucing rig based on not trusting employees:
- who the hell is finaly going to deliver anything?
- who is going to pay the wages of the legions of middleman passing the buck?

Just me (Sir to you)
Tuesday, August 27, 2002

You can trust your employees, that's why you accept a certain level of theft as a cost of business.  Remember, I wrote, "You probably want to trust your employees less than your business partners."  That doesn't sound like an ironclad rule, and it doesn't mean you should suddenly trust your partners with everything.

Maybe my statements can be twisted into a klein bottle, but I stand by them.

BTW, I meant "whites and wealthy MINORITIES" in my last post.

Tuesday, August 27, 2002

Maybe it goes like, if you lay of three people who were tracking your inventory and outsource it, that's three fewer people hauling shit out your back door. The number one source of theft, even in retail, is employees. They would be way better off putting the theft detection system on the back door rather than the front, imo.

Robin Debreuil
Tuesday, August 27, 2002

Maybe they should just put up cameras in each cubicle. Maybe a new email and web filter is in order to see what these filth are doing on our valuable time. I say scan them when they come through the door and when they leave. Make them wear clear pants to we can see their pockets. I don't even think they should be allowed in the building.

And that's just the employees! The customer should be treated like an enemy, never show weakness to him. If you catch him trying to get over on you make sure you cut off one of his arms. White and wealthy minority customers are not to be trusted! Watch them closely becuase your life may depend on it! You will not be able to see their eyes because of their sunglasses, but their knuckles will be white from inner tension and their pants will be crusted with semen from constantly jerking off when they can't find a rape victim. They will stagger and babble when questioned. They will not respect you. The customer fears nothing.

Tuesday, August 27, 2002

Um trollbooth, there are cameras everywhere. ;-)

It's not bad or dirty, just a different culture.  You should try these jobs for three months, esp fast food.  Basically think of it as like slashdot at -1.  Well, not quite that bad.

> They will not respect you. The customer fears nothing.

That's what I often thought...  But remember who is giving whom the burger.

Now I'll stop posting, I've rambled enough on this subject.

Wednesday, August 28, 2002

I know there are cameras everywhere! That's what I keep telling the chips in my fingertips. I whisper so "they" wont see me talking to "them". I got a tinfoil hat to break up the signal though.

I guess I didnt lay it on thick enough. My point - when you treat people like a commodity, whether they be employees or customers, don't be surprised when they despise you and treat you with equal disdain.

Wednesday, August 28, 2002

*  Recent Topics

*  Fog Creek Home