HP Helps Transform Legacy IT Environments by Delivering Simplicity, Agility and Value with Reduced Risk and Lower TCO

HP (www.hp.com) is helping financial services companies modernize their IT architectures and application environments towards a new future state, one that more fully aligns with the needs of the business and IT. This in many instances is a Services Orientated Architecture or SOA. Based on methodologies from the Software Engineering Institute they provide a portfolio of services that provides a ‘lifecycle’ of offerings to facilitate a pragmatic modernization of the software environment. They begin with a direct focus on the legacy system, concentrating on the rationalization, selection and decomposition of legacy architecture. Selection, evaluation and design of replacement architecture are also a focus of the services.

According to Richard Holling, worldwide director, insurance, financial services industries, “the goal is to offer clients an object assessment of the modernization options, their costs, risks and benefits.”

At HP, that means application rationalization, application modernization assessment and application modernization analysis.

WFS: Richard, is there truly a legacy crisis?

RH: The very breadth of the crisis defies imagination, yet we know all too well its size. The year 2000 problem brought sobering metrics. A decade ago, there were an estimated 120 billion lines of legacy code, primarily COBOL and FORTRAN2. Today, the Gartner Group estimates that approximately 10,000 mainframe application systems worldwide contain 200 billion lines of code. In addition, the average Fortune 100 company maintains 35 million lines of code and adds about 10% each year in maintenance and enhancements.

WFS: How would you characterize a legacy system?

RH: Systems don’t have to be hosted on a mainframe to be considered legacy systems. Any system that significantly resists modification and evolution to meet new, constantly changing business requirements can be considered legacy.

Characteristically, they include large code bases often exceeding millions of lines of code. Some of that code is brittle and sensitive, meaning very expensive to maintain. They’re usually well over 10 years old, often mission-critical, built around legacy databases and consist of dozens to hundreds of independent applications.

WFS: How much of a typical IT budget is spent on maintaining the current environment?

RH: According to the last Celent insurance CIO report, ‘Insurance CIO/CTO Pressures, Priorities, Projects and Plans in 2007,’ around 60%.

WFS: Few firms can absorb that percentage. It’s also starving creation of innovative business applications, isn’t it?

RH: Yes – and not just in budget terms. Key initiatives need integrating to these older systems.

WFS: Why’s the lead-time for response to a firm’s business needs taking as long as six months? Is this causing ‘frustration’ between business and IT staffs?

RH: IT departments have conflicting goals. Uptime is usually a key component of SLAs. The best way to achieve uptime is to not change anything. Inertia is in-built. Then, when change has to happen, poor documentation and a graying workforce conspire to delay things further.

As for seeing frustration between IT and the business side, yes and often that requires a third party to step in and mediate.

WFS: Can conflicting qualities of agility and performance ever coexist?

RH: Of course, the key is those characteristics at the front of any design process.

WFS: Can vendor-oriented, distributed architects grasp the nature of the mainframe paradigm?

RH: Yes, but remember that architects are now drawing on well over a decade of experience.

WFS: How can a procedure-centric, batch-driven system shift to a nimble distributed system without destroying the company?

RH: I think you should ask, ‘can a company survive with systems that cannot change?’ In emerging markets, there’s virtually no legacy. How long before those insurance companies start to move into mature markets?

WFS: Where are the risks and how can they be mitigated?

RH: That question requires a multi-part answer. First, mainframe architecture is not mapped easily onto the distributed model. Its code doesn’t necessarily always transfer into distributed code. Often, it may be replaced by modern architectural services.

Next, mainframe workloads don’t always fit into a typical distributed system symmetrical architecture, particularly batch processing. Their workloads also present performance problems for modern managed-code platforms, such as J2EE and .NET.

Third, legacy business logic may map to multiple locations in the target architecture.

Fourth, testing and validation of re-engineered functionality is difficult to devise and automate.

Fifth, objective decision criteria must be presented to decision makers.

Sixth, risks must be identified early and mitigated vigilantly.

And seventh, costs and ROI must be weighed early.

WFS: How are CIOs, now faced with a spectrum of modern architectures and a confusing array of design choices, dealing with pressures from inside and outside of their organizations?

RH: Decisions on target architectures are made with thorough oversight, sometimes because of pressure from incumbent vendors due, in part, to basic human nature, such as the Woolsey-Swanson rule.

WFS: Which is?

RH: People would rather live with a problem they cannot solve than accept a solution they cannot understand. Premature decisions can also be caused by a simple misunderstanding of the importance, complexity and consequences of the choice. Often the truly significant questions are never asked because the choice of an architectural style presupposes their answers.

For example, it shouldn’t be a choice between .NET and J2EE before it’s a choice among more critical architectural qualities. Often these questions are not asked because the opportunity to frame the questions comes too late.

WFS: What architectural scenarios surround the most critical functional aspects of the target architecture?

RH: Before getting what you hope will be the right answers, you need to start by asking the right questions.

For example, which quality attributes are evident in these scenarios? How may the quality attributes be quantified? What is the impact of the quality attributes on the target system? What risks are evident in meeting these quality attributes? What server resources are most stressed in the current workload? What are the arrival rates of my online transactions? What should be the service rates for my online transactions to prevent saturation of my servers? Can managed code handle my batch workload? And, can I effectively decompose and possibly eliminate my batch workload?

WFS: Application modernization is a vital component of any organization’s IT strategy. What’s driving its importance?

RH: The pace of change in the business world continues to increase. Modern business markets are brutal and you simply can’t tell a customer our systems don’t allow us to do that.

WFS: Should application modernization be viewed as the ‘norm’ or the ‘last resort’ when considering overall IT modernization? And why?

RH: Application modernization has to be the norm. We’re not just looking to reduce cost through re-platforming. Old apps on new systems are still old apps and in the perception of many business managers, that’s not money well spent.

WFS: What role should SOA have in future state?

RH: Distributed systems have evolved and SOA is the latest step in the continuing advancement of technology. SOA promises in-built agility and should provide a sound basis for the never need to change business functionality in applications.

WFS: Richard, thank you.