Why is the Bar Set so Low for Enterprise Applications?
The DevOps Zone is brought to you in partnership with Go Continuous Delivery. Learn the 5 key patterns to setting up a successful deployment pipeline, including designing parallel workflows, running tests in parallel, and more.
Consider a typical Enterprise Application. There's a help desk, ticket tracking, a user support organization that does "ad-hoc" processing, and a development organization to handle bug fixes and enhancement requests. All those people doing all that work.
If people need all that support, then the application is -- from a simplistic view -- broken.
The organization, however, has coped with the broken application by wrapping it in layers of people, process, tools, technology, management and funding. The end users have a problem, they call the help desk, and the machine kicks in to resolve their problem.
It is a given -- a going-in assumption -- a normal, standard expectation that any enterprise software is so broken that a huge organization will be essential for pressing forward. It is expected that good software cannot be built.
We're asked to help a client create a sophisticated plan for the New Enterprise App support organization. Planning this organization feels like planning for various kinds of known, predicted, expected failures. Failure is the expectation. Broken is the standard operating mode.
Consider a typical non-Enterprise Application. Let's say, the GNU C compiler. Or Python. Or Linux. An almost entirely volunteer organization, no help desk, no trouble tickets, no elaborate support organization plan. Yet. These products actually work flawlessly. They're not wrapped in a giant organization.
Why is the bar for acceptability so low for "Enterprise" applications? Why is this tolerated?