It’s a plain fact that there are certain kinds of math problems that even bright people don’t solve very well and computers solve better than we do. Some of these look surprisingly simple. If you’re a retailer, when should you mark down product and by how much? Or if you’ve got to make six deliveries, should you use one truck and make six stops, two trucks with three each, etc.

Entrepeneurs in the world of enterprise software have recognized this fact for a long, long time and have seen an opportunity there. They develop so-called optimization software, which solves an essentially mathematical problem and then provide it in various forms to the market. A few have provided only the engine itself, most of them ending up in I-Log, and many more that provide optimization solutions that address specific problems, like supply chain optimization, markdown optimization, or the subject of this post, sourcing optimization.

Now if there’s one thing that’s completely clear about optimization software, it is that the track record has been disappointing. I’m not just talking about the overpromising and underdelivering that afflicted the big-name supply chain optimization vendors. (No names, but you know who you are.) I’m talking about really wonderful products, like Joe Shamir’s ToolsGroup, which have struggled to put their tools in the hands of people who need it.

Sourcing is no exception to the general rule. In sourcing, optimization came to the fore when companies like FreeMarkets or Digital Freight wanted to set up sourcing “events,” where possibly hundreds of bidders could bid on thousands of line items, offering discounts for bundles of selected lines. What if A bids X for lines 1, 2, and 3, and B bids Y for lines 2, 3, and 4, etc.? This is one of those math problems that linear programming solutions solve better than human beings do.

A number of vendors still in the market place (you know who you are) proceeded to develop solutions for setting up and managing these events, which of course did a lot more than just figuring out which bids to accept. And to some extent, they worked; they did change the way many companies do business, and sourcing events are now fairly normal, with several large companies being big proponents.

But in my (admittedly somewhat limited) view, the optimization piece has been relatively unimportant. Certainly some companies have developed some good optimization algorithms, and they are used, but in the events I’ve seen or heard about, it’s not clear to me that the solutions they offered were actually all that optimal, and the reaction of buyers that I know to the solutions they offered have been tepid, shall we say.

I’m not surprised, as I say, because I’ve seen similar reactions from users of other optimization software.

Now I have a degree in math, and I’ve taken a course in linear programming. I know that the solutions they give you are better than what people can come up with by themselves. So are the people who don’t like these solutions just grousing? That’s certainly what most vendors think.

Well, the other day, I got a glimmer of the answer from some terrific research done by Vishal Gaur of Cornell University. (See my earlier post, “An Automated Replenishment System.”) He found in his case study that a solution produced by optimization software had a highly suboptimal operational effect because it was optimizing around the wrong things. The math was done perfectly, but the problem had been set up incorrectly.

This is always a problem in principle when you set optimization software chugging away. The software draws a box around the problem and finds the point inside the box with the best available solution. If you draw a different box (usually a larger one), the solution will be different, and will take longer to find.

In Professor Gaur’s case, the software developer had drawn the wrong box around the problem. Now what’s interesting here is that the software developer never knew that he’d done anything wrong. He delivered the software, and the IT people who were using it expressed satisfaction. And you might think, “Well, so what, even if it drew slightly the wrong box, it got roughly the right answer.” But in fact, when you change the box, you change the answer completely. So in this case, the users had to replace (manually) all the solutions the software offered (manually) with better and completely different solutions.

If you have optimization software, in other words, you have to draw the right box, or the answers that it gives you are not better than what you can provide, they are worse, often much, much worse.

Now look at how this applies to sourcing optimization. Let’s say that you set up the problem in one way. (You only allow bids from certain vendors, for instance, and you require that they offer discounts of a certain percentage.) If you draw the box differently, you will come up with quite different answers.

I was discussing this problem with Garry Mansell, president of TradeExtensions, a small sourcing optimization vendor. He argues that the only way of solving this problem is to provide a lot of services, along with the software. The experts that he provides (it just so happens, of course, that he’s in the business of providing this pairing) can keep the sourcing on track and make sure the right box is drawn.

Now I react to most honeyed words from vendors the way I react to offers of honey for my tea. (Hint: “No, thank you.”) But this struck me as roughly right. The problems that I’ve seen with implementations of myriad kinds of optimization software wouldn’t be solved, then, by fixing the software. It would be solved by helping people to make sure that they’re drawing the right box around the problem.

So who knows. Maybe Mansell is right. (Or maybe he’s just selling software. Or both.) But it seems to me to be a useful thing to keep in mind. If you’re looking at sourcing optimization software (or, more generally, any optimization software), don’t buy it and don’t use it, unless you have some serious experts, who can help you make sure that you drew the right box.

It stands to reason, doesn’t it. The more thorough and rational the buying process for enterprise applications, the better the outcome. For sure. Right?

Well, the other day, Dennis Moore, aka @dbmoore, a well-known figure in the industry, posted a query on Twitter asking for data that would show this is true. The more thorough the buying process, the more effective the implementation has to be true, doesn’t it. But no, the guy wants data. “Not anecdotes,” he said later, “but data.”

He isn’t going to get any. There are three reasons for this. First, there isn’t any reliable data of any kind on whether implementations were successful, at least none that I’ve seen in a career of nearly two decades. Second, most effort expended on pre-purchase analysis of software is misdirected, adding little to the quality or accuracy of the decision. And third, if you work backwards from failed implementations and identify the causes of the failures, it is very rare that the cause is the kind of thing that could have or should have been caught by a more thorough analysis.

The fact that there is little reliable data on whether an enterprise application product works is, of course, a scandal, but the fact remains and will continue to remain just so long as enterprise application companies want everybody to believe that the odds of success ar high and customers are embarrassed to admit failure.

I have been involved in at least two attempts by large, reputable companies to get a good analysis of what value, if any, has been gained after an enterprise app was implemented. The first interviewed only project managers and determined that the project managers found many, many soft benefits from the implementation. The second, a far larger effort, was eventually abandoned.

But let’s say that we had some rudimentary measure, like number of seats being actively used versus seats planned to be used two years after the initial projected go-live date. Would it show that thorough investigation really helps?

I don’t think so, and here’s why. The question of which software application to buy and/or whether one should buy one at all is usually a very simple question, one with a relatively clear right answer, at least to an objective observer. But it is rarely, if ever, treated as a simple question. People wrongly worry about a lot of irrelevant things; they are (usually) distracted by the salespeople, who naturally want the purchasing decision to be based on criteria most favorable to them, and because there’s a lot of risk (A LOT), people tend to create lengthy, rigorous, formal processes for getting to a decision, which do very, very little to improve the accuracy of the final decision.

Honestly, I can usually tell in an hour’s phone conversation what a company ought to do, and I often check back later — sorry Dennis, more anecdotal evidence — and I’d say I’m right at least 2/3 of the time, maybe more. And because of the way my business model works, I don’t even charge for these conversations.

What do you need to look at? Well, it’s a complex question, don’t get me wrong. But because the number of providers is limited, the capabilities are limited, and the likelihood of failure pretty high, there are usually only a few things that actually matter. And when there are only a few things, it shouldn’t take you that much time to figure them out.

Give a call, any time, if you want to test this out.

In many previous posts, I have complained, bitterly, about the sales tactics that every enterprise application vendor uses, mostly to defend aging, poorly designed products. It’s one thing to put lipstick on the pig, I’ve essentially said, but it’s outrageous to charge admission, just to see the pig.

This is, of course, what happens in most sales situations. Companies big and small buy the software through a highly-paid salesperson, part psychologist and part snake-oil salesman, who listens to you, discusses your pain with you, and then arranges a long, long process that you and your team will go through: functionality requirements and demos and business cases and who knows what all.

Let me fill you in on a little secret. It’s mostly a waste of time. And money. Not just your time and your money. But also the software company’s. You are both driving up the cost of software, simply by accepting and perpetuating a system where rigmarole is the rule of the day.

In a time of economic growth, maybe both companies could afford it. So what if you use up a lot of IT hours compiling functionality lists and sleeping through demos. (Who could stay awake in them?) The IT guys like it well enough, and they like to be asked for input. So what if the software company wastes a lot of, er, resources flying in executives or taking the team out after all their hard work to a place where attractive women perform. (Happens, believe me.)

In a time of economic frailty and, not coincidentally, a time of doubt about the value and merits of enterprise software, no one can afford it any more. Not you, who has better things to do with your resources. Not the software companies, whose sales resources are being spread thin by companies that are insisting that the salesperson do more and more for them.

Wouldn’t it be better to use some of the resources squandered on these endless sales cycles for something else a little more worthwhile? LIke getting both parties to the right solution faster?

Top 10 things to use the money for, once you stop paying maintenance.

10. Reducing the backlog at internal support. This doesn’t take much money, of course, since you’re already saving the hours your people had been on hold waiting for the software company to answer.

9. First-Aid. You know all those open, raw spots in your current installation, the ones you hoped would be fixed by the latest version, if you could ever get it installed? Take charge and fix them, ’cause now your former supplier ain’t gonna do it. You’d be surprised what rudimentary first-aid tools can do: a few user exits, a virtual machine for low-profile Java apps that the exits talk to, a little user training, a few reports. You’ll get people back to the front in no time.

8. Raises. You know life just got easier. But that doesn’t mean that you shouldn’t use some of the money to reward your staff for all the effort they put out over the years dealing deal with your former supplier.

7. Shutting down the patch testing environment. Of course, once you do that, you have even more money, so…

6. Buy something you couldn’t afford. Go on, live a little. Here are some suggestions…

5. Invest in mobile. Every one of your executives wants cool stuff on their iPhone (or an iPhone if they don’t have it). Make yourself a star. Give it to them. They’ll go to their graves believing that IT support improved on the day you stopped paying maintenance.

4. Invest in the cloud. Face it. With the end of enterprise support, you don’t have an excuse not to do development that you can’t afford to do. So start by reducing the cost of development. With EC2 or Force.com or Rackspace, you can suddenly start doing it right, that is light and cheap.

3. Don’t invest in social networking. But do take the shackles off. Spend a little, tiny bit of money encouraging people to figure out what they ought to be doing with these new tools (if anything). And maybe use some of the tools to help everybody keep track of the efforts.

2. Return some of the money to the CFO. He or she has been walking around the halls looking for some spare change. Now you can reach in your pocket, pull something out, and feel good for the rest of the afternoon.

1. Hold a check-burning party. Write out 10 of those big checks made out to whoever it is, go out to the parking lot, and reduce them to their constituent elements. Hint: bring some beer.

Got your own suggestions about what to do with the money? Add some comments here.

The Oracle Quarter

June 23, 2009

I was following some Oracle deals, as their quarter closed last month, and what struck me most about some of these deals is that Oracle competitors are trying to out-Oracle Oracle–and failing.

Let me give you an example. One of the most common, best-known plays in the ERP salesperson’s playbook–the equivalent of post-right in football–is called elevating the deal.

When you elevate the deal, you try to take it out of the hands of the “team” that has been assembled to evaluate your product and put it in the hands of busy executives, preferably several levels up, who are in a position to override the team. When you’re put in front of these executives, you pitch business benefits, instead of functional capabilities, and fill their soft little heads with visions of flexibility and agility, competitive differentiators, and money dropping like rain to the bottom line. At this level, of course, you just assume that your software actually has the functionality that will allow you to gain those benefits, which is of course what that low-level team was taking all this time trying to assess.

Both Oracle and SAP are past masters of this particular play; when they run it, it’s Tom Brady to Randy Moss, man.

So this quarter, I heard about two situations where one ERP vendor tried to elevate the deal, at the express instructions of the coach, er, head of sales. In either case, was it Oracle? No, it was the other guy. And did it work? Not a bit. The only thing the competitor succeeded in doing was ticking off the selection team.

It’s a pretty small sample size, of course. But it made me wonder. I know that the applications themselves showing their age. Is it possible that the tactics that go along with those apps are beginning to fray, too? I have been saying for some time, now, that they’ve outlived their usefulness to the customer (if there ever was any). See my blog post, “Lawson’s New Office,” for instance. But now, I’m wondering, have the old sales tactics stopped working for the vendors, too?

I’d be curious to get comments on this; as I said, my sample size is too small. But assuming I’m right, there’s one other question to ask. Why has Oracle figured this out and other companies haven’t?

If so,

Designed for Stability

June 22, 2009

I was just talking recently to a specialty chemical company whose specialty product is used primary by an industry that is now under water. They have a lot of middle-aged systems, and they’re looking for something, anything that they can do in the systems area that can help them out.

We’re talking about a company that needs to contract by, say, 50% until their market comes back.

So what can they do? Well, nothing. But the reason they can do nothing is well worth paying attention to and pondering.

You see, the systems they have–I won’t tell you which one is preponderant, but it’s one of the $AP family, that is, SAP, Oracle, PeopleSoft, JD Edwards, etc.–are all designed for stability. They work well only when things change very little. Change a manufacturing line, get a new big customer, add a new product or two, and these systems can deal; it only takes a few man years of work.

But change the business in some fundamental way and everything breaks. Move a line from one factory to another, and it might actually be easier to move the physical line than it would be to move the data in the old ERP system into the new one.

Chrysler faced this a while back, when Cerberus bought it; now, both GM and Chrysler are having to deal with it. I ran into the problem at an electronics company that was deciding to outsource and at a company that was trying to shift a lot of its business onto the web. Their systems wouldn’t let them change.

Well, it’s a good thing if the company that’s setting up the system is stable, has a product that doesn’t change too much, has reliable customers and a business model that will work for the next twenty years.

Know any companies like that?

It’s a bad thing, though, if your company wants to or needs to change fast. Then your systems will get in the way.

Do people ever think about this simple fact when they’re buying the systems in the first place? I’ve never seen any company that did. Do they think about it when they’re buying a company? I’ve only seen a few. When they’re figuring out whether to consolidate systems, that is, do they consider the tradeoff between the money they’ll save by consolidating systems and the money they’ll lose if they have to disentangle the newly consolidated entities? I’ve never run into anybody who did.

It makes sense, of course. Everybody thinks that things will stay more or less the same. Companies, their employees, the people who sell them systems, the people who design the systems. So that’s what they plan for, build for, and buy for.

The only problem is that much of the time, it isn’t true.

Not only the systems, my dear, but the entire mode of doing business with the vendor.

They come to the conversation talking to me about consolidation; they want to use fewer systems, servers, support personnel, etc.

I don’t think this is going to work; in fact, I think they’re going in exactly the wrong direction.

Lawson’s New Office

April 22, 2009

If you read this blog at all, you know that I hammer over and over again at a single theme: the middle-aged application. What is a middle-aged application? It’s one whose basic mode of interacting with data was invented almost 20 years ago. It stores data in tables; you interact with it by pushing data into those tables or taking the data out. It was a great model, 20 years ago. Today, in my view, it’s fading.

What do you do if you’re a vendor, and you have an app that was built on a paradigm invented 20 years ago? Well, one thing you can try is a new interface. That way, even though you’re still basically storing data in tables, you’re doing it in a way that’s brighter, more colorful, and possibly more useful.

Unfortunately, this is kind of an obvious idea, and the landscape of ERP systems is littered with “new” interfaces that turned out to be not so new after all. According to the vendor, every single one of these modernized the application completely. But all they really did was put lipstick on a pig–and not much lipstick on an exceptionally hairy pig.

The latest such attempt (and surely one of the most creditable) is an interface demo’ed by Lawson at its recent CUE conference. I got a chance to take a look at it (if not a look into it), and I would have liked nothing more than to say that it changes something important about the application.

Unfortunately, that’s not possible, but not for the reason you’d expect. It isn’t that I looked at it and saw, “Oh, it’s just like all the others.” It’s that Lawson made it impossible for me to tell one way or the other. This is not a good thing, of course; if Lawson really has something great, they should show it to people. But it does say something important about the software industry.

First, let me tell you what I know. Lawson told us at the conference that they’re offering two new things that might change the way users work with the application. The first is a search function, which allows you to search for records via their contents, rather than getting at them through the menu system. The idea of this is really good; if you had to name just one thing that makes the old ERP apps middle-aged, it’s the fact that you can’t Google through them in any way, shape, or form. The second is something called Smart Office, which puts a Microsoft Office-like skin on Lawson and lets you interact with Lawson through Microsoft Office products, like Excel and Outlook.

The search function is particularly exciting, because the problems with search are built into the way 20-year-old ERP systems work. ERP systems store their records in a database; to get the records out, you have to use the tools the database provides. Search isn’t one of those tools. (It is too slow.) Lawson gets around this problem by manages pushing all the records in the database out to an appliance, a separate virtual machine, and then using a tool that wouldn’t work on a database, the open source search-engine, Lucene.

From what I could tell, there are some really thoughtful things in the way they’ve implemented the search. Particularly impressive was the fact that you can search back on all the work you’ve done, which makes it easier for you to stop in the middle now, go back to something when somebody asks you about it, or correct mistakes.

Smart Office, alas, seems to be a little more ho-hum. Some of what SmartOffice does was actually built into PeopleSoft more than 10 years ago; much also looks like a knock-off of Duet, the much-vaunted SAP attempt to integrate with Microsoft Office. Still, when you take a quick look at it, it doesn’t seem too bad.

If either product had been introduced ten years ago, I think I would have left my reporting at that. Lawson had come up with something new in the interface and demo’ed it. It wasn’t really very clear exactly what. But who cares. One needed to give them the benefit of the doubt. Surely it was better than a green screen.

Ten years later, though, I don’t think that’s right (even though that’s what most of the analysts did). Ten years later, there’s been a lot of experience with “major” interface improvements, and, as I said above, it’s been a disappointing experience. Most of these improvements have been at best, an injection of Botox, doing nothing about the basic problems with an aging interface, and possibly making things worse.

What this means for Lawson is that the burden of proof has changed. If they’re going to come up with a change in the way users get at data and claim that it’s a compelling, potentially transformative difference, they’re going to have to prove it, some way or another.

Certainly, if the language of the demos is any guide, Lawson does think that they have a compelling and transformative innovation. To listen to Dean Hager, their inimitable and endlessly enthusiastic spokesman for the product, Smart Office and Enterprise Search are, at the very least, what people were offered in the movie, “Seconds,” a brand new body and hence a second life.

So did they prove it? Nope. Yes, there were a few things in the demo which were encouraging. Some of the examples of how to use Search, for instance, were pretty insightful. And while the SmartOffice demo couldn’t be made out by those of us watching on the web, some of the claims sounded good, and the customers who were video’ed were enthusiastic.

But there were also a few things that were discouraging. Since I couldn’t actually see the demos (Lawson doesn’t invite me to their user conferences, even though I don’t ask them to pay my way), I can’t point to anything concrete. But I can say that I found the fact that Smart Office is a client technology (not a thin browser technology) provided by Microsoft less than heartening. (Anybody who doesn’t understand why that’s a problem should take about a ten-second look at a phone that runs Windows Mobile, then take a 10-second look at an iPhone.) Also not so heartening was the fact that Lawson’s broadcast of the event for “remote analysts,” that is, people they don’t think are very important, was incredibly web unsavvy. (Unless you use Microsoft products, you basically can’t even get a feed.)

Add up the discouraging and encouraging, though, and do you get proof? Certainly not. Both the positives and the negatives are way too vague.

And that’s precisely the trouble. It’s 2009. People have been working on these products for 20 years. There’s a great deal known about them. And today, there’s a presumption, born of bitter history, that when a vendor announces something fabulous, but most of what the vendor says is hand-waving, that what they’ve got isn’t really that fabulous.

So what would it take for me (or any rational person) to be convinced that the latest Lawson innovation is one that matters?

Well, let me tell you, it’s not easy. Even if I had full access to this application, something that there’s not a snowball’s proverbial chance that Lawson would give me, it would probably take me a day or two–I’m not kidding–to figure out how much of an improvement it is. To see why this is, let’s just take search as an example.

Lawson says they’ve made search of an application’s records as easy as Google search and that they’ve done this, as I said above, by putting the records on a separate appliance and using an open-source search engine. Certainly, doing this solves the problem of speed, which has been a serious problem.

But the trouble is that solving the speed problem does not make the record search as easy as Google. To make it as easy as Google, there are a lot of other problems you have to solve, too.

Here are some examples. You need some way of ranking what is sent to you in a way that makes sense for your uses; otherwise, as with Google, you’ll get tens of thousands of records when you make a search, and you’ll have to page through them. And you need to solve the ontology problem, the fact that you want to include synonyms in what you found, as well as exact matches. (Sometimes, these “synonyms” are nothing more than making sure that IBM, I.B.M., and International Business Machines are all included in the search results.) You need some way to use metadata descriptions. (Can you easily–and I mean easily, easily–restrict the search to sensible populations, like AR records, or sales orders from two years ago.) And above all, you need to deal with the problem of bad data. Many of the records you’ll grab in any search are records that shouldn’t be in the system. You need some way of filtering them out.

(Enterprise applications that have been in use for any time at all have this big, smelly layer of refuse in them, just the way lakes do. On the whole, I think, the bottoms of lakes smell better. Unless carefully managed, search has a way of stirring up all that stuff on the bottom, not something you want to do.)

If an enterprise application search product doesn’t deal with those problems, well, it isn’t much good. You can say it’s as easy as Google. But when the customer uses it, they just won’t have that experience.

There are still other problems, and one of them’s a real biggie: it’s what I call the transition problem.

You see, if the search (or Smart Office) is really going to change the way people interact with this 20-year-old app, people have to use it. So, in addition to providing a brand-new very hot, ultra-cool search capability (or Smart Office capability), Lawson has to make it possible for its existing customer base to take this capability up and take it up in a way that prevents the costs from overwhelming the benefits.

This transition problem is a thorny one for all the providers of middle-aged enterprise apps; I’ve seen versions of it at SAP, Oracle, and Infor, as well as Lawson. The provider figures out some way of getting an app to sit up and sing, “Rule Brittania,” as the old phrase goes. But then they tell the users that they’ll have to go through a massive upgrade and retrain all their users in order to make the trick happen. Then they’re surprised when most users opt to dispense with any stirring displays of patriotism.

To prove that Enterprise Search or Smart Office actually does something important, it seems to me that Lawson has to tell people (you, me, the customer, etc.) in a clear, simple way just exactly what it has done to deal with all these problems, and then it needs to provide us (you, me, the customer) with enough access so that we can genuinely see for ourselves.

Has Lawson done that? Well no, of course it hasn’t. I’m sure the thought of doing something like that never even entered Dean Hager’s head.

Not only is this unfortunate, it also says something important about the enterprise application industry and about the ability of Lawson (or any of the other middle-aged app companies) to modernize. The fact that Lawson (or SAP or Oracle or any other apps company that does this) doesn’t even realize that the burden of proof is now on them shows how far behind they really are. In a way, it’s puzzling. In the era of the iPhone and FaceBook and the collapse of GM, shouldn’t any company like Lawson be worried? But the answer seems to be, “No.”

Why don’t they think so? I”m not sure. What it comes down to, I guess, is that middle-aged apps and middle-aged apps companies are a lot like middle-aged people; it seems obvious to them that they’re still young, and so they don’t realize it when people start laughing at them. They think that they can give a cute demo at a user conference, have a lot of salespeople go out and tell their customers that it’s the latest, greatest thing, and then the IT staff will put it into the plans. That’s how it was ten years ago, and that’s how it is today. After all, the customers are paying maintenance, and Lawson is taking the maintenance money and working on things that keep the product up to date. What more is wanted?

Well, what is wanted is evidence. Without that evidence, the presumption has to be that applications like Salesforce (enterprise search three or four years ago) or Workday, which uses Flash, not Microsoft, and doesn’t use a 4GL, are now carrying the innovation banner.

Of course, the middle-aged apps vendors are unconvinced, just as all middle-aged employees are. We have the experience, they say; we have the know-how; we have the functionality; see, we can still dance a jig.

They say it, but in my view, they are wrong. Viewed by anybody who uses an iPhone every day, these apps just don’t work all that well any more, relative to how much they cost. They badly need to be brought up to speed. Ten years ago, we could assume that the companies were trying to keep up and we could accept mere assurance. But ten years later, that is no longer enough.

Yes, it may take the customers longer to figure this out than it does the analysts. But eventually, even the most ardent fan realizes that Elizabeth Taylor weighs a little more than she used to.

Talk to the typical SaaS executive about the complexities of customer service in Cloudland, and they give you a blank stare. What’s the problem. We provide our service. We guarantee it. We do a better job than

Well, yes. But that’s not all. When you’re getting cloud services, the services are often coming from multiple providers. Each of them can think they’re doing a good job or the right job. But even so, delivery can fail. And when that happens, it’s a nightmare for the customer. A nightmare.

Here’s a simple example. I have a Blackberry Pearl. My web site and domain name are hosted by XO. Two SaaS providers. I get my Blackberry e-mail from XO, which forwards it to the Blackberry domain name (tmo.xxx.com).

All of a sudden, this weekend, I started lots and lots of new spam–you know, the usual, sex stuff, plus a lot of spam with a Facebook return address, etc., etc., stuff that had been filtered. The new spam appears on both my Blackberry and in the e-mail delivered directly to my POP3 Mail account on my Mac. But much more new spam appears on my Blackberry.

Obviously, something happened to one or more of the spam filters that are provided to me. I know of at least two of these filters: one at XO and one on my Mac. Is there another one at RIM? Who knows.

I’d like it to stop, but I don’t have the time to troubleshoot this problem. Did XO change its forwarding policy? Did RIM install a new filter and screw up? Who knows.

If I just had one provider, I’d have some chance of solving it. But when I have two, I just have to sit and wait. The worst of it is, it might be the case that neither provider will ever realize that there’s a problem.

I wonder if the iPhone has a spam filter on it?

The point? Well, cloud service providers need to start thinking about this–and taking responsibility for the actual delivery of services, not just for making those services available.

Acres of Servers

April 13, 2009

Brian Sommer offers this astonishing story about a bad implementation. The story comes from early in his career.

“I worked an entire year getting the first mainframe General Ledger (and other vendor apps) in production at a Texas client. I have never before or since worked so many hours in one year.

After that project, I was off to another installation of the same vendor. When I arrived, I found a team that had been diligently preparing for a conversion to take place in approximately one year.

The users wanted to push this software product to the absolute extremes of its functionality. The software was going to be configured with virtually every conceivable option.

Having just lived through the Bataan death implementation, I knew there were some practical limits for this software. Within 24 hours of being on-site, I shared with the client my disk space concerns for one of the validation tables: a reverse code block look up table. By my calculation, this table alone would require 14 acres of IBM 3350 disk drives. That’s
correct:14 acres.

The client didn’t believe me.

Two weeks later, the client executive director invited me to listen in to a call he’s having with the vendor’s CEO. Everything went well until we got to the subject of the lookup table. The software CEO confirmed my math and told the client that his software was ahead of its time. He said that hardware hadn’t caught up with his software and that the client should “either scale back the functionality or do a hostile takeover of IBM”. Needless to say, that didn’t go over well with the client.

Now the client believed me.

They also believed me when I told them that the product wasn’t ready to run in IMS DB/DC. It took another 12-18 months before the technical platform was ready.”

Thanks, Brian. But one question. Who was at fault? The client? The vendor?

“Fault. It was the project team. They went along with everything the client wanted. Sometimes, in the long run, you need to show clients a little tough love.”

Oh, and one other. What is an IMS DB/DC?

Four-Five Years

March 31, 2009

Within the tiny world of SaaS executives, there’s a little-known rule of thumb. I call it the Four-Five Years Rule. The rule is this. “When comparing the cost of SaaS offerings against an equivalent perpetual license offering, the break-even point comes in four-five years.” That is, when you add up the total cost of leasing a SaaS offering and the total cost of a perpetual license offering, the latter including hardware, the software license, and maintenance, and even the cost of money, the SaaS offering is cheaper for four years-plus; after five years, you’ve spent less on the perpetual license offering.

Did you know that? Bet you didn’t.

So is that an argument for SaaS, or is it an argument for perpetual license? After all, most installations last longer than 5 years. So maybe you should bite the bullet and pay up front, right?

No. You see, there’s a big, big difference between the two at the break-even point. With a perpetual license application, the application you’ll have is four-five years old. (You see, I’m not including the cost of upgrades.) But with a SaaS application, the application you’ll have is brand new and up-to-date.

It’s sort of an inversion of the old automobile lease-vs-buy conundrum. At the three-year breakeven point, if you buy you have a car, but if you lease, you have an empty parking space. With software, if you lease, your installation stays new. If you don’t, it gets old.

It’s also an inversion of the standard idea about SaaS, that it’s cheaper, but you get less. Not at all, after five years, it’s more expensive, but maybe worth it, because you’ve got a superior product, one that’s been kept up to date.

Not necessarily worth it, mind you. If you don’t need all the stuff they put in to keep the software new, or if you need to customize, you’re definitely better off with perpetual license. A lot of it depends on what you think the useful life of the old software will be.

One last argument for perpetual license, of course. If you do think the old software will have a long useful life, you can plan to save a boodle by going off maintenance sometime after those five years are out. If you do that, perpetual license can be way cheaper.