When ASPs Go Under
lar3ry writes: "eWeek has a lead story about companies that have been catching the ASP bandwagon, and now are finding themselves high and dryas ASPs are going out of business. I may be old, but I remember when I was writing applications being used by other companies, that the contracts had agreements that provided for the source code to be held in escrow in case the company that I was working for went out of business. Does this mean that common sense is no longer a virtue in the Internet age? Just whispering a few hot terms like "ASP" makes the CIO of a company blind to any financial exposure that an application has to another company's future? Geez!" This is one thing that scares me about various companies' plans to take care of your data and apps. And unlike "Perpetual Care" at ye olde cemetery, you're still around to feel if the perpetual care stops.
We did this a *long* time ago with a mainframe package -- source code in escrow, with us paying the escrow account fees. The company went bankrupt and died; we petitioned the court for the source, as called for in our contract.
Not allowed. The court rulled that the source code was the *only* asset the company had, and, contract or not, couldn't be delivered to us.
So we ordered the contents of the lock-box destroyed (seemed to have been the *only* copy of the source code -- it had been trade secret and the authors left the company after getting peeved at the legal types that forced a takeover) and filed for a full refund of the contract payments because of breach of contract.
We got about 15 cents on the dollar.
Escrow would only be helpful if these companies were offering proprietary products - some of them may be, but many are not. They are offering access to applications which the out-sourcing company could either not afford to pay full whack for as they're only using it from time to time (maybe a major accounting package) or applications which the companies don't want to spend the time and money learning how to administer. These two cases are about access to available applications in a new way, not about access to new applications.
/. yesterday, maybe this is a good model for OSS applications - you don't need to train too many people to support the software, you just need them available from a central point.
Microsoft, don't forget, is going with a licensing model that is likely to help the ASP model - you license for use, but that doesn't mean that you hold the software yourself - why not get someone else to look after it for you?
My general feeling is that there is a lot to be said for an ASP-like model. If I have 20 people out of 2000 using a complicated ERP package, for instance, why should I have 2 or 3 of my IT support staff learning all about it so that they can support it all the hours of the day? It may be mission critical, but if I can find someone else to provide access to it, and not have to worry about training for support, then that's got to be a good thing. The problem seems to be that either the market isn't ready, or the model isn't mature enough. Maybe the applications don't suit the deployment model.
What's more, given the discussion about tech support on
ASP, then, isn't by definition a Bad Thing[tm] - but it may not yet be a Ready Thing for everybody. We seem ready to accept managed hosting - before we sentence the ASP model, let's think around it in more detail.
An ASP is, essentially, trusting someone else with something you don't trust yourself with. In many cases it is a wise decision, e.g. should Mom & Pop's neighborhood small business try to run their own accounting system or let IBM do it? However, it is of vital importance to remember that you are trusting your mission critical apps to someone else - and these are the sorts of things that a business would not be prudent to rely on a contract to protect.
So, in short, don't sign up with an ASP you don't trust. (When I say "trust" what I mean is you trust that they 1. don't go out of business 2. don't screw up 3. don't attempt to screw you over, etc... no small amount of trust.) Which pretty much means don't mess around with VC fueled startups. I suppose it would also be a good idea to have an escape plan (e.g. some way to export your data into a competitor's system) but by no means does it alleviate rule #1.
The poster mentions an escrow scheme and licensing so that the customers can, presumably, take over the software they are licensing if the provider bails. However, this is not an adequate solution.
The whole premise of application services is that it is not economical for the customers to purchase, install, and support their business software, and must rely on an outside service provider to do those things for them. Is a company which considers it uneconomical to even perform these normal IT-type tasks going to be willing to take over the development and provision (even if only internal) of the service in question? Not bloody likely. Even if a company is forced to take on such a burden by sheer business necessity, it will involve a huge amount of disruption to the normal activities of the business.
Such a contractual solution is no solution at all. Companies which use application-services vendors to provide software essential to their core business must understand that they are in effect betting their company on the hope that the ASP will not go under- a rather foolish bet in this industry, unless the payoffs are truly enormous.
"Never let your sense of morals prevent you from doing what is right" -Salvor Hardin
Indy: "Snakes. Why did it have to be snakes?"
Sallah: "ASPs. Very dangerous. You go first."
--
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
Application Service Providers. Remote hosting of mission-critical applications. They're dropping like flies
Timothy get's an F in grammar today.
And so does the Grammar Nazi.
-jon
Remember Amalek.
Just whispering a few hot terms like "ASP" makes the CIO of a company blind to any financial exposure that an application has to another company's future? Geez!"
I got up close and whiserped "A-S-P" in the CIO ear and he didn't exactly go blind like this author would have you think. In fact he just looked at me like I was a freak or something... proving that his eye sight is in fact fine.
Slashdot should check there fact before posting this junk.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
I have seen so many companies buy into the outsourcing myth. A few execs and PHB's look great for a while, as they count up the savings. But then, lo! and behold, there are some surprises. I have a large, long-term client that outsourced its entire IT organization to IBM. Now, this is no knock on the many good IBM engineers who were providing my client its services and support, many of whom were my friends; unlike many outsource deals, this one did keep good resources and practices in place. But after a couple of years, the company was still hurting, because there was nobody inside the headquarters building whose job it was to make an informed technical decision. All their strategic choices were delegated to a third party in the computer services biz, not in the user company's biz.
Any time a company outsources its mission-critical systems, knowledge, or decisions, it's taking a big chance.
JMHO -- Trevor
-- We all have enough strength to endure the misfortunes of other people. La Rochefoucauld
Maybe I'm nuts, but stuff like this whole .NET thing, and all of the other "let us host your apps and data, it's better" companies make me really nervous. I guess I'm just a control freak, but with the current state of tech support (hold please) I just don't feel comfortable that these folks can do what they say they can. Hell, the phone company can't even keep something as simple as my DSL running right, what incentive do I have to believe that remote apps will be any more reliable.
Where's my lobbyist? Right here.