Link: Driving Diversity Change In a “Problematic” World

“If you’ve ever had to plan a long project — getting to the end state can seem so difficult and impossible. The work that takes to get there is painful and fraught with peril and compromises. We think the path to success looks like a nice, neat flowchart. We think change comes from the top down, or the bottom up, when in reality it’s a bunch of arrows coming from a variety of crazy directions, with missteps and everything in-between.”
Original source: Driving Diversity Change In a “Problematic” World

“the obsolescence of Java EE” – Notebook

Bottom line: Java EE is not an appropriate framework for building cloud-native applications.

In preparation for this week’s Pivotal Conversations, I re-read the Gartner write-up on the decline of traditional JEE and the flurry of responses to it. Here’s a “notebook” entry for all that.

From Gartner’s “Market Guide for Application Platforms”

This is the original report from Anne Thomas and Aashish Gupta, Nov 2016. Pivotal has it for free in exchange for leag-gen’ing yourself.
What is an “application platform” vs. aPaaS, etc.?

Application platforms provide runtime environments for application logic. They manage the life cycle of an application or application component, and ensure the availability, reliability, scalability, security and monitoring of application logic. They typically support distributed application deployments across multiple nodes. Some also support cloud-style operations (elasticity, multitenancy and selfservice).

An “aPaaS,” is a public cloud hosted PaaS, of which they say: “By 2021, new aPaaS deployments will exceed new on-premises deployments. By 2023, aPaaS revenue will exceed that of application platform software.”

On the revenue situation:


Commercial Java Platform, Enterprise Edition (Java EE) platforms’ revenue declined in 2015, indicating a clear shift in the application platform market…. Application platform as a service (aPaaS) revenue is currently less than half of application platform software revenue, but aPaaS is growing at an annual rate of 18.5%, and aPaaS sales will supersede platform software sales by 2023.


Currently, the lion’s share of application platform software revenue comes from license sales of Java EE application servers. From a revenue perspective, the application platform software market is dominated by just two vendors: Oracle and IBM. Their combined revenues account for more than three-quarters of the market.

Decline in revenue for current market leaders IBM and Oracle over last three years (4.5% and 9.5% respectively), meanwhile uptick from Red Hat, AWS, and Pivotal (33.3%, 50.6% and 22.7% respectively).
Decline/shifting is driven by:

given the high cost of operation, the diminishing skill pool and the very slow pace of adoption of new technologies, a growing number of organizations — especially at the low end of the market — are migrating these workloads to application servers or cloud platforms, or replacing them with packaged or SaaS applications.


Java EE has not kept pace with modern architectural trends. Oracle is leading an effort to produce a new version of Java EE (version 8), which is slated to add a host of long-overdue features; however, Oracle announced at Oracle OpenWorld 2016 that Java EE 8 has been delayed until the end of 2017.3 By the time Java EE catches up with basic features required for today’s applications, it will be at least two or three years behind the times again.

Target for cloud native:

Design all new applications to be cloud-native, irrespective of whether or not you plan to deploy them in the cloud…. If business drivers warrant the investment, rearchitect existing applications to be cloud-native and move them to aPaaS.

Vendor selection:

Give preference to vendors that articulate a platform strategy that supports modern application requirements, such as public, private and hybrid cloud deployment, in-memory computing, multichannel clients, microservices, event processing, continuous delivery, Internet of Things (IoT) support and API management.


Oracle and Java: confusing

Oracle’s stewardship of Java has been weird of late:

It’s all about WebLogic and WebSphere

I think this best sums it all up, the comments from Ryan Cuprak: “What this report is trying to do is attack Oracle/IBM via Java EE.”

I wouldn’t say “attack,” but rather show that their app servers are in decline, as well as TP processing things. The report is trying to call the shift to both a new way of development (cloud native) and the resulting shifts in product marketshare, including new entrants like Pivotal.

I can’t speak to how JEE is changing itself, but given past performance, I’d assume it’ll be a sauntering-follower to adapting technologies; the variable this time is Oracle’s proven ambivalence about Java and JEE, and, thus, funding problems to fuel the change fast enough to keep apace with other things.

Autonomy quarter stuffing

When Autonomy was negotiating a sale to an end user, but couldn’t close the sale by quarter’s end, Egan would approach the resellers on or near the last day of the quarter, saying the deal was nearly done. Egan coaxed the resellers to buy Autonomy software by paying them hefty commissions. The resellers could then sell the software to a specified end user – but Autonomy maintained control of the deals and handled negotiations with the end user without the resellers’ aid. There’s no way these transactions could be revenue.


“It was just dumb”

This a good parable on what can go wrong in large organizations when incentives are not working as planned.:

But the reality seems to be messier and more boring: Wells Fargo wanted its employees to push lots of real accounts, it asked too much of them, and the employees rebelled by opening fake accounts to get the bosses off their backs. The fake accounts weren’t profitable for Wells Fargo, and no rational executive would have wanted them, which is why Wells Fargo kept telling the employees not to open them. But the employees did anyway because they felt like they had no other choice. It was not an evil high-level plot. It was just dumb. It was a form of employee resistance that was channeled into fraud by bad incentives and bad management. There is a limit on how many times you can ask a guy in a hearing “this thing you did was pretty dumb, wasn’t it?” Though look for the Senate Banking Committee to test that limit.

Knowing very little about the details, back in IT-land problems like this usually mean the culture needs some tweaking.

Check out some more commentary.