3 ms·

Can you explain some of the terms you use a bit more? You say that Microsoft's strategy is not about enabling the development of "enterprise applications". Th

Can you explain some of the terms you use a bit more? You say that Microsoft's strategy is not about enabling the development of "enterprise applications". Then you say it's about providing tools for "business process applications". What's the difference? Then you say it's not about providing tools for "applications" but rather "API integration and orchestration". Are you trying to say that the latter is about building headless processes without a UI? Don't a lot of processes require forms and human input? Aren't those "applications"?

ajcp 5y ago
I'm sorry, yes, re-reading it I do conflate some terms. Enterprise applications are those that are built for, enable, and underpin enterprise sized concerns. So for your financial department you want and enterprise application that owns, orchestrates, and audits the work of finance. However most if not all business processes cannot exist solely within an enterprise application, so you want to give them "tools for application to the business process". That's probably more high-handed than it needs to be, but eh :D So in this what I'm arguing is that MSFT here isn't trying to position Power Apps/Automate as a tool for developing enterprise applications, but rather high-grade capabilities (I'm remiss to say "enterprise grade" as people will then conflate that too) that allow the business to tie all ends of their business process together. The best way to do this is by giving everything outside of the enterprise application knowledge and reach to each other via API. To your point, yes, this could require the business to build applications for their own processes, but these aren't enterprise applications, simply process specific applications. Traditionally these were macro enabled Excel workbooks and Access apps that were squirrelled away deep in so many Network Drives, underpinning vital business process functions but wholly unknowable to leadership or those maintaining the enterprise application itself.
- mgummelt 5y ago
  Ah, I see. I wouldn't say API orchestration is the "new RPA", though. It's rather the "old BPM", and "current IPaaS". That is, we already have tools for API orchestration. It's nothing new. RPA is something different entirely. And it's benefit isn't just for automating legacy systems. Automating the UI they're already familiar with is a much more intuitive experience for lots of people than going out of band to integrate with APIs.
  - ajcp 5y ago
    That's the thing MSFT is trying to solve for with things like Power Automate and Apps. Sure, getting an API schema and then writing a GET request in C#, Node, etc to get invoice data out of your financials system is out of band for a business user, selecting the action "Get invoice by number" from the "IBM Cloud Financials" connector in Power Automate is well within band.
    - mgummelt 5y ago
      That's easier than writing a GET request, but the easiest would be never leaving your native application, which AFAIU, RPA lets you do in theory (though practice is a different story).

ajcp 5y ago

I'm sorry, yes, re-reading it I do conflate some terms. Enterprise applications are those that are built for, enable, and underpin enterprise sized concerns. So for your financial department you want and enterprise application that owns, orchestrates, and audits the work of finance. However most if not all business processes cannot exist solely within an enterprise application, so you want to give them "tools for application to the business process". That's probably more high-handed than it needs to be, but eh :D So in this what I'm arguing is that MSFT here isn't trying to position Power Apps/Automate as a tool for developing enterprise applications, but rather high-grade capabilities (I'm remiss to say "enterprise grade" as people will then conflate that too) that allow the business to tie all ends of their business process together. The best way to do this is by giving everything outside of the enterprise application knowledge and reach to each other via API. To your point, yes, this could require the business to build applications for their own processes, but these aren't enterprise applications, simply process specific applications. Traditionally these were macro enabled Excel workbooks and Access apps that were squirrelled away deep in so many Network Drives, underpinning vital business process functions but wholly unknowable to leadership or those maintaining the enterprise application itself.

mgummelt 5y ago
Ah, I see. I wouldn't say API orchestration is the "new RPA", though. It's rather the "old BPM", and "current IPaaS". That is, we already have tools for API orchestration. It's nothing new. RPA is something different entirely. And it's benefit isn't just for automating legacy systems. Automating the UI they're already familiar with is a much more intuitive experience for lots of people than going out of band to integrate with APIs.
- ajcp 5y ago
  That's the thing MSFT is trying to solve for with things like Power Automate and Apps. Sure, getting an API schema and then writing a GET request in C#, Node, etc to get invoice data out of your financials system is out of band for a business user, selecting the action "Get invoice by number" from the "IBM Cloud Financials" connector in Power Automate is well within band.
  - mgummelt 5y ago
    That's easier than writing a GET request, but the easiest would be never leaving your native application, which AFAIU, RPA lets you do in theory (though practice is a different story).