The problem with &#x27;enterprisey&#x27; corporate applications has more to do with the culture of the developers who build those applications.<p>Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private&#x2F;internal&#x2F;public) instead of at the interface level (ie pipes&#x2F;REST).<p>The problem isn&#x27;t that the capability doesn&#x27;t exist, it&#x27;s that corporations are either unaware or unwilling to experiment with alternative approaches.<p>For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain.<p>Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain.<p>Both accomplish the same result. The second is a lot less prone to error&#x2F;bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data.<p>I have fought that battle and it&#x27;s a lost cause. Even when adequate proof of cost&#x2F;time savings are presented in a business-friendly format, inertia trumps reason.<p>A company <i>could</i> theoretically hire a developer to deploy a digital assistant to streamline&#x2F;automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it&#x27;s a really hard sell business leaders on the idea of adopting processes&#x2F;tools that they don&#x27;t fully understand.