NewsWire Q&A: Harry Sterling

General Manager, Commercial Systems Division

A New GM for the New Year

What I've learned with the customer focus, and how important it is to work closely with customers, will help me most in my new role. I had contact with customers before, but it was in a very different style. What we learned in CSY in the past two years was to be in listening mode rather than tell mode. In the past we had a solution in search of a problem. That's the major change we've made over the last three years, going into listening mode much sooner in the process.

We're trying to understand the customer and business environments, then making our investment consistent with that. We look across HP and figure out what are the ways we can provide the best solution for the environment.

I don't really see that we're going to make any major changes. We're going to keep the same structure that we have. We have a good strategy. We're in the midst of our planning process, and I think we'll keep tuning the process as we go.
We are no longer platform-centric. We're not necessarily focused on providing the 3000 as the only part of the solution.

The others aren't as far along in that as we are, but they're certainly trying to move in that direction.

We've never actually converted a 3000 to a 9000 under one of these arrangements. I do know that we've converted a 9000 to a 3000. The customer chose to go back to the 3000 rather continuing with their 9000 implementation.
This is not something new. We've been doing it for over a year, but it hasn't been on the price list. In the one case I'm familiar with, they felt like if they had this guarantee, it would make the purchasing process easier for them. The issue we're facing is the up-front purchasing decision on HP 3000s. We're finding some MIS directors get hit with a lot of questions about standards when they go to consolidate. This kit is simply a way of making that process easier for them. It became an easier process for the salespeople if they have this kit available.

I hope not. We did this because the customers told us it would make it easier for them to purchase HP 3000s.

If the customers tell us that's what they need, then we'll do it. Right now that conversion is a factory special, and we can do that. It's a lot of internal work for us to put it on the Corporate Price List.

To further improve our ability to work closely with customers and to really execute our plans and strategies. Two years from now when I look back, I'd like to know that we've done the right thing for the customers, and that the customers are still saying that CSY is the best division to work with.

They'll feel the investments made in products offered by CSY were a wise investment, and they won't have any regrets in making those investments.

One of the key steps is for me to work very closely with GSY in terms of integration with our Unix platforms and with NSD in terms of integration with our future NetServer and NT server platforms. We have to be realistic about looking at the environments in the customers' sites and be able to have our products fit very well. That requires that we work very closely with some of our key business partners.

I think that's true of every R&D organization, don't you? Aren't there always more good ideas than there are people to work on them?

If you talked to some of GSY's customers and found out what they want in terms of new features, you'd get a similar answer: we're not able to do everything as quickly as customers would like.

Absolutely.

Development budgets are set in direct relation to revenue. How much money our customers spend with us will determine how much we can afford to invest in R&D. That's the bottom line. One of our corporate objectives is profitability, and every division is held to a profit objective.

That's not something I can answer. We are both profitable, but I can't be more specific than that. It's a matter of degree and volume.

I was responsible for setting up that whole relationship when I was R&D manager, so there are no plans to change anything. The plan is that they are an extension of our R&D organization and we will use them wherever they can add value. The one thing I do want to do is to get them more involved with customers. I'd like to take advantage of the fact they're on the other side of the ocean and get them more involved with European customers.

There's certainly more that we could be doing. It's a question of prioritization and investment levels we're able to make. We are not a database company or a database division. We are attempting to provide a total solution for our customers. When we come across a customer need we will look at all existing products in combination with future investments. We want to balance all that to come up with the best solution for the customers.

Absolutely. IMAGE/SQL is a core competency and part of our solution. And we're going to continue making those investments.

We're currently evaluating that, and I don't want to make a comment on that right now. We'll be making an announcement on that in the next few months.

Yes. The VARs are very pleased with the work we've done with SQL on IMAGE. I was in Atlanta talking with one of our channel partners, and they are trying to move their product to use the SQL rather than IMAGE interfaces so they can be more portable and offer their product on Unix in the future. They want us to do continued work with performance improvements. We're going to work with them to better understand how we can tune the SQL interfaces.
There are other examples where we're working with customers to understand what we need to do with IMAGE itself - where they're not using SQL. We're going to keep working with the customers, working through SIGIMAGE, very actively to understand what the future needs are and continue to make those investments.

Yes. The real issue with a 64-bit version of MPE/iX is not so much performance as it is scalability. We're finding that our larger customers are becoming concerned about putting all of their applications on a single box. In some cases they're looking to move to more of a cluster environment, so they don't have quite the risk of failure of having all of their users off the system. We're trying to understand if it's better for us to continue to scale up in terms of the size of the box, or would we be better suited to work more on a clustering technology - like Shareplex - in making that a better solution. You could increase performance by adding a new cluster.

No, because the clock cycle is still the same. What 64 bits gives you is larger addressing. As long as we can continue to gain the performance improvements of the faster chip, we'll continue to scale performance-wise. We may not be able to have as many users on the system or be able to run as many applications as you could with full 64-bit implementation. It's not clear that's the direction our customers want to go. That may not be the for the mission-critical environment.

Exactly. We had one in particular that had done a consolidation onto a single box and now they're backing off to two boxes, because of a problem in doing backups and in doing system maintenance. Two boxes gives them more flexibility in shifting their users between them.

We may not want to go any higher than where our capacities are already. We may now want to move toward clustering technology. Maybe 2,000 users is enough.

That would be the only area that we would actually have an advantage today by using 64 bits. We actually do have internal 64-bit addressing already in MPE. We may begin to evolve, and as we need to change limits we may start to slowly start using 64-bit addressing. It's not going to be a massive, one-shot project for us. It will be more of an evolutionary transition. As we need some new capability that 64 bits may give us, we might do that.

We're not going to have a massive 64-bit conversion. We'll evolve as we need to take advantage of that. Right now I'm not sure we know where we need to use 64-bit and where we wouldn't.

About every nine to 12 months. We're still looking at platform releases every 18 to 24 months. We're already planning the release after 5.5.

I don't have a specific goal other than to continue working with our strategic VARs and VABs, which is primarily how we sell our systems.

One clear differentiator is ease of use. It's still much easier to use a 3000 than a Unix solution.
I'd like to think it's the relationship that customers have with CSY more so than the platform. Our objective is to have the customers believe when they spend their dollar on an HP 3000 they're getting the most for that dollar. It's a matter of protection investment and lasting value. Our customers don't see that when they purchase another platform. If our GSY friends get to that level, then I think our customers win overall.

We're always looking for ways to get the message out to customers, to have a two-way dialog. I'll continue to keep the organization focused on customer contact and communication.

Co-existence, to have the 3000 exist in whatever evolving environment the customers have in their business climate. We haven't done a lot yet to understand from the R&D side what coexistence means from an NT perspective.

It could, by working with some our VARs who are positioning their solutions to a new customer. If their customers know the new 3000 solution could easily link into their existing environment, it could be a real advantage.

No. I'd rather work with those companies individually, to try to come up with a kind of deal that would let them have that kind of capability at the lowest cost possible. If we tried to use a Unix workstation as a platform, there's no NIO bus for us to have I/O with, so we'd have to write all new I/O drivers for the peripherals that would be integrated in the box. We'd have to leverage an existing box. It would be a huge investment for a very small payback. I don't think the cost of the development platform is an issue.

We're attempting to make the 3000 as flexible as possible, to meet the needs from both Unix and MPE directions. Our coexistence strategy does provide the customer with the applications they need, without having to change their current environment. The installed base is growing today, because we have very strong third party VABs selling new applications to new customers.
We're not being real successful in terms of attracting new applications, and it doesn't have anything to do with the platform itself. It has to do with the VARs ability to support multiple platforms. That's why we've moved to the coexistence strategy. We're done our work in the past couple of years in trying to attract many new applications to the 3000. The bottom line issue for a VAR is what's the largest market opportunity for them to sell their solution, and how much does it cost for them to support their product on multiple platforms.
Even though we have made the 3000 compatible in terms of portability, it's not a platform that most large application vendors are willing to support. They're even limiting the number of Unix platforms they're supporting.

That the 3000 is going away. That's the myth that I want to go away. I want customers to believe and know that when they buy a 3000 it's a good, wise decision when it's best suited to meet their needs. We in CSY and HP are going to be here to support them well into the future, to ensure their purchase is of lasting value and that they can evolve to the future, whatever that is.

Go back to the NewsWire Planning table of contents