KeyCorp focuses on integration, simplification

IT initiatives range from data marts to CRM, and CIO Bob Rickert has to cleanse legacy data and reconcile legacy apps.

With two data centers, more than 1,400 IT employees and an array of disparate systems to manage across its many bank branches, simplification is a central theme connecting KeyCorp's current and planned IT projects. CIO Bob Rickert spoke with Computerworld's Robert L. Mitchell about KeyCorp's technology agenda and the IT challenges facing the Cleveland-based bank.

Q: What critical technology projects does KeyCorp plan in the next 12 months? Web-based XML messaging is one thing we're trying hard to implement. We have a package type of environment where we buy different things, be it Oracle financials or brokerage trading systems, and the mission is to integrate that stuff.

We're really trying hard to improve the reliability of our systems, and the productivity of our development organization and the messaging [project] play to both of those themes. I'd like to simplify out the environment.

Q: What approach are you taking? We formed a group, the [Component Architecture Reuse Team]. It's an application architecture team, and they're developing the middleware objects to try to link some of our legacy systems. Part of the goal is to simplify the environment by reusing some of the components. We're trying to drive the productivity of new development up as well.

Q: What else is on the IT agenda? We have put a lot of effort into an enterprise data warehouse project. We want to capture not just the immediate transactions our customers are doing with us, but also historical transactions. We want to build very good models based on historical experiences around the risks of default, or what have you, and use them to help price our products.

We are using a data warehouse/data mart architecture. Our whole concept is to have a central master data store [from which] we can then ship the data down to others for specific ad hoc reporting or modeling.

Q: What issues did you have to overcome to build a data warehouse? The limitations we're running into are . . . data quality limitations. As you round up all these disparate databases that have all kinds of different historical roots, just reconciling all this data and getting it clean is where we are most challenged right now. We are really living with the consequences of some of the sins of the past.

Q: Once the data is cleaned up, how will you leverage that? Where we are going with the data warehouse is [to focus] very heavily on customer relationships. We're putting a lot of effort into mapping out a strategy for a [set of] CRM-type systems.

[Today] we have a set of CRM-like systems that are in many ways homegrown. But these systems are not completely integrated. They're point solutions, and we're trying to move off that onto an enterprisewide customer relationship system.

Consolidating all this data and getting a single view of the customer information in the database will form a good foundation [for] our CRM system. We'll be kicking that [CRM] project off in the third or fourth quarter of this year. What we're trying to do now is make sure that the business units are heavily engaged in this effort.

Q: What other projects are on the front burner? In our information security arena, we are implementing [IBM's] Policy Director . . . which consolidates a lot of the Internet sign-on, user ID, authentication and authorization functions. In the past, we had every app building its own [authentication systems] or using somebody else's system. This is really a big deal.

[Policy Director] involves a segregated network where the Internet connection will come in [to] some Unix machines that have a hardened OS and Policy Director sitting on top of that. Then there's a set of APIs that Policy Director exposes that the applications can make calls to [in order to] authenticate users. We're hoping it will simplify the whole effort associated with doing customer authorization and authentication.

Q: How is the Policy Director project progressing? We struggled a bit with it, but we seem to be on a good track now. [IBM has] really been heavily dependent on third parties to offer service and support. That didn't work out well. We wound up having to push pretty high into IBM . . . so we could get access to the development folks [in order to] better understand the API set. IBM and I think they've learned this probably needed to be more engaged in the project rather than rely on a Deloitte & Touche or a KPMG or whomever . . . especially if [the user] has big, complicated environments.

Q: What common issues do you face in rolling out these projects? As we try and simplify the environment, that's going to require retooling of peoples' skill sets. There are a lot of cultural obstacles to be overcome, and we're working our way through that.

Q: What are your biggest gripes about the state of IT? The vendor community in general is too uncontrolled in the changes and the enhancements that they make. . . . What that presents us with is whether we are ready to migrate to the next generation . . . or whether we should stay with this old platform and then have to deal with service and support on maybe an unsupported platform.

The vendor community needs to move to more of a predictable, scheduled release [of upgrades]. They [should] support a couple of versions back and you can choose which one you want to be running on, so you don't always have to leapfrog to the latest and greatest stuff, which generally is not the most stable.

My second complaint is that many vendors don't focus on service and support of their products the way they should; they're all focused on sales and presales activity. Cisco does a particularly wonderful job of after-sales support. But we've had a fair amount of struggles with a number of other vendors, keeping their attention after they've gotten the check and dropped off the product. If they would more often [make] sure the customer is able to use the product successfully, it would make life easier for us.

Ask for Help

Rickert offers the following advice to IT professionals who face technology decisions similar to those at KeyCorp:

-- If you haven't done it before, assume you're going to have a lot of problems.

-- You're going to need help from whomever sold you the technology, and you should get that help locked in early.

-- If for some reason you get into trouble, don't beat your head against the wall. Go call [the vendors] and make them help you.