| Front Page | Subscribe | Advanced Search |
Winston Prather
HP Commercial Systems Division
Moving from Defense to Distinction
Winston Prather means to lead from his product's strengths. The general manager of the 3000 division (CSY) succeeded Harry Sterling last fall, after Sterling made the decision that saved the HP 3000 by committing to new IA-64 architecture. Now Prather must deliver on Sterling's commitment, starting with the N-Class HP 3000s due at the end of this year. Prather's predecessor left him with something in the bank to pay for these 3000 commitments: political coin within HP once more, showing the company 's top management the value in a product with profit and a loyal customer base. Comparisons between these two men are inevitable, but a close look will show they are cut from the same cloth — believers in customer contact.
Prather was a part of the renaissance the 3000 enjoyed under Sterling's leadership, leading in the division's labs. He has been working with HP 3000s since he was in ninth grade, and joined HP in 1985. After more than 22 years experience with the system — the first eight as a customer and user — he has led the HP 3000 architects and engineers in the labs during Sterling's GM tenure. What Prather gets to build upon is the respect the 3000 division has regained inside HP. His GM post is now part of Business Critical Computing general manager Janiece Chaffin's staff, one that helps the 3000 division get included in technologies for other IA-64-bound systems.
The question to be resolved in his predecessor's term was the survival of the HP 3000. Prather faces a mission just as important — the successful transition to HP's latest technology, and making the system a vital part of the new e-services push so central to HP's message in 2000. Perhaps even more crucial is the challenge to make the HP 3000 stand out from other systems in an era when hardware is fast becoming a commodity. We asked Prather to outline his goals for building on the renaissance and his plans to establish the system as a unique computing platform.
Customer connection has been CSY's mantra. Have the customers been asking about the e-speak connection to the 3000?
Not necessarily. It seems to be more interest from third parties and ISVs. I wonder if that's because of a lack of understanding from customer about what you can do with e-speak. Or everybody is pretty locked down with Y2K. The way we have positioned the technology is that if you have an asset that you could Internet-enable, e-speak will broker that asset across the Internet and either sell or buy services. It's a technology that could work for customers as well, although I see it as first being deployed by ISVs.
Since you've had e-speak running on an HP 3000 since mid-summer, what kind of connection will the language have to the MPE platform? Is e-speak helping to elevate Java's potential for the 3000?
I'm not sure I understand enough about how the two would interact to know how it would elevate Java. The general message we heard back from our ISVs was they like the [e-speak] vision, and they think it's really going to turn into something. But I think they feel very focused right now on taking advantage of the Internet and what may be called Chapter One-type technologies. We asked the ISVs what they're spending their R&D time on now, and it's Internet enabling their applications. They view that as a prerequisite for taking advantage of e-speak. There was lots of intrigue and interest, but I'm not sure they're ready to start working with it. We'll continue to keep e-speak ported to the 3000. We do have a prototype running on the 3000, and we're evaluating how to best use that with our ISVs. I think it's too early to know exactly what it's going to do. It's still an up and coming technology, and HP's pushing hard to ensure it will help the industry evolve toward e-services. It's still a little early to say when our ISVs will start using it.
SIGSOFTVEND chairman Birket Foster says that MPE/iX "only lacks seven Posix calls" to qualify as a Unix under the standards. Assuming what he says is true, would it make good business sense to add these calls to MPE/iX — if they don't break anything already installed?
First let me comment on the "only lacks seven Posix calls," because Birket has mentioned this to me, too. I went and talked to some of the lab folks about this. There may be seven different categories of things or issues. But here's the bottom line: if they were easy, we would have already done them.
It's a huge effort to implement some of these things. A lot of them have to do with the way MPE interacts with terminals. There's this thing called a General Terminal Interface, or GTI, that most Unixes support, and that's a big issue for us. There's something else called select, which is a Unix function that allows you to find out if you're talking to a socket, a file or a terminal — so it's also related to terminals — that's not easily implemented. There's something called hardlink, that I'm not familiar with, but I think that would have a ripple effect through the STORE and RESTORE and potentially third party products.
As 64-bit APIs have come along, Unix branding requires you follow the specific APIs for 64-bitness that our large file project hasn't implemented. We do understand what it would take to do, and it's a big technical issue. The real issue that it comes down to is whether it's worth the effort.
I have two thoughts on this. If we could attain a Unix branding, it would allow resellers and ISVs to say, "It's just Unix." Which may get them in the door, which is probably where Birket is coming from. I can see value in that, although it leads me to another thought. I don't think we're doing a good job of selling the value of MPE. I believe it's a differentiator, and I don't want it to be another Unix. I believe MPE is better than most Unixes, because of all the things it has built into it. If you go back to some of the core things like transaction processing, reliability, I think it's better.
I understand the point about getting in the door with RFPs. That's why I go to the technical staff and ask what does it take to do this. I don't want people to try to position us that way, because you miss the point. You need to be able to articulate the added value. That's something I think we need to help our resellers do a better job of. All too often we end up trying to compete on price alone, when what we sell is a completely different package if you look at the value you get. Buying an MPE system versus many of the Unix systems out there, I think it's a whole lot better. But I don't think we do a good job of articulating that.
Christine thinks that way too, and is working with the marketing team to look for ways we can help our resellers articulate that. It's a much bigger deal than Birket thinks. Every one of those seven things are very hard. The real bigger issue is we have to help people articulate that MPE adds more value than Unix. Look at all the additional things you have to purchase when you buy a Unix system. Everybody ends up with these huge MC ServiceGuard configurations to get the reliability. The majority of our customers don't need that, because the base reliability is so high. I had one reseller tell me jokingly, "The thing is just too damn reliable, and because of that we don't get to sell redundant systems." I told him, "Well, I think that's a positive thing."
All too often our resellers get stuck, because we haven't provided them with that information. Then you're in there competing on price.
It sounds like what you're proposing is a way to highlight the different and unique features of the HP 3000. Are you ready for that?
I'm a little tired of being defensive. I understand the arguments about Unix this and Unix that. But I think we get too defensive, as opposed to articulating the value of MPE. We accept that it's not Unix, and people think of that as a bad thing. I actually think it's a good thing. I'm very proud of MPE because of the things that differentiate it from other environments. Too often we end up defending why we don't do it that way, as opposed to saying why this way is better. I totally understand about the getting in the door, which is why we should look at accomplishing these things. There's a team looking at exactly what it would take. A quick estimate of what it would take to accomplish these is probably something on the order of eight engineering years.
Even if we can't support all of it, we have an effort underway right now where we are evolving the Posix environment to porting enablers. These make it easier to port applications to the 3000. There may be overlap between the improvements we want to make from a porting point of view, and this list of seven things. But if I had to guess, we won't be able to get every one of these things on the Unix branding list. And the way I understand it is, if you've got 230,000 of them and you don't have one, you're out.
Is the forthcoming N-Class HP 3000 a candidate for Multiple Operating System Technology, where more than one OS could be on the 3000?
The past projects were all software based. The N-Class does not necessarily make it easier to do this. If you look at the version of the N-Class we'll come out with initially, and the version that's supported on Unix, the hardware doesn't support multiple instances of operating systems.
Now, in the future HP will be coming out with hardware that will help move in that direction. It's not been announced yet, or coming in the short term. In the long term we're definitely coming out with hardware that will make it much easier. You'll get the hardware support you need to make it easier. I think when we have hardware like that available, and then it will make sense to go back and reevaluate whether it makes sense to do this.
We don't think when the N-Class is shipped it will be a good time to re-evaluate this, but we do see it coming down the road.
Since Oracle 8i is so tightly aligned with HP's announced plans for e-services — the database is being given away on HP systems that go out in the box-for-profits swaps HP's doing. How can the 3000 participate in HP's e-services plans without Oracle8?
The main reason Oracle is such a big part of e-services on the 9000s, it's where the majority of the applications really run. If I were to do a comparison with the 3000 world, I would say the majority of our applications run on TurboIMAGE. In the 3000 space, to participate in e-services, it would be more important to make sure TurboIMAGE works with e-services. The 3000 has a small installed base of Oracle customers.
Are you working on making TurboIMAGE participate in e-services then?
We're working to make the 3000 participate. Specifically what does that mean for TurboIMAGE versus Allbase or Oracle, I'm not really sure. The 9000 people feel strongly about bundling Oracle because that's where a lot of the applications are. For the 3000, we already bundle TurboIMAGE.
So you mean there's no inherent advantage to Oracle in an e-services offering on the 3000?
I don't see a connection between having Oracle 8i on the 3000 and being successful in e-services. A lot of the e-commerce successes we've got going with Smith-Gardner don't involve it.
I don't want to be defensive about why we don't have Oracle8 on the 3000. I want to say why we think TurboIMAGE on the 3000 is really the right thing.
Have things changed much for Oracle on the 3000 since last fall, when you explained the Oracle installed base on MPE determined the division's level of investment?
A couple of things have happened. We have gotten contacted by a number of resellers and ISVs who think making a business case for Oracle on the 3000 is a really good thing to do. It's still a very small percentage of the resellers and ISVs on the 3000. It was enough that it prompted me to have some discussions with Oracle, that are still ongoing. I have been discussing the possibilities.
We have a jointly funded porting center in Bangalore, sitting in both the HP offices and the Oracle offices. It's more than a porting effort; from Oracle's point of view, it's a porting effort and a support effort. Whatever is ported has to be supported. It's not as simple as we go port it, although even that is not simple. Oracle has to be really behind whatever the right thing to do is. Their position over the last couple of years is that TurboIMAGE is the 100 percent successful database on the HP 3000, and they just can't get any penetration and don't see it as a viable platform for Oracle. The customers on the 3000 love TurboIMAGE. Oracle can't get a high enough market share on the 3000 to see the value proposition. There are resellers who use Oracle on their 3000 applications, but not that many.
If I go to the application providers on the 3000 and ask them to port to Oracle, what percentage of them are going to do that? There haven't been enough ISVs that thought that was the best answer for them.
Customers view Oracle on the platform as a signal that will influence the future for the 3000. They need to recognize that it's such a small portion of the 3000 business that it doesn't have anything to do with the life of the 3000. Oracle looks at it from a business perspective and says, "Customers don't want our database on your platform." Until our ISVs line up with Oracle, it's harder for them to [commit]. We've got to make sure we do something that's good for everybody.
What does it take to be a trusted peripheral on the HP 3000? What plans do you have to help customers who are encountering tape-related database errors happening over SCSI busses?
Most of the customers have already moved to SCSI devices already, don't you think? If we support a peripheral, you should trust it, or we need to make it trust-able. If you're implying that SCSI peripherals' quality is not acceptable — [database utility suppliers] need to make sure they don't do the support on this, and they turn it back to our support folks. I'm personally not aware that SCSI drives are less reliable, other than a question I heard from Ken Paul of Adager at HP World.
If the real issue is whether SCSI is having a quality issue, I can put that to the right people, and what are the issues. [Ed. Note: CSY lab managers subsequently confirmed they are studying this problem.] We don't draw a distinction between devices. If we port it and write the driver, our goal is that they will all be trusted.
Will the HP 3000 be part of the capacity-on-demand program HP recently announced for the Unix N-Class servers?
It's something we are considering for our version of N-Class. It depends a lot on customer feedback about whether it's something a lot of customers will use. Technically, we basically just ship a system with all the processors. You can turn them on on the fly. We don't have online processor allocation and de-allocation, and Unix already supports this. The basic idea is that based on the load, the operator could turn on five more processors, for example, based on the load. Since they're sitting in the system disabled, it's easy to do. Then you get billed for it.
Can they turn them off when they don't need them?
I don't think you can. From a technology viewpoint you can, but from a sales point of view, I don't know if that's part of the program. It's a really fast upgrade, and most environments that need that are really at the high end.
How do you expect the HP 3000 community and market to change once you've cleared the Y2K issues? When do you think your customer base will have most issues resolved?
I would hope [as of late November] they have most of their issues resolved already. I think the comfort zone is going to be after the leap year date, February 29. I think the masses won't feel it's behind them until we get into March. Then they'll get back to normal, which is looking for ways the IT department can add value for the business, as opposed to ensuring they're safe. I really think we're going to see Webifying, and turning their attention back to that. There's a big pent-up demand for non-Y2K stuff.
What are your goals for the growth and evolution of CSY's Bangalore operations?
The goal for the program, which just celebrated its fifth anniversary, was to create two strong labs. It has taken us quite awhile, but I do feel like we're successful now. I will absolutely acknowledge the challenges we had. I would look at them as normal challenges for growth. It wasn't doubled, but it was significant growth. The number one challenge has been learning to operate as a global team. How we can increase our efficiency as a global team, because of the time zone difference. It's either 12 and a half or 13 and a half hours difference. There's no overlap in time of day when the two offices are there. How to do design meetings when half your team is not at your site. How to rely more on e-mail and less on face-to-face meetings.
It's been a huge learning curve for us, but I really feel good about the program right now. It still impacts a lot of the personal lives of those here and in India. My staff meetings as R&D manager used to be at six in the morning, so we could have the section managers from India there. I still have one-on-ones at 9:30 at night. Every CSY R&D employee has had to have that kind of flexibility.
For the first number of years, the ramp up was even greater: every night we'd be doing training sessions. We've gotten to a steady state now. At first Bangalore provided current product engineering, bug fixes only. It's probably one-third of what Bangalore does now, and two-thirds new development. That was always our goal. In the last year instead of duplicating teams, evolving to where we have centers of expertise. If you look at the majority of where our networking work is done, other than the PCI new driver development, all of the rest of it is done in Bangalore. If you look at databases, we have a small number of engineers here, but the majority of the work for the databases is done in Bangalore. If you look at kernel, it's still split 50-50. This cuts down on the overhead when half your team isn't there.
If we decide to launch a new networking project, it will probably be in Bangalore. We have two labs, and they have different expertise.
Your engineering dollars go farther in India?
That's hard to say. The cost per engineer, in salaries and floor space, is pretty significantly cheaper. In the Cupertino organization, the average experience is 15 years. Once you weigh all those things, it's hard to answer. The average experience there is two and a half to three years. I view what we've done as a big success for the business, but at the same time very challenging for the people. This has become part of our culture. People enjoy working at CSY because of the flexibility we give. We have many people who have decided to leave the Bay area. We are a global environment.
Why is it necessary to fork the operating system to support IA-64?
I think there's confusion over what we mean by fork. Our goal is to have common source — meaning that if we put new features into the CI, for example, for the version of MPE that sits on IA-64, you'll still get that functionality on PA-RISC. We will have to have separate binaries, so the operating system will be compiled with either a PA compiler or an IA compiler. It will be different bits, but we really hope that won't be something the customer sees. Is there a fork in the operating system? Internally, there will be things like low level code that actually talks to the hardware. There will be separate code for the two different platforms. But I don't think customers are really going to see that.
When a customer says fork, they think when the IA-64 version comes out there won't be new stuff on the PA-RISC version. That is not the case. This is very different from when we went from CISC to PA-RISC. That was a complete start over, to rewrite the kernel and user interface and then emulate the old one. With this we're only changing the low-level code, so all the high level code will be the exact same code. That wasn't the case when we went from MPE V to MPE XL. From a customer's perspective, that was a fork, because we didn't have common source for the user interface, for example. Our goal here is to have common source wherever possible. To date I haven't seen a place where we aren't able to do that.
Will customers have more than one version of MPE if they have PA-RISC boxes and IA-64 boxes?
They will have different binaries. Our goal would be that this is not a big deal for customers at all. I'm also leaving open the door that they'll have a lot of work to do. It's true that we'll support more than one version of MPE, but I don't think the customer will ever know. It will be forked at a level much lower than what you think of as the operating system.
What's your philosophy about bundling functionality in MPE versus working with third party vendors? How much are the customers entitled to for free?
First of all, the customers would argue that nothing is free; they're paying. When you say free you mean included. I don't have a clear answer. If you look at the way the industry has evolved, third parties have been providing much more functionality, and charging for it. Historically, where the 3000 has come from, we bundled it and included it. I think I'm trying to find a happy medium. To continue to be successful I need to do less bundling and including, and more relying on third parties to complete the overall solution — which by the way will mean customers will have to pay for some of that functionality.
Which does beg the question about why you would expect HP to give it to you for free, since there's clearly value there. I don't want to go strictly to the far end of the scale, where Unix and NT is — you get nothing bundled, and you buy it all. At the same time I have to move a little bit in that direction, so that we can be competitive. If we try and do everything ourselves, we're gonna fail. We just don't have the resources. And the third parties will fail, because there's nothing out there for them to do.
We will still bundle things, much more than Unix or NT, but you'll see where we do find opportunities where it does make sense to work with third parties. The logic that I'd like to use to decide is "Who has the best expertise?" If we're not the best people to do that, I'd like to have that opportunity for the third parties. That's the commitment I'm making to the third parties; there will be opportunities. For this entire ecosystem to survive, we need everybody to win.
From a customer's point of view, you will need to look for third party solutions a bit more than you have in the past. But not nearly as much as you do in Unix and NT environments. I do believe this is a differentiator for the 3000. We will try to articulate that. It's part of the value proposition, that you get a lot of that stuff, and you don't have to pay for every little thing.
It's not because we're just trying to get out of doing stuff. To make this whole ecosystem successful, everybody has to have some skin in the game. That includes the third parties as well as the customers. I've had frank discussions with customers who say "Why isn't that bundled?" I say, because it's adding value. Shouldn't you pay for value? They understand the point, and it depends who you ask. The technical people and lower level managers say we should give them all that stuff. The people who are running the business understand that everybody is in business — and if there's value in it, they'll pay for it.
Isn't it difficult at times, because those technical people often carry the torch for the 3000?
They do. They are our road warriors, and carrying the torch. I need to be able to help them articulate the value to their executives.
Can you describe what it's been like to follow Harry Sterling in the GM job? What are the upsides and challenges that you've experienced in the last three months?
It's been great. Harry has been such a good personal coach for me. [As of late November] he's not gone yet, and I've been to his desk many times to ask him "What do you think?" I've told him I plan on using him for advice as long as I can get a hold of him. I've spent most of my time in areas that are new to me. I haven't spent a lot of time on the R&D side. I've got a really great management team on the R&D side, and they have not pulled me into anything. Which is great — and also makes me think I wasn't needed!
That's a good thing. I've spent most of my time talking to customers and the channel and marketing, with Client Systems, making sure I know what the issues and plans are there. One of my personal goals is to get more engaged with end-user customers, and also with our third parties and ISVs. I've been on three times as many of those calls as I would have in the past.
I'm really looking forward to getting back out and meeting one-on-one with customers. I have to balance that with the family thing. Just like any new job, there's a big spike in the amount of effort I put into it, so I can feel comfortable I'm doing a good job. I'm clearly in one of those spikes now, working long hours and loving it. My wife is very understanding; she's seen it with every promotion I've gotten.
Copyright The 3000 NewsWire. All rights reserved.