Home

The Problem with the “Enterprise”

Published 02/16/2018

Somewhere there is a great pun about the Starship Enterprise from Star Trek.

Sadly, though, as big of geeks as we are, we never got into Star Trek.

So we’ll skip the joke and get right down to it.

In the software world, “Enterprise” refers to a type of software – usually offered by large companies and those companies are generally Microsoft and Sun Microsystems.

Breaking it down even further, we’re talking about Java, Oracle, .NET, SQL Server and Windows.

Collectively, these technologies make up what is called “the Enterprise” and it’s a group of technologies that large companies and government agencies foolishly come to rely on to the exclusion of other options.

Take the IRS for example.

The IRS used Windows XP as their operating system of choice and did so since pretty much the launch of the operating system in 2001.

Over the years, the government agency had numerous software applications built for Windows XP, which the IRS became dependent upon.

Microsoft has a policy of offering support for operating systems up to 10 years after launch and even made an extension for Windows XP which took support to 2014.

As the years went by, Microsoft released Windows Vista and then Windows 7 in 2009.

However, the IRS had a problem – they couldn’t upgrade.

The software they had become so dependent upon was basically locked to Windows XP.

The developers had not followed Microsoft’s own API guidelines and upgrading to Windows 7 would hopelessly break all the software because of it.

So 2014 came and went and the IRS was forced to pay Microsoft millions of dollars to support just the IRS after Microsoft ended support for XP.

This is a prime example of Technical Debt, which we see often.

Technical debt occurs when you know you need to make a change or upgrade to your software, but rather than footing the bill immediately, you hack or patch it to get you buy to tomorrow and worry about paying the bill “another day.”

In today’s world of short-term profit, we see this all the time and it’s the biggest problem with Enterprise software.

But why is that and why to companies continue to insist on enterprise software?

Let’s start with the latter question.

Sun and Microsoft have been the heavy hitters since the dawn of the Internet.

As other companies struggled to put together reliable software and open source hadn’t yet found its legs, these two companies were, by far, the most reliable and trustworthy in the wild-wild west.

The could scale, meaning these applications wouldn’t come grinding to a halt if more than 1,000 people used them at the same time.

The had support, meaning if something went wrong, there was a human being you could pick up the phone and call.

So the technologies from these companies became the standard.

So software was written in .NET or Java.

Then, when the next contract came up for the software, the agency selected a company that knew .NET or Java because, well, that’s what their software was written in, and why make an expensive upgrade to a newer language?

Not only that, but bids were going to the lowest price, so these bidding companies were basing their bids on patches to the existing systems rather than replacing them.

And when that contract was up, the agencies did the same thing again.

And again. And again.

And pretty soon, we have software that has been patched and hacked by four different companies and no one really remembers what this patch does or that patch does.

And yet, the agencies continued to insist on .NET or Java because, well, that’s the way it’s always been done.

The truth of the matter is, today, .NET and Java are vastly superior languages than they were in the 90s.

They’ve come a long way.

But those improvements mean nothing if we have to build upon the cruft of yesteryear.

Eventually, the bill on that technical debt needs to be paid.

And while the enterprise has come a long way, non-enterprise languages and systems have come even further and offer vastly superior advantages in many cases.

The point is, you need to completely scrap your software every few years, and if you’re going to do so, you should evaluate what the best technology stack is to do so in the current paradigm.

In a lot of ways, agencies are getting half of that down.

We see more and more that agencies want to pay down that technical debt, which is great, but they’re still locked in on “the enterprise” using arguments that stopped being true 10 years ago.

Yet, tradition is a tough thing to overcome and no one wants to be the one to break with tradition and go with something other than .NET or Java, which is a huge mistake.

Non-enterprise technologies allow technological advances in infrastructure such as serverless environments that offer vastly improved performance at vastly lower costs.

And non-enterprise languages are more capable of agile and iterative rapid development, which means labor costs will be lower because software is being built in less time.

There’s also just more developers available now for non-enterprise technologies because that’s the direction the rest of the world is going, so it’s going to be more expensive to find a .NET/Java developer/engineer than a Javascript counterpart.

So don’t make the mistake of the IRS.

Realize that software is like a vehicle and needs to be completed scrapped every so often to pave the way for something much better.

And don’t fall into the trap of believing that “the enterprise” offers some security blanket because it’s backed by big names and has been around for a long time.

Use the right tool for the right job.