The other thing that we’re working with most of our enterprise customers is, what is an exit strategy? What do I need to do, if one moment I decide that I would like to move over to another provider? That for any large enterprise is just good due diligence. If you start using a [SaaS application], you want to know about what do we need to do to get my data out of there, if I want to move let’s say from Salesforce to Workday.
It’s the same for most large enterprises. They want to know how much work is it actually for me to actually move if I decide to go from cloud provider A to cloud provider B, or maybe bring it back on premises.
That’s something that we’ve been working on with most of our large customers, because that’s just good due diligence.
Original source: Enterprise Software Priorities for the Next Decade
“Getting feedback on the effectiveness of the initiatives, and acting on it quickly to refine the strategies and initiatives to ensure their alignment with the purpose is critical for sustaining the effectiveness of the organization towards fulfilling the purpose.”
Original source: Q&A on the Book Enterprise Agility
Original source: Gartner Survey Shows Why Projects Fail
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.
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.
- The InfoQ piece by Victor Grazi is a great round-up.
- John Watters summary, inc.: “Java EE moves at a slower pace than solutions from vendors such as Pivotal,” Josh Juneau added, “as it should. The point behind Java EE is not to be on the bleeding edge of technology. Rather, it is to be using solid, tried-and-true standard solutions.”
- Pavel Pscheidl: “A quick reaction to hate on Java EE present in Gartner report”
- John Clingan: “Reanalyzing the State of Java EE”: “My primary issue with the Gartner report is that it seems to completely ignore the advancements that Java EE vendors have made beyond the traditional Java EE APIs and runtimes, nor mention the MicroProfile efforts to develop microservices APIs for traditional Java EE developers.”
Oracle and Java: confusing
Oracle’s stewardship of Java has been weird of late:
- July 2016: Oracle at first backing out of JEE support, then retracting that.
- Oracle’s Thomas Kurian, president of product development goes over some things JEE needs to do to modernize to cloud native.
- Oracle, as always, isn’t too good at assuring open communities, even it’s own. “And now the entire enterprise Java world is upside down, because a single company loses interest.”
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.
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.
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.
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.
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.
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.
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!
A little while back I did an email interview with Ray Wang from iThome Weekly, in Taiwan. It’s a little piece about DevOps getting more and more into the enterprise. To read the Google, robot translation, it looks like I did some things “single-handedly,” where in fact I was one of many hands.
As always, here’s the original email exchange we had:
Q. You mention about software-defined business in your article, can you tell more details about what is software-defined business? Why CEO have to think about the software-defined business？ Why DevOps is so important for software defined business?
“Software defined businesses” are companies that are using custom written software to dramatically change and enhance how they run their business. Uber is a good example. Instead of just being a taxi or car service, they use software they wrote to change how their business runs: calling and paying for a taxi on your sell phone is much different than hailing a cab and paying in cash. Insurance and banking companies that are moving more and more of their daily business and interaction with customers to run over mobile apps and other custom written applications are another good example; we see this happening at Pivotal customers lie Allstate, Humana, and banks that use Pivotal Cloud Foundry.
Q: What’s your definition of DevOps? Does DevOps equal to Continuous Delivery?
Which definition of DevOps you don’t like most and why?
In general, I think of DevOps as the process and “culture” you wrap around continuous delivery to get the full effect of CD. I tend to speak about them interchangeably at this point; I suppose you don’t need DevOps to get the full benefits of continuous delivery, but they seem to go together well (you could always have just a jelly or just a peanut butter sandwich, but they seem to show up together a lot). CD is always looking to automate as much as possible, delivery to production frequently, and use the feedback loop this rapid cycle gives you (you an observe what your users does each week or day instead of each six months) which are many of the things DevOps seeks to enable as well.
It’s easy to get caught up in DevOps conversations that spend all of them time talking about “culture” and the need to change. I’m interested in that, but I always want to hear about actual, tactical things companies can do to get the benefits of DevOps. We all know how businesses use IT needs to change to be better, and that it’s hard to do so. I want to make sure the overall community is giving advice that’s helpful and, dare I say it, “actionable.”
Q: Should companies have to implement agile development before implement DevOps? Why?
It certainly helps to know what agile development is as a school of thought and to have done some form of agile to trust that way of thinking. If you’ve never done agile before, it just becomes part of trying to do DevOps. It’s certainly hard to think of being successful at DevOps without also doing agile software development.
Q: If CIO want to tell his CEO boss about what’s the value for non-technology companies , what’s your suggestion?
Time to market is the main, measurable, benefit. What that means, to me, is that software is being given to customers more frequently. New features and fixes come out weekly instead of once every 6 to 12 months. The business (the CEO) has to figure out what to do with time to market. If you can put a new features in production each week, how will that help the business? In the consumer space (where much of this mentality comes from) you can add more and more features to out-compete competitors. In the business space, the actual business has to change and evolve at a fast pace to fully take advantage of time to market. All that said, I don’t think any CEO is satisfied with the pace of change in IT. They’d all like it to move not just “faster,” but to get more meaningful features in production more often. Humana provides an interesting example: because they had been honing their software delivery process they were able to launch an Apple Watch app in just five weeks. That timeline is pretty amazing for most enterprise IT projects, let along being in the App Store on the first day of the Apple Watch’s release.
Q: Gartner say 2016 will be the year of DevOps. Do you agree with that? why or why not?
Sure, but I think you’ll see the next 3 or so years be the year of DevOps. I don’t think there’s any one year in particular that will stand out. I don’t think there was “a year of Agile Software Development” in the 2000s, it just took over slowly. What important is for companies to understand what DevOps can help give them – faster time to market for their software-driven products and services – and figure out what they’d do with that new ability. “Doing DevOps” is not easy, so you really need to value the end result or you’ll likely loose interest in the transformation process and let it unhelpfully fizzle out.
And, check out the recording of the DevOpsDays Austin talk referenced in the article if you’re interested.