Time to face reality. Some of our bedrock assumptions turn out to be unfounded. And chief technologists can be subject to outdated beliefs as often as any professional. With that in mind, we addressed six common IT myths and de-constructed them to give managers a clear view of some important assumptions that might otherwise throw a monkey wrench into their technology plans. InfoWorld set about tracking down the sources of the myths in question and found nearly all had little basis in fact. For example, the myth persists that server upgrades matter. No way. Another myth: that business acumen is now the key to a successful CTO career. Not even close. And the one about 80 percent of corporate data residing on mainframes? Check your math. Our dogged reporters found many more time-honored tales to debunk, proving once again that while common wisdom may indeed be common, it is not always wise. Myth 1: Server Upgrades Matter Reality: don't pay extra for upgradability; you'll never need it. When was the last time you swapped out the processors on a production server? Have you ever ripped out a working system's RAID controller and substituted one with bigger cache? How about pulling out a machine's mirrored 18GB Ultra160 SCSI boot drives just to replace them with some 36GBUltra360 spindles? Despite the fact that top-tier server manufacturers boast about the field upgrade capabilities of their server platforms, it's a myth that anyone ever fiddles with a production system except to replace a blown part. If the server is less than a year old, chances are that it was ordered with the right parts and doesn't need to be touched. If the server is more than year old, nobody in their right mind is going to pop the top to crank the gigahertz. To research this myth, I contacted all the tier one server manufactures. Not one would formally cooperate when asked for statistics regarding enhancements to their servers, either by sales of upgrade parts or through calls made by their field-service teams. Some said the data wasn't available. Others said it was proprietary information that couldn't be released for competitive reasons. All claimed to find the question surprising and were interested in reading the results. Fortunately, one vendor, who shall remain nameless, forwarded the informal comments of a marketing manager, whose name was removed from the e-mail. The manager's thinking echoed my own: "I believe the majority of customers purchase initially a server populated with the RAM and processors for future growth."The manager added, "Many customers secure capital expenditures for the hardware and it is easier to purchase under this capital than to try to expense some more hardware down the line."Another reason, of course, for not upgrading a system would include a fear of screwing things up, either by having hardware problems or by encountering difficulties with the operating system, drivers, or applications. Given that there's going to be only a minimal performance improvement in going from, say, 2.0GHz to 2.6GHz processors while the rest of the server remains the same, what's the point in taking that risk? If one could generalize, then one would say: The smaller the server, the less likely its hardware is going to be touched after the system has been deployed. The chassis investment in an eight- or 16-way server might warrant enhancements to its I/O backplane. It also might make sense to add processors, if some of the sockets were initially unpopulated. By contrast, it's hard to imagine anyone doing much to the hardware on a dual-processor 1U or 2U server or to a server blade, other than adding memory if needed. If that low-profile server can't handle the workload, the solution would be to replace it with a more powerful server or to add more servers to a load-balanced cluster. What about swapping the processors or adding a faster backplane? There's no ROI for spending good money on old servers. When you're considering specifications for new servers, make sure the system fits your existing needs, and buy it with the headroom you anticipate requiring for the expected life span of the machine. Unless you have an IT culture that actually performs server upgrades, don't plan on performing any, and don't pay extra for features such as upgradable CPU cards capable of accommodating future processor platforms. You won't use them. Alan ZeichickMost Likely Upgrades Adding hard drives to empty slots Increasing memory Installing additional processors Adding a Fibre Channel HBA Installing Gigabit Ethernet adapters Least Likely Upgrades Upgrading RAID controllers Replacing functioning hard drives Replacing processors with faster ones Myth 2: Eighty Percent of Corporate Data Resides on Mainframes Reality: try 50 percent, or even less. It's past time to retire the myth that mainframes, those impenetrable-looking boxes understood by only a few IT magicians, still store 80 percent of all corporate data. Since their introduction in the 1950s,mainframes have largely been the unchallenged gatekeeper for all mission-critical corporate data. IBM became Big Blue, the color of their early mainframes, by popularizing mainframes with the company's hardware and operating systems and eventually its line of applications and then gained an iron grip on the entire market for decades. But IBM's early monopoly of the mainframe market came under attack in the 1970s and 1980s. With the arrival of the first minicomputers and then microcomputers, which both held the promise of distributing centralized data closer to users doing the work, Fortune 1000 companies started demanding less reliance on mainframes. Even with the desktop revolution, the notion that mainframes held at least 80 percent of all corporate data remained intact through the mid-1990s in the minds of many. But the birth of the Internet and the resulting flood of unstructured corporate data, such as e-mails, Web pages, Microsoft Word documents, and various technologies to manage and store this digital data has led many to conclude that the stranglehold mainframes have held on corporate data has been slipping. "In dealing with some of our clients, it is almost shocking to see some large organizations' financials being managed in a couple of Excel spreadsheets. Plus with all the blogs, instant messages, e-mails that do not pass through a mainframe, the amount of data now residing on mainframes is now probably in the neighborhood of 40 to 50 percent," says Stephen O'Grady, senior analyst at RedMonk. Reinforcing this growing trend, there is already an impressive amount of mission-critical financial data being generated, shared, and managed out of the sight of mainframes, says Dana Gardner, senior analyst at The Yankee Group."Some corporate users now have Spreadmarts big, honking flat files in spreadsheets used to manage many business processes and in a really decentralized way," according to Gardner. And with the aggressive promotion the past few years of dozens of integration strategies that threaten to tear down the technology borders between mainframes and distributed platforms, some question the relevance of where data resides. "Does it even matter anymore [where corporate data resides] is the more relevant question. I think it has less meaning today than it did a few years ago. In fact, the more you hold onto that old axiom, the more you point out it is a proprietary and isolated environment. I wouldn't think anyone would want to continue promoting that idea," says Steve Josselyn, research director of the global enterprise server solutions program at IDC. Another trend eating away at the mainframe's dominance is the rise of SANs and NAS appliances. Although many such environments have direct pipelines into mainframes where data can be shared back and forth, the inclination of more and more corporate users is to plant data on SANs and NAS devices. "Increasingly, the type of computer becomes irrelevant with the local-area storage networks and the increasingly sophisticated storage that has come into play," says Hadley Reynolds, research director at Delphi Group. Ed Scannell and Cathleen Moore Myth 3: All Big Shops Run Multiple Platforms Reality: this "myth" is closer to fact than fiction. As the New Wave band Devo said,"Freedom of choice is what you got. Freedom from choice is what you want." Were they right; is having no choice easier than having to decide for yourself? Does this principle apply to IT? Do enterprises seek heterogeneity rather than single-vendor solutions? Experts agree this is not a myth. Some smaller companies are homogeneous, but larger companies inevitably become heterogeneous because of mergers and acquisitions, says Mike Gilpin, vice president and research director at Forrester Research. Besides, heterogeneity provides leverage."It's always useful to have some other vendor that you can use as a threat," Gilpin says. An official at Oblix concurs. "[IT personnel] like the leverage that they have by keeping it a heterogeneous environment," says Ken Sims, vice president of marketing and business development at Oblix. "It's gone to the vast majority [being] heterogeneous," says David Bartlett, director of customer and partner programs at IBM's autonomic computing group. Formerly, the ratio of homogeneous to heterogeneous environments was about 80-20, but that ratio has at least reversed itself, Bartlett says. Companies' desires to be global, to operate on a 24-by-7 schedule, and to be on the Internet have led the way to heterogeneity, Bartlett says. "Most customers today usually have a mix of server types," according to Jim Goethals, infrastructure simplification program manager at IBM's systems and technology group."If you look at what's typically on a desktop, for instance, that's going to be Intel. Depending on the departmental environments, they could have Intel based servers or Unix servers, and when you get into the datacenter, you're going to find mainframes" as well as Intel and Unix systems, Goethals says. Both heterogeneity and homogeneity have their pros and cons. One-vendor, so-called proprietary solutions bypass the hardships of having to make systems work together that were not built to do so. Proprietary solutions, however, tie a user to the whims of one or just a few vendors and offer limited options. So-called open solutions give users a variety of technology choices, theoretically driving down costs, given that multiple suppliers have to bid for your business. IT administrators, however, can have their hands full making everything integrate in an open world, requiring development of an alphabet soup of standards. Just what exactly is an open system? If you talk to any technology vendor, it will tell you its system is open, whereas all the competitors' systems are closed. The term open is usually applied to software or hardware that conforms to standards or features commodity parts. Whereas most shops desire heterogeneity, some users prefer a single vendor approach to at least part of their IT architecture. The city of San Jose, Calif., for example, recently has come under fire for making local networking vendor Cisco Systems its supplier of choice for networking equipment at a new city hall under construction. In his 27 years of experience, Joe Poole, an IT official at Boscov's Department Stores and manager of technical support, has watched his shop grow and diversify from a mainframe-only environment to a mix of a mainframe running VM and Linux plus RISC Unix boxes and Intel systems. Some applications such as the company's merchandise and its graphical applications simply run much better on the newer platforms, he says. Poole believes tha, these days, no one can continue to be a single-platform shop. "Nobody can, and I don't think they will," Poole says. - Paul Krill Myth 4: CIOs and CTOs Have a Greater Need Reality: tech chops matter more than ever. Job No. 1 for the first CIOs to emerge in corporate shops almost 20 years ago was to make sure the business goals of the corner office were being served by the technologies put in place by the IT department. They were to be the bridge between two very different cultures. Simple enough. But during the past two decades, as technology has become inextricably entwined with a company's core business strategies, many CIOs and, in larger companies, CTOs have been forced to spend an inordinate amount of time on the business side of the chasm. And as the number of technology projects has grown, many CIOs and CTOs have pushed more decisions for individual technology purchases and their methods of implementation farther down the organizational ladder. Too often, those making product decisions have been purely focused on technology and so have made tactical decisions without enough regard for how those decisions will benefit overall business goals. "One of the top reasons I think some IT projects go off course technically and/or over budget, if not outright fail, is the lack of guidance from upper management on the technical side. Sometimes they shouldn't be so fast with the rubber stamp until they get a better grasp on some of the technology they are asking their people to implement," says Joe Johns, a LAN administrator at a large bank in North Carolina. Well, so much for the myth that CIOs and CTOs need more business savvy than technical expertise. In fact, there seems to be some concern from industry observers that CIOs and CTOs need to spend more time gaining a deeper understanding of technologies and products, particularly emerging ones. One of the major reasons CIOs and CTOs have been forced to focus more on business than on technology decisions has been the dot-com bust. With so much aimless spending on technology in the second half of the1990s resulting in little ROI, many CEOs are demanding short-term if not immediate returns on any sizable tech investment. "A lot of companies are in reactionary mode right now," says Will Zachmann, president of market research companies Canopus Research and Agylity."Now that we are in the dot-bust era, the pendulum has swung back hard the other way, and it has everyone afraid to do much of anything technically." But concentrating so narrowly on short-term financial gain forces the majority of CIOs and CTOs to defer the steady implementation of long-term technology visions until better economic times arrive. Such delays will only put them at a competitive disadvantage to those who are striking a more reasonable balance between ROI and high-tech investments. "Those CEOs and CIOs who are joined at the hip and who want only short-term ROI are myopic about where IT should be going technologically. An organization that really understands IT technologies and what to do to turn [those technologies] into genuine competitive advantage can be in a great position right now," Zachmann contends. Ed Scannell The Skills IT Executives Need Ability to think independently instead of simply relying on experts' opinions Familiarity with a wide range of technologies Ability to communicate how the organization should leverage technology to practical advantage Commitment to continuing education in both business and IT Focus on business results rather than personal gain Willingness to take reasonable risks and to learn quickly from mistakes Flexibility to change with the technology and the times Source: Will Zachmann, President, Canopus Research and Agylity Myth 5: Most IT Projects Fail Reality: it all depends on how you define failure. Do most IT projects fail? Some point to the number of giant consultancies such as IBM Global Services, Capgemini, and Sapient, who feed off bad experiences encountered by enterprises."Sapient is a company founded on the realization that IT projects are not successful," says Sapient CTO Ben Gaucherin. Others counter by saying failure is relative. Sure, many projects have minor system glitches or come in over budget, but they don't rise to the "failure"status that would seriously harm the user's business."If a project is three months late or 5 percent over budget, that may be a disappointment, but it's not a failure. That's the case with most IT projects,"says Jim Shepherd, vice president of research at AMR Research and coauthor of AMR's 2004 ERP report. Although there may be myriad ways that projects can experience problems, actual implementation usually succeeds, Shepherd says. The Standish Group, which exists solely to track IT successes and failures, sets out very strict criteria for success. For its Chaos Report, The Standish Group surveyed 13,522 projects last year and showed that unqualified project successes are well below 50 percent,34 percent to be exact. Out-and out failures, defined as projects abandoned midstream, are at 15 percent. Falling in between the two are completed but "challenged" projects. The report says challenged projects represent 51 percent of all IT projects and are defined as projects with cost overruns, time overruns, and projects not delivered with the right functionality to support the business. The level of success can be tied to the degree of user involvement, executive management support, and having an experienced project manager, in that order, the report says. For IT project consultancy Sapient, the key ingredient to success or failure rests on the processes a company puts in place to manage risk. In other words, it's essential to identify a point of failure before it brings down an entire project. "The larger the project, the greater the chance of failure, and therefore the more effort you want to put behind managing risk," Sapient's Gaucherin says. Gaucherin adds that potential problems can be managed by "bubbling up risk," a methodology for identifying problems before they get out of hand. To that end, projects are put on a value chart with plot points becoming project milestones plotted over a time line."As soon as we start veering off, we ask [ourselves] why," Gaucherin says. Probably the news with the most damaging implications for IT projects is not the number of those that were abandoned, rather it's those that were completed but offer fewer features and functions than originally specified, says Karen Larkowski, executive vice president at The Standish Group. "Content deficiencies of more than 50 percent would most likely be considered a failure,"she says. But AMR's Shepherd has another view, which he says is more realistic. "Failure would be a situation where orders stopped being taken, or the books couldn't be closed, or the project itself was simply abandoned," Shepherd says. "That's rare." Ephraim Schwartz Myth 6: IT Doesn't Scale Reality: virtually any technology is scalable, provided you combine the right ingredients and implement them effectively. At one time or another, nearly every kind of information technology has been judged and found wanting. The failures are often summed up in that most damning of epithets: "It doesn't scale." The reason, of course, is that at one time or another, for one reason or another, every kind of information technology has failed to scale. Unfortunately for the victims tarred with that brush, scalability is a wildly imprecise term. Applications may be expected to scale up to massive server farms or scale down to handsets. And size is only one axis of scalability. Others include bandwidth, transactional intensity, service availability, transitivity of trust, query performance, and the human comprehensibility of source code or end-user information display. There is no magic bullet that will slay all of these demons, but that doesn't stop us from trying to find one. Case in point: the recent furor that erupted when Friendster, a social-networking service, switched from J2EE to PHP and improved its response time dramatically. Reacting to a long history of allegations that "scripting languages don't scale," advocates of PHP could now gleefully assert, "Java doesn't scale. "The debate generated a lot of heat but also shed some light on what PHP's inventor, Rasmus Lerdorf, calls its"shared nothing" architecture. Because PHP is stateless, he explains, potential bottlenecks are pushed out of the Web tier and into the database tier. If you're using Oracle, Lerdorf says, scalability is proportional to "how big a check you write to Oracle every year," and if you're using MySQL or PostgreSQL, "it comes down to whether you have configured replication correctly and have a nicely architected tree of database machines." Of course, Java can be used in a similar way. When eBay made its widely publicized switch to J2EE, the statelessness of the new architecture was cited as a critical success factor. "Part of the mandate of EJB is to be stateless,"says Sun Distinguished Engineer John Crupi, whose team helped redesign eBay. The revised architecture used stateless session beans, avoided clustering, and focused on a set of business objects backed by eBay's highly customized database tier. In the end, scalability isn't an inherent property of programming languages, application servers, or even databases. It arises from the artful combination of ingredients into an effective solution. There's no single recipe. No matter how mighty your database, for example, it can become a bottleneck when used inappropriately. Many dotcom-era Web publishers learned that lesson the hard way when their database-driven sites were crushed by the Slashdot horde. The current blogging revolution represents, among other things, a more optimal balance between two synergistic methods: serving dynamic content from a database and serving cached, static content from a file system. It's tempting to conclude that the decentralized, loosely coupled Web architecture is intrinsically scalable. Not so. We've simply learned and are still learning how to mix those ingredients properly. Formats and protocols that people can read and write enhance scalability along the human axis. Caching and load-balancing techniques help us with bandwidth and availability. But some kinds of problems will always require a different mix of ingredients. Microsoft has consolidated its internal business applications, for example, onto a single instance of SAP. In this case, the successful architecture is centralized and tightly coupled. For any technology, the statement "X doesn't scale" is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn't (yet) come in a box. Jon Udell -"Myths of IT", InfoWorld, August 16, 2004, Issue 33