Regarding recommendations from people who haven’t taken the time to understand your business, be advised that prescription without proper diagnosis is malpractice. Beware of promoters using trendy buzzwords. Also be skeptical of vendors who “sell high,” pushing for business execs to mandate massive technology purchases. The goal of those who over-promise and under-deliver is to avoid close scrutiny, a common practice of those selling alleged mainframe alternatives.
Responsible mainframe executives should resist management-by-magazine and beware of not-so-whitepapers that tout the merits of in-vogue technology. To help you make the right choices, here are four points to consider for your sanity checklist:
1. Measure the business value of IT. Anything not measured is not managed, and value isn’t always determined by the lowest cost. If quality is defined as doing things right, value can be defined as doing the right things. Successful companies develop and refine their own measures for business task productivity within their IT architecture, which is complete with technology standards.
Quantify the overall economic value to the business when expanding IT capabilities. One car-rental company with 1,200 telephone agents calculated it could annually save $400,000 for each second shaved from the average time to book a call-in reservation. Similarly, a credit-card firm justified the investment to add parallel computers to their arsenal because they reduced the run-time for a critical application from several days to several minutes, allowing the company to expand its direct-marketing efforts.
Properly applied technology is much more than a simple ROI issue, as it can open up new business opportunities. Where use of systems, especially large ones, appears to be qualitative rather than quantitative, simply look at what it would cost to do business without the systems, including any lost opportunities that would result.
2. Centralize control of IT spending. One large company reported annual savings totaling tens of millions of dollars merely by reducing down to three the dozens of PC suppliers it used. These gains are relatively easy to achieve, but sometimes common sense isn’t all that common. If distributed systems and distributed budgets have led to loss of IT control, establishing centralized control points can ensure against duplication of tools and efforts, while remaining nimble and flexible enough so business units can fully exploit IT opportunities. Be sure to stipulate requirements for financial justifications. For example, compare solutions using cost-per-user or cost-per-transaction numbers over a three- to five-year period. The analysis gets at the true cost of ownership by totaling cost of hardware, software, and personnel that tend to the technology. Also include costs of a migration when toolsets change.
3. Seek simplicity and reuse. Successful technology projects often break down complex tasks into smaller, simpler pieces (e.g., security, resource management, workload management, etc.). Unsound IT infrastructures are loaded with unnecessary complexity, which ultimately results in higher support costs. Cloud computing is resonating with people on both counts.
Decentralized models, whether in business or computing, tend to make the underlying tasks or processes more complicated to perform, as opposed to centralized models where complicated tasks typically become easier to perform and manage, and offer economic advantages by making it simpler to share resources. History has proved that distributed systems work best where the number of users is small and large-scale distributed systems will cost a premium.
4. Insist on rigorous pilot testing that clearly demonstrates proof-of-concept before you approve any major overhauls of your IT infrastructure. Challenge those who tell you a decentralized IT model provides the best support for a decentralized business model. Collaboration between centralized and distributed systems leverages the strengths each has to offer.
One company attempted a wholesale conversion to a decentralized IT model after a few accounting applications had been moved from the mainframe to a distributed system. The massive downsizing strategy was aborted when shortly into the migration it was discovered that the network of distributed systems couldn’t sustain the company’s transaction workloads, even after the vendor re-sized the hardware to twice the capacity originally forecast. The moral of this story: Approve no migration plan until the proposed solution’s architectural and practical limits are clearly identified. Hold consultants and vendors accountable. Take legal precautions to protect your interests and minimize finger-pointing should problems get out of hand.