Brittle Applications
August 31, 2009
In a previous post, I said that MRP was a “brittle” application, and a commenter questioned me. What is a “brittle” application? Is this a technical term? What makes MRP brittle? All good questions.
A brittle application is one that doesn’t work at all unless a lot of disparate conditions are met. MRP, for instance, doesn’t work unless all the data is right, people know how to use the program, the demand for the products is stable, purchasing is also committed to minimizing inventory levels, etc., etc.
The notion applies to a lot of other programs besides MRP, though I’ve rarely heard the term used. But notice that it brittleness isn’t so much a feature of the program as it is the purpose to which the program is put.
Let’s take a simple example: a word processing program. For normal purposes, a word processing program in this day and age is not brittle. A rank novice can use it to type and print. But even today, if you want to use, say Microsoft Word, to put out a 16-page brochure, complete with illustrations, well, good luck, is all I can say. You try to get an illustration and have it float and change the size and put in a table, and–well, just try it, it’s a nightmare. So, to put a 16-page brochure together, Microsoft Word is brittle, but to print out a letter, it’s not.
The point about the MRP program that QAD wrote, which follows the APICS standard religiously, is that it’s brittle relative to the purposes for which it was intended. Pam and Karl and Evan (the founders of QAD) really believed that QAD’s could do supply chain management for manufacturing facilities very effectively. My point was that the program is too brittle. To get things right, you have to get all the data right and keep it right, etc., etc. And if you don’t, what you have is an overwrought and overcomplicated Kanban system, without Kanban’s virtues.
Are there other enterprise application systems that are brittle? Lots and lots of them, I think. Almost all the old, Siebel-style CRM systems were simply too brittle; they depended too much on the good-will of the salespeople, the accuracy of the sales model embedded in the system, the reliability of the sales cycle, etc., etc. You wouldn’t think that financial systems are brittle–after all, they have to work–but they often had components that were overly brittle: cash management systems, for instance, and fixed asset systems and budgeting systems.
What do most companies do when they have an overly brittle system? They use the system for lesser purposes. And they feel REALLY bad about it. So, the Microsoft Word user makes a brochure that is far less fancy, but more manageable, and the QAD MRP user uses the product for tracking inventory. And both of them keep on saying, “Well, one of these days, I’ll get around to really making this product sing.”
They shouldn’t. Brittle applications are brittle for a reason. A lot of the time, it’s because they’re really a special-purpose product, but yours is not that purpose. Some of the time, they’re brittle because they’re badly designed. Some of the time, the model they’re using (MRP is a good example) just doesn’t fit the situation you’re in. In any of the cases, the fact is that they really can sing for the right user, but that doesn’t mean it’s your fault if they don’t sing for you.
What do you do if you have a brittle app that isn’t singing? Give up on it. It won’t work for you. Get another app, one that works. Or change the process. Or just accept the fact that it will never work the way you thought it would.
In any case, good luck.
Think Small: Appropriate Technology for the Enterprise
June 24, 2009
Vinnie Mirchandani frequently rails against maintenance fees in his Deal Architect blog, quite correctly in my view. As apps get older, the ecosystem becomes more robust, the number of people available to make the things work increases, and the underlying technology gets better, prices should go down. That they don’t is a testimony to the chutzpah of the application vendors and the, er, timidity of the customers, nothing more.
But let’s say, Vinnie, that you know this and you’re not particularly craven, but you need these guys. What do you do? Or let’s say that you’re just buying something they’re offering, because it makes sense. What do you do? Or let’s say that you believe those silly pundits and you’ve decided to go off maintenance. What do you do?
As I said in an earlier post, you still need an application strategy. The question is really, “What should that strategy look like?”
In that earlier post, I suggested that you should favor cloud applications, because they reduce the invisible, but very real long-term infrastructure costs. You should think Google Apps and Salesforce and developing on Amazon (but not on Intuit’s QuickBase, no matter what you do).
But this isn’t in itself a strategy, it’s just a guideline. So let me add another such guideline.
Think small.
Do you remember back when Jerry Brown was governor of California and was talking about something he called, “Appropriate Technology.” Appropriate technology was small stuff, which worked, which didn’t cost too much, and which was suited to a small, local problem at hand.
Let me give you an example that I remember from the time. Our local, San Diego power company wanted to build a plant in the desert, basically to deal with peak power demand. This was a big technology solution. Perhaps emboldened by Governor Moonbeam, the appropriate technology people proposed a combination of cogeneration and peak usage pricing. Miracle of miracles, they one. Why? Well, I can assure you it wasn’t because San Diego County had gone blue. It was because everybody could see the point of not having to pay for concrete and transmission lines, when they didn’t have to.
Oh, gosh, am I talking about best-in-breed apps, heterogeneous computing environments, multiple vendors, nightmarish integration costs, etc., etc., all the things we were trying to get out from underneath when we jumped onto the big app bandwagon?
Yup, yup, yup. That’s what I’m saying. In this day and age, you’re better off figuring out small, local solutions to specific problems–and accepting the costs associated with that–than you are buying a large, global solution, that supposedly offers economies of scale, but never delivers them.
If you adopt this strategy, you think (or at least you entertain the possibility) that a small, light call center/knowledge management app that deflects 10% of the time-wasting calls and can go in tomorrow, SaaS, might do more for you than the global call-center app that is designed to automate your interaction with most of your customers, costs jillions, and will take so long to install that none of us will ever be there to see what happened–even though the large app is supplied by your primary IT supplier and will become part of your global application footprint (the one you pay all that maintenance for).
I know it’s a radical notion. But that’s the idea. Think small. Look for small improvements. Buy small apps to make the small improvements. Don’t buy more than you need; assume that light apps that do less are the way to go.
Given the cost structure in place today, you’ll not only do more, faster; you’ll save money.
Why? Well, when you cut through all the nonsense, it’s the same reason I pick up a wrench rather than call the plumber. It doesn’t require that much. The job gets done. And there’s no reason to pay any more than I have to.
Chiseling On-Demand
June 15, 2009
You know the old joke, “How can you tell whether a software salesperson is lying?”
What about when it’s a “No-software salesperson?”
The question came up the other day when one of the people in the office went off to Intuit’s road show for its on-demand database. (Intuit is putting Quickbase on line, promoting it as the cloud’s answer to Access, and the road show was for people who might develop on it, using a Flex-based front end.)
This person came back less than wowed, of course; what do you expect, it’s Intuit. But the quality of the product seemed to me to be beside the point. No matter how good or bad it is, I argued, you would have to be absolutely cracked to have anything to do with it.
Why? Because the way Intuit behaves itself in the on-premise world makes them a non-starter in the on-demand world.
Believe me, I know whereof I speak. I am a heavy user of Intuit products: TurboTax for 10 years or so, QuickBooks for four, Quicken, now, for two. I have thus had more exposure than I would ever, ever like to have to Intuit’s chiseling ways: the design that plumps unerringly for the cheap and stupid way of doing things, the support that has at times left me screaming at the telephone, the innumerable ways they have made my life harder because they only want to deliver the absolute minimum, the endlessly inventive efforts to extract an extra $5.00 or $20.00 from me.
I use the products, despite all this. But only because, over the years, I have figured out how to keep the chiseling costs down to what I think is an acceptable minimum.
Mind you, sometimes they nail me, even so. This year, it happened twice. This year, for instance, they decided de-support QuickBooks 2006 Professional Edition. “Desupport, I thought? I don’t get any support from them anyway.” Turns out, of course, it was a way to get me to plunk down another $300 for the latest edition. Didn’t work; I finally figured out that there was no reason to pay another $300 for software that I already owned. But it did cost me more than a few hours to figure that out. And it burned me when I figured out that what they were doing, in order to make me want to upgrade, was taking away their QuickBooks e-mail invoicing service. $100/year to send out invoices? Give me a break.
But they weren’t through with me of course. This year, I saw the most inventive piece of chicanery I’ve seen in a long, long line. Instead of sending me a check for the TurboTax rebate, they sent me a debit card with a $10 credit. This turned out to be much more fiendish than you might think. First of all, even though it says debit card on the card, it’s actually a credit card, so if you say, “Debit,” to the cashier, it’s refused, something I find embarrassing. Second of all, even after you get on to that dodge, it’s a lot of work just to use it. Either you have to come up with an item that costs exactly $10, or you have to split the bill between two credit cards–also embarrassing. So what did I do? I finally bought a $7 item, and I guess I’m going to let them have the remaining $3.
So what does this have to do with cloud computing? Well, let’s put it simply. If you have enterprise application software, and you’ve bought a perpetual license, you have a defense against at least some of the chicanery and chiseling that seems to be built into relationships with software vendors. You can stop dealing with them and still use the software. But with a cloud computing vendor, you don’t have that defense. So you’re much, much more vulnerable.
My supplier of enterprise application software happens to be Intuit, and with Intuit, I simply don’t allow myself to become that vulnerable. I never use the Intuit Quickbase product or the On-Demand version of Quicken or QuickBooks; I don’t even use the on-demand TurboTax backups. Why? I have been victimized by Intuit’s sharp practices many times, and I don’t want to give them an even bigger and more vulnerable target.
Now I don’t blame Intuit. They invented a business model that really worked for them and apparently works for millions of customers–a kind of RyanAir for software, where you provide the maximum amount of irritation and inconvenience possible in return for a rock-bottom price. But this is not a business model, I think, that consumers should accept when it comes to cloud-based applications. There’s just too much risk that a Ryan Air-like application company will ask you in mid-flight to chip in a little bit more so they can get you back down on the ground.
If it were just Intuit, of course, I wouldn’t burden you with my ranting. But it seems to me that Intuit is not the only company that came of age in an era when you delivered software to the premises and discovered that you can make a fair amount of money in that context by overpromising, underdelivering, and making sure that you have your customer’s wallet firmly in your gunsights at every moment. I hate to say it, but there are much bigger companies that deliver much bigger accounting software that have the same mind-set. So if it’s unwise for consumers to trust Intuit’s approach to business when it comes to cloud applications, isn’t it unwise for consumers to trust the other guys?
Now wait a minute, Leo or Larry might say, aren’t you tarring perfectly reputable, upright, leading companies with a brush that should be reserved for Intuit? Well, I dunno. I don’t own your software. You tell me, L&L. I know that Intuit has provided me with support that was completely inadequate and left me genuinely vulnerable as a result; has your enterprise software company done that? I know that Intuit has misled me about what’s in upgrades or in more expensive editions and cost me a lot of time and money as a result; has your enterprise software company done that? I know that Intuit has tried to charge me for things that I thought were included in the original deal and has raised rates on me without providing anything to me in return; has your enterprise application done that? And I know that Intuit designs software in a way that shifts a lot of costs onto me, even though it would often be very simple for them to avoid doing this. Does your enterprise application company do that?
If the answer is, “Yes,” to any of those questions, what’s going to stop you from doing this to your customer again, when your customer buys your cloud-based apps?
Maybe there’s an answer. But until there is one, my recommendation for customers of companies that do this would be to avoid their cloud-based applications for the same reason I would run, not walk away from Intuit’s.
So how do you know if your No-software salesman is lying? Well, I guess you don’t. But if he used to work as a software salesman, shouldn’t you at least check what he says?
The Applicator 