Click here for HP Sponsor Message

New Opportunities for HP 3000s

NewsWire Q & A

Harry Sterling came to HP World '97 with a bag of goodies for HP 3000 customers. The general manager is coming to the close of his second year as head of the Commercial Systems Division and he's used his time wisely -- mostly to get specific business cases from a customer base he appears to know well and then translate them into the products they need. When Sterling took the GM post after a decade in MPE development, the word on him was that he's capable of changing his mind about things after he gathers adequate information. Seeing a shift in 64-bit strategy for MPE/iX and watching a 3000 application developer's bundle appear proved that point at HP World. Good profitability and beating quota for many quarters has earned Sterling's division some grace and elbow room to try and extend the 3000 market. And cutting a deal with Netscape for a bundled 3000 Web server also impressed many observers, perhaps one of the best measures of how far the 3000 division has come since Sterling's arrival. In assembling his own management team over the past year he's had the opportunity to put his own stamp on HP 3000 policy. We asked him at HP World to outline how things have changed, and why.

How have things changed for the 3000 division in HP's current organizational climate?

The climate right now in HP with the restructuring of our field organization is ripe for us to basically go in there and say: This is the way we're going to do it for the 3000 business. Frankly, we're getting very good support from our managers because we're so successful this year. We're doing very well from the business point of view and consistently what we're being told is: "You've got the formula; it's working for you." We're not going to mess it up. We're basically being allowed to put the structures in place that we feel we need for our business. For us, it's really an exciting time right now. Really exciting for us on the management team looking out into the next year. We've got some really good opportunities for the next 12 months to do some brand new things.

You know I don't talk about that. We don't talk about our financials. Just say that we're doing very well. We're having a successful year.

Yes. This is basically an annual cycle. We just concluded visiting about 25 or 30 customers. We typically do that number about every two years and we sort of take a smaller check point on the off years. This validates current plans and it helps us know where things have changed, where there are new trends, new opportunities that we can move forward. This part of that process is what made us conclude that we needed to do some major investment on the high end from a performance perspective.

That's when we launched the Technology Council. We pulled together all of our architects, including three from Bangalore who joined us for about a month. We had intensive architecture discussions about where our current performance issues are. That led us to the conclusion that two major areas have to change: memory manager and virtual space management. We also already knew we had to do the file system for 64 bits. We had already initiated a rewrite of the transaction manager last year in Bangalore -- that's still underway. That piece has also been brought into the architectural discussions.
As a result we have a huge, thick document that contains all of the potential things that we can work on over the next three years. We wanted to take at least a three -year look of what we needed to do, also understanding what new chips were coming and what's happening with the compilers and how we can take advantage of all those, leveraging the rest of the work that HP is doing.

Now we're in the process of assimilating that information, understanding what the current customer needs are over the next three years and figuring out how do we now take this architecture and map it into that three -year plan and how to phase it out over the next three years? That's the piece that we're working on. We are about ready to launch our Solution Teams for next year. I think we've currently got about 10 solutions identified, although we don't know how we will phase them and how many we will actually initiate.

There is no limit. It's basically a combination of two things. First of all, somebody expressing an interest that they want to work with us. And then, our architects working with them initially in discussions -- listening to their ideas, listening to what their design thoughts are. Basically, assessing their ability to do it. Then if it seems like a good match, we will work with them to do that.

It's a pretty loose process, but it's engineers talking with engineers, basically. And then if we agree that it's a go-ahead, then we go through the nondisclosure. Particularly if we're giving them access to source code. But that's an easy part of it. We know how to do that pretty quickly.

No. Our solution teams are made of engineers in Bangalore and in Cupertino. It's a virtual team. It's not like Bangalore does this set of solutions and we do that set of solutions. We don't carve it up that way because we have mirror images of the different projects.

We've created an environment where our engineers have been able to establish personal relationships with the engineers at Bangalore. For example, they've often been there. One time or another over the last 18 months most of the engineers from Bangalore, at least certainly all of the leads, have been to Cupertino for some period of time. We have pictures of their whole organization in our hallways so we know who they are. We know what they look like. We know, in many cases, we know about their families and it's like another HP employee just happens to be on the other side of the world.

They're real people to us, a part of the team. And that's what's made it work for us. We don't just treat them like we've subcontracted some of our work to a team in India. There are some HP organizations that treat them that way, but we've had a much greater success. They are so proud to be a part of CSY. They have a big sign that says CSY Bangalore. They don't view themselves as being part of HP's ESO structure. They view themselves as being part of CSY. We've effectively carved out 70 people that we fund and are considered HP employees. Administratively, they report up through ESO because of local country culture things and that kind of issue. But, effectively from a working relationship, we view them as part of our organization.

As a matter of fact, when I worked on the materials management product, in parallel they were working on the financial equivalent -- FA, if you remember, in Germany. We worked very closely together. I spent four months over there when we were mobilizing products.

Back then we carved out a chunk of the charter. They did the financials. We did the manufacturing. We kind of shared the tools, and that part of it didn't work really well. I think the difference is, with this model it's a joint ownership. And I think there's a lot of sensitivity on our part to the cultural differences, and there are some. As a matter of fact, we're sending our managers through a special training class in the next couple of weeks focused specifically around India. And the differences and the cultures and the things that we need to be aware of. And we're going to do the same thing for them about the American culture. There's more sensitivity to the differences.

I believe part of it is cultural. There's a real commitment to their work. I think that the other part of it is that there is some very, very strong talent in Bangalore. We have a former college professor working on our file system. It's pretty amazing.

Before I answer that, I want to say one thing -- there's a third dimension too. I think it's from our side in that knowing that we really wanted to expand the number of people we had available to work on MPE. I think there's been more sensitivity from the people in Cupertino to spend more time in formal training of [new architects] than you would a new employee coming out of college that happens to join the project team.
Because of the distance, we had to really formalize the training. We videotaped everyone at the training session, so we now have the ability of training new people just through the videotapes. It forced us to do a lot of documentation of things that we hadn't really done a good job of in the past. Better training brings people up to speed faster. We've gotten a lot of good tools that we can now use to train additional people in the future.

Clearly, yes. And especially if we can creatively come up with additional sources of funding, like for example, this idea of support contracts funding additional R&D work, so we can maybe do some things that the SIGs want us to do that are kind of below our cut list.

Yes. Actually, I think either model would work. I think the thing that I want to be real clear about is if we go into this, is that I don't want to have this become so pervasive that it causes our engineers to have to work on managing these activities to the point that we're not doing the critical 64-bit work, for example. But, for the enhancements that are maybe below the cut list for us, that maybe the majority of the customers don't necessarily need, I'd certainly entertain using consultants and outside contractors to do the work for us. We would provide some level of architectural support, but not to the point that every one of our architects is now tied up 50 percent of their time managing these external things. I wouldn't want it to become a huge activity -- but something within the range of maybe a couple of hundred thousand dollars or something would certainly be reasonable.

I remember having 30 open staff requests at one time and not being able to find people to hire. Half of our charts said TBH -- To Be Hired.

I think the quality is better, and I think the reason is that we're smaller. When we had probably 1,000 engineers working on MPE XL Release 1.0, just the communication and decision making was horrendous. I mean, we had probably 15 different independent R&D centers working on different pieces and trying to make sure that when we built that system and it all came together and it actually worked. And there were incredible problems about just some of the external interfaces not being well defined -- the networking people thought it was this way and the parameters were in this form, and the OS people having a different interpretation. You put it together and it didn't work.
We don't have the problems because we're sort of self-contained all in one R&D organization. We collapsed all of that into a single management structure. We've got all of the architects working together in an architecture team, 15 of them representing different parts of the system. And they can all sit in one room together and hash it out in an afternoon, and everybody has heard the discussion. It's not trying to be passed on in written form and getting misinterpreted. It's just so much easier.

So the quality is better. And we've extended the same model with Bangalore, which is why we fly them here when we have these kind of intensive design sessions. We bring them here so that they are sitting in there listening to the same discussions. In a sense, it's going back to HP's traditional history of keeping divisions small and contained and focused, it's really the right model. The downside is that maybe we can't do quite as much as say the Unix division can do, but the reality is I think we probably have a higher quality. Maybe it takes us longer to get things out, but I think in the long run from a customer's point of view, it's probably better.

I think the high-end customers, where they have typically larger IT staffs and more technical people, have moved to Unix and have adopted Unix and their environment and can support Unix. They've been very successful in those environments. For the sort of midrange class of customer, where you can typically have maybe five to 10 programmers and three or four operators, it's a little harder for them to move to Unix. And so I think in that category of customer, they're the ones that have been reluctant to make a move. In some cases they bought maybe smaller packages like Oracle Financials, and they've been successful in running them. But if they have to put together all the pieces themselves and construct an application, I think it's really pushing the skill set of those people.

I think NT is a different story. I think it's more similar to the 3000 environment. It's easier to operate. I don't know too much about the development tools on NT, but I assume that they're probably similar, if not better than, on the 3000. I think that we're going to see more NT systems in the 3000 installed base than maybe we're seeing in the Unix side of the business.

In the high end I think we're seeing Unix and NT both. In the midrange we're seeing less Unix, more continued commitment to the 3000, but more deployment of NT servers. Typically, either a point solution or as file servers or work group servers and that kind of environment. I'd be interested in knowing what your epiphany was.

Yes, system managers. The programmers are largely what we see. These people are not abandoning the 3000; they're supplementing.

Well, I think they are smaller companies. They're self contained. They're not plugged into networks, and so security is not an issue. They don't have corporate auditors that come to them once a year and audit IT organizations like we do.

I think there will be some reservation by the high-end customers, but on the other hand, I think typically they have home-grown applications. They won't buy a product that's not supported by HP, and they're very concerned about relying on a very small company.

Right. For them, I think Glenn is right. Unless HP is willing to stand behind the product, being really able to guarantee that if that company goes belly-up that HP will in turn support the product, that they would be concerned about that. I think with the mid-range customers that's less of an issue. If it works and fits their need, they'll probably buy it.
I think there's a lot of opportunity to attract some new applications that would allow us to sell it to the midrange -- the kind of traditional 3000 customer which is where we need the applications anyway. I'm willing to take the risk, and I'm also willing to take the risk that we come up with some really good solutions. Some really good applications have come forward, and it may behoove us to stand behind the developers, to be willing to say we will indeed guarantee that if they don't make it, we would take over support or something like that.

You guys have been telling us this now for two years. I said: Hey, I think it's time we try it and see what happens.

I think it's going to be pretty substantial number of tools and even some applications. I think that people will want to bundle because their motivation is: Hey, we want you to know about our products, so if you do develop a solution, and you go out and sell it to a customer, you're going to know about all of the other things that are available too. And that's one thing that we haven't had in the past. I mean, HP's Workload Manager is a perfect example. Even Smith Gardner wasn't aware of it.

We've actually been negotiating with them for quite a while. As soon as we knew Open Market was basically getting out of the server business, we began looking at other alternatives. And basically started discussions with three or four different partners, and Netscape was the one that was the best deal.

No, he could not. There were some critical components in terms of being able to bundle it. That was absolutely something we felt was absolutely important, because it's kind of like IMAGE was when we first released on the 3000 -- we wanted it to become pervasive, and it is pervasive. And the only way to make it pervasive and get people to start playing with it, is to get it out there free. And so that was a critical piece for us, and that required that we had to pay some license fees.

One of the things that was really critical to me was an absolute love of customers and a real desire to spend time with them. A desire to really get what the business problems are. I think we have a really exciting team.

I suppose it's pretty apparent to you that I have a certain emotional attachment to the 3000. Not actually to the hardware -- I've hardly ever seen one. I honestly don't even know what the latest models look like. I see them with the guts out in the cabinets, and sometimes when customers want to show me their computer, I see what it looks like. It's just the customers that I am really attached to. I've gotten to know so many of them. I am just having a whole lot of fun doing what I'm doing.

Copyright 1997, The 3000 NewsWire. All rights reserved.