4 ms·

Your comment predicts the next few waves of no/low-code automation, I think. Early phases will involve the introduction of no/low-code automations that integra

by jka 6y ago

Your comment predicts the next few waves of no/low-code automation, I think. Early phases will involve the introduction of no/low-code automations that integrate existing APIs, services, and systems within businesses for the purposes of automating existing processes. That's good for the APIs, systems and automation platforms because they become essential and encumbent components of operating those businesses. The later, and I suspect much longer, phases will involve identification of business processes that aren't really needed and that can be removed by thinking about the ways that organizations function in entirely new ways, or that can be streamlined. By that point some of the integrations may have become so baked-in that they'll require significant maintenance to update. And as we see with some cloud-based IoT devices, it's possible for service providers to encounter outages or cease operating, in which case internal businesses processes may halt. All this is similar to the gradual automation and improvement of physical assembly lines; it's a case of applying the same principles to organizations. And yep, the cheapest, most efficient and reliable component is one that doesn't have to exist.

ethbr0 6y ago
So, there's something of a story behind this. To simplify things, the early phase you mentioned is simply computing, and has been proceeding since the 1960s. The latter phase is called business process management (aka BPM) [1] and has been a thing since ~1980(?). In promise, BPM says "Encode all your business processes and their relationships into our tool, and we'll optimize and automate them." In practice, BPM is doomed to failure because (1) it's invariably implemented in an organization by management consultant types who care more about billable hours than actual solutions & (2) it's fundamentally an imperfect abstraction over your actual business processes, leading to leaks / hacks in implementation, leading to yet another system that further slows down the business. SAP is illustrative here, with the adage that smart businesses change their business to fit SAP, rather than try to change SAP to fit their business. [1] https://en.m.wikipedia.org/wiki/Business_process_management https://en.m.wikipedia.org/wiki/Business_process_management

by jka 6y ago

ethbr0 6y ago

So, there's something of a story behind this. To simplify things, the early phase you mentioned is simply computing, and has been proceeding since the 1960s. The latter phase is called business process management (aka BPM) [1] and has been a thing since ~1980(?). In promise, BPM says "Encode all your business processes and their relationships into our tool, and we'll optimize and automate them." In practice, BPM is doomed to failure because (1) it's invariably implemented in an organization by management consultant types who care more about billable hours than actual solutions & (2) it's fundamentally an imperfect abstraction over your actual business processes, leading to leaks / hacks in implementation, leading to yet another system that further slows down the business. SAP is illustrative here, with the adage that smart businesses change their business to fit SAP, rather than try to change SAP to fit their business. [1] https://en.m.wikipedia.org/wiki/Business_process_management https://en.m.wikipedia.org/wiki/Business_process_management