Browsium

Browsium Blog

Java Pain Points

Posted by: Seth Posted date:

By Matt Heller

Browsium was started to solve a particular customer pain point – helping customers migrate off IE6 to end that chapter in the history of the web. As we were designing the solution to that problem, we began to see it was merely a manifestation of many browsers related pain points that customers would be facing now that computing had shifted from installed executable applications to web-based ‘modern’ ones. We’ve had many conversations with customers over the past 10 years about their web application management pain points and thought it would be good to share some of those themes. Throughout a few upcoming postings, we will share many of the top issues and common problems our customers face. We hope that you will learn something new, or learn that your organization doesn’t need to reinvent the wheel…we’ve got a decade of experience addressing these issues and ‘we know a thing or two because we’ve seen a thing or two.’

At least once a week we get on a call with a customer, and before we can finish introductions, the subject turns to Java. After the colorful language is used to describe feelings towards it, we move on to hear how difficult things are for the customer trying to balance business needs, security, patching, operations, and performance. Many of our calls involve representatives from a variety of business areas – the IT staff, the security team, and often a business unit or two. Everyone has their job to do, and that means competing requirements and objectives. There’s always a notable hesitation and disbelief when we explain that we can satisfy them all, but by the middle of our demonstration they can see we deliver on that promise.

Looking more in detail at the Java pain point, we often hear the desire to eliminate Java is a top priority, but that can’t happen overnight. So the organization is faced with trying to maintain it for some period, but they can’t just leave it be due to ongoing security updates and threats of attack. So they want to isolate it, which leads to a question of options and cost. Virtualization is costly on many levels – hardware and software – as well as often disruptive to end-users with process changes. For customers that have existing virtualization environments, this is easier, but not cheap nor simple. Deploying virtualized solutions end up forcing end-users to change their behavior to use specialized packages or launch dedicated systems to limit the use of Java. Our customers are keenly aware of the impact on productivity and do not want to revisit those issues. With one or two specialized images for Java containment, it might work, but customers with 6 or more versions will attest to the chaos it can cause.

Then we present the Browsium approach, which requires no new hardware, no end-user training (they don’t even know anything is happening), no changes to software management or modifications to the business process at all. Once the client is deployed and the configuration is complete, it just works. Java is controlled, locked down, prevented from abuse, blocked from unapproved use, you name it. We have customers saving millions of dollars per year after switching to manage Java use with Browsium.

They have saved money by:

Shrinking the QA test matrix

– Don’t need to test what won’t be impacted

Eliminating security vectors

– Hackers can break Java that won’t load for them

Our solutions to Java management and control are extensive. We’ve been doing this for a long time and have solved many issues for many customers. Let’s talk about how we can help get your organization on the path to a better relationship with Java.

  • Share:  
 

Recent Posts

Java Pain Points
Posted on: July 18, 2019
Ensuring the web is part of your strategy
Posted on: June 20, 2019
Top 5 reasons why you need a browser management strategy for 2020 and beyond
Posted on: April 9, 2019

Request Demo