Why is the Bar Set so Low for Enterprise Applications?
Join the DZone community and get the full member experience.Join For Free
Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.
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?
Published at DZone with permission of Steven Lott, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.