The Pervasive Data Center

IBM's industry analyst meeting last week in Austin, Texas, covered the present and the future of its Power line. This is the system lineup once called the RS/6000 and pSeries into which was more recently folded the iSeries (previously AS/400, System 36, etc.) to form a new family called IBM Power Systems.

For our purposes here I am going to focus on Power in the guise of IBM's RISC-based lineup running a combination of AIX (IBM's flavor of commercial Unix) and Linux (either natively or using PowerVM Lx86 to run x86 Linux applications). IBM i, the successor to OS/400, also runs on the unified Power line.

IBM is slated to publicly unveil some of the details of Power7 , the next generation in the Power microprocessor lineup, at the Hot Chips conference at Stanford University on Tuesday. At the top-level, IBM describes Power7 as having eight cores per chip, four threads per core using simultaneous multithreading (SMT), and two to three times the per-chip performance of Power6 using the same amount of power.

Specifics of the systems based on Power7 will come later. IBM did say it'll build Power7 systems that generally add the required memory, bandwidth, networking, and so forth to keep the systems balanced.

Beyond future hardware, though, there were a few themes from this meeting worth highlighting.

IBM's Unix business is a smooth running machine at this point. We repeatedly saw a chart detailing IBM Unix Server revenue share gains at the expense of HP and Sun. The three companies held roughly equal share at the start of 2005; today IBM holds about 37 percent of the total market, about 10 percent more than those competitors.

One can always argue about which particular slicing and dicing of data most accurately represents the state of the market--of course, each vendor chooses the view that paints it in the best light--but it's hard to argue against the idea that IBM Power is on a nice upward trajectory.

Part of this is IBM's processor road map. One of the corollaries of Moore's Law is that time to market is performance. What would be a truly compelling processor in Year X is much less so in Year X+1 and even less so in Year X+2. And IBM Power development has been on a solid three-year cadence for major releases combined with interim speed bumps. Competitively, Sun's "Rock" has been reportedly canceled and Intel's next major iteration of Itanium, "Tukwila," has been much delayed.

However, it's also a case that IBM has simply made advancing Power Systems a real priority and has systematically put the resources in place to make that happen. I'm inclined to argue that this focus on scale-up, mission-critical, and integrated stacks that have helped lead to Power's success and the mainframe's renaissance have worked against IBM is the less differentiated segments of the x86 business. (IBM does bring many of the same concepts and even technologies to x86 with its higher-end eXA products.) Be that as it may, when it comes to Power Systems, IBM's understanding of the needs of large enterprise data centers for their core applications has paid off.

Some of this may seem unremarkable. It is IBM we're talking about here after all. However, the idea of a Unix server as an integrated stack or solution is actually a relatively new one in historical terms. Before x86 servers became so ubiquitous it was the Unix server that epitomized the roll-your-own style of computing. And Sun, until quite latterly, painted lack of any forced software (much less services) integration as a virtue.

Thus, while Power Systems are certainly still widely used in high-performance computing where the ethos still tends toward more home-grown customization and integration, Power Systems have generally evolved from a traditional Unix server mindset to one more familiar to mainframe buyers and operators. This isn't to say that Power Systems slavishly imitates all the approaches that its System z mainframe brethren take. After all, if a buyer wants a mainframe, IBM already makes one; no need to re-create a second version.

But concepts such as the benefits of owning many levels of the hardware and software stack are twined throughout Power Systems presentations--and this is very much a mainframe characteristic.

Perhaps this shines through most closely with virtualization, which is a central theme to Power Systems discussion.

• Power servers are virtualized. That doesn't mean that they have an embedded hypervisor that can be booted up or that they're factory-loaded with virtualization in some way. Rather, even if you choose to run just one copy of an operating system, you're running it virtualized. IBM's 6 million transactions per minute on the TPC-C benchmark was on a virtualized system. Virtualization is inherent in the processor and firmware in addition to the IBM management software that sits on top.
• Power Systems users make use of virtualization. As measured by the sales of PowerVM--IBM's suite to deploy, manage, and utilize multiple VMs on a server--about 66 percent of Power customers use or at least plan to use the features of virtualization at some level. (PowerVM comes in several editions; more money gets you more features.) Contrast this with x86 where, for all the legitimate interest in and excitement about virtualization, the penetration with new servers is still something in the 15 percent or so range.
• The largest Power servers are huge. With rare exceptions and bragging-rights benchmarks notwithstanding, big servers these days aren't about running one workload or even about running one operating instance. It's about running many, many workloads with the appropriate combination of workload management techniques to enforce separation, provide flexibility, and offer mechanisms to guard against failures of various kinds. Virtualization (in several forms) is the foundation for all of this.

It wasn't that long ago, even by the standards of the computer industry, the IBM's RISC/Unix lineup was in danger of becoming a sideline. IBM dabbled in Unix "unification" efforts and with Intel's Itanium processor, and invested heavily in work associated with scaling up Linux. These efforts often seemed aimed at marginalizing its own RISC/Unix processor and operating system development work over the long term. However, in 2001, IBM released Power4. It was a major step forward in processor performance, and had two CPUs per processor die--then an unusual feature. Around the same time, IBM also doubled down on the development of its AIX flavor of Unix.

The result of those decisions, combined with consistent execution, is a very good one for IBM.

At Tuesday's Hot Chips conference IBM is scheduled to take the wraps off Power7, its next generation of RISC microprocessor. This is a big deal for IBM because Power is the foundation for its AIX Unix operating system, which has been one of the stars of its server portfolio in recent years. Power also supports the IBM i operating system and can also run Linux either natively or in an x86 binary translation mode that IBM acquired from Transitive. (Transitive is the company that developed the "Rosetta" technology that Apple used for the PowerPC to Intel transition.)

Modern microprocessors are incredibly complex machines. And major iterations, such as Power7, incorporate a multitude of new features, approaches, and techniques that are collectively far beyond the scope of a piece such as this to describe. Therefore, rather than trying to touch on everything, I'm going to touch on just a few aspects of the new processor generation that struck me as particularly noteworthy.

Power7 bumps both the number of cores and the performance per core over its predecessor. Its eight cores each support up to four simultaneous multithreading (SMT4) threads for a total of 32 threads per chip. SMT is a technique that helps make better use of the many execution units within a core by reducing the amount of time that software spends waiting for resources to become free. (One of the big issues with modern processor design is that some parts of the system run much more slowly than others so it's easy for a given thread to effectively create a roadblock while it's waiting; SMT is one way to alleviate this problem.)

This relative focus on multi-threading is a considerable departure from IBM's current Power6 which, at its 2006 unveiling, showed a focus on processor on frequency and hefty individual cores at a time when radical multi-core designs were grabbing the limelight. Despite its core count increase, Power7 continues to pay attention to per-core performance, but it's through techniques other than frequency; IBM says that the Power7 core has higher performance at lower frequency than the Power6 core.

One of these techniques is the aforementioned SMT4, coupled to an increase in the number of execution units per core. Power7 also reaches back to earlier Power playbooks and reintroduces out-of-order (OoO) execution, which was temporarily shelved for the Power6 generation. OoO execution can be thought of as a complementary technique to SMT that lets the processor skip over instructions that aren't ready to be processed because they are waiting on data.

Striking a balance between single-core and total-chip performance is one aspect of a general "balanced design" theme. Another is bandwidth. Each chip has dual-DDR3 memory controllers for a total of 100GB/sec of sustained memory bandwidth per chip. Scalability ports built into each chip are expandable to systems with a total of 32 sockets with 360GB/sec SMP bandwidth per chip.

Another aspect of balance is the design of the cache hierarchy, the memory physically near the processor that keeps frequently and recently used data near the processing units so that they can be accessed faster. Perhaps most notable is that there's a 32MB shared Level 3 (L3) cache in the middle of each chip. In the past, IBM has often implemented L3 caches as a separate die on a multi-chip module (MCM). This provides lots of room for the cache but means that the memory is physically further away (and therefore often slower) and demands lot of pins on the processor package to communicate with it.

Power7 takes a different approach. It's the first major commercial processor to implement an on-chip L3 cache using embedded DRAM (eDRAM). Caches are more typically constructed from static RAM (SRAM), which is faster and doesn't need to be refreshed on an ongoing basis but requires six transistors per device, rather than one for DRAM.

IBM estimates that the eDRAM has a 6:1 Latency improvement for L3 accesses relative to an external L3. Relative to an internal SRAM array, eDRAM takes about one third the space and consumes about one fifth the standby power. As for performance, IBM characterizes it as "almost as fast" and says that it handles the memory refreshes required by DRAM--memory contents have to be periodically written or they will decay--during "windows of opportunity" and generally won't have much of an impact on system performance.

As is increasingly the norm with microprocessor designs, power management also plays a big role in Power7. It's also an area where microprocessor designers are still learning. Power6 placed considerable focus on a feature called power gating, that effectively turned off portions of a core when they weren't being used. Power7's top power-saving mode, sleep, is less aggressive. It drops the voltage to the minimum level required to retain state. With the 45nm process used by Power7, IBM says that this almost eliminates leakage current and provides most of the power benefits of turning off the power entirely while saving a lot of verification complexities.

Finally, as the processing power of chips and the servers built on them grow, so too does the need to provide a level of resiliency against errors both transient and permanent in the literally billions of electronic features that make up these systems. It may be a cliche to note that if you're going to put a lot of eggs in one basket, you need to protect that basket well--but it's no less true for that.

Many of the new Power7 reliability features are focused on memory. For example, there's full X8 "chip-kill" with 64 byte error correcting code (ECC). This means that a full DIMM can die and the data can be steered over a spare device. For system partitions tasked with particularly critical workloads, Power7 can also do selective memory mirroring--think RAID 1 for memory. Power7 also just generally keeps building on error-checking and failover features; this includes the new ability to dynamically fail over if the main oscillator (clock) associated with the chip fails.

At a high level, Power7 shares a number of general design philosophies and directions with microprocessors from other vendors, including those from AMD and Intel that are more associated with scale-out designs and redundancy at the software level. This, in part, reflects that all vendors are fighting the same physical laws and are largely constrained by the same fabrication technologies. We see a general shift toward multi-core, an increased focus on power efficiency, and a need to protect against the inevitable glitches that affect ever smaller transistors--it doesn't matter who the vendor is.

However, that said, Power7 is a different design center than the scale-out standards bearers. While not literally a mainframe, its focus is very much the same sort of resiliency and performance balance at high vertical scale.

At the conceptual level, there isn't a huge amount of disagreement among technologists about the fundamentals of cloud computing--its forms, its characteristics, its potential benefits, and its limitations.

That said, individual vendors come at cloud computing from particular perspectives that often reflect the character and needs of an existing customer base. Nowhere is this truer than in the case of IBM. I attended an IBM event at their new Littleton, Mass., location a couple of weeks ago, and I was struck by the degree to which its latest cloud computing announcements and the strategy of its cloud computing organization mirror the focus and strategy of IBM in other areas.

Several related threads collectively define IBM's primary approach to cloud computing.

The first is "private clouds."

By "private," IBM means one of three things: 1) infrastructure within a customer's data center, 2) infrastructure operated by IBM for a customer within an IBM data center, or 3) IBM infrastructure dedicated to the use of a single customer.

In other words, private pretty much covers the gamut of everything that is not a shared, multi-tenant public cloud.

However, that shouldn't be read as IBM just using the term "cloud" here as a marketing buzzword to cover just about all computing. It's easy to draw that conclusion given IBM's focus on dedicated infrastructure. But while IBM uses the term broadly and very pragmatically, it does associate it with certain specific characteristics.

For example, one IBM exec at the event spoke of an existing virtual desktop infrastructure (VDI) deployment and noted that it was not, yet, a cloud because it is the operations analysis, the service orchestration, and self-service that make a cloud. (In this context, operations analysis refers to identifying and modifying workflows and interactions between people--such as eliminating "ad hoc chatter" that duplicates effort or adds latency.)

A second thread is IBM's main target for this phase of its cloud rollout. That would be development and test--mostly for the reason that IBM sees this as the low-hanging fruit. It's an area of enterprise IT where change happens all the time and resources are often not easily reclaimed even when they're no longer being used.

If this sounds like a familiar storyline, it should. This is where virtualization got its start and for many of the same reasons. At the same time, what IBM is doing here goes beyond test/dev virtualization.

And this brings us to the third thread, the precise nature of the audience for these products.

What's different here from just loading up VMware on a blade server and even adding a VMware product like Lab Manager is the other IBM tooling in place. Rational development toolsets and Tivoli service management are integral parts of these integrated packages. (Tivoli plays a central role in IBM's approach to cloud in general.)

You might think that this is a heavyweight and heavy-duty enterprise-centric approach to cloud computing. You would be right. I made this observation to one of their senior cloud executives and he didn't disagree.

The exec's response: "Our natural constituencies are the enterprise developers and we have to cater to the enterprise developer and enterprise developer teams. Within them, we have the subset who write enterprise transactional software. These are the apps who decide over life or death of a CIO and we have to cater to them. They are also the majority still of the central development organization."

This is not to say that IBM isn't also doing things related to lighter-weight, such as RESTful, development approaches. There's an IBM Mashup Center, for example, and cloud resources on IBM developerWorks. However, this style of cloud computing is not at the forefront of Erich Clementi's cloud computing organization.

But IBM is putting the wood of the arrow behind cloud computing for the core mission-critical applications in an enterprise, its primary target outside of the cloud as well.

Not long ago the infrastructure pieces needed to construct a data center were pretty straightforward--Computer Room Air Conditioning (CRAC) units, power conditioning equipment, uninterruptible power supplies (UPS), and electrical and plumbing to tie it all together. It wasn't unimportant. But it was largely a well-understood extension to the HVAC infrastructure of a typical commercial building.

That's changing in a big way for two major reasons.

The first is that servers may have gotten smaller but IT shops are trying to cram ever more of them into a given space. The result is that more power has to be delivered to and more heat taken away from ever smaller volumes of space.

The second is that data center operators are starting to factor power efficiency into their buying decisions. Power Usage Effectiveness (PUE) has entered the lexicon as a metric for evaluating how much of the power delivered to a data center goes into running the computers themselves as opposed to the infrastructure needed to support them.

In short, figuring out innovative ways to build efficient data centers is suddenly sexy. I've been offered more tours of data centers in the past year by companies such as Intel intent on showing off newly developed approaches to cooling and modularity.

Thus, it's not especially surprising that IBM is now announcing that, together with Syracuse University and the state of New York, they "have entered into a multi-year agreement to build a new computer data center on the university's campus that will incorporate advanced construction and smarter computing technologies to make it one of the most energy efficient data centers in the world. The data center is expected to use 50 percent less energy than a typical data center today, making it one of the 'greenest' computer centers in operation."

The $12.4 million, 6,000-square-foot data center will have on-site electrical co-generation system that uses a natural gas-fueled microturbine engine to generate all the electricity for the center and provide cooling for the computer servers.

Syracuse will manage and analyze the performance of the data center, "as well as research and develop new data center energy efficiency analysis and modeling tools. IBM will provide more than $5 million in equipment, design services and support, which includes supplying the electrical co-generation equipment and servers such as IBM BladeCenter, IBM Power 575, and IBM z10 systems. The New York State Energy Research and Development Authority (NYSERDA) is contributing $2 million to the project."

This will be an operational data center, albeit a relatively modest-sized one compared to mega-service provider facilities. (New Microsoft and Google data centers are reportedly in the 100,000- to 500,000-square-foot range.)

This may not be a particularly surprising announcement given the level of activity in this area. But it's nonetheless notable that an aspect of computing that was, in many respects, a sleepy backwater of incremental advance and its own impenetrable jargon is suddenly the subject of lots of new fundamental research.

The new world of computing has not been particularly kind thus far to the historical management vendors. It's not that virtulization and cloud computing in their various--and often ambiguous guises--have made past styles of computing irrelevant. COBOL programs still underlay lots of important business processes, after all.

(Credit: IBM)

But newer approaches to computing--often characterized by ground-up and tactical solutions to IT concerns--have tended to trump the sort of big, architected, expensive paths to nirvana that the likes of enterprise management have tended to take.

The fact is that the likes of CA Unicenter, HP OpenView, and IBM Tivoli may not have been a part of computing over the past five years or so--but they haven't exactly been on top of the exciting new action, either.

This is a context that makes IBM's Dynamic Infrastructure news, coming out of its Pulse conference in Las Vegas, worthy of more than passing mention.

Tivoli is, broadly, IBM's management software assets within its broader software group. IBM breaks Tivoli software into a variety of categories such as asset management; business application management; security management; server, network, and device management; service management; service provider solutions; and solutions for growing medium businesses.

The announcements IBM made at Pulse touch on a variety of areas--including storage. However, what I find most strategically notable are those related to service management. These include:

• IBM service management software and services from IBM Global Business Services, IBM Global Technology Services, and specialized IBM Business Partner capabilities. Together, they enable organizations to design and implement IT systems that centrally manage and monitor an entire industry infrastructure, enabling greater performance of both traditional assets, such as manufacturing robotic equipment, as well as emerging technologies like "smart meters" and RFID (radio frequency identification).
• A new governance-consulting practice. Through the practice, IBM works with clients to design governance systems to help mitigate risks related to business changes, changing market conditions, and regulatory requirements.
• New Tivoli Service Automation Manager software, which automates the design, deployment, and management of services such as middleware, applications, hardware, and networks, tasks that today are largely done manually and thus are subject to error, time constraints, and other human limitations.
• New Tivoli Key Lifecycle Manager software, which helps organizations simplify the life cycle of encryption keys by enabling them to centralize, automate, and strengthen security through key management processes, with an increasing number of IT infrastructure elements having built in encryption to protect them.

What most struck me about these announcements is the way that they intersect with other discussions that I've had with IBM of late related to System Z (i.e., IBM mainframes) and cloud computing.

On the System Z front, IBM's Karl Freund and Joe Castano recently walked me through a road map discussion that was fundamentally concerned with issues such as how to deal with "composite" applications that run across multiple platforms (including, but not limited to, System Z) and how to simplify hybrid transactions in such an environment. From my perspective, this sounds a lot like past System Z initiatives related to being the "hub" of the digital enterprise.

But this has a much more explicit management--which is to say Tivoli--focus.

More broadly, I also had the opportunity last week to hear Erich Clementi and Chris O'Connor walk me though IBM's new cloud-computing organization.

Clementi and O'Connor presented what my colleague Jonathan Eunice described as a "very heavyweight, enterprisey view of cloud." Put another way, my take was that this was really about how IBM will help the enterprise implement a version 2.0 of SOA (service-oriented architecture): lots of IBM Global Services (IGS) and lots of Tivoli management goodness.

There is nothing wrong with any of this. But it's a view of the cloud through the top-down lens of an enterprise-architected Tivoli and IGS approach, rather than the bottom-up, tactical, always-in-beta methodology that's been most associated with the consumer cloud.

I got an early-morning laugh out of this post on Timothy Sipple's Mainframe blog:

Will the popular press ever get it right about mainframe-hosted applications? I'm still waiting, after seeing this one: "...the computer mainframe handling unemployment claims is 30 years old and won't take many more technical improvements."

I can guarantee that the State of Florida is not running a 30-year-old mainframe. And "won't take many more technical improvements"? What on earth do they mean by that? That the application is holding a picket sign and threatening to march on the state capitol building, angrily knocking on the doors of legislators?

Good grief, this is lame, Florida. Go appropriate some funds and develop whatever improvements you want already. Want to write new functions in Java (to pick something at random)? Go for it--you already have it (on that not-30-year-old mainframe). Geez!

It wouldn't shock me at all to hear that the state of Florida is running old and poorly documented applications written in some language with which few of their developers are familiar. But that is fundamentally an obsolete application issue largely orthogonal to the question of the platform on which it's running.

The press that deals with technology topics on a regular basis has (mostly) gotten hip to the fact that the world doesn't begin and end with small x86 servers and that "Big Iron," in its various guises--whether mainframes, RISC/Unix, or scalable x86--still has a big role to play.

Outside of tech industry media, however, one often still sees the mainframe term used to conjure up antique computing a la Desk Set.

Over the past year or so, IBM has been revamping its Systems and Technology Group (STG) organization in a major way.

We see those changes reflected in a major way with IBM's Power systems announcement Wednesday at its COMMON User Group Conference in Nashville.

Two aspects of the STG reorg are of particular interest here.

The first is the customer aspect. This announcement reflects its venue; COMMON is IBM's midrange user group--which at IBM historically more or less equated to System i (and its iSeries and AS/400 predecessors). However, this announcement pulls in multiple product threads--including blades. This reflects how the client-facing part of the new STG organization now breaks down by customer type, rather than technology base. STG's Business Systems Group (BSG) is chartered with selling to the midmarket--across product groups. This is essentially a return to the older IBM sales model that was subsequently replaced by a more specialist-led approach.

The announcement also reflects changes to the product side of the reorganization. Looking back, System i and System p (to use the product line names in use prior to this announcement), sprang from wholly different roots. System i, long known as the AS/400 (although its lineage actually goes back further to the System/36 and System/38), was long an independent thread of IBM systems development based in Rochester, Minn.

Midwinter trips to AS/400 headquarters were not eagerly sought! It was a competitor to low-end and midrange minicomputers from the likes of Digital Equipment and Wang Labs.

System p, on the other hand, was long called the RS/6000 and had its home base in Austin, Texas. Its competition was other RISC-based servers running Unix such as those from Hewlett-Packard and Sun Microsystems. Especially given that the "old IBM's" product divisions could be best described (however uncharitably) as warring fiefdoms, there was little sharing of technology or anything else between them.

However, IBM has been steadily tearing down the wall between the two lines. Both i and p have used the same Power-family processor for several years now. Still, this week's announcement represents the first time that the wall is truly gone. System i is System p and vice versa. They're now both Power systems.

What this means is that there's now one common set of system models that can run AIX, i, or Linux operating systems--or a combination thereof using the integrated server virtualization features that fall under the PowerVM umbrella. The specific server models covered in this announcement are:

• IBM Power 520 Express is an entry-level server with up to four Power6 cores. The Power 520 Express is available in AIX, Linux, and i editions.

• IBM Power 550 Express is a midrange server with up to eight Power6 cores. The Power 550 is also available in AIX, Linux, and i editions.

There's also an i Edition Express for BladeCenter S. This basically backfills i support to previously announced Power blades in the SMB-oriented version of its BladeCenter and also adds the JS12, a new single-socket blade.

This is both a major midrange product announcement and the final (or, at least, as final as such things ever are) coming together of a complex organizational and product integration task that's been going on for years.

x86 servers with a single processor (as in single socket) are hardly unusual. They anchor the entry point for most vendors' product lines. Furthermore, beyond those systems that are sold specifically to be used as servers, an untold number of PCs sit under desks or in closets functioning as impromptu file or print servers.

However, pretty much since the advent of mass-market multiprocessing--in the Windows NT 3.51 era or thereabouts--uniprocessor servers have been very much the penny-pinching server option. Yes, they have fewer processors than their dual-socket brethren; that much is obvious. However, uniprocessor boxes have also typically jettisoned all manner of other capacity or reliability upgrades from memory to power.

This makes IBM's release of the uniprocessor IBM System x3350 notable and, perhaps, a harbinger of broader changes accompanying the wide adoption of multicore processors. (For whatever reason, this appears to have been a rather sub rosa announcement--rolled in almost incidentally with a broadened Lenovo partnership.)

For the x3350 is not another uniprocessor in the usual vein. The 1U rackmount server's features include:

• Hot-swap, redundant power supplies
• Integrated management controller
• Up to 8GB PC2-5300 DDR II 667MHz memory, using 4 DIMM slots
• Choice of dual- and quad-core Intel Xeon processors
• SAS or SATA drives, optionally hot-swap and RAID

In short, specs that wouldn't look out of place in a compact 1U dual-socket server.

Historically, each step down in processor count has tended to come with a concomitant cutting of other features--not just I/O or memory capacity (as might be expected), but also various and sundry management, reliability, and redundancy features. However, the storyline is getting more complicated.

On the one hand, server virtualization does appear to be pumping up interest in larger, scale-up servers. Part of the reason is that larger servers offer a degree of simplification through physical consolidation. They also tend to have the ultimate features to protect against memory failures and other hardware glitches. And server virtualization helps separate workloads and thereby makes effective use of this relatively expensive hardware.

At the same time, with quad-core well on its way to being the mainstream in x86 servers, individual processors look a lot like whole multiprocessor complexes of a few years back. This seems to be driving at least some interest in uniprocessor servers that aren't just cheap, cheap, cheap. Beyond x86 servers, Sun Microsystems' octal-core UltraSparc "Niagara" and "Niagara 2" servers are currently "uniprocessor" only (though with numerous cores and hardware support for multithreading, and multi-socket "Victoria Falls" versions coming). Of course, processors have been getting faster for pretty much forever, but the purchasing dynamics seem to be shifting with Moore's Law now reflected more by core count than by frequency.

The System x3350 doesn't foreshadow a massive change in how rackmount servers are designed and consumed. But it does offer an interesting data point that suggests the landscape is shifting.

IBM's last major Systems and Technology Group (STG) reorganization in 2000 both put an exclamation group on and added momentum to the company's resurgence. IBM described the introduction of the umbrella "eServer" brand atop all of its server product lines as:

a product of Project Mach 1, a major cross-company initiative begun three years ago to harness the company's best technologies and practices to support the infrastructure for the next phase of e-business. From the consolidation of IBM server manufacturing and development, to the realignment of its sales force, to breakthroughs such as copper chips, Silicon-on-Insulator and Memory eXtension Technology, to partnerships with leading software vendors, to IBM's corporate-wide embrace of Linux--every corner of IBM moved closer to today's launch of the IBM eServer.

This unification stood in stark contrast to the past norm in which product groups in Poughkeepsie, N.Y., Austin,Texas, Raleigh, N.C., and Rochester, N.Y., often seemed more like warring fiefdoms than different faces of a single integrated company. True, the various product lines--xSeries, zSeries, iSeries, and pSeries--maintained distinct (if sometimes uncomfortably overlapping) identities within the eServer scheme. Nonetheless, by historical IBM standards, eServer under Bill Zeitler looked like a big and (mostly) happy family.

This latest reorg can perhaps be best thought of as taking the next big step toward shifting away from a structure based on technology and product line distinctions, and toward a structure along the lines of distinct customer segments.

The new STG organization retains groups, led by general managers, oriented around the various product lines: Mainframe Platform (System z), Power Platform (System i and p), Modular Business Platform (System x and BladeCenter), and Storage Platform. However, these are now entities mostly concerned with managing product development and rollout. Go-to-market activities, including sales, now reside in four other groups:

• Enterprise Systems. This could also be thought of as "major accounts" because, in addition to selling into large-scale datacenters, Enterprise Systems also encompasses sales to workgroups in large enterprises.
• Business Systems. We first got a taste of this reorg last year when IBM created this SMB-oriented group. Given the nature of the market, much of the sales strategy here will be to leverage partners of various types.
• Industry Systems. This group will focus on areas like retail or health care where IT often plays roles outside of a traditional data center environment--often in the form of embedded OEM products. Although, in a sense, Industry Systems follows in the footsteps of its engineering services predecessor, IBM has also made it clear that its focus is now far more on replicable products than one-off projects.
• Microelectronics continues to offer a variety of services from semiconductor fabrication up through turnkey design.

IBM's justification for these latest changes is that customers want to see one face of IBM. They don't want to see System x and System p sales reps each offering whatever parochial solution is better for their particular comp plan. Even if the customer doesn't mind all that much, IBM is doubtless not a big fan of customers playing IBM divisions and sales reps against each other to get the best price. The customer segment approach is a play that IBM's run before--indeed, run quite successfully. There were good reasons for getting away from it in years past, but there seem to be good reasons to get back to it now.

That said, any organizational scheme has its trade-offs. Product-centric alignments are in some sense more natural, or at least simpler. They match up with the underlying technologies. This makes it easier, for example, for sales teams to become experts on particular product sets--without more complicated overlay sales specialist schemes. A product orientation also means that you're likely to see more effort go into pushing products into new areas where they aren't necessarily the most natural fit; Linux on POWER is one example from IBM's playbook. Although some force-fitting may well be wasted energy, such initiatives can also open up new markets for a company.

At the end of the day, it may even be reasonable to ask how much the specific organizational structure ultimately matters. Some mappings may make more or less sense at a given point in history for a given company, but I've seen so many cycles and fashions over the years that I have some trouble accepting that any one approach is ideal. Perhaps it's more important to occasionally shake things up and avoid complacency than it is to lay out any particular form of organizational chart.