Monday May 26, 2008

Eco Business Case

Several weeks ago I was interviewed by a business school student building a case study for "eco" as a corporate imperative. What started with a line of questions aimed at highlighting the growing interest in "green" approaches to business turned quickly into a discussion of the other kind of green -- financial incentives. I don't think you'll find any company that wants to admit to being anti-green or anti-environment; but there are few companies that will actively fund and endorse "eco" as a strategy.

We (and I mean my generation, the late boomers, the current group of IT professionals) treat "eco" as a social initiative, and not as a business initiative. That's no longer possible: social, business and large-scale economic initiatives are intertwined, and companies that "get it" will gain greater acceptance in the market, have an easier time hiring new college graduates, and find that their marketing and sales efforts are amplified by the tangentially understood "social media". Put another way: the next generation of consumers -- of IT, of consumer products, of social services -- wants social action, has grown up immensely connected to their communities and the world, believes it can enact gross change, and provides instant feedback both good and bad. If a company doesn't make the link between eco as a green computing initiative and eco as a business initiative, they will sink into the Millennial equivalent of the Rust Belt.

Put another way, we fail, miserably, if we simply treat eco-computing, and eco-business, as something Carol Cone calls the ribbonization of America -- a nice cause for which we'll slap a ribbon on the back of our cars. Eco has to go beyond a corporate cause and turn into a set of actions and priorities embedded in how you think about the long-term priorities of your business. One of the best things Scott McNealy ever said to me was "Don't ask me to solve the problem, you're the engineer. Tell me what to execute because I'm an executive." Sounds trite, but it's been outstanding career advice. So here are my four actionable - executive - imperatives for dealing with eco as a business-driven, financially motivated priority.

1. Reduce demand. The most obvious one, but bound by just how much demand you can take out. Power efficiency is driven by an entire chain of transmission functions from power entering the data center to the power supply units inside of servers; moving toward more efficient distribution and conversion is a requirement.

2. Switch demand curves. If you think of power and cooling capacity demand along a classical economic supply/demand curve, eco-computing demands that you find completely different curves as well as demand-reduced points along existing curves. One approach: carefully examine where you can use tape instead of disk, trading latency for power. Tape has the eco-wonderful property of drawing zero power when it's not spinning in a drive. Another approach: look at the relationship between software and heat. Huh? Inefficient software uses more CPU cycles; increasing CPU utilization drives power consumption and demand for cooling. Yet another view: Put Moore's Law into historical context. Moore predicted the number of transistors in a processor, not the actual processor performance. How we allocate those transistors into cores, threads of execution, cache and system support functions like I/O and memory control govern the overall throughput and power efficiency of the processor. Why does Sun continu to invest in processor design? Because major refactoring of transistors in a high throughput processor creates these new demand curves.

3. Scale with sub-linear cost. Increasing delivery of IT services over the network, and rapid adoption of those services are "network scale effects." At some point, we hit a non-linear cost point in data center capacity planning where we need a new data center design or a new physical data center. What's our incremental cost of adding data center capacity? If it's a major real estate project, it tends to be measured in tens to hundreds of millions of dollars and in years, not weeks. Projects like Sun's Modular Data Center (AKA "Project Blackbox") stimulate thinking about raising capacity without building another raised floor. Being able to scale up requires a service delivery design that spans the architectural milieu from hardware layouts to load balancers and security blueprints; we've captured a set of design ideas in Sun's architectural wiki. With technology adoption increasingly driven by social mechanisms (from iPods to Twitter), companies need to identify the social drivers of growth for compute, storage and networking so that we can avoid the equivalent of an impulse function in meeting that demand.

4. Scenario plan for 10 or more years. You would never tell your investors that you don't plan to be in full operational mode a decade from now. Failure to address long-term growth and scale issues creates constraints for your successive set of business executives. The root of this scenario planning is to answer questions about who is using your products (and services) and how they'll be used (and re-used). Sun's eco-computing initiative has spurred seemingly minor product design changes that have had long-lasting impact. For example, we've removed plastic bezels and trims from our hardware products, making the systems skins fully recyclable. At a completely different abstraction level, we need to look at the encoding of corporate data, from databases to documents to intellectual property: how will it be retrieved, read, re-used and retained in five, ten or fifty years? We need interoperability across different representations today, and across future representations if we want this data to be of any use.

All four of these actions are cost driven: current operating cost, future operating cost, or cost avoidance planning. The social aspects of eco-computing make it appealing while the cost aspects make it compelling.

Friday Jan 18, 2008

Abstraction and Ingredients

I stopped reading package ingredients a few years ago, after getting regularly depressed that what I considered a "snack size" actually contained an entire day's worth of calories, fat, sugar and not nearly enough vitamin content. Let's face it: when you pop open one of those airport snack packs, you aren't thinking about how you'll divvy it up into three servings; you're looking for a sugar fix and you're less concerned about what other things it drags along. Not exactly heart-healthy and aligned with the much-rumored new year's resolutions for 2008, but immensely practical.

Packaging and abstraction drive use. If something is easy to consume, you'll consume more of it, and if it presents an abstraction that hides the ugly {technical, political, nutritional} details, you'll find it easier to use. That, in a (healthy) nutshell, is the motivation for Project Caroline, a Sun Labs effort focused on simplifying service deployment and delivery. (For anyone questioning my failure to craft a pun around Sweet Caroline, it's an anti-New York Rangers sentiment bubbling through the otherwise sugary stuff here).

VP of Advanced Development Rich Zippel and I sat down with our USB microphones to record another Innovating@Sun podcast, extolling the virtues of Caroline in all of its nuts and bolts, from the motivations for a simple service platform to the derivation of the name (again, no Neil Diamond, thankfully).

This is a much bigger deal than a research project and an attmept to rationalize the array of interfaces presented to deployers, not just service developers. The biggest challenge for data center designers today is not choosing a virtualization platform or a networking switch vendor or even a cooling technology. Those are implementation details (large details, to be sure, but details). The challenge is balancing the needs of the CTO or VP of Application Development to "go fast", creating more value in IT for the business, with the needs of the CIO, who wants to "go slow," controlling the rate of change, mananging risk, and squeezing as much utilization (and efficiency) out of the computing assets as possible. The path to achieving this balance doesn't involve Xen (sorry) as much as thinking about abstraction across the entire array of applications: networking, computing, storage, sessions, data caching and persistence, and language.

Moving up to a higher level of abstraction for the data center means that you're less concerned about how it's built and more concerned that it "just works" -- an artifact of what Sun CTO Greg Papadopoulos calls "Network Scale Computing." That's the intent of Project Caroline, and it's a message that has resonated with every CIO with whom I've met in the last two months.


Hal Stern's thoughts on software, services, cloud computing, security, privacy, and data management


« July 2016