Jiri’s Notepad

Interesting to watch the dynamics and personal and corporate preferences towards buying a system off the shelf and getting something that is cheap and cheerful versus developing your own and ending up with something that is just right for your needs, but costs you more.

The first viewpoint from Philip Windley’s excellent essay on strategic planning and tactical deployment:

Of course, the problem with the SVP of Sales just ordering in Salesforce.com over lunch is that while the deployment is easy, the planning isn’t there. How will the on-demand sales automation application integrate with other enterprise processes? Well, the SVP of Sales probably doesnt careshe just wants her team to be more productive tomorrow instead of next year. But, pushed to its extreme, you end up with a hodgepodge of automated business processes that don’t work together.

Enterprise applications like SAP, PeopleSoft, or Siebel, on the other hand, are strategic in nature. To deploy one, you have to plan (a lot), budget, initiate a project, and assign people. If you’re successful (and I stress if), you will have automated major parts of your business, cut your operations costs, and increased your ability to monitor your critical business processes. On the other hand, you may have also just set in stone the business process that the SVP of Sales will want to change the week after the project ends. Most enterprise applications installations are so painful that the last thing you want to do once its over is change anything.

And the second one, a diatribe from Jonathan Schwartz (which is conveniently skewed towards Sun’s products, but good anyway):

I was recently with a customer in the retail industry that continues to run its own private Linux distribution. The distro was developed a couple years ago, by a team that stepped off the beaten path for good reason (at the time) - that same development team now owns maintaining the distro, and making decisions about whether to replace it. As time has moved on, the customer has found no major ISV willing to certify to their private distro (without a check, that is - we declined the opportunity to port our Identity engines), and the team involved has found themselves buried with support obligations - driving more resource requirements while the parent company is looking to prune costs. I’ve seen a number of companies in this predicament (a few on Wall Street, btw).

My view, in this instance, is the “private distro” mud path should be paved with a commercial product, on the assumption Sun, Red Hat or Microsoft will all outinvest and outsupport the dedicated team - and bring with them a bevy of already certified ISV’s. But neither the team, nor their management, will hear any of this. “Our OS costs less than Solaris, it’s free.” Right, free like a puppy.

Consider another example - a packaged goods company deploying a large scale enterprise application, that failed to resist the tempation to customize their implementation. Their customization looked convenient (the end users will get “exactly what they want”) - but such customization actually ends up creating bad hair days for CIO’s (and CFO’s) that linger for years. As with the custom distro, a custom SAP or Siebel or Amdocs deployment is vastly more expensive to support than a “standard” off the shelf implementation. The short cut, even paved over with a “commercial off the shelf” product, stays pretty muddy.

The decision on this matter is not easy as there are situations in which it is desirable to go custom-build way, and others in which off-the-shelf is a clear preference. The tricky bit is that what essentially a question of TCO is touching some deeply hidden cultural preferences and tends to escalate into holy wars.