Monday, 27 September 2010

Oracle and the Business of Java

Oracle now owns Java. But how do they view it as a business? As a Java Champion, I had some additional meetings at JavaOne which provide a slightly different take on this important topic. This also affects #bijava to some degree.

The Business of Java

JavaOne 2010 saw a new start for Java with Oracle in charge. Many of the same big names, now employed by Oracle instead of Sun, were there providing deep technical talks on the major Java topics. What was interesting is who else was there and what their roles were.

For most of us, being a senior technical lead or architect is not sufficient to enable us to implement our plans. Instead, we need a stakeholder from the business with a budget - typically a product manager.

Under Sun, I am informed that the product management side was minimal (please note that I don't have any links here, just heresay). Contrast this to Oracle, where there is a clear, separate and in control product manager for each key technology area in Java.

One public example of this was the Java FX talk, where Richard Bair was speaking on the technology changes. In the Q & A section, whenever an awkward or forward looking question was asked that implied commitment or spending money, he was able to bring his product manager up to answer that question. This isn't something I remember seeing with Sun.

At this point, your reaction might be "but I don't want business people in charge".

In my view, having a product manager is generally a Good Thing, and looks like working well for Java. The key aspect is the ability to treat Java as a product (both gratis and with paid support/extensions). The paid elements provide some of the funding going forward to invest in the elements that technologists want from the platform.

Moreover, the product manager provides an independent way to balance competing priorities. Clearly, there are many, many things that might be good enhancements to Java. Which ones should go ahead is not always obvious, and an external perspective is useful. Its also one that most of us outside Sun/Oracle deal with everyday.

One way that the analysis and investment decisions can be made is by Cost-Benefit-Analysis (CBA). Oracle has about 100,000 employees. Of these, lets say 10% (10,000) are Java developers (there are many, many deveopers working on Oracle Java-based products). It should be clear that any change that make a developer even 1% more productive would have massive savings just within Oracle itself (thanks to the 10,000 in-house deveopers). As such, many changes or enhancements can probably be justified simply on an internal CBA.

To emphasise the point, there is no need to say "change X will save the industry Y million dollars per year". Instead, there can be a calculation that says that the change will save Oracle Z million dollars per year. Clearly, such an analysis is much more useful.

I have been reassured in conversations that this does not place product managers in absolute power. More specifically, the technical leaders (whose names we all know), will also have a say in what goes ahead and what doesn't. I saw no signs that the product manager will be deciding the syntax of Project Lambda for example!

In terms of #bijava, the point here is simply that to move forwards with a break in compatibility requires both technical and business buy-in. But there are also good business reasons for that break - competition, market-share, productivity of those 10,000 developers, and against - risk, cost. Balancing those competing elements is probably more a product decision than a straight technical one, so it is actually useful to have these new product leaders in place.

Summary

Sometimes as developers we like to think that we could do without the business sponsor or product manager. In truth their role is vital.

Oracle now has clear product managers for all the Java technologies, something I am given to understand was lacking prior to the takeover. I see this as an unequivocal Good Thing. However, we in the community now need to respond by making the business as well as the technical case when making proposals.

6 comments:

I like the SCRUM philosophy on this: the technical guys present a points-to-implement per end-user feature. The business guys can decide which features to do first, but now how to do them.One important thing is to protect the business guys from themselves:The technical guys automatically calculate in, in the points-to-implement score, any technical refactor needed to do the feature right and don't allow the business guys to decide about the need for those refactors.

I agree that a *good* product manager is a good thing for a company. When I say "good" pm, I mean someone that does not think developers or technical people behind is just interchangeable crap, and that HE is doing the real important job.

At least in France (I'd be glad to know if this is different in other countries), technical skill is not very valued, and "managers" are almost always generally seen as the level above.

If management managers would just understand their job is to manage, but that's they're not compulsorily more important than techies, then techies mightn't dislike them as it's so common today.

I thought Oracle had multiple product managers, sort of like Microsoft. I am sure I have met several JDeveloper PM's without every being able to assert differences in responsibility.

Also, don't you kind of forget the other side of the coin (pun intended), "change X will cost the industry X million dollars per year", as in, all change costs something.

I believe this was the single biggest problem at Sun, and explains why we now have such massive entropy issues. A vendor such as Microsoft seems to take the beating gradually rather than waiting for the big crunch, which causes pain but allows them to progress - sort of like removing a band-aid slowly. Hopefully Oracle will not be as conservative as Sun.

The cost-benefit analysis argument you give is not very strong, unfortunately: In any company, there are always many possibilities to invest. Spending money on 1% productivity improvements has to compete with other opportunities, for many of which success is easier to measure. Also, upfront investment that will save (as opposed to make) money in the long run is a tough sell. Let's hope that the product managers don't have to micro-justify every improvement but instead have a negotiated budget. Then it's "just" about making wise decisions within the budget.

I second my compatriot Baptiste about the situation here. What I see over and over again is tech people disengaging because the PM is making much more money and it's not fair. The (little) innovation I see is from techies who just decide to apply common sense. Then they relapse.

Baptiste and exdevfr - That is pretty much SOP everywhere. You will find places where technical people are valued, but that is not the norm. A lot of this is due to "the good ol days" where you had one language and one platform. (FYI, i am in the USA). I just had conversation with a P[roject] M[manager] a few weeks ago and I said they need to include us sooner because of our insight. And she said ... I use to program - meaning that is all I do - code to some spec.