The term “Enterprise-Class Software” was always a funny one since it’s been used to describe an amorphous class of software that’s somehow “more serious” than any other software – it’s “enterprise class”. But what is “enterprise class” software? What’s the “enterprise” that the term refers to? A 3,000 employee business? Or a 30,000 employee business? Can 3 people in an office do “serious” business that requires “enterprise class” software?

In the last few of years, I’ve seen the term slide from being merely amorphous to being outright poisonous and pointless.

We’re at a point where the private needs of an “enterprise”, and that includes the biggest ones, doesn’t represent much of an interesting frontier for software anymore, at least not from an architectural perspective. The industry has learned and is continuing to expand the knowledge on how to build systems that scale well beyond the need of an individual enterprise. We have learned how to deal with failure in ways that no longer require huge boxes with built-in triple redundancy.

The term “Enterprise Software” is poisonous because it implies a scalability ceiling for a solution serving a few 10,000 people that used to be ambitious, but that’s no longer the case. It’s also no longer the hardest class of software solutions – not at all.

A simple multi-player game for a mobile device that allows a quarter million or more players in groups of 16 to play against each other is killing the vast majority of “enterprise class” solutions in terms of required sophistication of its messaging infrastructure. It needs to scale to  an audience size that even the largest enterprises in the world won’t get on a system concurrently and that audience is going to be enormously unhappy if the infrastructure is dropping messages or is slow. Just search for “MW3 lag” and you’ll find plenty of opinion about latency that’s louder and much more impactful on business than a few hundred employees lamenting about the speed of an internal website, because here you’ve got customers who are individually putting money on the table.

To suggest that consumer-facing scenarios are not “enterprise class” isn’t just arrogant, it’s also dangerous. Enterprises that don’t embrace mobile devices and start deeply interacting with consumers at “consumer scale” will find themselves in deep trouble. Software infrastructure vendors will find themselves in deep trouble if they still think of “enterprise scale” as a key capability or aspiration because their own customers, enterprises, will have to turn outward and embrace consumer scale or face the consequences. There’s also no reliability monopoly that “enterprise” holds in some way. When a systems needs to perform millions of transactions directly interacting with consumers, there’s no room for sweeping failures under the rug. It is actually easier to handle failures and provide high reliability in a tightly controlled, low-scale system than in a system that is the front-door of a business where each hiccup may personally upset a paying customer. It is also easier to shut down a system over the weekend or over a long holiday break than to keep it running 365/7/24. And it’s also easier to secure an insulated internal system than one that’s exposed to the outside world and where a single breach can tarnish the entire business’s reputation.  

“Enterprise software” is something where a single sale can generate a ton of revenue. But “enterprise-class” doesn’t represent anything interesting on the engineering side – except an outdated set of goals and a level of scalability that’s several magnitudes below what’s needed for an environment where more and more consumers have a personal computing device in their pocket and another on the coffee table.

PS: Put “Web scale” on the same heap of useless terms. You ought to scale to your audience, not the web.

Categories:

I've long wanted to write an architecture book. The problem with books is that writing them robs you of at least half a year of your life, and that half a year is a very painful one. I've done it. So instead of a book, I talked to the folks at Pluralsight and made an on-demand video course.  

"The Elements of Distributed Architecture" is about the foundational elements of distributed architecture and about the ‘physics’ that affect distributed software designs. The goal of this course, which is designed to be independent of specific languages, technologies, and products, is to provide software teams with a shared baseline of concepts and terminologies in the areas of information management, communication, presentation, processing, failure management, security, and safety.

I think of this course as a baseline and there's plenty of runway for more in-depth material. If you like this one that will give me motivation to spend more private time (this course is not related to my Microsoft job) to create architectural material.  

If you don't have a Pluralsight account, you can sign up for the free trial here

Categories: Architecture

December 1, 2011
@ 05:38 PM

I answered 4 questions in Richard Seroter’s series of interviews with folks working on connect systems. See the Q&A here.

Categories: Architecture | SOA