Contrarian Minds: Hal Stern

Turning innovation into customer value.

By Al Riske

20.May.04--From coaching his son's soccer team, Hal Stern learned that you don't kick the ball to a teammate -- you kick it into an open space that your teammate runs into.

"That's how you create momentum," says the CTO of Sun's services business. "That's how you score goals."

This elementary lesson applies to computer companies as well, he says. "Part of Sun's contrarian approach is seeing when spaces are going to open up and then executing into them."

Right now, the whole industry appears to be going in the same direction. Like eight-year-old boys playing soccer, everyone is swarming around the ball -- in this case, complexity -- and trying to kick it.

So how is Sun a contrarian player? Compare what we do to what our competitors do (not what they say).

"IBM says, 'We want to make everything self-healing, but we have a lot of people who are going to help make it self-healing.' You pull back the curtain and there's a short man named the Wizard of Oz back there operating the controls," Stern says. "Well, that scales really easily -- just get yourself a lot of wizards. But there's no magic there."

Sun's approach? "Attack the services market with far fewer people than any of our competitors and do so leveraging what we know about networking, about instrumentation, about policy issues -- how you ascribe operational characteristics to something. Security, privacy, trust, performance, reliability.

"We're doing this today. We offer managed services for our customers. It's a several hundred million dollar business for Sun services, where our customers say, 'We want our systems to run like this,' and we say, 'Okay, we'll provide some measure of automation, some measure of people, and we'll work with partners who may host the equipment for you," Stern explains. "We don't do it by hiring tons and tons of people. We do it by applying technology to the problem and then applying people appropriately."

Stern sees himself as "an applied computer scientist." He doesn't create technology; he applies it -- in ways that are both practical and competitive.

In a controversial article for the Harvard Business Review, writer Nicholas Carr proclaimed that "IT Doesn't Matter."

Depends on how you look at it, Stern says.

"You can look at technology as the product or as the raw material that builds the product," he says. "If you look at it as the product, yeah, it's a commodity, so you should always go find the cheapest and be a laggard like Carr says. But that's only if you think acquiring bandwidth and CPU cycles is the goal.

"The goal," Stern counters, "is to do something with all that -- change the economics of your business or enter a new market with aggressive new economics or introduce a new product quickly.

"It's what you do with it that counts," he says. "The question is always: Where does technology change the economics of the market?"

One of the most common -- and commonly misunderstood -- examples is Amazon. "Everyone thinks of Amazon as disintermediation. You know what? You're not buying books directly from the publisher. What Amazon did was quickly reintermediate," Stern says. "By taking search and applying it to a big database of every published book, Amazon was born. That was applied technology. It created a new intermediation channel."

Stern is contrarian by nature, but also deeply pragmatic. "A lot of things in computer science involve finding the appropriate tradeoff because you're fighting against time, the problem is overconstrained, or simply can't be solved," he says.

Can't be solved?

Stern chooses the traveling salesman to illustrate his point. "Let's say I give you a set of 10 cities and tell you how much it costs to go between any pair of them. Now go find a circuit -- visit each city exactly once at the lowest cost. If we add more cities, the problem becomes exponentially harder. A number of business problems map to that, and when you get up into the hundreds, the problem eventually becomes insolvable.

"Now the fact of the matter is problems like that get solved every day," he says. "Salesmen travel. Things get routed. Do they happen optimally? No. But people are willing to make the time and cost trade-off between never solving the problem and solving it in a close-enough way that you can make the trip.

"Because we're using technology, the thought is that we should always get the perfect answer, the perfect solution. You know what? Nothing in the world is perfect. This kind of trade-off is going to appear more frequently as we talk about security versus privacy versus trust. You have to triangulate how far you want to go in one direction and figure out what you're trading off there."

As a case in point, he recalls working with a financial services company several years ago, building one of the first electronic clearing networks.

"The problem is the order flow isn't even. There's a huge spike when the market opens. Then everyone goes to get coffee, they tell jokes, and they see where the market is trending. Around 2 o'clock it starts picking up and ramps right through to the end of the day."

That initial burst was giving Stern and his team fits. "If you wanted the backup copies to be perfectly synchronized, the system ended up being really slow. If you wanted the system to be really fast, the backup would be out of date," he says.

"We went back and forth on this for weeks. So finally the guy from the brokerage said, 'Look, if there's a failure, I'm going to have three guys sitting at the backup site from my group of traders. Pick up the phone! You say, "Did trade 47 complete or not?" If it didn't, we'll restart the system from there.'"

The lesson: Don't optimize for failure; optimize for success.

"We were looking for a technology solution when there was a perfectly good social solution," Stern concludes. "We tried to oversolve it, and this guy said, 'You're wasting my time. Just use the phone.'"

That's a pretty contrarian conclusion for a technology company, but it's one Stern applies again and again.

The goal is not perfection but customer value, he says. "I could tell you I'm going to take your risk index to zero -- you have no exposure at all -- but by the time I get done patching and configuring and changing stuff, it's probably not worth it to you.

"So, what's the acceptable level? And how am I going to get all your systems to that same acceptable level?

"If you have three systems and they're all supposed to be running the same application as part of a single cluster, they ought to be configured the same. What we're finding out is they may be configured with dozens of variations across those three systems.

"Those are things we can automate, those are things where we can take cost out, and those are things our customers find valuable."

In addition to electrical engineering and computer science, Stern also studied economics, art history, and literature at Princeton. All of which, he says, taught him to think critically.

"Part of where my natural crankiness comes from is trying to figure out what someone was getting at, whether it was a painting or a work of literature. What were they trying to say? That extends to my current role and always asking, What are we trying to solve here?"

"The big challenge is how do we go look at the installed base of systems we have, treat them as an enormous grid of sensors that are throwing off data, and go learn from that data.

"What do we learn from our systems as they're running? What do we learn from the applications, from the operating system, from the hardware? Then we can use something called P cubed -- predictive, proactive, preemptive services -- to keep things from breaking.

"The first time it fails, okay, I'll fix it. After that, I should be able to identify that a customer is missing a patch, they have a configuration susceptible to failure, or they have an increase in what we call their operational risk index.

"I think change control is the next killer app -- automating this process. Environments are constantly changing, but that change tends to introduce cost, risk, or security problems. If I'm going to automate change control and risk management, I don't need to send you 40 engineers to go in your datacenter. I can work with you on the architecture and let the automation do its thing -- not spackle over the problem with a lot of people."

That's where Sun's approach to services is truly contrarian. While others try to emulate IBM Global Services, Sun recognizes that less is more. "We don't want to have 100,000 people," Stern says. "Historically services has been roughly a third of the company, maybe a little less. Contrary to what industry analysts may think, that's a good size -- and place -- to be right now."