Home Page
Langenbergs Laws
Manifesto
13 Commandments
Satellite Radio
Resume
Business Card
Feedback Form
Pictures Menu
To Hosting Site >
To Search Site >
To Network Info >
Links
Les Schwab
Site Map
Manifesto
The Chuck Langenberg Manifesto -- Version 1.94
An Exit Strategy from Technology Providers
Last Updated: Tue-Sep-25-2007 @ 09:00 PM PDT
Introduction:
I see lots of similarities between the Internet today, and the prior 25 years of the information age. This manifesto takes into account my experience as a computer store manager, data processing manager, Internet service provider and webmaster.
 
My suggestions herein are most heavily drawn from my data processing manager era -- for 15 years -- at the same company. I think it's important that I emphasize this at the outset as my perspective. Because as the architectural decision maker, buyer and implementer -- my customers (i.e. users) and I lived with the benefits and consequences of my decisions -- for many years. I didn't use architectures that were chosen by someone else. And I didn't change jobs every five years -- leaving others to deal with my legacy. I slept in the beds I made. So with that as my intention, I made them a lot differently.

I think it's pertinent to point out that I was fired from the corporate world in 1996, shortly after the introduction of Windows 95 rev zero. So I have never supported that chaotic platform in a corporate environment. My IT experience is based on an extremely stable Novell LAN, and my authoritarian control over an even more stable HP-3000 mainframe. While this doesn't reflect current IT products, I believe what I have to say is just as applicable to today's environment.
 
Overview:
What follows is my advice on how to benefit from the offerings of technology providers, while keeping the steadfast control of a tight leash, and making each individual technology provider expendable with a simple broom sweep.
 
Form vs. Substance; Take what you Want, Leave what you Don't:
Two people recently opined that it sounds like this manifesto was written by an angry person. They're right, I am angry -- at not only unstable products, but the vendors who cash in on them, and even more-so at the many technical vendors who's number one objective so often is to lock you into their offerings.
 
Incidently, when I questioned those two people what the point of this manifesto was, neither of them had any recollection that it's "An Exit Strategy from Technology Providers". I think the reason they missed the main point, was because they were focusing on form rather than substance -- not what was said, but how it was said. My response was to thank them for their input -- but the teeth will remain in this manifesto. Because that's just the kind a guy I am.
 
Onward:
I will now provide my personal perspective on the history of the past two generations of computer hardware and software. Then I'll elaborate on how I think lessons learned during that timeframe can prepare us for the future.
 
Brief History Lesson:
It's a fact of life that technology providers come and go. Hot today, gone tomorrow. A lot of big fish, with big revenues and big attitudes, have left big skid marks as they slid down the slippery slope. And they all had certain things in common -- lots of momentum, lots of overhead, and the inability to maintain quality while keeping up with the ever changing pace of technology. So when the landscape changed right in front of everyone's eyes -- they couldn't alter their courses quickly enough to save themselves. That's right, the whole world knew about it -- they knew it, the trade rags knew it & their lowly customers knew it. But they bit the big one anyway. It's a fact.
 
I watched the mainframe computer companies disappear as they lost their market share to the minicomputers. Then most of the mini companies went belly up as toy microcomputers took over their turf. In both of these situations the giants were outnumbered from below -- by smaller fish -- who were more agile, responsive and aggressive. And less expensive -- with shorter commitment cycles. Most importantly though, from the perspective of customers, these little fish had better attitudes. These days it appears as though history is repeating itself again -- with the advent of Internet based Application Service Providers (ASPs).
 
Remember Sperry, Burroughs, Honeywell, DEC, Data General, Wang and NCR? And the list goes on. And what about the hundreds of software companies that had their horses hitched to the wagons of those hardware giants -- and their proprietary operating environments? Gone -- for all practical purposes -- gone. And t
he bigger they were, the harder they fell, and the more partners (or whatever they demand to be called) they took with them.
 
Loyalty:
And
on their way down the toilet, do you think any of these technology providers gave a rip about their loyal customers? NooOOoo -- they had their own skin to look out for. It was the same deal with both hardware as well as software vendors. And with big fish as well as their little small-fish, wet-nosed, whipping-boys. (Note: Small-fish, wet-nosed, whipping-boys are spineless vendors who graciously hoop jump to the satisfaction of big fish. And if you can't see the dollar signs, spewing out of their mouth every time they open it, then I think you may be a bit naive (that's as diplomatic as I get). And for this loyalty they receive a poor quality third generation fax with a little gold sticker inside a frame (purchased at the Dollar Store on the way to work that morning) after becoming deemed worthy of the title authorized, partner, affiliate, associate & other similar sounding US$20 terms which bestows forced reverence, honor, attribution, love, admiration, loyalty & in general just an overall sense of importance to the ego (and the bottom line) of the big fish. After that, the little fish is not only entitled, but required to locate the big fish's authorized logo on their business cards, stationary, advertisements, storefront & at the bottom of their homepage -- prominently displayed in such a way that no more stature would be afforded any other logo which may regretfully be present -- including your logo -- that's right, they think they own your business, and they sort of do, because you did sign their agreement (and if you don't believe me, re-read it, that's your signature at the bottom pal). The logo requires adequate pixel spacing between it and any other logos -- as defined by & in the sole opinion of the big fish -- the terms of which are subject to change without notice & become immediately binding. Failure to comply with all terms will result in a fine of no less that US$1000, half the distance to the goal, and a 3 month probationary period after which time, notarized proof of mandatory sensitivity training & kow-towing must be presented -- along with a renewed acceptance to all of the latest legal agreements including an ever longer list of companies you can't deal with for a "long" time (beginning with all of their perceived competitors) in order to comply with the big fish's exclusivity requirements -- all signed by a duly anointed little wet-nose whipping-boy trainer in good standing, who's also been certified & authorized by the big fish. (If it's any consolation, the trainers subject themselves to 10 times as much crap -- which ought to help explain why they're such potato-heads). The trainer must consistently meet quota, religiously spout the big fish's party line and your exorbitant fees to them must be paid in full. All training, a new set of obsolete & overpriced training materials (whether or not you need them or want them), examinations, hoop jumps, fingerprints, urine tests, retinal scans, suck ups, the latest generation new-world-order implant in the back of your neck & any other such demeaning acts must be re-inflicted -- the fees for which are to be paid in advance by the little fish -- and never mind certified checks or wire transfers -- because these days they demand that you allow them direct debit access to your checking account. But don't worry, they won't take any more than they need. This all sounded pretty good to start with, because they were going to direct deposit money right into your account -- and save on all that nasty paperwork. But then there is that simple clause which allows them to pull funds directly from you too. So in the spirit of good faith (and since you rally had no choice anyway) you signed it. The fees are very important. Don't forget the fees. Because any other slipups after this point will result in permanent termination, tar & feathering and forced sterilization by an off-shore veterinarian. And that's if they're in a good mood that day. So like I said, don't forget the fees. (LL35 (Proper attribution to Les Schwab's book Pride in Performance for inspiring this paragraph in red. You won't see any Firestone or Michelin signs in front of his tire stores -- or any clutter on my homepage for that matter. But I digress.))
I'm back. Anyway, I've seen dozens of technical companies take the ungraceful slide down the the slippery slope -- and I've come to the conclusion that only chump customers are loyal to technology providers. And even more-so for any providers that were loyal to larger fish. I mean these guys come and go about as often as you get a haircut. And they're saying, "Depend on us?"
 
And I say, "Fine, depend on them, but have an exit strategy."
 
All Locked In and Nowhere to Go:
To add insult to injury, technology providers try to lock you in. And they say, "Don't worry, we'll always be here to serve you. And hey, our profits have increased for two whole consecutive quarters." And life is good -- right up to the point that another gold rush comes along -- at which point they'll begone -- off pushing the next generation gizmo -- which catches mice twice as fast, for half as much. Then they scoff at that the dusty old architecture that you're using (which they sold you). And they say it isn't fun anymore. But you're stuck with it -- for a few more years. And your check's long since been cashed, so you have no leverage. And it's hard. And when you dust off the contract, you may find that it's no longer effective because of a bankruptcy. Or mergers and acquisitions which so commonly occur as drowning companies start grabbing onto each other as they're going down for the count. And guess what? That's the good news. Because there's one more little bitty issue -- they've still got you hooked. It gets worse -- because they don't even want anything to do with you any more. How bad is that -- hooked by somebody who doesn't want anything to do with you. And at that point there isn't enough money in the world to get their attention. But if you're persistent enough to find a phone number that gets through to them, and if you call them up, they look at their caller ID, and they see it's you, and you get voicemail, which they don't return, of course. After a while you'll get the idea -- you're on your own. Deal with it.
 
And here's the part that really gets me -- on their way down the slippery slope do they once think to throw you the keys (such as login documentation, a clear path to self sufficiency, and 100.0% source code) that would free you of their shackles? Nada. They hang you out to dry, baby. Intentionally and without any sense of guilt. Off to hook new chumps in a new arena. Such is the shameful unrepentant life of technology providers -- with less scruples than a pet rock.
 
But fortunately and ironically -- the majority of their little customers survive. Even though most of them are dwarfed in size by these flash-in-the-pan technology giants -- who's products and full page ads are, by now, buried layers deep in forgotten landfills. But their (ex) customers are a little older, and a little wiser, and life goes on. Yup.
 
History Repeats Itself:
The point is -- history repeats itself. And I predict that it's going to be the same thing all over again with the current technology kingpins; Microsoft, Oracle, Amazon, AOL, Yahoo and Google. Along with a whole lot of Internet companies. Yeah sure, they look invincible today. But trust me, they'll begone tomorrow. It's just a matter of time. But you, and I, and Boeing, and the nationwide chain of 7-11 stores will still be here (for now), too busy to mourn the passing of yet another generation of technology wannabes playing king of the mountain. Primarily there are two kinds of technology companies who are going to bite the big one; those with attitudes, and those without. And you can take that to the bank.
 
Now that my history rant is over, and now that you're all agitated, I'll discuss how to get ready for the inevitable, how to minimize disruptions -- and how to proactively prepare an exit strategy from your technology providers.
 
The Natural Order:
Generally you will be pleased when you start using products and services from technology providers. And you will like all of the things they are doing for you. But as sure as the sun will rise tomorrow, you will eventually come to dislike what they are not doing for you, or what they are doing to you. One day you will notice that your competitor has capabilities that you can not offer because of your technology provider. Eventually you will come to realize that the only way you will be able to obtain this new functionality is to jump ship, or sail two ships. No hard feelings Pal, this is just the natural order. Really! This is just the way it is!
 
Now to be fair, there are rare occurrences of technology providers who have survived changes in the landscape (so far) by reinventing themselves. A few have even prospered in the process. A couple of current (read my lips, current) examples are IBM and HP. Nonetheless, the customers who adopted their legacy products still ended up eating them. For example; IBM 360/370's, 34/36/38's and HP 42, 48 & 68's. But from a customer's standpoint so what if IBM and HP are still alive? What's that do for you? The point remains; every technology provider and every generation of technology that you buy into will someday become obsolete. You bought it -- and you're going to eat it. It's just a matter of time. That's the way it's always been with technology -- where rock hopping is a fact of life. I'm not sure if that's the way it's always going to be or not. But considering how long it's been that way, doesn't it just make sense to hedge your bets?
 
The Solution:
Any problems though, can be greatly minimized if you plan an exit strategy from the get-go. And constantly reassess it. The trick is choosing which wagons you hitch your horse to, which wagons you don't hitch your horse to, how you hitch it, when you hitch it, and when you unhitch it. As long as you have to eat obsolete products, why not do it on your terms and on your time table? And why not do it with minimal impact to yourself and your company?
 
Every technology provider has one or more strong suits. That’s why you’re looking at them, right? But none of them can perform every function that your business needs. And the more modules that you select from a single provider, the more likely it is that one or more of these modules will be weak. In fact, some modules may be so weak that your ability to compete may be hindered by using them.

 
In addition, technology providers are constantly improving, evolving and expanding their product line to fill in the holes. So what they don’t offer today, they may have tomorrow -- but then again don't count on it. After we consider their less than stellar batting averages on product delivery promises -- we get to guess whether or not we think such products will be worth waiting for. And sometimes we have to go for the sure thing -- and buy into a module today -- from another technology provider. After that, as they say at the Olympics, "Let the games begin". Because no matter what you do (or don't do), sooner or later you will be forced to interface modules from multiple providers in order to fill in the holes. Plan on it. Plan for it.
 
Modules:
So now the question is; what is a module and how is it defined? And my definition would be; it’s different in every technology era -- although the concepts are the same. A module is hardware, software, services, and a million other technological wrinkles that you use in your business. I would also define a module as your onramp ISP, your web hoster, webmaster, ECommerce provider, EMail provider, application service providers (ASP), DNS provider, domain name registrar, and so on. A module is anybody that you write a check to -- and indirectly anybody that they write a check to. I would even go so far as to define modules as your employees, yourself, and myself. In summary, a module is anything or anyone that you have put your business into the position of depending on.

 
Striving for Perfection:
If there is such a thing as a perfect solution, then I believe it’s the one that you arrive at yourself -- and which you feel best suits your business. Not what the Jones' are using. Not what's on sale this week. And not the latest fad that the experts in the trade rags are hyping and selling editorial about. I would not define the perfect solution as a single solution -- but rather, a group of modules from multiple providers -- for which you have clearly defined the functions to be performed by each -- interfaced together with cleanly delineated lines. And most importantly, I define the perfect overall solution as a situation where each individual technology module is straight forwardly replaceable when it becomes obsolete.
 
Ergo, the first order of business is to look for modules that are designed to be cleanly interfaced to. This can be a real challenge since most of the time there are no standards on interfacing technology modules with one another. In fact, if a particular field has stable standards, then maybe you should ask yourself if you even define that field as technology at all.
 
In addition, some vendors (or employees) implement subsets or supersets of standards -- sometimes intentionally -- sometimes without any consideration to the big picture -- and sometimes clueless to the concept of a big picture. At any rate, I would immediately dismiss any module which does not provide interface mechanisms to complimentary modules from various module providers -- including their competitors.
 
The Hook:
When choosing modules remember Langenberg's 2nd Law; Look for the hook and you won't get took. Hooks are a fact of life -- especially where technology is involved. And if you don't find them, they will most certainly find you. And hooks don't exactly jump out at you and identify themselves saying, "Hi, I'm a hook!". No indeed -- the most effective hooks are camouflaged as tasty lollypops. So I would stay on guard for any module that feels like it was designed to lock you in, shackle you or limit your options (especially your exit strategy from them). Because if it feels like it was designed that way, it probably was. I mean you don't really think marketing folks overlook issues this obvious, do you? Of course not -- but often they're hoping that you or your profit minded, convenience oriented supervisor will overlook it. And the odds of you taking the bait are increased if they make it con
venient -- and tasty.
 
With products like this, things are not likely to get any better with such a provider as time goes on either. So while you will eventually 86 every module that you ever implement -- you’ll be singing, Ding Dong The Witch Is Dead when you bag and tag this one. On the other hand, perhaps a little milking by a provider is acceptable. It's your call -- you're the customer. But my contention is that it's time to draw the line when a module, or bundle of modules (ah yes, the bundle) seem like they're being intentionally manipulated to lock you in, and inhibit your exit strategy.
 
So let's stay on guard for any module that thinks the world revolves around it, wants to increasingly dig it's meat hooks into your entire operation, or makes you feel like an owned resource. The key is to look at each module -- and try to envision what life will be like once it's replaced. If it's going to be a tough transition, then one of two things is true; either the module (hardware, software, service or person) has unacceptable hooks into you, or you have not planned an exit strategy. Either way, you're really setting yourself up for the big one. It's just a matter of when, not if.
 
Modularity and Clean Lines:
Suppose you are considering modules A, B and C -- all from different technology providers, and all of which work in unison to perform complimentary functions -- with love, harmony and peace on Earth. Stopping there would be taking the easy way out. Why not prove out your exit strategy? Look for additional modules that would interchangeably replace each of these -- but still cleanly interface to your other currently selected modules. Try to keep the interface lines between your existing modules as black and white as possible. Consider splitting one module into two, or combining two modules. Just make sure that you end up with replaceable chunklettes, and that each module is individually replaceable in preparation for it's certain eventual disposal. By the way, don't worry if a replacement module doesn't exist today. Just envision and implement modules in such a way whereby replacements can and should be designed. Because if it can and should be designed that way, have faith that Mother Capitalism will eventually make this building block available.
 
And Then Come the Changes:
You know what they say, "the only thing constant is change". And this was never more true than with technology modules. So what I'm saying is that by being proactive -- you can avoid disrupting your entire organization every time one of your modules changes. Why not be in a position to individually swap out each obsolete module? Langenberg's 87th Law applies here; Pay me now -- or pay me later. And to pull this off you definitely have to pay as you go -- and consider how each improved module will affect your overall exit strategy from every other module.
 
Once you have your modules selected and implemented -- the changes will come. It’s never over. Each change will include new features. Rather than blindly implementing each change, ask yourself, “Is this a feature, or a hook? If I take advantage of it, will my exit strategy be inhibited? If so, is this feature so good that I should redefine the lines between my existing modules? Should I combine two modules into one? Split one module into two? Can I still use this updated module without deploying some of the new features? Is there a way to implement this feature that won't leave you hooked? Or is the module provider
forcing their features on you whether you want them or not?
 
Some upgrades may feel heavy-handed -- intended hook you deeper and blur the lines between your existing modules. Even worse, some module providers will do this to you while adding little or no value to anybody but themselves -- and their (current and future) revenue stream. In such a case, if a new feature inhibits your exit strategy, it might be fair to at least consider that it was intentionally planted there -- often by marketing people in an attempt to tighten their grip on you know what, further hooking you into their products. And while you may not be a soothsayer, you can count on the fact that the bubble's ripe for bursting when more and more of their features lack any technical merit. And you can take that to the bank. Their bank. If forced features without technical merit is the case, their next change (or upgrade) will almost certainly try even harder to hook you even deeper. At that point it's a fair bet that the pube-grabbers have taken over the operation -- and the top priority of their every decision is to lock you in and keep milking you. From which point forward, your service won't go up & your price won't come down. They would deny it of course, but you weren't born yesterday. So at this point it may be time to find a module from somebody else -- and get out from underneath this provider's thumb altogether. It's best to avoid getting splashed by the residue of any bursting bubbles. But hopefully your clueless competitors will.
 
To summarize this section; since technology modules are constantly evolving, it might be wise to continually re-evaluate the interface lines between them. The focus being to continually re-access and/or re-define your exit strategy from each individual module.
 
Everything's Temporary:
To some degree, once you buy into a module you have to play the hand you're dealt -- for a while anyway. But smart gamblers intentionally and proactively locate themselves in a position where they can move to another poker table -- with minimal hardship. A smart gambler doesn't commit in advance to sitting in the first con
venient chair all evening (e.g. long term contracts). A smart gambler can leave the saloon when they want -- and immediately ride their horse down the street -- or to another town. Why? Because before they entered the saloon in the first place -- they made sure that their horse was fed, watered and not fenced in -- even if, for insurance purposes, they knew that there was a reasonable chance that they may be going to unload that horse. A smart gambler understands the concept of blinders -- that they're OK for horses and other lesser forms of life. But a smart gambler never personally wears blinders. Perhaps a smart gambler only plays with a stacked deck.
 
Cover Your Butt:
Now then, no matter how you deal with the people who authorize or write the checks, sooner or later somebody's going to start micromanaging your purchase decisions -- because they're in the loop of the money, and they're going to make their presence known. Count on it. Maybe they'll wonder why you wanted to feed & water a horse that you unloaded the next day.
 
Trying to reason with a non-technical bureaucrat, that this was insurance against a replacement not arriving (or something like that) is completely futile, trust me on that one. And a bean counter (executive or accountant) is always, always, always going to choose the least expensive option -- which means you're going to get hosed and be working overtime. But I always had to have a contingency plan, I was always going to cover my butt, no matter what, downtime was not an option.
 
Before proceeding, I recommend that you review Langenberg's 27th thru 33rd Laws. If you are reading this, I hope you are covered by the 28th Law, and I pray not the 29th Law.
 
So what I learned over the years, and what worked the very best for me, was to keep the bean counters dumb. The less they knew, the less they had to complain about. And the more you tell them, the more ammunition you give them. (keeping in mind that I worked for a pretty informal, but fairly political company, which was not in a highly secure or government environment.)
 
First of all, the bean counters are only going to find out about it half the time. But they'll feel completely entitled to be twice as mad about it. So you think, well 50%, that's not good, but it's actually better than that. Because half the time you'll have made the right decision in the first place, which saved the company time & money. So now it's down to only 25% of the time, that you'll have to deal with their double rage. These are not scientific numbers of course, and maybe you'll be better able to predict ship dates & the quality of undeveloped products. And I sure do admire you if you can.
 
This can be improved on by tarnishing their technical credibility (remember you're the one that's going to be working overtime dealing with any short sighted decisions, and the only thing they usually know is what you were dumb enough to tell them). Maybe they'll discover something and complain loudly, but it turns out in their own favor, or in favor of an executive. Eventually, as your reputation for uptime nears 100%, they'll stop questioning every purchase, but it will never go away completely.
 
One Provider vs. Many -- Integrated vs. Interfaced:
The more modules that you acquire from a single provider, the more likely it is that your overall system will be more integrated and easier to implement -- but the tougher it's going to be to get out from underneath one or more of these modules when the provider takes the slide down the slippery slope.
 
Conversely, the more providers that you introduce into the fray, the more up-front (and ongoing) effort it will require on your behalf to interface these modules together.
 
Now I'm going to take a moment here, to point out, that I've used these two words many times, integrated and interfaced. And I've taken great care, in the way I've used them.
 
Integrated modules from a single provider typically fit together more con
veniently. Whereas it is generally more difficult to get (and keep) interfaced modules talking to each other -- because they are from multiple providers. But hey, you're the customer, so it's your call. Isn't this fun?
 
But the buck has to stop somewhere. And somebody has to decide whether to grab for each con
venient lollypop or pick and choose -- with your exit strategy high on the list of considerations. If you're that person, making these decisions will be easier once you consider that your business will almost certainly outlive each of your temporary technology providers.
 
But once everything's been considered, in my opinion, you really have no choice but to interface modules from multiple providers.
 
Band-Aids, Lollypops & Isolated Islands of Automation:
There will be times when it is not possible to find a module that interfaces adequately with your overall system. In other words, for a while (possibly a long while) somebody may have to perform a function which isn't interfaced or integrated, but ought to be. You may find yourself in a position where -- in order to provide some short term gain -- you need to introduce a temporary island of automation -- and crudely attach it to the other modules with a band-aid. At least until a better fitting module comes along which does interface.
 
It is important to replace all temporarily band-aided modules ASAP. Because the longer you keep them around, the more inclined (and pressured) you will be to interface them into the mainstream -- in any way possible -- shortcuts included. If you use band-aided modules long enough, people are likely to forget (sometimes conveniently) that they were only intended to be temporary. Ergo, if you don't eliminate the band-aids -- your overall architecture, over time, will consist of multiple lollypops crudely grafted together. In this case your numerous short term gains will at some point collectively turn into a big heavy long term boat anchor hanging around your neck. And at that point all those shortcuts won't be going away very easily. In fact you may be the one going away if you're responsible for introducing this sort of prolonged chaos. So from an up-front proactive point of view, "Pay me now, or pay me later".
 
Application Service Providers (ASPs):
As of the last update to this document (listed above) the pendulum appears to be swinging in a new direction -- that of Internet based Application Service Providers (ASPs). My guess is that this really may be some sort of a trend. But at this point, nobody really knows for sure -- other than a handful of sure-fire ex-Data General salesmen who have been laid off a handful of times by Dot-Bomb companies.
 
If the current ASP trend really does take off though, you will be purchasing less in-house hardware and software -- and more outside services. But keep in mind that modules are modules -- whether they be hardware, software, services, people, or any other technological wrinkle or fad. And since modules are something or someone that you must depend on -- and since they're all going away someday -- it's just as important to have an exit strategy from each service as it is for hardware, software or people. So let's keep our guard up -- just in case some of your future ASPs went out and hired the marketing dirt-bags from a Dot-Bomb Internet company, who got them from a failed minicomputer company, before previously working for a failed mainframe company.
 
Gaining a Competitive Edge -- Let George Do It:
Learn about the technology modules that your competitors have implemented. Find out about any high priced or long term technology stakes that they have they driven into the ground. What holes have they dug that will inhibit their exit strategy? Have they blindly painted themselves into a corner? Discover what functionality they can't take advantage of because they couldn't resist schlepping into some of those tasty con
venient lollypops. Then of course, don't make that type of mistake yourself.
 
Summary:
It requires a lot of discipline to maintain an exit strategy from technology providers -- involving the (occasional or frequent) choice between sacrifice and sin. So rather than just blindly stepping on every land mine planted by marketing people, you might want to recognize some features for what they are -- hooks. Then even if you recognize them as such, the next question is, does it add any real value to your operation -- or is this a solution to a problem you don't have? Is this a solution that will create more problems than it solves? And if so, remember Langenberg's 4th Law; What you don't do is more important than what you do do.
 
Regards,
Chuck Langenberg

 
PS: Your comments are encouraged.
 
Related Articles From The Web:
ZDNet -- Web services -- Look before you leap
ZDNet -- Outsourcing Do's & Don'ts
InfoWorld -- Most companies unfit to manage outsourcers
ZDNet -- Second Source, Not Open Source, Is The Key
InfoWorld -- The Top 20 IT Mistakes to Avoid
Sys-Con France -- i-Technology Viewpoint: The New Paradigm of IT Buying
ZDNet -- Gates: We're Entering Live Era of Software
InfoWorld -- Easing app deployment with an open source sandbox
InfoWorld -- OpenAJAX Forges Ahead
InfoWorld -- Agile scripting: Bigger bang for app-dev bucks
InfoWorld -- SaaS Will Make Fat Clients Thin
InfoWorld -- Google buys JotSpot
InfoWorld -- Google Apps upgrade threatens Office
InfoWorld -- CEO: 'Salesforce.com 2.0' to take on Microsoft
 
 
TM & © 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 & 2007
Chuck Langenberg -- All rights reserved.