• Steve Jones - Editor (4/13/2009)


    roger.plowman (4/13/2009)


    Data in the cloud? Are you *NUTS*???

    Salesforce.com (and similar entities)

    Lots of online payroll companies.

    It can, and is working. For every system no, but it does make sense in places.

    There is quite a bit of misunderstanding about "cloud" computing. I feel compelled to dispel a few myths and add some of my own thoughts here:

    1. Cloud computing will never be cheaper than local hosting. The pay scale must of necessity pay for the equipment it runs on. Far too many have been duped into thinking otherwise. Payroll, lead management, and all other segments fall into this. The only types of tasks/needs saved by centralization are those that are highly regulated, and serve less brain damage to let someone else handle it. Note: I say again - this does not make it cheaper.

    2. There is an assumption that one can put their particular need in the hands of an expert who deals with many of the same types of needs for many others, and all gain orders of magnitude of savings. This is patently misguided. No entity is more responsible for the need or service than the organization that owns it and must remain stable with it. Outsource and cloud companies do as little as possible for price, and levels of complexity are added to administer outsourced projects. Personnel counts do not diminish; they are only somewhat transferred and cost more.

    3. MS SQL Server is currently nowhere near cloud capable for any enterprise situation. At this time it is really only positioned for web-facing lookup DBMS, order capture systems, and other thin-client needs. Cloud MS SQL is not even close to being able to house Marketing Databases, analytics, major BI processing, and etcetera. There is no way that in two years that business as a whole will lean on the cloud first. New, un-learned businesses maybe... but they will pay a painful price.

    4. Using examples such as Salesforce.com and Payroll processing, without examples to prove validity and cost savings, shows only that many are excited about the ideas, but do not really pay attention to TCO. Having experience with both, I can quantifiably testify against and refute any that claim that they are either better and/or cheaper alternatives. In some cases it is merely less brain damage to a company to not have to "get up and running", but cost far more long term as roadblocks and customization take toll on the TCO bottom line. Do they work? Yes. Can they be made to work for your specific enterprise? Yes - for a price. I have seen companies pay 3 times as much as what it would have cost them to host and man locally their own process or need, but due to tailored marketing to execs that are lacking in IT knowledge, and to all the hype in-tow, bought in.

    5. The internet is not nearly fast enough for most enterprise back-office needs.

    Other points to ponder:

    - Most here would agree that a poor foundational design can ultimately cost 10 times (and more) what building it right the first time would have cost, if it doesn't kill the business. Why then would one just hand that much potential future over to some wispy vaporware system? If a business does not like it after 1, 2, or 3 years, it bites to be you because it is not that easy to extract a business from such an extension.

    - I believe that most on this forum would also agree that a process or system designed specifically for a need is far more stable, speedier, and maintainable, than a solution that tries to be all things to all needs. The IT industry as a whole keeps ping-ponging between the poles of centralized processing, and distributed processing. Terminal services threatened to change the desktop into thin ware, much as the old dead-terminal-on-mainframe days. The problem is, mainframes and widely centralized processing equipment cannot be maintained at the same rate as distributed processing can, and the cost is prohibitive. So the pendulum keeps swinging, and we keep learning the lessons over and over.

    - A company must be responsible and accountable for its own data and processes. Too many execs hand it over expecting things to "just work as advertised", and then blame "unforeseen" issues on project failures. The problem is, whose responsibility was it to foresee in the first place? How does this happen? Execs usually trust the sales pitch in an outsource offer, but the legal jargon in the actual agreement keeps them from reclaiming damages, and also, from leaving early (short of bankruptcy).

    RDBMS as a whole are still deeply in the realm of local management, and likely will still be so in 5 to 10 years... and it still won't be cheaper.