The elephant is dancing nicely with Java

Imagine you’re playing a free association game. Someone throws out a name and you shoot back the first few adjectives that come to mind. When you get served up “IBM,” what do you say? “Nimble, responsive, market focused?” I don’t think so, but indeed that seems to be exactly what IBM has been over the last 18 months when it comes to Java technologies.

If that surprises you, you are not alone. Not only do analysts find IBM’s swift and widespread adoption of Java uncharacteristic of a company its size, so do veteran IBM managers who are watching Java up close.

“I’ve been with IBM for 32 years,” said Mike Oliver, program manager for IBM’s S/390 Emerging Technologies Group, which is charged with Java for mainframe environments. “Certainly I have never seen anything become so popular so fast as Java. When I look at the maturity Java has achieved, and see what people are doing with it, I am amazed,” Oliver said.

“We’ve gone from thinking in terms of Web-years, which are 90 days, to Java-years that we consider 60 days long,” said David Gee, program director for Java Marketing at IBM. “We are concentrating on getting technology out to customers as fast as possible. We used to sit and analyze the market only to find out the market had passed us by before we got our act together. We now have people thinking and planning in 60-day periods,” he said.

Bruce Anthony, chief architect and strategist for IBM’s Network Station, has been with the firm for 15 years and said he can think of no other technology that has caught on so pervasively and so quickly. “This is the most incredible ride I’ve been on in my career,” he said.

And when addressing a recent Lotus developers’ conference, IBM’s top man — Louis Gerstner, the firm’s CEO — put it this way: “We’re hard-core about Java at IBM. Between Lotus and IBM, we have one thousand or more developers in 19 laboratories getting Java ready for global business. Over the next few years we’ll spend hundreds of millions of dollars on Java development.”

Analysts that spend a great deal of time looking in on IBM are somewhat surprised. “IBM does not have a history of embracing other people’s technology, or of being particularly fast and responsive to the market with product. With Java they have done both those things,” said Tim Sloane, director of Internet Research for the Boston-based Aberdeen Group.

Sloane says IBM is moving at lightning speed for a company of its size. Referring to a comment Gerstner made when talking over corporate leadership in 1993, Sloane said, “The elephant seems to be dancing pretty nicely. I mean nimble is not really the adjective that generally comes to mind when you’re thinking of IBM.”

Rationale

So why has IBM been able to push ahead so quickly with Java? According to sources inside and outside the company, Java held the key to solving several fundamental problems the firm faced.

First and foremost, IBM is counting on Java to solve its incredible platform incompatibility problem. Having so many different hardware and operating-system platforms is hard on IBM customers, IBM’s own developers, and IBM’s consulting and services workforce.

“Trying to get applications to run between AS/400s, RS/6000s, S/390s, and the rest of its product line has been no small pain in the butt for both IBM and its customers,” said Sloane. “The ability to have Java as an integrating suite across its product lines is a win/win for IBM and its customers. It will be interesting to see the kinds of solutions IBM brings out to leverage Java as a cross-platform solution,” he said.

A second thing Java lets IBM do is consolidate the way they handle consulting projects.

“Imagine the fun they now have when they consult on IBM equipment. They have different development and production environments they must deal with on many projects. It is hard to apply what you’ve just done on the AS/400 to a different customer that may have the same problem, but a different IBM architecture,” said Sloane.

Amy Wohl, principal of Norberth, PA-based Wohl Associates, a long-term IBM watcher, points to both SAA and OpenDoc as central precursors that readied IBM for the strides they are making with Java.

“SAA was an early attempt by IBM to lay out an architecture that would work across all its platforms. The problem was that SAA did not work either technically or from a market point of view,” said Wohl. It did not work technically because it was far too complex and impossible to keep all the pieces synchronized. From a marketing standpoint, people were never convinced it could work, she noted.

Pulling the plug on OpenDoc — a cross-platform component architecture it pursued in conjunction with Apple — was the last straw for IBM, Wohl said. Both experiences set IBM up to be very receptive to a component architecture that could actually deliver.

Wohl also points to IBM’s recognition that OS/2 never was going to be a volume platform, its acquisition of Lotus with strong cross-platform aspirations, and the nascent idea of a network computer percolating inside IBM as contributing to IBM’s Java-readiness.

Having many hardware platforms, “none of which have mainstream or volume market operating systems,” according to Wohl, is a major platform headache. In addition to the problems it causes for customers and for IBM internally, it is also a big problem for commercial software developers.

The AS/400 platform, for instance, was successful largely due to available applications, said D.H. Andrews, principal of the Cheshire, CT-based D.H. Andrews Group. Helping software vendors to better leverage their investment across multiple platforms is essential to make sure those vendors continue to support older architectures with their latest and greatest software.

Historical antecedents notwithstanding, “I think what IBM has done with Java is amazing,” Wohl said. “I had a conversation with an IBM employee I first met 20 years ago as a consultant. We both agree that the IBM I knew, and that he worked for, could not have imagined doing this, much less actually pulling it off. To think of developing to a platform that someone else controls, in the way Sun controls Java, would have been unthinkable for the old IBM. And to do it with enthusiasm and to develop whole strategies based on it — this is all quite amazing,” she said.

From an internal perspective, IBM is very interested in Java “because it gets us back to our core business,” said Simon Phipps, IBM’s chief Java evangelist. “Our core business is helping companies be effective at the corporate level — letting companies take their business data and spread it horizontally across the enterprise, creating inter-departmental and company-wide applications, and serving them from central servers.”

Phipps’ analysis is that many companies bought IBM systems to create horizontal solutions in the 1960s and 1970s. When users also started buying PCs and Unix servers in the mid-to-late 1980s, the diversity that proliferated made it harder and harder to create new horizontal solutions.

“We found ourselves in the early 1990s wondering how companies that invested heavily in vertical solutions — departmental systems — were ever going to get back to solutions that reached across the company and even out into their customers and dealer networks,” said Phipps. “Solving that problem is how Java helps us get back to our core business — enterprise solutions.”

IBM’s Gee said that Java provides “an enormous opportunity to level the playing field.” For him that means Java is a way for customers to develop one set of skills and tie together disparate technologies, for which IBM is partly responsible. Gee claimed 70 to 80 percent of the world’s business currently is conducted on legacy systems — what Gee prefers to call enterprise systems. Those systems must be integrated with the new network computing paradigm, rather than ripped out and replaced.

Reading between the lines of Gee’s metaphor, Aberdeen’s Sloane said, “Who wants to level the playing field if you’re ahead. Nobody! On the other hand, IBM is not ahead of the game, so a level playing field puts them in a position where they can be a frontrunner again. IBM is betting Java will be so widely adopted that a leader in Java will, in essence, also be a leader of the computing pack,” Sloane said.

If for some reason Java falls flat, IBM would probably have to consolidate some of its platform commitments, or it would continue on the road to becoming a custom consulting business rather than a primary hardware and software vendor, Sloane said.

Those are awfully big stakes to pin on Java, but that’s what IBM has done. While IBM is a firm that generally pursues multiple options simultaneously — hedging its bets — that does not seem to be the case with Java.

“I believe [IBM is] fully committed to moving forward on Java. I believe the number of resources moving to work with Java within IBM grows every day, which only strengthens its commitment,” said Sloane. “I don’t believe [IBM is] working on a backup plan if Java doesn’t work out. I don’t think there is a backup option,” he said.

Getting started

The initial push for Java came from IBM’s Hursley Park facility in the UK. It owns responsibility for the lion’s share of IBM’s middleware products, including CICS, its popular transaction processing manager. It is also the home office for Mike Cowlishaw, an IBM Fellow who created the Rexx programming language — now updated to NetRexx for Java.

Cowlishaw was studying virtual machine technology at the end of 1994 and early 1995, when he caught wind of Java. He confidentially bought a license to Java as early as possible, said IBM’s Phipps, who also is based in Hursley Park. “Mike determined that not only was it an interesting virtual machine but Sun also was doing all the right things in terms of object-orientation, security, and network support. And the licensing terms and conditions were attractive. That combination, Cowlishaw predicted, would be very powerful,” Phipps said.

Cowlishaw teamed with IBM’s chief UK scientist, Ian Breckenbury, to port and evaluate Java. Phipps joined that team in July/August 1995, and the group wrote a report to the Chairman’s technical panel — Lou Gerstner’s advisory panel of senior vice presidents and technologists — saying Java was either going to be the killer technology or it was going to have no impact on the industry. Either way, an early investment in Java would be extremely inexpensive to get in on the ground floor of Java and shape its direction, so the decision-making panel approved the team’s request to pursue Java.

“We delivered Java ports in a timely fashion and convinced the AIX and OS/2 people they have nothing to lose by embedding it in their operating systems. That attracted a lot of attention and helped us educate many grass-roots, middle managers inside IBM,” said Phipps.

“To be perfectly honest, toward the end of 1996 a lot of people inside IBM `suddenly discovered’ we were doing Java and wondered what it was. There was no master edict from the top. It was obviously the right technology. It was being implemented by all the really sharp folks inside IBM. And it seemed clear it was the right direction to take,” he said.

According to Phipps, IBM Fellows are the highest form of technological life inside IBM, and Breckenbury is a vice presidential-level technologist. The initial Java group thus had unprecedented access to the right people across IBM.

“When you start evaluating the technology at that level, you can move forward pretty quickly,” Phipps said.

Quite separate from Hursley Park, IBM’s Rochester Laboratory in Minnesota also may have influenced IBM’s readiness to aggressively take Java enterprise-wide. The San Francisco business frameworks initiative started in 1994 within the AS/400 Division. Its goal, said Andrews, was to deliver object-oriented business application skeletons that medium-size ISVs, and some end-user shops, would use to deliver applications for common business tasks such as general ledger, accounts receivable, order processing, and warehouse management.

“In November 1995 we started prototyping with Java behind closed doors,” said Ralph Christ, IBM’s senior development manager for the San Francisco Project. The project officially switched to Java in June 1996, including a decision that probably raised eyebrows within the firm — to dump IBM’s CORBA implementation SOM/DSOM in favor of RMI, the Remote Method Invocation API now part of JDK 1.1. CORBA’s strength is legacy integration, while RMI is designed for interaction between pure Java objects.

Three stages of pursuit

IBM has aggressively pursued Java in three phases: Java virtual machines and development toolkits, Java-enabled middleware, and solution-oriented deliverables such as tools and frameworks. (See sidebar

IBM aggressively expands range of Java products

.) By the middle of 1996, IBM delivered a JVM and JDK for all its platforms — AIX, OS/2, OS/400, OS/390 — and even for Windows 3.1. It then delivered Java interfaces for its CICS transaction processing manager, DB2 and IMS databases, MQSeries messaging, and Java wrappers for Lotus Notes classes.

In 1997 IBM will roll out Java toolsets and frameworks, including VisualAge for Java, the BeanMachine (formerly code- named AppletAuthor), and Kona from Lotus. The first few frameworks should be delivered in late 1997 by the Sharable Frameworks Project, code-named San Francisco. IBM also has 24-hour development work underway to create business-oriented JavaBeans components. And the company just announced a new collaborative middleware infrastructre, code-named inverse technology, that is written in 100 percent Java.

The odd man out in terms of IBM divisions with high-profile Java development programs appears to be the Tivoli group, which focuses on system and network management. Expect some Java-related announcements from them later this year. If a Java-related roadmap is not forthcoming from them soon, it will be noteworthy.

Measuring success

Most analysts agree that it is difficult to measure the success of IBM’s Java initiatives in traditional return-on-investment (ROI) equations. No one set of investments, or single product effort, stands alone. The entire “write once, run anywhere” vision held out by Java is designed to leverage everything else, directly or indirectly.

“Java isn’t about a product here or there. It is about how the total picture comes together,” said Scott Hebner, manager of application development marketing at IBM. “We are going to have more success going into a customer and selling them a complete networked solution — everything from services down through building-block components, tools, middleware, all the way to the operating system — versus the past where IBM groups would go in individually to sell them OS/2, or AS/400, or tools. We don’t want our customers to have to put this all together,” he said. “We want to be able to do it for them.”

For IBM’s Gee, the ROI equation is not a simple one, but the revenue can certainly be stated in simple terms — Java leverages virtually everything!

“Java offers tremendous opportunities to sell servers, services, education, integration, and implementation. That is our revenue model,” Gee said.

“Our customers want quicker, smarter, and cheaper. They want to develop their applications quicker. They want to roll them out and implement them smarter. And they want a single set of skills throughout their organization that allows them to work cheaper. When you tell the Java story to CEOs or CIOs — who are spending one to five percent of their firms’ revenue on technology, updating their desktops every 24 months, migrating people across operating systems, and changing the applications every 12 months — they realize there is a huge savings potential with Java,” Gee said.

“I don’t believe it is possible to do an ROI analysis of IBM’s Java program because it is an investment in tomorrow’s market,” said Aberdeen’s Sloane. “Everything is predicated on Java becoming the underlying infrastructure of computing’s future technology. IBM’s vision says that will happen and thus this investment will pay off. If that analysis is wrong then this money is wasted,” Sloane said. “IBM is betting the shop that Java [will be] successful.”