To some people application modernization is a specific technology, user interface, or application architecture. For others, it's the scary specter of change without any concrete benefits. For many people, application modernization is a goal so nebulous that it's impossible to accomplish. The result is that the System i community has been arguing about just what application modernization means for at least a decade, while most System i shops have made limited progress toward achieving it.

One reason for this stalemate is that, from a technology perspective, application modernization is a constantly moving target. Client/server has given way to browser-based interfaces; the exclusive focus on Java has been replaced by a wider range of options that includes PHP and .NET. System i developers have flirted with Struts, Servlets, Java Server Faces, JSPs, WebFacing, Ajax, CGI . . . . The list is endless and ever-changing. Worst of all, nobody agrees on the "best" approach — in fact, most "experts" disagree with their own opinions from just a year or two ago. In an environment where software often has a lifespan measured in decades, this lack of direction is crippling.

An Alternate Route

To escape from the quagmire of technology indecision that has stalled many System i application modernization initiatives, it helps to ignore the technology (at least initially) and focus instead on business benefits. Once you define specific, measurable results, you'll probably find it easier to figure out how to move your project forward, instead of worrying about ever-changing technology trends and the near certainty that there will be a better technology next week, next month, or next year.

You might try thinking about application modernization as if it were a major purchase in your personal life — buying a car, for instance. Sooner or later, you have to choose from the available options and make a purchase, even though in a year, or two years, or five years, the choices will be better (or at least different). The same essential logic applies to selecting technology for application modernization — choosing something that's available now and that will achieve your business goals is much better than waiting for the "perfect" technology that's always just around the next corner.

In addition to giving you a way out of the technology indecision that plagues System i application modernization projects, defining application modernization in terms of results resonates with managers who are vital to the success of any IT project.

Identifying the Stakeholders

Understanding how your project affects end users and helping your programmers develop new skills are important goals, but for too long, application modernization has focused on programmers and data-entry personnel. If you want your management team to invest resources in a project, you must focus on business decision-makers, define the results you expect to achieve, and explain them in terms that make sense to managers. Instead of extolling the virtues of a particular programming language, development strategy, or user interface, you'll get better results by explaining the business problem you're trying to solve and the business benefits of your proposed solution.

The issues you highlight should take your audience into consideration. Though all managers have some goals and concerns in common, a manager's specific goals depend on that person's role (or roles) in the organization. Top-level corporate managers (CEO, CFO, COO, and CIO) have different concerns than line-of-business managers, for example.

Within these larger groups, each manager has specific, and often competing, concerns and goals. For example, people who manage resources such as personnel and facilities tend to look at IT projects differently than their counterparts in marketing and sales. Managers who are responsible for creating products, whether on a manufacturing assembly line or in a hospital surgical theater, have yet another view of application modernization projects.

Though we can divide stakeholders into categories based on their roles in the company and their goals for a particular project, it's important to remember that each manager has additional aspirations and concerns that may not always be apparent. Being aware of these individual needs can be the difference between success or failure; projects can be sabotaged (intentionally or unintentionally) by misunderstandings and unfounded fears just as easily as by technology roadblocks or lack of funds.

To explain your application modernization projects effectively, you need to consider the different management roles and the goals and concerns each group brings to the question of application modernization.

At the Top of the Food Chain

First, let's consider corporate managers such as the CEO, CFO, and COO (the CIO is a special case). Depending on the size of the company, these people may be directly involved in application modernization decisions, or they may delegate responsibility to others. Either way, because these managers ultimately control the allocation of resources, no significant project (whether it's an application modernization project or a new product rollout) can succeed without their endorsement.

At this level, all managers are concerned with questions that affect the entire company and potential return on investment (ROI) — first, whether or not there is an ROI, and second, whether the ROI is commensurate with the risk.

The CEO is concerned with how to deploy various divisions and gain competitive advantage, so IT solutions that can adapt rapidly are important. For example, if your company acquires or merges with another company, the CEO expects the IT systems to work together seamlessly. To address the CEO's need to assimilate changes quickly — whether they are driven by competition, acquisitions, or other market forces (e.g., rising labor costs) — you should consider application modernization techniques that make it possible to invoke applications through clearly defined, language-neutral interfaces, a strategy that falls within the general definition of service-oriented architecture (SOA).

Top-level managers, like every individual in the company, are also concerned with access to data, both for themselves and for the people who report to them. The CEO needs to contrast and compare your company's performance with measurements for other companies in your business and the overall business climate. For example, the CEO might compare your company's stock price with the stock price of a competitor, taking into account each company's market share. To capture the CEO's attention, you need to deliver an integrated view of both internal and external data in a seamless, intuitive interface.

The CEO needs information delivered regardless of location — at work, at home, or on the road. As a result, you may find that your CEO is particularly enamored of projects that facilitate platform- and language-neutral data presentation using nonstructured data and asynchronous messaging. Just don't try presenting the project from a technical perspective; you'll likely get much better results if you explain that your project will make it easier to deliver sales reports to the CEO's hotel room via cell phone.

The CFO's perspective is similar to that of the CEO, but naturally focuses on financial and compliance issues (e.g., SOX, HIPPA). To address these requirements, you need to provide the CFO with solutions that integrate financial information from multiple sources while retaining an audit trail that meets regulatory requirements and can be verified by people whose expertise is accounting, not IT. On a personal level, your CFO is probably comfortable with spreadsheets and will likely welcome any application modernization project that makes it easier to work with corporate data in spreadsheet-like applications.

The CFO has many responsibilities related to security, so expect questions about how data integrity and privacy are maintained throughout the system. The CFO may ask you to develop solutions that reduce the vulnerability of credit card numbers, Social Security numbers, and other sensitive personal data used by your applications. For example, the CFO might initiate an application modernization project that requires encryption of Social Security numbers or that replaces Social Security numbers with some other unique identifier, such as an employee number or a patient number. The CFO will also be interested in solutions that ensure documents, from e-mails to spreadsheets, are secured, managed, and archived properly.

The COO has a more operational view of the business than either the CEO or the CFO. A COO is typically concerned with the overall business process and making sure data is flowing from one system to another. Solutions that eliminate re-entry of information and manual distribution of reports, for instance, make sense to the COO. Because a COO may be responsible for units that are geographically dispersed, the COO will probably also be interested in solutions that make information available independent of location, such as web-enabled business intelligence applications. The COO may also have particular concerns about data security and encryption for mobile devices, such as laptops.

Understanding Your Boss

If you're a CIO, you can skip this section, but for those who report to the CIO, it's important to have a good understanding of how your CIO measures success. While the CIO shares the concerns of other top-level managers, as the leader of the technology team, a CIO is responsible for aligning IT initiatives with business initiatives.

Unlike with most other top-level managers, you should expect the CIO to be concerned about the technologies and application architectures you select. The details may not be important, but the CIO will want some assurance that you've considered the potential stability and longevity of the technologies you're selecting and any business partners who will be participating in your application modernization efforts. The CIO may also ask for your assessment of design and development techniques such as agile programming, model-driven architecture, and universal modeling language (UML). You should be prepared to explain why you're using specific "modern" development technologies and practices (or why not).

The CIO has broad responsibilities for data security and system availability, including a mandate to protect backup media from theft or destruction. Your CIO may want to know which data is encrypted and something about the encryption solutions you're using. The CIO will also be interested in factors such as source-code control and software-configuration management that help improve the long-term maintainability of IT solutions.

Forging a Partnership

Often the immediate instigators of application modernization, line-of-business (LOB) managers play a vital role in selecting modernization projects and ensuring their success. Higher level managers, such as the CEO, usually pay close attention to the concerns raised by LOB managers, such as lack of access to data and long development cycles.

Business intelligence solutions that make it easier to access the data a LOB manager needs to make decisions — whether it's a sales report or a list of open positions — will get the support of LOB managers. You should look for technologies that make this management information more portable (e.g., web-based interfaces) and more accessible (e.g., graphical displays).

LOB managers are at the front line of integration between systems (both internal and external) and will be directly affected if integration is expensive or incomplete (e.g., requiring data to be re-entered). Depending on their particular responsibilities (e.g., sales versus manufacturing), LOB managers will be interested in solutions that address issues such as system downtime (i.e., high availability), supply-chain management, and customer-resource management.

Like the CEO, LOB managers are looking for ways to squeeze out competitors and drive down costs, but they're also looking for ways to cooperate and communicate with vendors and customers. To facilitate those interactions and to fulfill contractual obligations, LOB managers may need solutions that incorporate technologies such as RFID and web services.

While LOB managers can be champions for application modernization, they can also be your most vocal critics. It's part of your job to make sure that LOB managers understand any trade-offs made in the new application design.

Focus on Results

Generally speaking, as each new technology enters the spotlight for its 15 minutes of fame, IBM has provided System i-specific solutions. Not all of these solutions have been embraced by the System i development community, and you can certainly make a good argument for rejecting some of the solutions that IBM has offered. However, perceived lack of appropriate technology is not a valid reason for System i developers to reject application modernization out of hand. Instead, you need to find the tools and technologies that work for your environment and move ahead. But don't procrastinate so long that you find your System i replaced by a fleet of Wintel servers.

The System i development community has been talking about application modernization for a long time. However, a new century requires a new approach to application modernization that focuses on business results. This is a different view of what application modernization means, why it is important, and how it is cost justified. Fortunately, IBM is investing heavily in technologies that you can use to modernize your applications and deliver the results your management team is looking for.

Carson A. Soule is an System iNEWS technical editor and the CEO of CAS Severn, Inc., an IBM Premier Business Partner in Laurel, Maryland. He is a frequent speaker at conferences and seminars worldwide.

Sharon L. Hoffman is a System iNEWS senior technical editor. She began working with IBM midrange systems in 1981, and her background includes extensive application development as well as creation and delivery of technical education.