% fortune -ae paul murphy

Judging a POD opportunity

Yesterday I described what our nearly completed Sun Pod would cost and laid out an e-commerce technology refreshmeant scenario for discussion as an implementation opportunity.

The bottom line on the opportunity looks simple: just upgrading what's there to current Microsoft software on Xeon would cost somewhat more than $70,000. Replacing everything with a fully loaded POD would cost less than $60,000.

Seems like a no-brainer, except that I've left out most of the important stuff from a decision making perspective.

Right now the people in place know, or think they know, how to run a Windows based applications cluster that meets the current state of the original corporate business requirement. Give those same people a newly installed Java applicationn that runs on Solaris and the time it takes for costs to get out of hand while performance and reliability decline will be a direct function of quickly they learn to over ride role assignments and gain root access to the servers.

In other words it would be somewhat irresponsible to simply sell this as a system in place and then walk away - but most customer IT staffs in this position wouldn't be interested in a hosted solution and the budget generally wouldn't be there for continual on-site operational support.

There seem to be two solutions open to us - three if you count simply telling them that upgrading to Windows/XP 2003 server will be their minimal hassle solution and thus declining to bid on working with them.

The first solution isn't something a small consultancy or a Unix group within an organization can pull off - it requires marketing and support from Sun or a fairly big ISV. The approach there is packaging: offer the pod and its software in the guise of an e-commerce appliance: combining custom configuration with remote management and a gradual transition of control to the customer's own IT staff.

The appliance approach works - it's what drove business Linux adoption in the 90s. Basically you set it up right, charge the customer a monthly support fee for keeping it running, and don't let the locals have the root access needed to get it to fail. Cool, but of course when Linux became more widely used a lot of instant experts configured their own appliances just so they could have that control and the appliance business largely died - dragging Sun's investment in Cobalt with it.

For a bigger system, like this one, you would need to couch the offer in terms of risk management and risk reduction: basically find a way to make this as nearly risk free as possible to the customer while tying internal IT management to its success rather than its failure.

Since the overwhelming majority of internal opposition to IT change always expresses itself as systems mis-managment, I generally like to propose doing the entire thing on hardware we own (and operate) and giving the customer the choice of buying it in place only after a fairly long -four to six months- acceptance period or turfing us out. That lets us present the thing outside IT as relatively risk free, lets us talk about offering training and "knowledge transfer" for internal IT staff, and nicely positions the internal IT folks to sabotage themselves instead of us -because when they take over, user management will know that it works reliably and be fully briefed on what to ask when it starts to fail.

The other alternative, of course, is to talk to business management directly in terms of what they aren't doing and present the pod solution as what it really is: the basis for significant business change in that e-commerce operation. In other words we tell them it's a $60K pod that requires them to hire an $85K guru we'll help them find and recruit and then talk about cost recovery through business benefits arising from the technology - things like software flexibility and unique Niagara features like hardware accellerated SSL encryption.

That way we sell ourselves as standing shoulder to shoulder with the IT director in getting his budget and span of control increased, the Windows people babysitting the cluster go do something else with the gear and the time we're freeing up for them, and business management gets an obstacle to change out of the way.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.