By Pat Brans

I recently read the results of a survey of how more than 100 different companies managed IT service. The study covered a variety of subtopics, including questions on how IT personnel are notified of an urgent situation in the middle of the night. It turns out that manual dispatch is still a common method, and those companies that have moved beyond that—setting up an electronic dispatch system—generally use set and forget methods that are passive and lack audit trails. Nobody can be sure the message was received, and no automatic actions are taken when the dispatch isn’t accepted after a preconfigured interval.

Another startling revelation is that the vast majority of companies have never computed the cost of downtime. They know IT outage is a major risk, and they have some idea of what industry analysts say about the costs of outage, but they’ve never quantified what such an occurrence means to their own bottom line.

Take, for example, the case where a batch process fails at 2 a.m. What is the cost of not getting the results on time and of having to run the same process again the next night? The answer to that question varies from company to company, so every company has to do the math for themselves. And based on the cost you estimate, you will probably want to allocate money to minimize the chances failure will occur and to reduce the mean time to repair in the event something actually does go wrong.

One group within IBM Global Services (IGS) in Germany has worked this out quite nicely. In their case, there’s a double whammy when a failure occurs. Because they rent mainframe time to other companies, when something goes wrong, not only is IGS impacted, there’s also a good chance their clients will feel it. For them, a failure could very easily result in lost revenue.

To minimize disruption, IGS has worked out that if a batch process crashes, they want their own IT personnel immediately notified. But if an application bombs, IGS wants to notify IT personnel from the client company that owns the application. In all cases, a precise log has to be kept so everybody knows what failed and when, and how much time it took to fix it.

As you can imagine, IGS’s requirements call for a robust system with a lot of configurable options. For different events, different groups of people need to be notified. Depending on the time of day, the day of the week and holiday schedules, a different individual within each group needs to be alerted. If the first person doesn’t respond after a certain amount of time, somebody else must be prompted. On top of that, each member of a group has his or her own preferences on how he or she receives notification. Some people want an email message, others want SMS, and still others want a voice communication. In all cases, IGS needs the notification to be reliable; that is, the sender has to know the message reached its destination and that the recipient read its contents.

Being on top of things, IGS has implemented a neat solution to its requirements. They use a network management system to detect failure and to log the status of service requests. The management system interfaces to mobile middleware, which generates alarms to different employees based on a sophisticated set of rules.

When a problem occurs, such as a batch process failing, the appropriate IT person is alerted on his or her mobile device. That person must then accept or reject the request within a pre-configured amount of time. Once the problem is solved, information is entered describing the resolution so a record can be kept in the system log.

While some unfortunate IT staffer might be alerted in the wee hours of the morning to fix a problem, I can assure you, everybody else in IBM Global Services now sleeps much better at night.

By Michael Oara

Your application portfolio runs your business. It automates core operations from finance to customer management, so it’s critical these systems operate as expected. Outages, security issues, and privacy exposures are significant concerns.

Most development organizations have created best practices to ensure these challenges are avoided by coding, documenting, and delivering high-quality applications. But enforcing these standards has become increasingly difficult as:

• Time pressures have increased, leading to a greater rush to deliver code.
• The global nature of development makes monitoring standards more complex.
• Resource pools are spread across a wider range of applications.
• Formal standards have replaced original standards based on the programming style of legacy personnel.
• Development staff members have left, taking knowledge of standards with them.

This article discusses how managers can monitor and enforce code quality standards across distributed teams. Doing so leads to:

• More understandable applications
• Improved efficiency in debugging applications
• Enhanced application performance and quality
• Reduced time to train new employees
• Easier transition between global development teams.

Aligning With Standards

Coding standards include policies created by management, architectural committees, business analysts, and other stakeholders. Once established, these policies should be applied against existing software assets to identify divergences from standards. As these misalignments are located, managers can prioritize steps to return software— and the processes they automate—into alignment.

Misalignments also can be detected during the software development lifecycle, as development professionals adjust code for maintenance or modernization. Ensuring compliance with policies at early stages in the development lifecycle avoids the costs and risks associated with deploying non-standard code that could compromise efficiency, agility, and stability.

Application Portfolio Reality

The reality of today’s development teams is that they’re globally distributed. Management may be in Europe, architects in India, and development in Brazil. So, it’s important that all departments be able to access the same information about their application portfolio. Such information would include the structure of existing code, the applicable standards, and the results of applying these standards to the code.

Information, when stored in a central repository, can be accessed by remote teams. Development staff at an international location should have access to the same reports, analytics, and intelligence as management located in an office on the other side of the world. Managers can then monitor the quality of the same sources that the development team is programming.

Application portfolios consist of a diverse array of languages, so managers must realize they need to apply standards across different environments.

Generate Software Insights

Software can be managed from multiple business perspectives. You may wish to control the quality of code in a core business process. You may wish to apply stricter standards to code that manages customer data. Or, you may wish to monitor the adherence of outsourcing providers to Service Level Agreements (SLAs).

To do so, managers should overlay “business context” or metadata onto their applications. This step lets users apply different standards to different business groups in their application portfolio. Users can then isolate code by context into a project that can be individually assessed for standards adherence. This helps development teams ensure adherence in business contexts that matter to the organization.

Define Governance Policies

Responsible individuals should define the policies to which software assets must adhere. Creating these policy frameworks should be simple and actionable. They should be instantly applicable against source code. Commercially available software lets users define policy criteria in its querying engine’s wizard. Adding, sharing, reconfiguring, and chaining these policies simplifies the identification of misalignments.

Invoke Policies

Next, we can think about when the policies are to be applied. Numerous parties will want to govern how well their software assets align with corporate policies. For instance:

• Management may want to determine the level of service or performance that a set of software assets provides to a business unit.
• An outsourcing manager will want to verify that the provider is adhering to SLAs for code quality.
• An architect may decide to validate architectural quality before sending an application into production.
• A development professional may monitor how his changes are affecting alignment with corporate standards.

When the policies are invoked will determine the likely path for reporting non-compliance. For instance, they could be flagged during development as a list of violations. They could be marked in a collaborative development environment as tasks that warrant follow up. Or measurements could be tracked and presented via a dashboard to management.

In some commercially available tools, application source code is parsed into a repository where all characteristics of the code are captured in a model. Where coding standards exist, it’s possible to create searches in your analysis tool that identify where application source does not adhere to these standards. These searches can be chained together and executed in a batch environment to provide an automated method of identifying non-adherence to standards.

Let’s look at common times when the application of standards could be launched:

• Prior to change: Managers can investigate existing applications to identify candidates that are misaligned with standards. Then, as change requests come in, developers can systematically correct errors as they adapt code for maintenance and enhancement activities.
• During code change: While changing code, the developer can load his unit test version of the program into the platform and execute the queries to monitor adherence to standards. The developer can then adjust code that failed the test before promoting it for system test.
• During code promotion: During the code promotion stage, code can be re-verified. If there are deviations, failed code will be flagged for rapid correction, minimizing delays.

Sample Standards

Various types of standards may be applied to promote different enterprise goals. An enterprise may choose to enforce standards related to performance, maintainability or security. Some standards may refer to program code; others may refer to higher-level architectural aspects. Some may be related to the ongoing production systems, others to future directions in which applications are expected to evolve. Here are some samples in some of these categories:

Maintainability standards: The term “spaghetti code” is well-known among programmers. It refers to program code that’s disorganized, convoluted, and hard to follow. Spaghetti code is hard to read and understand, making it hard to maintain and error-prone. Maintenance time may dramatically increase if certain standards aren’t enforced. For example:

• Limit use of COBOL GO TO statements
• Avoid large programs and replace them with smaller components.

Performance standards: Standards in this category would ensure good response time and reduce total CPU power required:

• Use binary representation for variables used in arithmetic computations
• Use binary searches rather than full scan searches.

Security standards: Security may refer to avoiding both internal and external threats. It may prevent unauthorized people from changing or viewing data. It also may prevent fraud:

• Don’t hard code account numbers
• Limit data displayed in hard paper reports.

Modernization standards: Such standards are needed to ensure the application can evolve toward a particular future configuration:

• Don’t allow use of retired programs (even if they’re still available)
• Separate user interface logic from data access logic; this is required for Service-Oriented Architecture (SOA) migration.

Monitor Policies

Growth in the Application Portfolio Management (APM) market provides solutions to monitor the adherence of applications to coding standards. Managers will want to monitor trends and status of their global development team’s adherence to SLAs. Browser-based dashboards help managers view “scores” for the metrics that matter to them. This allows efforts to be directed toward the highest value opportunities for correcting misalignment. At a more focused level, development staff also may view APM data in their Integrated Development Environment (IDE) during daily analysis activities.

Continuous Improvement

By identifying where misalignment exists, users can prioritize activities to ensure that software complies with governance mandates. What these activities are will vary, depending on the scope of the misalignment and the stage within the application lifecycle. For instance, a small misalignment may be flagged during development time. This may simply require a development professional to adjust a small portion of an application. However, an investigation may reveal larger divergence from corporate policies that may require more effort. For instance, it may be necessary to alter the architecture of an application, or poor performance levels may lead to a strategic decision to modernize or redevelop an application.

Managing Teams

It’s imperative that all development teams—including those in remote or outsourced locations—adhere to corporate standards. This process could be facilitated in multiple ways:

• Application baseline: Businesses can assess their existing application portfolio to determine how their source code compares to corporate standards. This provides a baseline that can be used to compare ongoing performance of outsourcers and to establish SLAs.
• Accurate budgeting: It can be damaging for outsourcing relationships when the provider misjudges the size and complexity of a contract. By providing accurate information about the application portfolio at the beginning of the relationship, there’s less chance for miscalculations and adjustments to the contract.
• Ongoing management: Businesses can regularly invoke policies to assess the adherence of outsourcers to established SLAs.

Conclusion

Enforcing coding standards can significantly improve the efficiency of IT operations and boost developer productivity. However, it requires successfully applying these standards against complex application portfolios. By centralizing business and technical intelligence about your applications, applying standard policies in an automated fashion, and making the results available to managers and appropriate staff, your team can quickly move toward efficient, agile, and compliant systems.

By Sreedhar Kajeepeta

CIOs and CTOs should take a fresh look at modernizing mainframe applications. The impact of a sluggish economy on capital expenditure is one of the many forces that could converge this year, perhaps with a vengeance, to make the case for modernization stronger than ever. Modernization in many organizations is 10 years or more overdue; it’s time to plan for and act on this opportunity with urgency, responsibility, and foresight. Modernization should be a multi-year initiative to carefully take the enterprise through a planned, flawlessly executed path of constant, responsible transformation—not a hurried agenda of modernizing various random elements.

This takes a broad interpretation of the term modernization. Although it has often been used interchangeably with the term transformation, we need to realize that modernization is just one aspect of the process of transformation. But to be practical about it, we could use both terms to point to the single endeavor of creating a more business-aligned, flexible, and efficient IT.

To begin, let’s review highlights of business cases for moving ahead and also consider the risks associated with the status quo. if this process or the facts it uncovers seem familiar, it may be useful to explore why “we’ve been there, but not done that” yet.

Business Cases

Early business cases have been pouring in ever since “cheap” UNIX/Linux and Wintel platforms began luring IT shops away from more “expensive” mainframes and their high software licensing costs. The new platforms started becoming even more compelling with the advent of virtualization technology. With servers sporting multi-core chips starting in 2005, which are now scaling up to incorporate many cores of eight to 16 processors, the value proposition of virtualization can seem irresistible. The available alternatives look even more attractive with the new cloud computing IT services delivery model.

The cloud could be a combination of an off-premises public offering and a secure, custom-built enterprise service based on individual application needs. either way, a model where highly scalable and shareable infrastructure, platform, and software services that are charged only on a pay-by-the-drink basis will offer economies of scale that can’t be ignored. Suddenly, virtualization and multi-tenancy, which were synonymous with the mainframe, have become newfangled realities in the inexpensive world of distributed computing! Benefits of this brave new world include:

• Cost savings
• Faster environmental set-up and development
• Comparable or better Service Level Agreements (SLAs) for accessibility, availability, reliability, and performance.

So modernization advocates might simply ask, “What are you waiting for?”

Risks

What are the risks of leaving everything in COBOL?

• It’s getting increasingly expensive just to maintain these systems.
• The rigid nature of these systems is a constant drag on efforts to be more responsive to strategic business needs.
• The aging mainframe workforce is fueling a growing paucity of skills.
• Poor or non-existent documentation of the code and business requirements makes the skills issue an even greater long-term concern.

How do these risks compare to the risks of modernization? The biggest risk of a modernization initiative is trying to do too much too fast. It’s simply irresponsible to try to modernize everything at once; it’s also unnecessary, thanks to the interoperability and scalability of today’s platforms and systems. It’s quite possible to follow a well-thought-out, non-intrusive and evolutionary process that’s grounded in the key principles of business alignment, loose-coupling, IT accountability, reuse, service management, and service orientation.

The concept of services is fundamental to the process of modernization and enterprise transformation. Just as a business is viewed by the outside world as a collection of highly accountable products and associated services, as its support system, IT also must be governed by similar principles of accountability. Different aspects within IT must reflect that discipline and responsibility. Service-Oriented Architecture (SOA) facilitates the transformation by accommodating management of current requirements and delivering sufficient scalability to support the future service commitments of the business.

Focus on Portfolios, Not Projects

Begin your modernization effort by establishing a stronger business alignment using portfolios of applications, which at their level of granularity match nicely with business services. In addition to improving business alignment, a focus on portfolios prepares IT to face the new realities of financing. As budgets get squeezed, it’s no longer viable to pursue and fund modernization at the fine-grain level of a project. Today, IT must think of self-funded modernization work that yields portfolio-level efficiencies. In the parlance of SOA, a portfolio is synonymous to a Service-Oriented Business Area (SOBA).

A term coined by Gartner, SOBA represents a manageable, impactful unit of the enterprise that one can transform. Transformation of each portfolio or SOBA can in itself be a multi-year endeavor. Depending on the SOBA’s size and complexity, it might be necessary to take on a couple of representative portfolios together to identify a broad set of foundational services that need to be developed first, with follow-on work devoted to supporting the coarse-grain business services represented by the chosen portfolios.

Rationalize the Portfolios

A pragmatic approach is essential during the critical step of portfolio rationalization, which involves using an objective set of criteria to evaluate applications and to determine their immediate and long-term fate. As you rationalize your portfolio, remember that the mainframe and z/OS can be a foundational part of your service-oriented infrastructure. Depending on how broad or focused you want to be with your rationalization exercise, you might end up grouping the projects into categories such as leave-it-alone, re-host, convert, replace, and re-architect.

The industry has been pushing ahead to provide resources that can ease the process of rationalization. IBM, HP-Intel-Oracle through their Application Migration Initiative (AMI), and Microsoft through its Mainframe Migration Alliance (MMA), offer tools and techniques worth considering. Some examples include:

• Rational Asset Analyzer (RAA) from IBM
• Options Analysis for Reengineering (OAR) and Architectural Tradeoff Analysis Method (ATAM) from AMI
• Modernization Workbench from Relativity of MMA
• Application Modernization Suite with Discovery Edition from Software AG/webMethods.

These tools can help you carefully analyze your applications and underlying code to study their dependencies and data exchange requirements. Figure 1 summarizes the options available for each of the previously suggested possible groupings from the rationalization exercise.

Modernization Through Services

SOA is more than just one of the options coming out of a rationalization exercise; it’s a technique and discipline that supports other options, both transitional and steady-state. SOA is the future state of enterprise IT architecture.

The tactical gains of virtualization don’t erase the need for transformation and SOA. Cleaning up the infrastructure and making it more efficient should be viewed only as a good early step to meaningful enterprise modernization.

For best results, virtualization and SOA must be pursued together as a complementary set of initiatives rather than in isolation. They also need to be closely aligned with related initiatives such as Business Process Management (BPM) and Master Data Management (MDM). Such an approach creates a flexible, optimized foundation at all critical layers of the enterprise (i.e., infrastructure, data, and business logic).

Even more fundamental to your work is addressing governance and quality; both of which must be integral to the overarching management framework for modernization.

Governance for Modernization

Information Technology Infrastructure Library (ITIL) is a standard for governance; it’s a component of the broader IT Services Management (ITSM) standards. ITSM is an IT framework developed in the mid-90s by the U.K. Office of Government Commerce (OGC); it covers a wide range of IT management aspects such as assets, changes, defects, disasters, efficiencies, and finances. Version 3 of ITIL, developed in 2007, specifically covers aspects of service management, making it a viable governance umbrella you can use on top of SOA.

ITIL provides a business and management context to the concept of services. With its broad support for a service lifecycle that cuts across the boundaries of IT and business, it ensures that application services and business services are aligned. At the core of this discipline are policies and SLAs that are meant to create a metrics-based culture, which can improve the accountability of IT and the SOA infrastructure. The monitoring aspect of SOA, sometimes called Business Activity Monitoring (BAM), provides the dashboard analytics to illustrate the metrics related to compliance of the contracts (specific instances of service-policy relationships).

Quality of Modernization Efforts

Six Sigma, popular in the manufacturing sector since the mid-80s, has penetrated the services sector lately, and specifically IT. When aligned with the five stages in the ITIL service lifecycle (i.e., Service Strategy, Service Design, Service Transition, Service Operation, and Continuous Service Improvement), it can spur the operational efficiency and innovation needed for modernization.

The flavor of Six Sigma typically used in this context is called Define, Measure, Analyze, Improve, and Control (DMAIC). This classic model applies especially well to the latter two stages of the service lifecycle. The other and less explored aspect of Six Sigma, called Design for Six Sigma (DFSS), or Define, Measure, Analyze, Design, and Verify (DMADV), is more applicable for the upstream stages of a service lifecycle and can have greater impact on the architectural aspects of modernization.

Analysis, Design, and Implementation of Modernization

Let’s now turn our attention back to SOA, and the modeling, requirements gathering, analysis, design, and implementation activities of modernization. As a top-down exercise, this process should begin with business modeling or BPM, which is an effort to decompose the enterprise into business components, but only through a collection of portfolios. Techniques such as IBM’s Component Business Modeling (CBM) help identify such components that form the guts of the business architecture; they lay the foundation for the loosely coupled systems architecture to be developed further down the line. It’s at the CBM layer that ITIL and SOA should be aligned.

Complementing CBM are methods such as IBM’s Service-Oriented Modeling and Architecture (SOMA), which help in producing artifacts related to services and their orchestration. These methods support such activities as identification, specification, and realization of services and the corresponding workflow and events. The Enterprise Service Bus (ESB), an interoperable medium for services, events, and data integration across the enterprise, supports these aspects at deployment time.

Going deeper into analysis and design activities related to SOA, IBM has delivered a plug-in for Rational Unified Process (RUP), the standard methodology for application development, called RUP4SOA. Available in Rational Method Composer 7.0, this offering facilitates analysis and design of services. An SOA platform at the crux of a modernization effort would do well to follow Service Component Architecture (SCA), a widely popular programming model for developing truly open services. Open services are critical in fulfilling the promise of responsible modernization of all applications.

A major set of SOA vendors such as IBM, Oracle/BEA, Software AG, TIBCO, SAP, Redhat, Sun, and others back SCA. It supports applications written in Java/EJB/Spring, C/C++, COBOL, and Business Process Execution Language (BPEL). It also supports interpretive languages such as XQuery and Extensible Stylesheet Language Transformations (XSLT). Through extensibility, it also can support the Microsoft .NET platform (C#, Visual Basic), where a competing standard exists in the form of Windows Communications Framework (WCF).

At deployment time, in addition to the core infrastructure components (including applications servers, database servers, ESBs, service registries and repositories, security servers, etc.), these initiatives will incorporate the use of other special-purpose components such as XML appliances, vertical business services catalogs/repositories (sometimes referred to as fabrics), workflow engines, business rules engines, etc., as needed in a scalable, shared manner across the enterprise.

Putting It All Together

We’ve discussed how the modernization journey begins with a select set of high-yield portfolios that can help us lay the foundation for an open SOA platform, where applications of varied legacies can coexist. We talked about ways to rationalize applications and available modernization tools and techniques that can help you achieve maximum business alignment, quality, and openness (see Figure 2).

The reference architecture for modernization, as shown in Figure 3, is multi-layered to support separation of concerns (a fundamental principle of software engineering) and scalability. Each layer is singularly responsible for an IT function and can be plugged in or decommissioned in a non-intrusive fashion as needs and technologies change.

This architecture, at the infrastructure layer, will support the evolving needs of all portfolios across the spectrum, whether highly conservative or fully modern. At the platform layer, it will support services and data of different origins—bound together by an asynchronous service bus that also supports business events and orchestration. The platform layer also will support high-speed data transfer to support bulk loads through Extraction, Transformation, and Load (ETL) to support batch processing and data warehousing. At the presentation layer, it will extend support to batch reports, green screens as needed, Rich Internet Applications (RIAs) through the use of Web 2.0 technologies, mobile client devices, and B2B interfaces through secure Web services.

The sincerity of purpose, thoroughness, and commitment with which SOA and all the associated disciplines are moving together to facilitate modernization is definitely a promise to count on and benefit from. The idea to modernize now might seem questionable in these tough times, but we should actually be thinking about modernization because of the times. When implemented correctly, modernization can be a perfect vehicle to help us navigate through the economic, business, and technical challenges ahead.

By Joe Clabby

Hewlett-Packard (HP) has dead-ended several of its server architectures over the past five years, including the HP 3000 and HP 9000 architectures, as well as its AlphaServers. HP customers with these systems, and those that require more capacity, have only a few options. They can either buy used HP servers (Dec. 31, 2008 was the last day you could order a new HP 9000 from HP) or migrate to another systems architecture.

KMD, Denmark’s largest locally owned IT service provider, was facing these choices; it chose to migrate a homegrown application, called Perspektiv, from an HP 9000 cluster to an onsite IBM mainframe.

Background Information

KMD has close to 3,000 employees and annual revenues of approximately DKK 3 billion (about $570 million or €402 million). KMD operates seven distinct data centers, with approximately 3,000 Windows servers and 250 UNIX/Linux servers. KMD also runs two IBM System z mainframes that process 270 million CICS transactions per month and handle batch jobs. The company’s primary charter is to provide IT and consultancy services (hosted services) to public and private markets.

As a hosted service provider, KMD runs IT services on back-end servers for its clients. But KMD is also an Application Service Provider (ASP) and an Independent Software Vendor (ISV), and markets its own payroll and human resources application suite (Perspektiv) to government organizations and small, medium, and large enterprises. KMD also sells its Perspektiv independently, so some of its customers host Perspektiv on their own equipment.

From the outset, Perspektiv was designed to run on HP’s UNIX operating environment, HP-UX. It was initially deployed on an HP 9000 server, but this environment ultimately grew to four HP 9000s in a clustered environment.

HP announced it was planning to discontinue its HP 9000 a few years ago. It wasn’t long after this announcement that KMD determined it would need more capacity on its HP 9000 server cluster if it was going to continue to meet demand for its Perspektiv program.

KMD had four technology options to address its need for more computing capacity:

• Upgrade to an HP Itanium-based Integrity server (because HP has ended development and manufacture of its HP 9000 servers, leaving KMD with no future upgrade path)
• Move to a competing UNIX server environment
• Move to Linux on distributed x86 servers or blades (an option KMD didn’t see as viable)
• Get creative and find a way to exploit existing computing capacity elsewhere in its information systems environment.

KMD chose to get creative.

Migrating From HP to an IBM Mainframe

KMD migrated its Perspektiv payroll/human resource applications environment from the HP-UX operating environment to Linux partitions running on an IBM mainframe. By doing so, KMD greatly increased its application processing capacity and demonstrated significant cost-ofacquisition savings over a five-year period.

KMD projected it would run into capacity problems on its HP 9000s as far back as 2004. During that year, KMD systems engineers attended an IBM workshop in Amsterdam and explored Linux implementations on IBM’s S/390 architecture. At that seminar, KMD learned it might be possible to cleanly migrate its existing applications from HP’s PA-RISC architecture to a mainframe running Linux.

At first, this idea went nowhere. Other priorities were in play, so the idea came to life and died out several times. But as the capacity problem became more acute on HP’s 9000 systems cluster, KMD needed to take action. KMD studied the feasibility of moving applications to Linux on a mainframe and concurrently studied the financial implications of doing so:

• With respect to porting to Linux, KMD determined that the way its Perspektiv program had been written was consistent with Linux conventions, so porting would be straightforward. According to KMD, “programs migrated and compiled without difficulties.”
• As for the financial implications, KMD considered only three factors: hardware costs, software costs, and the benefits of virtualization on a mainframe. The mainframe alternative won on these criteria.

In June 2006, the business case for moving Perspektiv from HP 9000s to an IBM z9 mainframe was approved. Seven months later, KMD had five of its Perspektiv customers up and running in Linux partitions on a mainframe; the remainder of its customers were migrated in November 2007.

The Financial Case

When comparing mainframe costs to costs for distributed servers, IT buyers are often advised to consider the cost to acquire hardware, software, and networking components, system operations costs (such as power and cooling costs, floor space, etc.) and human-related management costs. But, because KMD already had mainframe capacity available, its business case was simpler and less involved. KMD compared:

• The incremental hardware cost for running Linux on specialized processors in its mainframes (these specialized processors are called Integrated Facility for Linux [IFLs])
• The licensing costs for running multiple instances of software on its distributed HP 9000 servers to the single license costs for running applications in a self-contained, singular mainframe environment; and then KMD
• Calculated the virtualization benefit delivered by the mainframe, which can consistently run at 100 percent utilization vs. an average of 15 to 30 percent utilization on distributed servers.

Using just these three metrics, the mainframe trumped the HP 9000 cluster in terms of projected cost savings. Of particular interest in KMD’s analysis:

• KMD didn’t weigh network cost savings, nor did it measure other potential data center cost savings (in power, cooling, real estate, maintenance, and the like). The savings would have been even more substantial if these costs were tallied.
• The vastly superior virtualization capabilities available on IBM’s mainframe played a huge role in this comparison. HP-UX can be virtualized, but HP has no further commitment to the virtualization of its HP 9000 servers.
• Staffing costs weren’t weighed. IT salaries are high in Denmark, so reducing people costs can have a huge benefit. Distributed environments generally require more people to manage resources than centralized architectures. Accordingly, this is another example of where KMD’s actual savings will exceed the figures it used in its analysis.

The Deployment

KMD was forthcoming in its discussion of the actual porting and deployment processes. Although no substantial issues were reported in the porting of Perspektiv from HP-UX to Linux, KMD did encounter a few performancerelated problems in its initial deployment. KMD indicated that IBM engineers were rapidly dispatched from France to their site to examine the actual Linux installation and deployment parameters, and the performance issues were rapidly overcome after tuning and adjustments.

Further, KMD did report that it “took some getting used to” when describing running the Linux operating environment from inside IBM’s z/VM operating environment. z/VM manages Linux instances in virtualized partitions on the mainframe, so both operating environments run simultaneously on the mainframe. KMD is now, however, used to running Linux in this manner.

The Management Environment

KMD pointed out they prefer to run their organization’s systems/network management environment using HP’s OpenView product line—but OpenView doesn’t run on mainframes. To bypass this issue, KMD long ago deployed IBM’s Tivoli management environment on its mainframes, and with a few extensions, Tivoli can collect Linux activity data and report it through Tivoli to OpenView.

From a monitoring and control perspective, Tivoli can monitor free space in a file system, CPU overload (for instance, if problem looping is occurring), trashing (extensive swap usage) and more, and report these instances to OpenView using a Java-based Linux Agent. Should any of these conditions occur, incidents are automatically registered with OpenView. KMD reports that Tivoli Monitoring, like most management products, does carry some detectable CPU overhead, but this overhead is minor and well worth it in KMD’s opinion to ensure systems are properly running.

Conclusion

KMD’s Linux on the mainframe implementation is significant because it:

• Proves that mainframes can run Linux (and Linux applications) in exactly the same way other platforms run Linux
• Demonstrates a viable way to rehost applications from other architectures on a highly reliable, highly scalable, highly secure platform (the mainframe)
• Provides a viable alternative to HP customers that have run out of capacity on their HP 9000s
• Demonstrates that mainframes are viable platforms for the deployment and servicing of Software as a Service (SaaS) applications.

Regarding the last point, KMD sells Perspektiv as an independently available software product, but also makes it available as a hosted product. There’s no reason KMD can’t also sell this as a SaaS application.

KMD could have replaced its HP 9000 with HP Integrity servers running HP-UX, but moving to an IBM mainframe server made more sense—both from economic and capacity expansion perspectives. KMD found a creative way to expand capacity without having to purchase another, completely different architecture in the form of HP’s Integrity, which is an Itanium-based server environment. This saved KMD and its stockholders a lot of money.

By Mary E. Shacklett

Since 1910, North Carolina Central University (www.nccu.edu) has been teaching arts, letters, and sciences to students. NCCU is located in Durham, NC, the fifth largest city in the state and home to both NCCU and Duke University. What makes NCCU unique is that many of its 7,000 students come from rural areas of North Carolina that traditionally have offered limited employment opportunities. They opt to attend NCCU, located near North Carolina’s Research Triangle Park, one of the most prominent technology research and development areas in the U.S.

Geographically and demographically, NCCU was well-positioned to make a difference in its ability to train employment-hungry students from largely rural communities for companies that were equally hungry for young talent that could supplement an aging mainframe workforce. The initial question was how to best proceed?

In 2004, IBM and NCCU initially discussed the concept of a mainframe skills curriculum. The following year, IBM delivered a formal presentation to educators at the university, followed by a roundtable that brought in more than 20 CIOs, vice presidents, and managers from corporate mainframe customers.

“At the beginning of a dialogue like this, one major challenge is getting educators to realize that the mainframe plays a critical role in the world’s business systems, and that young people should be prepared for this,” says Don Resnik, IBM’s External Skills Leader for System z. “At first, obtaining buy-in from educators is tough. Educators feel that students are already getting technology training on other computing platforms, and they also know they don’t have internal teaching skills for System z. We overcome these objections by holding System z roundtables on campus, where we invite 20 or more of our customers into a room with the educators. It’s the CIOs, vice presidents, and managers of these companies who talk about the criticality of the mainframe to their businesses—and of the need to infuse young skilled workers. They tell educators they will offer internships and employment opportunities for students who come equipped with critical mainframe skills.”

Professor Cameron Seay, who heads up NCCU’s Mainframe Skills program, recognizes some of the same challenges. “The mainframe is a culture and a way of thinking,” says Seay. “Part of the job we have to do with students is to break down their PC metaphors.”

That can apply to faculty, too. Traditionally, universities have focused on scientific computing using UNIX and Linux machines. For many of these academic institutions, incorporating computing and information technology into business management courses has been more of an afterthought, so it was only natural they would try to leverage the in-house expertise in Linux and UNIX they already had, and not mainframes. This is changing as institutions gain awareness that 70 percent of the world’s mission-critical business applications are on mainframes, and that there are resources that can help them establish mainframe programs and gain critical internships and job placements for their students.

“Because of the IBM endorsement of the program and placements early on, this helped establish the enterprise computing program at NCCU,” says Seay. “We voted to add an ‘Introduction to the Mainframe’ course to our curriculum as a requirement for all business majors with a computing emphasis, and we currently have more than 100 students in the program.”

Building a Mainframe Program

An initial challenge at NCCU that’s common to many of the other 550 universities participating in IBM’s worldwide mainframe skills program is a lack of professors on staff with mainframe skills. These teachers need to know that resources and companies are behind the mainframe program—and they gain confidence and affirm buy-in for a mainframe program when they see evidence of companies backing the effort.

Once that occurs, the next step is building a mainframe curriculum and transferring skills to classroom instructors. “When NCCU’s first mainframe class was held in spring 2006, the first two semesters of the course were taught by two full-time IBM programmers,” says Seay. “Each semester consisted of a mainframe introduction course that was aimed at computer information systems majors within the school of business.”

In the classroom, the strategy was to facilitate an accelerated process for NCCU staff to acquire training and expertise with the help of the two IBM volunteers, who would teach the mainframe class the first time. The class was a combination of lectures and lab exercises. IBM also provided NCCU staff with several weeks of training and education at the IBM Poughkeepsie facility, and arranged for mainframe access to support the exercises students would be doing in class.

“Our goal was to focus on teaching students the fundamental skills they needed to enter the mainframe workforce,” says Seay. “These included courses in JCL, ISPF, SPSF, CICS, and database. You also need VM skills for running virtual Linux on the mainframe.”

To apply the skills they learned in class, NCCU students connected to mainframe resources over the Internet. These systems initially were located at IBM facilities in New York and at Marist College, an early pioneer in academic mainframe education that has an ongoing resource-sharing arrangement with IBM. The arrangement gave NCCU staff and students free access to mainframe services and support, both critical factors since NCCU couldn’t fund these resources and services on its own.

“We were excited about bringing the mainframe program on board, but we also realized that we had an education job to do with our students,” says Seay. “Most of our students had little understanding of the mainframe or its role in business. Their background was in the PC world, which is a culture significantly different from the mainframe. In the mainframe environment, you have to quickly run a lot of jobs, which was different from their prior experience. There also are quality aspects of running mainframe jobs, which aren’t necessarily emphasized on other platforms that the students were familiar with. In transitioning to a mainframe business culture, I often tell students that we’re not anti-PC, but that we’re pro-enterprise architecture.”

Partnering With Industry

Partnering with IBM to bring mainframe education to NCCU was a major milestone for the university, but it wasn’t the only base they needed to cover. There was an additional need to build more relationships with potential employers of program graduates.

“We discovered that the larger companies, especially in banking and insurance, take a longer view on their IT workforce and are very supportive of our training programs,” says Seay. “They provide internships and work with us. … At the other end of the spectrum are many of the smaller companies, which just don’t see how the program will benefit them. They are under cash crunches and are trying to solve the problems of today. Many aren’t even looking at the long term and of these, quite a number just assume there are programs out there that will furnish them with the mainframe resources when they need them.”

Seay says he tells companies that NCCU is prepared to deliver a product and that product is the student, while in school, capable of performing a summer internship in a corporate environment on the System z. The students come in to companies with the ability to complete tasks in JCL, ISPF, and z/OS. They’re also capable of running jobs in the mainframe environment.

“Our customers are looking for basic skills and knowledge on the mainframe,” says Resnik. “They continue to train students onsite in the actual business computing environment in z/OS, Linux, z/VM, and some DB2 and WebSphere. We also have a large repertoire of courses that we can work together with universities on. We try to have our customers influence what schools will teach. Sites also know they have a better chance of retaining the students whom they work with.”

One such NCCU student is John Noel, who started in the mainframe program last spring, and has completed the “Introduction to the Mainframe” course.

“I’m now taking other courses in the Business and Information Technology program,” says Noel. “I have two other courses I’m finishing on the system implementation side, with several more courses on the business side. I’ve worked on the System z10 in the areas of z/OS, JCL, and several different subsystems. I’ve been talking to someone at Bank of America, and will be doing a summer internship there.”

Noel acknowledges it wasn’t that long ago when he knew virtually nothing about mainframe computing.

“When I first started hearing about mainframes, I had this sense they were these old, big computers that were phasing out,” he says. “A friend of mine in the mainframe program at NCCU began telling me about all the mainframe applications that existed. He encouraged me to read up on it, and as I researched mainframes, I began to realize [they] had continued to evolve, like other types of technology. I was fascinated that one machine could do so many things, and I became impressed with the mainframe’s phenomenal capabilities.”

Getting Results

NCCU’s mainframe program started small, but its record of securing internships and employment for students and graduates has been nothing short of impressive.

“We’re graduating nine to 11 people each semester, and we already have a track record of five students who have secured entry-level mainframe jobs in industry at $55,000 to $65,000 per year,” says Seay. “In 2008, seven out of nine of our graduates were placed. Another two or three are graduating this spring, and we’re anticipating placements for all of them.”

Seay is quick to point out that the success of NCCU’s mainframe program should be credited to the students. “The mainframe enthusiasm was driven by the students, and if our students hadn’t performed their jobs capably in company internships and employment positions, we wouldn’t have been successful,” he says. “Many of our students come from rural North Carolina, with limited educational and technology backgrounds, so … all you have to say is that by acquiring mainframe skills that companies need, they will be able to land good jobs.”

As part of the students’ education, Seay takes them to events such as SHARE because it lets the students interact with mainframe professionals.

“We’re building a ‘counterculture’ to what these students have been used to,” he says. “So, it’s invaluable for them to rub elbows with professionals who are doing the jobs they aspire to do.”

Although Seay says NCCU is securing a growing number of placements in the mainframe environment, he also acknowledges that “everyone wants mainframe programmers with 10 years of experience.” Given the mainframe skills shortage, there isn’t an easy fix for enterprises looking for that combination of skills and experience. Nevertheless, it’s causing institutions such as NCCU to take a hard look at building their mainframe programs.

“In the future, I would like to have a four- to six-course sequence in a mainframe program that students can take so [they] can be even more market-ready,” says Seay. “These courses would include not only the introduction to mainframes, but also courses such as networking with SNA, security, Assembler, DB2, JCL, and VM. We also would like to grow more business partners that will provide internships and employment opportunities for these students and more regional industry contacts within the state of North Carolina.”

Moving Forward With Best Practices

Mainframe education programs such as the one hosted at NCCU continue to yield insights on how educators, technology providers, and enterprises can all work together to address present and future business needs for mainframe skills. The keys are identifying critical success factors that facilitate skills training for industry—where it’s badly needed. The work at NCCU and other universities has identified several important success factors:

Classroom motivation: “One of the reasons the mainframe program has worked very well for NCCU is that Seay has been very motivated to get jobs for his students,” says Resnik. “The students also see value in working with larger organizations. The key is motivation in the classroom that enables the students to see the possibilities of employment and marketability of the System z skills they acquire.”

Strong working relationships among technology providers, academic institutions, and companies: Establishing relationships with professors who may not have any prior background on the mainframe can be a daunting task. The best way to build relationships is to find a specific professor at an institution who understands what the program is capable of achieving for student knowledge and job placement. The other side of the equation is cementing relationships with companies in industry that are in search of mainframe skills and are willing to place the students in internships and, ultimately, jobs.

Focus on market needs for superior student placement results: Many academic institutions can fall into the trap of continuing to teach courses that may once have been on the mark for industries that would hire their students, but no longer are. This is further complicated when professors continue to teach subjects they’re comfortable teaching, but which may no longer be aligned with major industry skills needs.

“The primary mistake academic institutions make with their technology programs is that they eliminate training students for the enterprise and for enterprise computing like the mainframe,” says Seay. “This is a problem because it has never been an issue that the PC would replace the mainframe. The two complement each other. There was a period in the ’80s when we were hearing that the mainframe was ‘dead,’ with analysts telling us that industry would simply chain processors together into distributed computing architectures—but the complexity of that, coupled with all those unused computing cycles, didn’t make sense. Nevertheless, this resulted in an entire generation of students not being exposed to mainframe technology. Now when someone tells my students the mainframe is dead, they just laugh.”

Making resources available and shepherding the program: Both IBM and Marist College initially gave NCCU free access to mainframe resources. Illinois State University and the University of Arkansas also assisted with mainframe resources.

“This program wouldn’t have happened without the help of IBM and of the National Science Foundation, which funded a mainframe study grant for eight or nine universities in the U.S.,” says Seay.

IBM also loaned two full-time instructors to take NCCU through the first year of the new mainframe program. This gave both professors and students time to get acclimated.

“The process is gradual at first,” says IBM’s Resnik. “Many schools first adopt a mainframe skills program through their extension courses. They then move into oneyear mainframe skills programs that fit into their undergraduate curricula…Most of them rely on IBM to connect with industry partners.”

Conclusion

With more than 550 worldwide universities enrolled in IBM’s System z Academic Initiative, IBM is making a major push to ensure tomorrow’s businesses aren’t short of mainframe skills. Just as important, more educational institutions are beginning to see the value and the need for mainframe training, and are proactively approaching the development of such a program. Institutions such as NCCU are paving the way.

“I tell students that we’re preparing them to run the world, and not just mainframes and technology,” says Seay. “I’d be very surprised if some of them aren’t CIOs in 15 years because it’s how you solve the problems of business with technology that matters—and that’s what we’re teaching.”