Enterprise systems are very different from “applications.” It’s almost all because of scale, but scale is a qualitative difference — programs built to “enterprise” or “Internet” scale are not just bigger (key — “just”) but they are dramatically busier.

Consider a blog that receives 2000 “hits” (page-views) a day. That can be served effortlessly using any technology on any hardware platform, from Raspberry Pi to AWS or Azure. This doesn’t mean that the blog isn’t important, or valuable (it could be a blog that is used exclusively by CEOs and world leaders). But it means that the scale is not a technical challenge.

Contrast that with Facebook, Amazon, Google, Twitter, or Bloomberg. They have tens or hundreds of thousand of transactions that involve data being created and altered according to complex rules — per second. These are the companies that caused the growth of enterprise technologies, and that need them.

But how does a solution that needs to go to Enterprise/Internet scale start?

Hint: it’s not with a scalable infrastructure using Docker and Kubernetes with CI via Jenkins.

Not Bashing Enterprise Technology

I shouldn’t need to say this but I want to make it clear: enterprise technology is amazing. Attempting to build “in the large” from scratch without all of the powerful technologies that are straining to handle the current load would be insanely foolish and intensely arrogant. Imagine trying to maintain 10,000 transactions per second with a Mac Mini running Python and a SQLite database file.

Before the Internet and Enterprise Scale

In the beginning, Facebook wasn’t the Facebook of today! There was a time when it was small enough to be handled on that Mac Mini in Python with SQLite. Like most things, it started small and young, then later grew and matured.

That is exactly what it should have done and did: it started small. Had it attempted to avoid going into production until it could handle the current load it would never have deployed at all.

Facebook did it right. Skipping the small and non-scalable is a mistake.

I encounter this problem far too often. It’s almost endemic in major corporations. Because they have enterprise teams that handle their production systems, they start projects using those same technologies and with scalable expectations.

And it haunts them (assuming it ever works at all).

The Mistake

It seems sensible at first … they have the staffing (though they always forget not enough staffing for their current needs!) and their staff has the expertise, so why not skip that “throw away” non-scalable version and the associated waste and build what is needed?

Grady Booch stated this well in his excellent Object Oriented Design with Applications that large working systems come from small working systems.

To attempt to avoid the lack of small systems, there are prototypes or “steel threads” and so on. But, fundamentally, all attempts to start large and evolve have the painful overhead of a production system, including DevOps, QA, multiple environments, dozens (or hundreds) of staff, meetings, etc.

The result of this approach is that the project attempts to have weekly (or every-other weekly) demos and such, but what they demo is inevitably the technology and not the product, because the product or system isn’t written and they have to “show something.”

This is also a side-effect of trying to understand the problem while building the solution. Since the idea of rapid iteration (today, Agile) is to get going at once and, as often said, “move fast and break things,” it’s accepted that the early work is going to be replaced and evolve.

What’s not often pointed out: that early work establishes the vocabulary, expectations, and processes that will remain with the project for the duration. The code itself can be replaced easily enough, but the shared vision and understanding within the team is going to remain for a long time.

As the steel thread starts to improve it becomes more and more dangerous to suggest throwing it away to do something else. And that leads to the dark side of Agile…

We need to make small steps, baby steps!

What happened to “move fast and break things?”

Not Tech Problem

Ignore silver bullets. Better technology won’t actually help this problem at all. The problem in many ways is exacerbated by better technology!

Take Kubernetes. It’s responsible for orchestration of containers to handle dynamic scaling, automation, etc., of containerized components (such as Docker). It is well known and popular and many people are taking advantage of it. It works.

So, with a great tech like that, shouldn’t it be used? Absolutely — when you’re ready at scale.

The technologies that empower scale increase the effort to do easy small things. Kubernetes isn’t needed for a PHP site served on a single account on a shared server. In fact, it would make it more expensive and take longer to use all those steps.

Some will argue that because of Gradle or Maven and CI systems like Jenkins the overhead of the enterprise tech won’t matter — but that assumes they have DevOps and that every developer that wants to test their code maintains enough locally to use those same things.

Compare that to “edit the PHP file and hit F5 on the browser.”

If there is unlimited staff (not money, but actual people) who have all the skills needed to truly keep all the working technology working, it would still not solve the problem.

Because at some point, developers need to create code. Those developers will need to be building enterprise components. They’ll not be doing simple PHP, but will probably be doing Java with Spring Boot.

As capable of handling the enterprise environment, complete with dependency injection, RESTful microservices, and HATEOAS is, it takes longer to write and test a web-page using that stack than PHP or even static web-page with CSS and ten lines of JS.

The addition of more technology in an attempt to simplify development only works if the addition of the technology doesn’t include its own overhead.

This is clear in the small: using PHP is faster to develop in than coding in assembly language. The overhead of PHP on the developers is less than the overhead of assembly.

But in the large and huge: Java with Spring Boot running in containers isn’t faster to develop in than PHP.

The end result is absolutely more scalable and powerful in terms of flexibility and load-handling, scalability, and so forth. But the steps to get there are not faster in calendar time.

The Faster Way to Break Things

So what can be done differently?

It doesn’t take more software tech or budget. It doesn’t require a large staff (in fact, more people slows it down).

What it takes is a change in order of operations.

Let the tiny team and representative individual users take the calendar time needed to make a non-scalable working reference implementation.

It could be as simple as PHP with SQLite. It might be Excel with VBA. It could even be PowerApps on Azure or PHP Fox with some extensions — the key is that the purpose of this version is to move fast and break things in calendar time.

When the small system is done, it can’t scale but it does work. This is an important distinction between a PoC/Prototype and a small working system.

What does it mean that it can’t scale?

That depends on the system. For instance, it might mean:

• It can not handle all the customers (so needs a closed group who can run it)
• It runs too slowly (takes 40 seconds instead of 1/5 of a second to get a result)
• It consumes a huge amount of disk because it uses naive storage
• It can only run on the LAN so it only works with one team in a single location

These are not failures! This is precisely what is desired — a working system.

What To Do with a Weak Small System

That working small system is a reference implementation. Because it works (does what the limited set of users wants and that they verified) it is precisely what is needed to do a few crucial things:

• Create an RFP where exactly what is needed can be expressed
• Launch a new project team to write the Enterprise production version
• Enable the project to be canceled because even with a working version it doesn’t add enough value to continue

It’s funny that canceling a project is a good outcome. But it’s better to discard an idea that doesn’t work in a few months than spend years before discarding the idea that doesn’t work.

Conclusion

Fred Brooks said to “plan to throw one away.” The small system legitimately expires once an enterprise solution is deployed. That small system may never even be globally used. But it is thrown away as scaffolding that was useful to build the system.

Not useful in its code, but in its lessons.

Make that small version work with “weak” tools and languages. Reap the benefits of Agile by moving fast and breaking things. Better to break the go-cart than the formula one race-car, right?