When middle-management is screwing it all up – Pivotal Conversations

cover-art-051

Whether it’s “DevOps,” “digital transformation,” or even “cloud” and “agile,” middle-management is all too common an issue. They simply won’t budge and help out. This isn’t always the case for sure, but “the frozen middle” is a common problem.

With a big ol’ panel of people (including two folks from RedMonk), we talk about tactics for thawing the frozen middle.

“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:

platforms-and-paas-revenue

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.

And:

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.

And:

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.

Responses

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.

The undying death of JEE – Gartner, app servers, and cloud native – Pivotal Conversation

One of your favorite technologies is on the death wagon, again. Gartner recently recommended avoiding JEE for new, cloud native application development. This predictably kicked up all sorts of push-back from the JEE stalwarts. In this episode we discuss the report, the responses, and all the context to figure out what to make of all this. Spoiler: JEE isn’t dead, as ever, it’s just a part of the ongoing gumbo that is a Java application.

 

Subscribe, follow, feedback

News Links

Gartner on JEE for Cloud Native

Gary Gruver interview on scaling DevOps

I always like his focus in speeding up the release cycle as a forcing function for putting continuous integration in place, both leading to improving how an organization’s software:

I try not to get too caught up in the names. As long as the changes are helping you improve your software development and delivery processes then who cares what they are called. To me it is more important to understand the inefficiencies you are trying to address and then identify the practice that will help the most. In a lot of respects DevOps is just the agile principle of releasing code on a more frequent basis that got left behind when agile scaled to the Enterprise. Releasing code in large organizations with tightly coupled architectures is hard. It requires coordinating different code, environment definitions, and deployment processes across lots of different teams. These are improvements that small agile teams in large organizations were not well equipped to address. Therefore, this basic agile principle of releasing code to the customer on a frequent basis got dropped in most Enterprise agile implementations. These agile teams tended to focus on problems they could solve like getting signoff by the product owner in a dedicated environment that was isolated from the complexity of the larger organization.

And:

You can hide a lot of inefficiencies with dedicated environments and branches but once you move to everyone working on a common trunk and more frequent releases those problems will have to be address. When you are building and releasing the Enterprise systems at a low frequency your teams can brute force their way through similar problems every release. Increasing the frequency will require people to address inefficiencies that have existed in your organization for years.

On how organization size changes your managerial tactics:

If it is a small team environment, then DevOps is more about giving them the resources they need, removing barriers, and empowering the team because they can own the system end to end. If it is a large complex environment, it is more about designing and optimizing a large complex deployment pipeline. This is not they type of challenges that small empowered team can or will address. It takes a more structured approach with people looking across the entire deployment pipeline and optimizing the system.

The rest of the interview is good stuff. Also, I reviewed his book back in November; the book is excellent.

Link

2% increase in IT budgets predicted

The big takeaway is that small increases in IT budgets are the new normal. Unlike previous recoveries, we have not seen a large jump in IT spending over the past five years. So if a CIO is only seeing a two or three percent increase this year, he or she should understand that is pretty much in line with other companies.

See more guidance charts on IT priorities, n=190.

Link

The point of business computing is increasing productivity

In covering his latest framing for why opportunity in enterprise IT Geoffrey Moore recounts some history:

Let me give some examples. In the 1980s there was enormous trapped value in manually intensive office paper work; office automation, especially word processing, spreadsheets, and email, became the mechanism by which that value was released. In the 1990s there was enormous trapped value in redundant functionality replicated inside every corporation, especially in relation to manufacturing and customer service transactions; enabling outsourcing to release that trapped value became the fuel the drove the client-server ERP revolution. In the 2000s there was enormous trapped value in media and entertainment being confined to a handful of publishers and physical distribution to tethered endpoints; this drove the deployment of wireless broadband networks, mobile devices, and electronic distribution.

That’s what business computing is all about: productivity. You either are removing costs and speeding up a process (a room full of mathematicians and accounts turns into an Excel spreadsheet) or, similarly, creating a new way to interact with your business that was too expensive, or impossible, before (advertising with Facebook and Google, ordering groceries from your couch, outside of NYC – not the best example).

“Entertainment” and, let’s call it, “personal productivity” (health trackers, Facebook for the users [not the real customers of the advertisers], mint.com, etc.) are much of the “consumer IT” benefits.

Whatever the case, the goal of using a computer (and the software on-top of it) in a business case is to increase productivity.

Source: “The Next Trillion Dollars,” Geoffrey Moore, April 2015.

Link: Googles challenge in enterprise cloud

Post Alphabet, where any previous inhibitions about pursuing new hobbies have evaporated, it is even harder to imagine the “capital allocators” choosing to invest in thousands of enterprise sales and support people given alternatives involving life extension and/or space elevators. After all, won’t the robotics division eventually solve any problem that today requires humans?

The rest of the state of cloud is pretty good. It’s a regular “pulls no punches and punches everyone” type situation.

If you threw in some charts and numbers, you’d have an even fancier missive, but qualitatively: just Jim-dandy.

Who run IT-town? Ops or Dev?

At container-oriented conferences, whenever a vendor or an open source contributor demonstrates the ease with which developers deploy containers to production, usually there are cheers. But in large enterprises, especially those that maintain strict compliance guidelines, it’s IT that makes the decisions about what gets moved from development to production, and how it is done.

This is what you might call the anti-RedMonk stance. In reality, nothing is as cut and dry as developers XOR operators being king. I’ve been in many strategy discussions over the past 5 years where the people involved would love for just one of them to be rulers of the roost. It’s make setting strategy so much easier than catering to both.

In my experience, it’s more like this: developers have a tremendous amount of influence and devilish-steering over long-term IT department purchases, while IT people control the gates and money.

  • Developers can also just subvert IT and totally ignore them. You get speed and flexiblity, but the trade-off is inefficiencies in the long-term: everyone is doing something slightly different so there’s no economies of scale with respect to knowledge, culture, or costs. (There’s a loop-hole where you all decide, for example, to run on AWS and “bottoms-up” decide to start collaborating and “work together” and all that – I’m not sure that pans out in donkey-land without a lot of centralized change management, though see below on DevOps.)
  • Operators can set orginization wide standards but have to “force” developers to follow their dictates. So, if you want orginization-wide standardization and “someone else” to pay the bill and help run it, you have to go through IT. Here, you have ultimate control and “governance”, but you sacrifice flexiblity and speed. (There’s a loop-hole here where IT establishes a centralized “cloud platform” [to use my work’s parlance] and lets the developers do whatever they want in the confines/contract on that box/platform.)

Of course, many of us have been trying to reuinite this “house divided” for several years, cf. DevOps. Hopefully that’ll pan out because what we really need are both those functions working together to not build boxes or subvert corporate best practices, but to focus on building good products and IT services. Good luck!

Open Source Usage in Large Enterprises

Across “100 C-Level execs” usage at their company: “When it comes to the actual usage of open source software (OSS) in large enterprises, only 21% of them use it across the enterprise and 25% have deployed it in a business unit. The other 54% are either at the planning phase (21%), or use it for Internet-related programs (13%) or are running a pilot program to evaluate it (20%)”

Open Source Usage in Large Enterprises

Just out: [Mobile] Developer Megatrends H1 2015

“Only 20% of mobile developers target enterprises, but 46% of them makes over $10K per month, versus 19% for consumer-oriented developers.” The other thing to note is how close we are to having “mobile developers” just upgraded to simply “developers.”

Just out: [Mobile] Developer Megatrends H1 2015