Enterprise is not a category of software, a size of company, or a type of architecture. Enterprise is a condition — a gravitational state that organisations fall into and do not escape, characterised by the progressive replacement of simplicity with process, speed with governance, and working software with meetings about working software.
Enterprise is what happens when a company grows large enough that the people who make decisions about software no longer use the software, the people who use the software no longer make decisions about it, and the gap between the two is filled with consultants, committees, and configuration management databases.
The word “enterprise” in front of any noun increases its cost by a factor of ten and its complexity by a factor of one hundred, while leaving its functionality approximately unchanged:
| Thing | Enterprise Thing | Cost Multiplier |
|---|---|---|
| Search | Enterprise Search | 10x |
| Message queue | Enterprise Service Bus | 50x |
| Database | Enterprise Data Warehouse | 100x |
| Agile | SAFe | ∞ (ongoing) |
| Software | SAP | yes |
The Enterprise Condition
The enterprise condition is not caused by size. Small companies can be enterprise. Large companies can avoid it. The condition is caused by the progressive accumulation of process in response to risk, and the inability to remove process once the risk has passed.
The lifecycle:
-
Startup: two developers, one laptop, deploy on Friday, fix on Monday. Risk: high. Process: none. Speed: maximum.
-
Growth: twenty developers, an incident, a postmortem. Someone proposes a change advisory board. The CAB meets weekly. Deployments require approval. Speed decreases. Risk decreases. This is reasonable.
-
Enterprise: two hundred developers, forty services, the CAB meets biweekly and has a backlog. Deployments require three approvals, a security review, and a regression test suite that takes four hours. A developer who wants to change a button colour files a ticket, waits for sprint planning, implements the change, requests review, passes QA, submits a change request, waits for CAB approval, and deploys in the next release window — sixteen days after the decision to change the colour.
-
Heat death: the process required to change the process is itself subject to the process. The governance of the governance board requires governance. The documentation of the documentation requires documentation. The system is stable in the way that a graveyard is stable.
The transition from stage 2 to stage 3 is invisible. No one meeting, no one policy, no one approval requirement causes the enterprise condition. It accumulates — one reasonable process at a time, each one justified, each one adding friction, until the sum of all reasonable processes is an unreasonable system.
The Enterprise Sales Cycle
Enterprise software is not bought. Enterprise software is procured — a process that involves:
- RFI (Request for Information) — “Tell us about your software” (3 months)
- RFP (Request for Proposal) — “Tell us how your software solves our problems” (3 months)
- POC (Proof of Concept) — “Show us your software working” (3 months)
- Vendor selection — “We’ve chosen your software” (2 months)
- Legal review — “Our lawyers will speak to your lawyers” (3 months)
- Procurement — “Our procurement system will process the purchase order” (2 months)
- Implementation — see SAP (2–7 years)
Total time from first contact to working software: 18 months to 9 years. Total time a startup would need to build the same functionality: 3 months.
The enterprise does not buy the software because the software is better. The enterprise buys the software because the enterprise cannot buy from the startup. The startup does not have SOC 2 compliance, a disaster recovery plan, an SLA with financial penalties, a dedicated customer success manager, or the ability to survive the 180-day payment terms that enterprise procurement demands.
Enterprise software wins not by being better but by being purchasable — by fitting the procurement process, the compliance requirements, and the vendor management framework. The product is secondary to the invoice.
Enterprise-Grade
The phrase “enterprise-grade” means one of two things:
-
The generous interpretation: software built to handle the scale, security, reliability, and compliance requirements of large organisations. High availability. Disaster recovery. Audit trails. Role-based access control. This is real and valuable.
-
The accurate interpretation: the same software, but with an enterprise pricing page that says “Contact Sales” instead of displaying a number, because the number would alarm you and the sales cycle needs time to establish the relationship before the alarm.
The difference between a $9/month SaaS product and its “enterprise-grade” equivalent is often: SSO (which costs $0 to implement but $100,000/year to license), a dedicated instance (which costs $50/month in cloud resources but $200,000/year in the contract), and a customer success manager (who costs $80,000/year in salary and saves the customer from the complexity that the enterprise-grade product introduced).
Enterprise-grade is a pricing strategy disguised as a quality standard.
The AbstractSingletonProxyFactoryBean
Enterprise has its own aesthetic in code. Where a startup writes:
greeting := "Hello, " + name
Enterprise writes:
GreetingService greetingService =
GreetingServiceFactory.getInstance()
.createGreetingService(
new GreetingConfiguration.Builder()
.withLocale(LocaleProvider.getDefault())
.withTemplate(TemplateRegistry.get("greeting"))
.withAuditEnabled(true)
.build());
String greeting = greetingService.greet(
new GreetingRequest.Builder()
.withName(name)
.withContext(SecurityContextHolder.getContext())
.build());
Both produce “Hello, World.” One of them has an audit trail, a security context, a locale provider, a template registry, a factory, a builder, a configuration object, and a billable consultant who wrote it. The other has a string concatenation and a developer who went home at 5.
The enterprise version is not wrong. In a regulated environment with audit requirements, multi-locale support, and security compliance, every one of those layers exists for a reason. The tragedy is not that the layers exist. The tragedy is that they exist by default — applied uniformly to every greeting, every button, every function, regardless of whether the regulatory context demands it.
The enterprise condition does not distinguish between software that needs governance and software that needs a string concatenation. Everything gets the full treatment. This is how a button colour change takes sixteen days.
The Lizard’s Position
The Lizard does not operate in the enterprise. The Lizard operates in a one-room apartment in Riga with a single binary and a SQLite database.
This is not a fair comparison. The Lizard does not process payroll for 200,000 employees, comply with financial regulations across forty jurisdictions, or survive an audit by Deloitte. The Lizard processes markdown.
But the Lizard’s existence is a useful thought experiment: what is the minimum viable governance for the work being done? For markdown processing, the answer is zero. For payroll, the answer is considerable. The enterprise condition is the failure to ask the question — the application of maximum governance to all work, regardless of what the work requires.
Every system should have exactly as much process as it needs. Not more. Not less. The enterprise has more. The Lizard has less. Somewhere between a SQLite database and SAP lies the correct answer for your organisation.
Finding it requires asking the question. The enterprise stopped asking.
Measured Characteristics
Enterprise sales cycle: 18 months (minimum)
Startup build cycle for same product: 3 months
Cost multiplier of "enterprise" prefix: 10x–100x
Approvals to change a button colour: 3–7
Days to deploy a button colour change: 16 (average)
Meeting cadence of the CAB: biweekly
CAB backlog: growing
Lines of code for "Hello, World" (startup): 1
Lines of code for "Hello, World" (enterprise): 47
Audit trails for "Hello, World": 1 (enterprise version)
Audit trails needed for "Hello, World": 0
Time from reasonable process to heat death: 5–10 years
Enterprise pricing pages showing prices: ~0%
