Technology Accountability

Does financial pressure leave you wondering during software license negotiations: What would Winona Ryder do?

December 16, 2002

3 Min Read
NetworkComputing logo in a gray background | NetworkComputing

When you buy patch-management software, does management wryly ask what happens when you need to patch that? Have vendor promises become as empty as the 401(k) plan of ? Does financial pressure leave you wondering during software license negotiations: What would Winona Ryder do?

We live in an era of accountability, born of the grand but unrealistic goals that are now part of turn-of-the-century lore. No need to repeat them here. Most of these circumspect projects, launched without IT input, buy-in or support, have fallen back into our laps with unceremonious blame.

Accountability as blame and albatross is as old as the stern lecture from your father and as new as the one your CFO delivers. Why not accountability as a badge of honor, to be worn in the face of those who thought they knew better, and shoved up the backsides of those who didn't but went right ahead anyway? Or perhaps, as I'm about to explain, accountability as a duty simply to do things right?

Technology accountability is built on four pillars: the reliability and scalability of the technology; the ease of its integration; the viability of its vendor; and its business justification.

The first two are staples. Network Computing has spent the past 12 years evaluating the capabilities of technology, testing how well it scales to meet the demands of your customers, how it withstands the test of time (far beyond a few well-intentioned packet blasts in the lab), and how well it can co-exist with and leverage your other systems and applications.Arguably, integration is the stuff you figure out after you're stuck with the goods, some six months past your rollout milestone and six figures into the consultant. We all know where the blame will rest, so now we ask questions first: Are my servers and storage properly sized, databases tuned, networks architected?

Vendor viability and business value are not the typical playgrounds of the technology-inclined, but suddenly we're being asked to justify the damn stuff. Business value refers to how technology can enhance the way an organization does business, thinks about new business processes or collapses existing ones.

To wit: Despite the sales pitch, voice over IP ultimately isn't about efficiencies squeezed from smaller staff and a consolidated infrastructure, but about what you can do with a converged network. Spare us the phone-number portability crap. That's a cute trick, but it's hardly going to make our customers better salespeople/HR managers/financial planners. Tell us about tying the system into customer data--and then we'll listen.

This discussion must go hand-in-hand with an honest evaluation of what it will take to get there--the hidden costs, deployment time, impact. Talk of value is nice, and vendors blabber about it endlessly, but let's not mistake promise for achievement.

Speaking of which, it's nice that innovation still happens, but your shops are probably littered with technology from long-gone companies. Don't shun the little guy, but ask them tougher questions the VCs giving them a third round (!) of funding might ask. Demand that even established players be easy to do business with, offering solid service and support and a long-term vision to match yours. Since you're held accountable for the technology you buy, make it their duty to be accountable to you.Now go rest your weary head upon these pillars.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights