8 ms·

I think this article misses the mark of the actual move Microsoft is making here, but I think MSFT also gets their own messaging wrong. Microsoft's "Low-Code" s

• quyleanh 5y ago
  The original article is brilliant but your correction is much more valuable. Thank you.
  • ajcp 5y ago
    Thank you and it's my pleasure!
• ethbr0 5y ago
  Well said. > The moat protecting the market share of the big RPA companies is created by the mature deployment systems that enable large enterprises to run hundreds or thousands of automated processes This is completely incorrect. Managing processes and bots is the absolute easiest thing they do, because it's entirely under their control and a solved problem. The actual moat is legacy compatibility -- how broad a tech stack does your RPA engine cover? Microsoft Active Accessibility? Excel? Excel + VBScript? Legacy Windows native? VB6? Early Java with custom UI grid classes? The point the author should be making is that Microsoft, Google, and Amazon have zero interest in eating UiPath's lunch. It's expensive (in people-time-dollars) and custom per customer. And ultimately, it's a long-tail game. Microsoft's play is to trivially link together new deployments or migrations (i.e. to O365), then continue adding customers as more migrate to them. Why pay to chase the customer, when they're already running towards you? (FWIW, I think UiPath realizes this, which is why most of their new products / features are pivoting to become an Appian-esque rapid app platform. AA and BP? Less clueful)
  • ajcp 5y ago
    100% agree. The real value of these RPA solutions is their orchestration capabilities, but that's not how they sell it. They will start bleeding customers as those systems they're automating are replaced with those that provide more surfaces to interact with (like API). The real utility RPA solutions are supposed to provide to the enterprise is cost savings. These savings should then be put toward upgrading those legacy systems that required the RPA solution. I have never seen a company disciplined enough to direct those savings in that way. RPA companies have been so caught up in being a "hot item" and classified as a sub-category of AI (for whatever reason) that they don't seem to realize they've been selling their own demise.
    • jwally 5y ago
      Maybe I'm too cynical, but my experience with RPA via automation-anywhere is that the primary audience isn't IT or Engineering, but frustrated Line-of-Business middle management who are tired of waiting for IT to build them a solution and can't get budget-approval for a third-party to do it for them. Couple that with woo like "self-healing", "insights", and "big data", etc along with dog whistles like "People will be scared you're automating them out of a job. You need to use discretion when implementing solutions". I feel like the way RPA is sold to big corporations is analogous to how health-food stores sell muscle supplements to teenage boys.
      • ajcp 5y ago
        You're not cynical, that is their strategy. It's why most IT organizations label RPA as "anti-pattern" and want nothing to do with it. It's sold in a way that explicitly calls into question ITs own utility, if not out-right calls it the problem! It's certainly not helpful. The only successful ROM (robotic operating model) implementations I have seen are ones that have the full-throated support and participation of IT.
        • ethbr0 5y ago
          The most beneficial model I've come up with was a cooperative one, where RPA is the wireframe / prototype of business automation requests to IT. IT promise to business: "You can use RPA if we tell you we can't build a thing in time." Business promise to IT: "We'll turn off RPA at such time as you deliver us a working solution." And then be very particular that business needs to have documentation of their RPA in order to implement in production (business process / ask, notsomuch technical). This accomplishes a few positive things: (1) takes {insert dumb / hard / bad ROI business request off IT's priority plate}, (2) forces business to think about what they actually want, (3) forces business to document what they actually want, (4) provides business the flexibility to change their automation, when the realize they don't want what they thought they wanted, & (5) burns not-developer time learning all the intricacies and quirks of {legacy software / website / data}. In the end, when IT comes back around knocking, their business counterparts actually have gasp documentation. And furthermore, documentation that's actually been battle tested and seen prod systems & data. (It's an admittance that most IT projects fail not for lack of technical feasibility, but for incomplete or shifting specs)
• jrochkind1 5y ago
  > but I think MSFT also gets their own messaging wrong. Or, is it possible MSFT knows that when selling to "enterprise", it works a lot better to say you've got a better version of "thing they know", instead of a brand new thing that will replace "thing they know".
  • ajcp 5y ago
    It very well could be. I think where MSFT gets mixed up is that they are obsessed with their products being able to solve *everyone's* use-case. Which means if they're talking to the business then it's a friendly "Low-Code" platform that any citizen developer can use. However, when they're talking to IT it's an amazing CI/CD tool for developing powerful enterprise applications! What's something that corporate IT is obsessed with? Making sure the business isn't creating shadow IT and developing enterprise applications.
    • jrochkind1 5y ago
      MSFT is just doing so well at getting "enterprise" lock-in, that I'm reluctant to conclude they are getting anything at all "mixed up" in their messaging to decision-makers. At present they seem to be doing it exactly right for their business goals. I have worked at and know of so many place that are "no, you can't spend money on that product, you have to use the equivalent from MSFT that is already included in our deal." Which is one reason it might be in MSFT's benefit to convince you that their thing is in the same class as some other thing you could spend money on, or may already be spending money on. And also, yeah, they are indeed convincing decision-makerse that they meet everyone's use-case and is whatever you want it to be, it's working....
      • ajcp 5y ago
        I agree. I think that's also true of all the cloud players these days honestly.
      • 7952 5y ago
        I work in an enterprise and use flow and other Power platform stuff. The sense I get is that management look at the headline features and see it as essentially safe. But Microsoft have included some features that will be exploited in unexpected ways that create a maintenance and security problem. A good example is that Flow/Power Automate can be triggered using an API end point. That can then be configured to provide a http response (including headers). It makes it super easy to setup APIs that have no security and expose corporate data. I think the Power platform is like a modern Excel. Simple and inoffensive at first glance. But full of features that let unskilled users do risky things that will quickly become business critical. But the convergence of Office 365, SharePoint, Flow, PowerBI and dynamics is unstoppable.
• haswell 5y ago
  These are some excellent points. I think the big takeaway here is that RPA isn't what it used to be, and the rapid changes in this space help explain why RPA is gaining traction (seemingly inexplicably, if one still assumes that RPA = screen scraping mainframes). RPA products are increasingly becoming integration products. For example, and vendors like UiPath increasingly provide native API integration capabilities where possible. I've even seen integration products that formerly would have fit into the "iPaaS" space market themselves as RPA solutions, even though they are primarily providing what is essentially an API abstraction layer, and they have no roots in "true" RPA. I think this is happening due to the hype around RPA, and how effective the terminology is with the target audience. I agree that "traditional" RPA is already a legacy solution, but at the same time, RPA vendors are rapidly pivoting to support API integrations (see UiPath's recent acquisition of Cloud Elements). I hate the muddiness, but I've also had to take a step back and re-orient how I think/talk about RPA products due to how quickly the space has evolved. Source: Also work in the RPA and Integration Platform space, primarily on the Product Management side.
  • ajcp 5y ago
    I think you're right and I may be a little too hard on the RPA vendors here. I wouldn't put it past UIPath or one of the smaller vendors being able to expand what they consider "RPA" into competing directly with what would be API orchestration with the likes of MuleSoft, Appian, Power Automate, etc.
• enraged_camel 5y ago
  I've recently been dipping my toes in the RPA space (with Kofax RPA) and what you wrote validates my first impressions. The partner firm I'm working with insists that they have been seeing "insane and growing" demand for RPA solutions, which I kind of find hard to believe.
  • ajcp 5y ago
    That's interesting as I figured Kofax would be an operation that would really nail RPA and then move on to providing a very robust API middleware solution, given Kofax's bread-and-butter is literally addressing use-cases that take data from outside the system (document processing) to inside the system (process and data management).
    • spydum 5y ago
      Pretty sure kofax road is just KaPow acquisition, but yes.
  • filoeleven 5y ago
    RPA is a financial services buzzword right now. I’ve worked on an RPA library that manipulates a web application…which the company already provided full API access to. The RPA library requires those working with it to examine the page HTML in order to hook into it, since it’s highly dynamic: you have to see what form fields are available and their internal IDs in order to interact with them. Meanwhile, the API layer gives access to all the same CRUD, and maybe with better documentation (I have not seen it). If you don’t have a human user, just use the APIs! That’s what they are there for!
    • ajcp 5y ago
      Stories like this make me sad :(
      • filoeleven 5y ago
        Oh, me too. I wrote a whole rant and erased it before submitting the comment because I judged it to be unhelpful.
• monkeydust 5y ago
  Nicely put. I have always felt RPA was the ' poor mans' option for automation.
  • ajcp 5y ago
    Thank you! Yes, as a SWE when you actually see how these RPA solutions run they are not impressive. Heck, before they moved to the cloud most of them were simply providing a wrapper for Windows interop assemblies (COM, Office, what-have-you) and its native Task Scheduler capability. As a piece of technology their real value proposition is the deployment, orchestration, & management of the automations. Even four years ago they should have included VMs/VM environments in that package, so that you're not just managing a "bot", but the whole kit-and-caboodle. This would have made their offering absolutely unique and more comprehensive.
• tootie 5y ago
  Would you say that Zapier is in this space? That seems to be the kind of use cases I see in my org.
  • ajcp 5y ago
    Certainly, I believe any of those API "middleware" tooling should be treated as the "new" RPA. IFTTT, Zapier, MuleSoft, Appian, etc
  • mgummelt 5y ago
    If by "this space" you mean RPA, then no. RPA platforms integrate with the target app's UI. Zapier (which typically is considered IPaaS, not RPA) integrates with the target app's API. It provides it's own UI to facilitate this, but it doesn't integrate with the target app's UI layer. Companies will always confuse these terms as they fight the marketing wars. UIPath, for instance, refers to any RPA solution that includes API integration as "end-to-end RPA". But the substantive difference between RPA and IPaaS is whether or not the API or the UI is the point of integration.
• Havoc 5y ago
  > RPA is already a legacy solution in it's current form Not sure about legacy. Modern glorified ducktape to make legacy stuff play nice is more like it imo
  • m1sta_ 5y ago
    Same diff.
• brushfoot 5y ago
  As a fellow SWE who's been in the RPA space for a few years now, I'll offer an alternative perspective. Traditional RPA is here to stay, and only getting bigger. By "traditional" I mean screen-scraping and click bots. It's not only for legacy apps. It also addresses two development pain points that will never go away: (1) complexity and (2) missing features. On (1), I've worked with companies whose APIs are so convoluted and poorly supported, and distributing your client in their ecosystem is so complex, that I've thrown up my hands and gone, "Forget it, I'll implement this with a service account." An RPA process logs into the front end, clicks around, scrapes some data, outputs it to the next process in my pipeline, and it's done. I've written processes like this that have been running for years with basically no maintenance due to stable-enough UIs. UI changes are still a risk, but if you have a mature UI, it's a great, simple alternative to a more complex process. Regarding (2), APIs don't always expose all the features of the UI, and sometimes vendors won't, or can't, add them in a given budget or time frame. I worked with a partner whose API had essentially one read-only endpoint. Their product was fantastic and they had other integration methods; they just hadn't prioritized API development, which they could afford to do because they delivered so well in their niche otherwise. We had to get creative in how we would pull the data.
  • Graffur 5y ago
    Building fragile solutions for missing features is a bad road to go down. It may be your only solution but good luck in the future..
    • brushfoot 5y ago
      I know where you're coming from, but if the ROI is there, it doesn't matter if the first iteration is fragile. Just make sure your monitoring and support are rock solid. If the RPA stumbles, someone needs to know right away, and they need to be there to catch it. And it should never be designed in a way that it could cause critical issues in the meantime. I would add, RPA isn't as fragile as its reputation sometimes suggests anyway. Sure, using it on a top-500 site is going to be a problem because of frequent UI changes. But we've successfully used it on systems in less "move fast and break things" industries that have been there twenty years, and they're going strong.
• mgummelt 5y ago
  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.
• bitcuration 5y ago
  The promise of universal API is overrated. It has some truth thatthe RPA brings the best bang for buck for mainframe etc., but in local on premise ecosystem the application API especially cross vendor is a hit and miss. The real promise is in the cloud where API becomes a mandate.
  • ajcp 5y ago
    That's what Microsoft is forcing here: there is no more "on prem only", even with Windows.