The Drive to Greater Data Center Efficiency

By Charles Rattray

In today’s volatile business climate, most Fortune 1000 companies face pressure to reduce or maintain flat IT costs while delivering new business applications and innovative services at an ever-increasing pace. Though data centers are bursting at the seams, there’s little appetite to build more facilities, especially considering large enterprises can expect an average cost of about $100 million per new data center, according to an April 14, 2008, report from “Dealing With Technology.” Ultimately, IT faces a significant challenge: How can you quickly identify opportunities for cost savings without an accurate view of applications and infrastructure—or a sense of how that infrastructure relates to delivery of business services?

Without visibility into the mainframe and distributed computing infrastructure and how it’s being used to support the business, data center resource planning becomes incredibly inefficient. Too often, more infrastructure than necessary is deployed to meet business objectives, leading to massive wastefulness. For example, according to Gartner in its report, “How IT Management Can ‘Green’ the Data Center,” Jan. 22, 2008, in the average large data center:

• 10 percent of servers perform no current usable function
• 5 percent of servers are marked as decommissioned in the fixed asset register, yet are still operational
• Most servers run at 10 to 15 percent utilization.

Each of these servers has associated administration, software license, facilities, and power and cooling costs that all contribute to the rising IT costs of just keeping the lights on. The deteriorating economy, the pressure to be “green,” and increasingly high expectations for business service delivery all underscore the need to optimize data center infrastructure. The goal is to ensure IT can continue to support businessas- usual services while providing room to innovate without getting bigger and more expensive.

The good news is there’s a significant, immediate opportunity for cost saving by removing the inefficiencies—starting with an understanding of how each server is used, which business applications it supports, and its actual value to the business. In this way, unused, unnecessary, and inefficient hardware can be weeded out or refreshed and software licenses reclaimed.

Continue reading ‘The Drive to Greater Data Center Efficiency’

ITIL v3 and the Continual Service Improvement Model: A Strategy for Optimizing Value, Quality & Performance

By Marv Waschke and Denise P. Kalm

Today, more than ever, IT must tightly align with the business. IT performance is tied to business performance: Every person-hour and every dollar must be allocated to deliver maximum business value. IT now provides much of the value the business offers its customers—as well as the effectiveness with which it works with its supply chain and business partners.

IT also must respond more quickly than ever to new and evolving business requirements. Two-year development cycles simply no longer work. So, alignment must be attained and maintained with tremendous agility.

Tight, timely business alignment can be achieved with the right strategies and tools. The IT Information Library (ITIL), originally designed by the British government to codify best practices and approaches to systems management, provides some of the industry’s most important guidance for maintaining alignment. Disciplined mainframe systems management—the structured adherence to change management, disaster recovery planning, testing and deployment—formed the basis for the development of ITIL. Although these processes had been long established in the mainframe world, they were still new to distributed systems. ITIL bridged that gap, offering a solution for all architectures.

This article focuses on one aspect of ITIL—continual service improvement—as it relates to mainframe systems management and the alignment of IT with the business. It’s based on the experiences of top IT organizations that have successfully implemented continual service improvement best practices in the mainframe environment. By learning from these experiences, IT organizations can effectively optimize the total business value they generate.

ITIL: Making IT Work

Business depends on IT. IT staff have technical skills and certifications, but their job isn’t to simply write code and maintain server performance. It’s to align with business goals to fuel growth and innovation. And that reflects a change in thinking from years past.

Continue reading ‘ITIL v3 and the Continual Service Improvement Model: A Strategy for Optimizing Value, Quality & Performance’

Useful Measurements for Application Portfolio Management

By Michael Oara

Application Portfolio Management (APM), recognized as a new discipline that helps align business and IT, gives a macro-level view of all software applications used in a company and how they align with key performance indicators. It’s an indispensable tool in IT planning that helps managers understand the costs and benefits each application provides so they can invest in projects that best support their company’s needs and longterm objectives.

As with any discipline based on handling large amounts of information, APM benefits from a high degree of automation. Here, the automation refers to the high-level charts and reports that support IT decisions and the more difficult process of gathering detailed data from several sources such as software code, production incident files, performance logs, accounting software, subject matter experts, or request logs. Software tools for APM should be able to use all these as data sources. An APM tool also should be able to incorporate—as automatically as possible—data coming directly from the business itself. This data often sits in the same databases the IT department manages anyway, so access to it shouldn’t be a problem.

APM should be an instrument to gather heterogeneous measurements from various sources. APM should organize and synthesize this data so IT and business managers obtain a clear view of alignment between software assets and their business to help them prioritize development activities. These measurements can be classified in three categories: technical metrics, stakeholder metrics, and other business metrics.

Technical Metrics

Technical metrics describe intrinsic characteristics of an application. Static analysis of an application can reveal several relevant APM measurements:

• Size can be measured in various ways. Perhaps the most familiar and easy to understand is Lines of Code (LOC), but other characteristics, such as number of programs, screens, reports, or files, also may be helpful.
• Complexity can be measured as a composite of complexities of individual programs or of the application as a whole. Complexity measurements are based on various characteristics of a graph, such as the graph of decision points in a program connected through execution paths. Complexity measurements aren’t easy to derive; they require use of specialized static analysis tools.
• Function points describe the size of the application from the user’s perspective. Introduced in the ’70s by IBM’s Alan Albrecht, this measurement assesses the amount of functionality provided to the user.
• Technology mix describes the use of various technologies in an application. You may be interested, for example, in the use of relational databases vs. flat files, or COBOL vs. Java. It makes sense to split this into at least three separate categories: data, programming languages, and interfaces. The percentage of each one of these technologies could be an important factor in modernization decisions.
• Connectivity describes the degree to which one application depends on or uses assets from other applications.

Continue reading ‘Useful Measurements for Application Portfolio Management’

Competing Visions of Enterprise Data Center Management

By Alan Radding

The trend toward recentralization of the enterprise data center puts new pressure on data center-based systems management. As more distributed systems are reeled back into the data center, the ante is being raised regarding the performance, availability, recoverability, scalability, and security of the systems, applications, data, and infrastructure.

“There’s a transformation under way, from the physical to the virtual. Organizations are loading up more and diverse workloads and running more virtual workloads. This is changing everything,” says Brad Day, senior analyst at Forrester Research.

Complicating the challenge is the unconventional nature of many of the new workloads coming into the data center. Web 2.0, rich media, Service-Oriented Architecture (SOA), converged networks, cloud computing, mobility, and more change the very notion of enterprise data center management. And the people who come with these systems aren’t likely to be experienced and disciplined data center veterans but a new generation of administrators whose distributed systems are being recentralized.

“The mainframe plays a big role in the new enterprise data center, but it goes beyond the mainframe,” says Peter McCaffrey, IBM’s director of enterprise systems. Driving this change is virtualization. “Through virtualization, you decouple the infrastructure from the application layer,” he explains. This decoupling enables such activities as cloud computing, where users take advantage of services from outside the data center. Although users may love this new world, the data center manager has reason to be nervous.

Another reason to be nervous: Business Service Management (BSM). “Now executives are asking IT operations to be managed in accordance with business priorities. At the IT management level that means breaking down silos, at least in terms of communications and management,” says John McKenny, vice president/worldwide marketing for mainframe service management at BMC Software, Inc.

This is where IBM also sees data center management going. It’s less about managing individual devices, systems, applications, or data. Just keeping systems up and running is no longer enough. Now data center management is about BSM, meeting service commitments, and aligning with strategic goals.

“In the past, managers managed the resources, the devices. But what you really care about is the service. That means you have to align resources with the business service,” says Vince Re, senior vice president/chief architect at CA, Inc. Email, for instance, is a vital business service, a showstopper if it goes down. When that happens, the problem could be anywhere from a browser on a remote desktop to any number of physical and virtual servers and the network links that connect it all.

At a high level, IT alignment with the business is simply good fiscal management. “Now you think: We have to support a business need, what’s the right place to put it in terms of cost or resiliency or performance or security?” adds Ralph Crosby, data management infrastructure architect at BMC. To address issues such as this, BMC is touting its BSM platform built around the BMC Atrium product.

This means managers will have to rethink their approaches to management. To resolve a problem such as the failure of the email service, they will have to think about managing across traditional IT silos (application, network, storage), often analyzing systems data in real-time with business objectives in mind. They also will need to bolster their management tools with new offerings from IBM, CA, BMC, and others. The bright spot in all this, says McCaffrey: “It’s easier to do this in a centralized environment.”

Continue reading ‘Competing Visions of Enterprise Data Center Management’

What Every Executive Should Know About Risk & Controls

By Gwen Thomas

You’re a leader at an organization that has a mainframe. That means you have data—lots of it. That also means you have lots of risk. Why? Obviously, your data is at risk; there are hackers and thieves who would love to steal, disclose, or compromise the information stored in your systems. But that’s not all. Data represents risk. The personal, private data that you collect and store can become a great liability if it’s improperly disclosed.

You can’t ignore this risk; you have to manage it. And you have to manage it in a way that resonates with auditors, regulators, and your internal compliance, privacy, security, and governance teams. To work with these people, you’re going to have to be able to effectively communicate with them. You’re going to have to be able to speak their language: the language of risk and controls.

Risk and Controls: The Elevator Speech

Protecting data is a business problem, not an “IT issue.” It’s a balancing act; one stakeholder group’s focus may be on freeing up information, while another is concerned about limiting access. You start by gathering requirements from various internal and external stakeholders, and then use a governance framework to help you make decisions and balance priorities. Next, you build a comprehensive stack of interdependent controls that help you prevent problems and detect data issues so you can address them before they become problems.

Organizational Alignment

Who’s “in charge” of aligning disparate efforts across your organization to manage data-related risk? Clearly, others besides you also are concerned with protecting your organization’s sensitive data. It’s a safe bet your organization has a plan, or more likely, several plans: one from the e-security team, one from your data privacy officer, one from your compliance group, and several from business and IT groups.

It’s possible these groups and plans are formally tied together. More commonly, your organization is depending on representatives from various groups to confer with each other and to align efforts in a collaborative manner.

If this is the case, it’s important to remember a lesson from Management 101: Someone has to be in charge. Someone has to facilitate and coordinate efforts to bring together a cross-functional team to review your organization’s approach to protecting sensitive data. Your Data Governance Office (DGO) may be the most likely candidate; most DGOs already work with data stakeholders and stewards, and DGO staff are usually trained in facilitation and communication as well as data-related efforts.

However, it doesn’t really matter who’s in charge. What matters is that the right stakeholders are involved, and that you can learn who they are if you need to.

Continue reading ‘What Every Executive Should Know About Risk & Controls’

IT Modernization: Architecture—Crossing the Fault Lines of Legacy Systems

By Dale Vecchio

All that is “legacy” is not lost! Many systems continue to represent good business value to an organization. They represent today’s business processes and are of such strategic importance that to consider any alternative is risky. So what’s a mainframe shop to do? The answer is Service-Oriented Architecture (SOA)! When issues with legacy systems are more about access than logic, they can be exposed to new systems and new development using an SOA interface. Mainframe shops need to undertake a fair and balanced evaluation of their portfolio, selecting SOA when new business processes or Web-based systems require a different way of accessing their existing business logic. This “orchestration” of existing transactions or data into services can give a new look and feel to legacy systems.

Many mainframe systems have been developed around transactions or batch processes that were intended for human consumption. New business processes may need to use these as building blocks, not by humans, but rather by another process. In some cases, existing transactions represent the instantiation of a currently valid business process and can be “wrapped” and exposed as a service. In this case, the wrapper may navigate the screen flow, extracting the information needed to satisfy the service request. In other cases, the desired service may be constructed from several existing transactions, data stores, and callable transactions from IBM’s CICS or IMS TP Monitors, CA-IDMS/DC or CA-Datacom, and both relational and pre-relational databases. The consumer of this service has no idea what it took to create the service, nor should he. The consumer issued a service request and received the contracted response. Perfect!

Existing mainframe developers, familiar with the intricacies of the existing systems and with potentially decades of process knowledge, can easily create the orchestrated services. These developers shouldn’t feel threatened by SOA, but should embrace it! Many mainframe developers, stuck in their expectations of yesterday’s mainframe transaction systems, can’t accept SOA as a performing solution. The future of the IBM mainframe is not about building more and more transactions on yesterday’s development paradigm. The future of the mainframe is more than just a “database server”—the future of the mainframe is as a business process server. When yesterday’s system still represents valid business logic—SOA is the modern answer!

IBM has clearly embraced SOA as the modernization strategy for mainframes. The challenge to customers is that they have many products from many labs with revolving names and a somewhat complex character. IBM’s story is great; its products are too complex. In addition to the IBM offerings for CICS and IMS, thirdparty vendors offer very robust and much easier to use solutions. Mainframe customers that desire the orchestration of their existing systems to occur on the mainframe can find strong solutions from Attachmate, GT Software, DataDirect, HostBridge, Rocket Software (Seagull Software), and SOA Software. These vendors provide strong and viable solutions to service-enable mainframe systems.

While much of the experimentation with SOA on the mainframe now is based on non-invasive reuse of existing transactions, organizations should consider code-understanding tools that can enable them to create “better grained” services, eliminating unnecessary code. Separating the presentation layer from the business logic and data layer is a good first step. These building blocks can become strategic pieces of an organization’s mainframe SOA strategy and companies must be willing to touch them!

The evolution of mainframe systems with SOA must recognize the aging workforce that exists on this platform. Leveraging these skills over the next decade before the workforce retires should be part of every organization’s SOA plan. Mainframe developers must not continue to operate in isolation, denying the value of any modern application development paradigm. SOA can become the lingua franca between these developers and those using newer technologies and languages. Break down the barriers! It’s worth it.

Identity Management: Why SOA and Identity Management Go Hand in Hand

By Robin Bloor

A Service-Oriented Architecture (SOA) is built incrementally. The process is both a journey and a migration. You start with a set of applications that inhabit an archipelago of systems—a set of application silos, each designed to meet the needs of a specific business application. Your destination is a computing environment that can be viewed as a single shared resource space, where the software components are either items of software infrastructure or loosely coupled business services that can be invoked as needed. And just to complicate matters, the business services may stretch out beyond the corporate resource space and connect to other computer environments in order to deliver yet more business services.

In siloed environments, users are defined in simple ways and identified more often than not through the act of logging in and providing a password. The identity they possess is a local one that provides local capabilities. However, a full-fledged SOA identity can’t be local because there is no “local.” There are services the user can or can’t use according to a set of permissions that have to be explicitly defined somewhere.

You don’t need to think about this for long before you realize that if you’re going to make the journey to SOA, you need to start thinking about identity management from the very beginning. It also will help if you think of identity management as a service rather than an application. Ideally, it should be a global identity service that users connect to when they enter the computing environment and which provides them with specific access rights to a variety of business capabilities.

SSH tectia

The Adoption of Identity Management

Be warned. Just as the adoption of SOA is a long-term activity, so is the implementation of identity management. The destination is clear: to have a single automated service that securely defines every user, whether a member of staff, or working for a business partner or a customer of some kind, which securely provisions for them every capability they have or will be allocated.

Identity management is similar to SOA in one other respect. With SOA you start with what you have and gradually stir it all in, bit by bit, to run in a service-oriented manner. With identity management, you also start with what you have, which may be little more than the login capabilities of a multitude of systems and applications, or may include some password management, or could even extend to single sign-on.

Sophisticated or simple, it’s old technology, which deals only with access. It’s a long way from an identity management system that fundamentally links people to the services (business applications) and, possibly, to things (such as cell phones, laptops, and even parking spaces) that are provisioned to them. The identity management system reaches into the HR application, touches every software service a company runs, and stands as one of the foundations of IT security. Aside from its responsibilities within the enterprise, it also will be the source of any security credentials that reach beyond the enterprise.

It’s often difficult to justify building an identity management service in a strict cost/benefit manner, because most of the manual admin costs associated with identity management tasks are spread across the organization—activities that tend to occur when new staff join or leave, or reorganizations take place. Nevertheless, automating them makes a genuine difference, and such tasks will become much more troublesome and error-prone if they aren’t automated as SOA is introduced.

Although it’s rarely given much prominence, identity management is one of the pillars of SOA. With SOA you work toward building a computing environment where new business services can be quickly and incrementally added; however, you can’t reliably deploy such services unless you can easily provision them to the intended users and secure them. For this reason, when I’m hired to consult by companies that are moving to SOA, I frequently feel obliged to raise the topic of identity management.

IT Risk and Consequences

By George Westerman and Richard Hunter

Because IT risk is now business risk, with business consequences, enterprises must change the way they manage it.

A half century of adopting information technology at an astonishingly rapid rate has created a world in which IT is not just widely present but pervasively, complexly interconnected inside and outside the enterprise. As enterprises’ dependence and interdependence on IT have increased, the consequences of IT risk have increased as well. What is IT risk? It’s the potential for an unplanned event involving a failure or misuse of IT to threaten an enterprise objective—and it is no longer confined to a company’s IT department or data center. An IT risk incident has the potential to produce substantial business consequences that touch a wide range of stakeholders. In short, IT risk matters—now more than ever.

This change in the meaning and importance of IT risk has caught some executives unaware. Every executive at some time has experienced problems with his IT organization and systems, including delays and unexpected costs in development projects, temporary or extended loss of service, data loss or theft, processes made unnecessarily complex by systems interfaces and limitations, inaccurate information from redundant or “buggy” systems, and a myriad of other ills. Executives have generally learned to perceive—and even tolerate—such episodes as regrettably common but relatively limited in their impact on key business metrics. Case studies of companies like Tektronix and Comair, however, demonstrate how such perceptions no longer apply.

SSH tectia

Comair, a $780 million subsidiary of Delta Air Lines, experienced a runaway IT risk incident on December 24, 2004, when the company’s crew-scheduling system failed.  An airline’s crew-scheduling system is mission-critical. Federal Aviation Administration safety regulations limit the number of hours any aircrew member can work in a 24- hour period. The scheduling system is what ensures compliance with that strictly enforced regulation. Without its scheduling system, an airline does not fly.

Because of the holidays, December is always the busiest month for U.S. airlines. December 2004 was busier than normal because unusually bad weather forced airlines to cancel or reschedule many flights, including 91 percent of all flights between December 22 and December 24. No one at Comair knew that the crew scheduling system (which had been purchased from an external vendor) was capable of handling a maximum of only 32,000 changes a month. At about 10 p.m. on Christmas Eve, when Comair entered one more flight change, exceeding the monthly capacity, the system abruptly stopped functioning.

Comair technicians realized soon after, to their dismay, that the system could not simply be restarted. The only solution was to reload the entire system from scratch as quickly as possible. The tech team accomplished that task and relaunched the system late on December 25, but by then Comair had problems assembling its widely dispersed crews and aircraft where they were needed. The airline didn’t resume normal operations until December 29.

As the company struggled to recover from the disaster, nearly 200,000 stranded Comair passengers helplessly roamed airport terminals throughout the United States.  Airlines were fully booked for the holiday travel season, and there were few alternative flights. Throughout the Christmas holiday, camera crews from local and national television news outlets followed passengers through those terminals, broadcasting travelers’ and Comair’s distress to the American public.

Two weeks after the system failure, the U.S. Secretary of Transportation announced an investigation into the incident. A week later, the company’s president, Randy Rademacher, resigned. In addition to the damage to the company’s reputation, its management, and its customers, Comair’s revenue losses as a direct result of this incident are estimated at about $20 million. In other words, the loss from this single incident was nearly as high as the firm’s entire $25.7 million operating profit for the previous quarter.

The company had planned, and delayed, replacement of the scheduling system several times before it failed. Despite the outcome, these decisions could be defended as rational business decisions. The system had been running for years, and the likelihood of a complete system failure—especially one that resulted from an entirely unsuspected source—was apparently low. That the system failed at a point in time when its failure was maximally damaging to the company and its customers was extremely bad luck but hardly predictable.

But something more was involved than an unfortunate decision to defer an upgrade. Comair lacked a viable plan for the immediate recovery of this mission-critical business process. Its executives failed to plan for such a high-impact failure, however unlikely it seemed. When the software went down, there was no backup system that could be pressed into immediate service, no outsourcer on call and ready to step in, no plan that could keep the company running manually while the system was fixed.

In other words, it wasn’t just the computer system that failed—it was Comair’s process for understanding and managing the business consequences of IT risk. And making sure that an organization’s major corporate risks— IT or otherwise—are managed to an acceptable level is the responsibility of the organization’s senior executives. Perhaps that’s why it was the company’s president, not the CIO, who departed in the wake of the incident.

The Comair case is about the risk of availability. The Tektronix case is about agility—the ability to change rapidly with controlled cost and risk. In the mid-1990s, executives at the $1.8 billion electronics manufacturer learned that their plans to divest a major business unit had hit an unexpected snag. Key financial and manufacturing processes for three Tektronix business units were riddled with undocumented interdependencies between critical systems. Extracting one business’ systems from that tangled mass was like removing a load-bearing wall from a building—it couldn’t be done without major restructuring.  The separated unit would require duplicating nearly every one of Tektronix’s major systems (including the sensitive corporate data they contained), as well as finding technicians to maintain the systems. The difficulty of spinning out a division, with or without its IT systems, brought a focus to those IT agility risks that had been present for years.

Tektronix arrived at this strategic dilemma gradually. For decades the company’s IT department had extended existing systems, built new stand-alone systems, and written software to link systems as needed. Every new “solution” was an unconscious trade-off of long-term agility in favor of short-term benefits. The problems inherent in this approach weren’t immediately apparent to executives, but they compounded over time, just as it takes time for unplanned, uncontrolled growth in a city to visibly overload roads, schools, sewers, and support services.

By the early 1990s, Tektronix executives knew their IT systems had problems. Changes took much longer to implement than they should have and than executives would have liked. It was frustratingly difficult to get an integrated view of the company’s customers, products, and orders. Business managers complained that IT support was getting worse and worse, and IT managers knew that the systems were becoming more and more difficult to maintain. Extensive coordination by smart support staff covering for system inadequacies was so frequent that it produced a motto: “Five calls does it all.”

Continue reading ‘IT Risk and Consequences’

Enterprise Manager: People Count for More Than Budget

By Jon William Toigo

According to various analysts, the IT budget of a corporate organization hovers at between 3 and 6 percent of revenue—of which about 45 to 50 percent is labor cost. In today’s economy, that labor cost component stands out as a huge nail that every TCO analysis tool wants to hammer into the ground.

There are many ways to reduce labor costs, including trimming redundancy. By consolidating identical or nearly identical work processes so execution is more streamlined, you may be able to consolidate the number of people required to manage and administer those processes.

Another approach is to outsource certain activities. The front-office, which sometimes has a hard time believing IT is part of their core business, is often enamored at the thought of using a third-party service to run IT—and at a significantly reduced cost.

But let’s be honest; hardly anyone I’ve spoken with recently is happy with their outsourcing decisions.

Take, for example, the Canadian financial firm; the IT manager says IBM Global Services has essentially locked him out of his own shop. He can’t see into their infrastructure beyond the non-granular dashboard they provide. With billing based on cycles, and a current Virtual Tape Library (VTL) solution consuming more cycles than it probably should, he’s being told by Big Blue that he needs to upgrade his software and gear. He knows he could probably tune the existing configuration to alleviate the burden, but he doesn’t have the right under the contract to actually touch or install anything. No doubt, he’s starting to wonder if he actually has a meaningful job anymore.

At the Midwest power company, the CIO reports that software development and maintenance are outsourced to IBM Global Services, while EMC is running the Fibre Channel fabric. The outsourcing deals, which were supposed to make the CIO’s life easier and improve company revenues, have created more problems than they’re worth. When the CIO makes a decision on hardware that favors EMC, local IBM reps write lengthy memoranda to senior management stating the foolhardiness of the choice, casting aspersions on the intelligence and integrity of the CIO. The opposite happens if the CIO’s decision favors IBM, except the email to senior management contains an EMC logo. The result is that projects are delayed while senior management or the CIO bring in outside consultants to validate the decision.

The Chicago-based telecommunications company is the saddest case of all. I ran into a fellow who used to manage storage for the telco, but found himself outsourced, together with his shop, to Computer Sciences Corp. a year or so back. Shortly after, CSC made the decision—predicated on reducing its own service costs—to pink slip all the acquired talent and offshore the operation to India. I haven’t heard how the senior management of the firm views the offshoring decision, whether help desk functions are helped or hurt by language and time barriers or other issues frequently discussed in the trades around this phenomenon. I do know, however, that my friend is plenty upset at losing his job … twice.

I’m not playing victim’s advocate here, but I do sense there may still be a disconnect between the bean counters and the technology operatives in the company. It may go beyond the issues of budget to the real efficacy of the outsourcing decision. Can blindly paying for technology upgrades requested by the outsourcing vendor who has you locked into a 10-year agreement really be a good alternative to rolling your own IT? Can having important information management initiatives delayed by vendor infighting really be more efficient and beneficial to a company than controlling those decisions yourself? Will offshoring compromise the presumed value of outsourcing from a service and support standpoint?

The bigger issue here seems to be one of the core value of outsourcing itself. Outsourcing is supposed to improve economic and service efficiency; it’s supposed to insulate companies from the costs of technology change and reduce labor expense. It seems to deliver on these values when routine processes—not problematic ones—are outsourced. The record on this score is long and clear. Ignore it, and your people costs will actually accelerate, since no one in their right mind will want to work for a company that has gutted all semblance of rational IT decision-making.

Bringing Enthusiasm & Excitement to the System z: An Interview With IBM’s Karl Freund

By Joe Clabby

In January 2008, Karl freund became the vice president of system z marketing—joining the system z group after a recent stint as IBm’s vice president of system p. His new task: do what he did in system p-land—bring some enthusiasm and excitement to system z—and greatly accelerate the platform’s product growth. His major challenge: convincing business and It executives that system z mainframes aren’t old technology, but rather one of the industry’s best platforms for consolidation, virtualization, security, service-oriented Architecture (soA), Linux/Java, energy efficiency, and so on. And how does he like his new job? Read on …

Who Is Karl Freund?

If you want to see a master vice president of Marketing at work, watch IBM’s Karl Freund. Seven years ago, he took over as vice president of Marketing for IBM’s System p—then in third place in the UNIX marketplace (significantly behind Sun and Hewlett-Packard). In five years of stewardship, IBM’s AIX (UNIX) operating environment on System p (now POWER systems) went from third place to first place—and is now growing revenues while grabbing market share (at the expense of the former leaders) in the flat UNIX marketplace.

After about a year-long hiatus from System p, when Freund headed IBM’s competitive marketing organization, IBM put Freund in charge of System z marketing. And given his past performance, it’s fair to expect him to perform the same magic he performed in the System p world—only this time on IBM’s venerable System z mainframe.

The Primary Challenge—and the “z” Advantages

According to Freund, the primary challenge is to convince IT and business executives to take a new, unbiased look at IBM’s System z. “If they do this,” he contends, “they will find a host of advantages in z architecture over other scale-up and scale-out architectures.” Without losing a beat, he articulates those advantages as:

• Outstanding performance: 50 percent more performance than the previous generation z9
• Virtualization leadership: System z is the “gold standard” by which other virtualization hardware and software vendors measure their progress. IBM invented virtualization on System z almost 40 years ago and is way out in front of the market in terms of depth, manageability, and sophistication.
• Consolidation facilities: For instance, thousands of Linux images can simultaneously run on one System z10.
• Manageability: Because the mainframe has been around for more than four decades, the level of manageability exceeds any other platform on the market. It can take fewer than half as many systems managers to manage a System z than a comparably configured competing system. In addition, in most parts of the world, systems management salaries/benefits are extremely expensive—so System z buyers can save substantial IT budget expenses by adopting System z architecture.
• Security: “There’s no other commercial system in the world that has attained an EAL5 security certification for logical partitioning. This means data can’t leak between operating system instances on our System z—which isn’t the case for several other vendors’ virtualization products,” Freund claims.
• Energy efficiency: This is a huge advantage, especially over distributed systems architectures, because System z uses highly efficient power supplies, water cooling that has a 3:1 heat dissipation advantage over air cooling, and a high-speed internal network bus that eliminates the need to install a myriad of Network Interface Cards (NICs) and the need to power energy-hungry external hubs and switches. “Underutilized, distributed systems architectures, by design, waste a tremendous amount of energy compared to our green-striped System z,” Freund says.
• Processing power: “System z packs a tremendous amount of processing power into a small footprint,” he continues. “For markets where real estate costs are high and getting higher, and where data centers have maxed-out in terms of available space, System z provides an excellent alternative to scaled-out distributed systems,” Freund says.

Continue reading ‘Bringing Enthusiasm & Excitement to the System z: An Interview With IBM’s Karl Freund’