[HN Gopher] Microsoft's low-code strategy paints a target on UIP...
___________________________________________________________________
Microsoft's low-code strategy paints a target on UIPath and other
RPA companies
Author : tlochhead
Score : 165 points
Date : 2021-06-02 15:22 UTC (7 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| bob1029 wrote:
| Who has actually seen a success story with this sort of thing?
|
| We arrived at "low-code", but by way of actually solving our
| problem domain through many hellish iterations and figuring out
| what all of the various points of configuration _should be_. As
| far as I am aware, this is not something that Microsoft or any
| other vendor can determine for your business ahead of time.
|
| I am sure that there are a lot of types of smaller needs that can
| be addressed with these sorts of tools, but the big tasks of
| integrating multiple unique/legacy business systems together into
| a single logical process with its own internal state is not ever
| feasible with these tools. You can always get close, but its like
| a siren song in my experience.
| MangoCoffee wrote:
| We have a Microsoft "Access app" build by a ex employee. it was
| used by a lot of people and now in process to be rewritten into
| a web app. i guess that's a success story(?).
|
| >I am sure that there are a lot of types of smaller needs that
| can be addressed with these sorts of tools, but the big tasks
| of integrating multiple unique/legacy business systems together
| into a single logical process with its own internal state is
| not ever feasible with these tools. You can always get close,
| but its like a siren song in my experience.
|
| i'm fine with that. when they hit a problem that no Microsoft
| "connector" can solve. you charge them 10x to implement a real
| solution.
| mywittyname wrote:
| This stuff is really prevalent. I'm a programmer and I'll
| happily build out some low-code solution in Google Sheets or
| whatever.
|
| Since it takes out of the equation a whole host of potential
| workloads (deployment, environment maintenance, source code
| control, etc), these low-code solutions offer rapid deployment
| of prototypes. Often times, these little prototypes end up
| being used by 100s of people within a company.
|
| I love it because I bill out like $x0k for a few days of work.
| Once it's done, I pretty much never have to support it, since
| Google is managing that for me.
|
| Clients love it because development is done in a few days and
| they never seem to have to contact anyone for support. The
| successful ones _always_ lead to more business. Especially with
| megacorps with lots of brands. Brand X will show off their new
| dashboard, and Brand Y wants their own version and will happily
| pay pretty close to the original price for basically a copy-
| pasta job.
| [deleted]
| CharlesW wrote:
| Do you consider Excel a low-code solution?
| bob1029 wrote:
| That depends on how you use excel. Lots of formulas, et. al.
| would probably become easier to manage as part of a proper
| codebase at some point.
| haswell wrote:
| On the flip side, some of those spreadsheets that reach the
| "would be easier to manage with a proper codebase" status
| never would have gotten off the ground had they started as
| a development project.
| bob1029 wrote:
| It really is full-circle with excel. You can start there,
| then wind up using it again once you realize its still an
| excellent data interchange mechanism.
| tyingq wrote:
| _" Who has actually seen a success story with this sort of
| thing?"_
|
| Citizen development stuff is usually more successful than an IT
| department knows. They think it's failing because every time
| they hear about it, it's because of some mess. The thing is,
| they don't hear about all the stuff that works fine. There's
| typically a ton of MS Access, Quickbase, Excel, Google Sheets,
| Salesforce, etc, "apps" written and run by non-tech folks that
| the IT department never knows about.
| Graffur wrote:
| This stuff is a tactical solution that fills a gap in poor
| business solutions. Give it 5, 10 years and these non-IT
| solutions will be a nightmare for everyone involved.
| throwawaysea wrote:
| How much of the differentiation here is because Microsoft is
| innovating better versus simply their size and ability to use
| existing sales pipelines and bundling to push these types of
| features/products? This article even includes a Teams versus
| Slack graph in it - I can't help but feel sorry for smaller
| players who will see a gigantic incumbent unfairly eat their
| lunch without performing the hard work of innovation in the first
| place.
| fartcannon wrote:
| This is the kind of article that I believe would benefit from
| authorship identification/stylometry. I would like to know how
| much of the conversation occurring in this comment section is
| real, and how much of it is part of the recently revealed work
| that Microsoft has being doing in swaying opinion on hacker news.
|
| Wouldn't that be an interesting tool for press releases like
| this?
| pkilgore wrote:
| > recently revealed work that Microsoft has being doing in
| swaying opinion on hacker news
|
| I'd love a link. Unfortunately "microsoft and hacker<anything>"
| get's swallowed up in search results by recent attack news.
| fartcannon wrote:
| https://sg.finance.yahoo.com/news/microsoft-corp-
| msft-q1-201...
|
| "In fact, this morning, I was reading a news article in
| Hacker News, which is a community where we have been working
| hard to make sure that Azure is growing in popularity and I
| was pleasantly surprised to see that we have made a lot of
| progress..."
| ajcp wrote:
| Recently? This article is over 2.5 years old...
| iudqnolq wrote:
| > it is part of the recently revealed work that Microsoft has
| being doing in swaying opinion on hacker news.
|
| I'm deeply sceptical this is real because the risk would be
| high and the reward miniscule. Source?
| fartcannon wrote:
| https://sg.finance.yahoo.com/news/microsoft-corp-
| msft-q1-201...
|
| "In fact, this morning, I was reading a news article in
| Hacker News, which is a community where we have been working
| hard to make sure that Azure is growing in popularity and I
| was pleasantly surprised to see that we have made a lot of
| progress..."
| filoeleven wrote:
| I searched the comments for some of the big-name RPA "solutions"
| I've had to work with before, and none of them show up at all
| (Blue Prism, mentioned in the article, was one of them). Not
| surprising, since ALL of their documentation on how to use the
| damn things or even how they work on a technical level is
| paywalled.
|
| As someone who's had to support them for an org's clients in the
| past, that lack of access is extremely frustrating. How can I
| develop a library that lets clients access the web app through
| RPA if the vendors refuse to tell me how to make things
| accessible to them? Waste all around. Good riddance. Not that I'm
| any more confident about Microsoft's offering here.
| omk wrote:
| If this works, Microsoft is going to hit a long-term retention
| jackpot. Low-code ecosystems are sticky and excel in ARR as their
| model is usually consumption based. Moving away costs companies
| millions. Every employee is automating their work on this
| platform. I working with a consulting firm and one of our
| customers (+50,000 employees) has onboarded power-platform for
| every individual to automate their work.
|
| If ever a change is proposed, the change management team is going
| to shoot this down or will be forced to create a 5 year migration
| plan.
| jerf wrote:
| I don't know if they're pursuing this, but Microsoft also has
| the opportunity to create low-code solutions that more
| gracefully transition into conventional solutions, because
| unlike a pure-low-code play, that doesn't have to mean they are
| losing a customer. They aren't incentivized to lock you in to
| low code as long as one way or another you pay Microsoft on the
| way out, too, via either being in the conventional Microsoft
| developer ecosystem or being on Azure.
|
| Given that they seems to be acquiring they way into this
| market, I'm sure it's nowhere near this integrated yet, but
| could you imagine being able to take any individual component
| of the system, or the system as a whole, and getting a "Click
| Here to create a Visual Studio Project" that completely
| replicates the low-code solution into Visual Studio, ready and
| waiting for you to start modifying it? Probably with some sort
| of automatic "Click Here to Deploy Your Changes Into Azure"?
| ajcp wrote:
| Couldn't agree more. By providing tools that allow you to
| "reach in" to every part of their ecosystem, from their OS to
| their productivity suites to their cloud offerings, they're
| creating a very comfy lock-in that would be hard to justify
| your way out of.
| akudha wrote:
| I think it will work, especially if Microsoft can also build
| self hosted version of some of these tools. There is a huge
| market for such tools (look at how much attention self hosted
| Airtable alternatives are getting). Between self/cloud hosted
| versions, their sales machine and deep integrations, Microsoft
| has a huge advantage over Google and Amazon.
| AtNightWeCode wrote:
| There has been a huge push for low-code over the last couple of
| years. The idea that anybody can setup a business flow is
| compelling and easily sold. But low code means a lot of config
| and these systems are nothing new and over time they will sooner
| or later become limiting. If you have everything in code any
| problem can be solved.
|
| You also still need to solve the things like CI/CD, CM,
| dependencies, data modelling, correctness, resilience, security,
| compliance, integrations and so on.
| m12k wrote:
| I'm currently porting a slackbot to Teams. Even with the backend
| logic and architecture mostly re-usable, the Teams bot is already
| taking at least 3x as long to code, simply because their
| documentation is so obscure. It feels like detective work,
| correlating data from 4 different tangentially related sources
| (AzureAD, app authorization flows, Graph, BotFramework). I've
| never had so many tabs open at once in my life. At one point, I
| gave up on their documentation, and just traffic-sniffed the
| library used in one of their example apps in another language, to
| figure which endpoint to call and which json format to send it.
| The jump from Slack to Teams feels like the difference between
| Rails and (Java) Spring - the former makes web-apps, the latter
| is a framework and dependency injection container, which can be
| used to make various apps and services, among them web-apps.
|
| Long story short, MS is a master at making you appreciate the
| difference between "technically possible to achieve" and "easy
| and realistic to achieve". If my experience with them is any
| indication, MS still has a looong way to go before they can make
| their ecosystem of services accessible to "normal" people.
| thrower123 wrote:
| Bot Framework is horrible. It's the most ridiculous IM platform
| I've built anything for, and I've covered a good bit of the
| spectrum.
|
| They really need to expose a full-featured API for Teams,
| something at least as powerful as what you used to be able to
| do with the UCMA SDK for Lync/SfB.
|
| I've given up on anything ever getting exposed through Graph
| API in a timely manner. It took two or three years before you
| could get online/busy/away presence information on a user
| without outrageous, unsupported hacks.
| WorldMaker wrote:
| Bot Framework was a good idea: one framework to write a bot
| for multiple IM platforms at once. But of course it
| immediately suffered the exact problems you would expect:
| lowest common denominator features, older target platforms
| falling into disrepair, new platforms never getting official
| support, etc.
|
| Using Bot Framework to write _just_ for a Teams bot is broken
| before you start. Using it to support both your Teams and
| Slack integrations sounds nice on paper, but probably doesn
| 't work in theory as soon as you need platform specific
| features or do something "advanced". You still can't use Bot
| Framework with Discord.
|
| I liked the theory behind Bot Framework, but the practical
| reality has so far been mostly a disappointment.
| ajcp wrote:
| I can see that. I think you're best bet is to throw that
| BotFramework out. I'm not sure why they keep it around, but
| they've all but replaced it with Power Virtual Agents.
| [deleted]
| jeff-davis wrote:
| Does SQL qualify as Low-Code? A lot of technical non-programmers
| are very successful using SQL.
| bob1029 wrote:
| We started leveraging SQL very heavily in our application so
| that business people can customize app behavior without
| bothering developers. We are getting close to 100% config-only
| coverage using SQL.
|
| We tried rolling our own scripting language and other ideas,
| but we decided that we weren't ever going to catch up with the
| level of testing & validation that SQLite has achieved with any
| amount of in-house resources.
|
| Once we embraced SQLite, we found an entire universe of
| capability. Here is one of the comments I made just yesterday
| about this kind of thing:
| https://news.ycombinator.com/item?id=27362708
| brixon wrote:
| Yes since it is describing more what you want and less how to
| do it, but SQL is not an end-to-end solution.
| pjmlp wrote:
| Pure SQL no, but when coupled together with language
| extensions and frontends like APEX, it surely is.
|
| I have seen departments fully managed with APEX applications.
| golergka wrote:
| Using SQL to get reports and analyse existing data, or to
| actually create schemas, change data, maintain transactions
| over related changes and so on?
| thrower123 wrote:
| I know somebody that spent a few days setting up a bunch of these
| things to handle contact forms on landing pages and that kind of
| sloggy boring projects. They work fine when they work, but things
| wig out with them often enough, or they decide that they haven't
| been run in X days, and are going to be reclaimed, that it's
| become a hassle that keeps somebody busy about half the time. Job
| security, if you introduce these low-code solutions, I suppose...
| Graffur wrote:
| Who will actually build and maintain these low code solutions?
| Will it be over qualified SWEs who will lose their skills over
| time if they work on this stuff? Or will it be citizen developers
| who were actually hired for some other skill set and won't care
| for solution design or future planning?
|
| Or will it be new employees hired with just this skill set?
| OrvalWintermute wrote:
| I'm surpised there is almost no mention of low-code and the
| excellent product that Microsoft killed off, in Visual Foxpro
| https://docs.microsoft.com/en-us/previous-versions/visualstu...
| simonbarker87 wrote:
| My last role had A LOT of VFP in the estate and it was still
| added to on a regular basis and all the main VFP devs kind of
| loved it.
| syshum wrote:
| Low Code is the modern version of "Write Once run Anywhere"
|
| It is pipe dream that will cost companies millions in Vendor
| Lockin, rewrites, and all of the other problems that come with
| non-developers "developing"
|
| See the nightmare that is Excel Workbooks, the fact they are
| modeling FX on Excel Function is a horror I do not even want to
| think about
| rchaud wrote:
| My university's application system is a set of workflows based
| on drag and drop Salesforce components. It processes tens of
| thousands of multi-step, multi-page applications without any
| issue.
| haswell wrote:
| > _will cost companies millions in Vendor Lockin, rewrites, and
| all of the other problems that come with non-developers
| "developing"_
|
| What many folks miss here is that companies still willingly
| proceed _despite_ these drawbacks because of the value that the
| end result provides.
|
| These tradeoffs are often less apparent when coming from a
| software development background or working for a company that
| builds software. But if you're in a different type of org - say
| financial services - these solutions are often the difference
| between launching a new product/capability, or putting
| structure around a paper process...or accomplishing absolutely
| nothing because development is currently tied up for the next
| two years.
|
| Not all companies have IT/Dev orgs that are capable of meeting
| the demands of the business. Some orgs are transforming their
| businesses (the "digital transformation" buzzword), and don't
| have a dev team at all. At best, they have some centralized IT
| department that is capable of rolling out point solutions.
|
| You might be right that these solutions are inherently inferior
| from a technical perspective, but if you look at this from a
| business outcome perspective, those tradeoffs are often
| worthwhile.
| syshum wrote:
| I agree somewhat, the problem with "business outcome
| perspective" likely means very short term thinking, get it
| done now, deal with the rest later.
|
| The people that cause the mess are not likely the ones that
| have to clean up the mess, people like me are. I prefer to
| greenfield things but instead I spend the majority of my time
| untangling the bad choices people made years before coming at
| it from a "business outcome perspective"
|
| There should be some kind of middle ground, likely starting
| with proper, actual training and restricting access to low
| code solution to people that have at least some technical
| literacy which often does not happen.
| haswell wrote:
| I tend to agree with you in most situations, but I do think
| there are some counter examples.
|
| The recent rollout of various COVID tracking apps for large
| companies come to mind. There was no way to predict the
| need, and low code tools were leveraged heavily to spin up
| quick solutions. e.g. I believe SalesForce products were
| used for some of the "Vaccine Finder" types of sites that
| spun up in my state.
|
| That aside, as a general rule, if these are such important
| projects, the business _should_ expand its development org
| and improve internal processes to better react to business
| needs.
|
| But it seems like an almost universal problem (especially
| outside of tech) that this just does not happen. There is
| often very limited appetite to take on the risk of a big
| dev project without understanding its value. You could
| argue that building a business case is a better way to
| prove that value, but on the other hand, if you can build a
| business case _by literally implementing a solution_ , and
| bring data to leadership that clearly says "this is worthy
| of investment, and here's a v1 already working to prove our
| point", this appeals to the risk averse management types
| since it _proves_ the need.
|
| I don't think this is a great mode of operation, but I
| think it helps explain why we see such investment and
| growth in these tools.
| tialaramex wrote:
| The CCADB https://www.ccadb.org/ is built out of
| SalesForce. Its purpose is to mechanise the paperwork
| needed to manage the relationship between the major Root
| Trust Stores and the Certificate Authorities.
|
| Its members are Mozilla, Microsoft and Google (in
| principle you could imagine Apple choosing to join some
| day, or then again maybe not, likewise perhaps Oracle).
| Clearly _any_ of those entities could build a web site,
| they already own _several_ web sites, and if this was
| rocket surgery (and it isn 't) they employ rocket
| surgeons already. But they chose to use SalesForce.
|
| And I've always supposed that one big reason is that you
| clearly can't let the other guy write the system you'll
| both use, and yet you also definitely don't want to waste
| your resources on working together to write it, that's
| usually even more expensive than either of you writing it
| alone.
|
| But low code as a matter of principle also makes sense in
| this space. This is "just" mechanising some paperwork, it
| shouldn't need to be complicated. There shouldn't need to
| be a Mozilla engineer working on the CCADB.
| shadowgovt wrote:
| The relevant question, I think, is extensibility. If the low-
| code solution, upon hitting a wall, can be extended instead of
| rewritten, it's going to be a great solution for small
| companies to prove out ideas without the cost of general-
| purpose developers and custom software stacks built from
| general-purpose software.
|
| If any company _can_ solve the extensibility question, I think
| Microsoft has a better-than-average shot at it.
| jimnotgym wrote:
| If Microsoft were serious about 'low code' we would be looking at
| Visual Basic 7.
| ajcp wrote:
| 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" strategy is not RPA, nor is it
| enabling the development of enterprise applications with "Low
| Code" development tools. RPA is already a legacy solution in it's
| current form, and increasingly only useful with regards to
| mainframe emulators and applications that don't offer an API,
| which are rarer and rarer with the move to cloud everything.
| Enterprise applications should only exist as applications, not as
| components/products of another enterprise application.
|
| Microsoft's Low-Code "strategy" is providing tools for business
| process applications, they're just really bad at messaging that.
| Enable original data to get into their ecosystem (Power Apps),
| transform, evaluate, and move it around (Power Automate), and
| then provide understanding and feedback (Power BI). If every part
| of their ecosystem -*including their productivity suite and OS*-
| has an API backing it up (which it does) then their real play
| here is not providing "Low-Code/No Code" tools for building
| *applications* but rather for API integration and orchestration.
| This is the "new" RPA.
|
| Why would one need to build an RPA "bot" or enterprise
| application if one can just generate a form with Power Apps, use
| Power Automate to reach into your Outlook, Excel, SharePoint
| List, OneDrive, or Windows file system, and then crap out the
| desired product in the system of record or a Power BI dashboard?
|
| Source: I've worked in the RPA space for over 5 years now as a
| SWE, Tech Lead, and Architect.
| brushfoot wrote:
| 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 wrote:
| 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 wrote:
| I know where you're coming from, but if the ROI is there,
| it doesn't matter if the first iteration is fragile. Just
| ship it. 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.
|
| This has helped my team deliver on projects that the rest
| of IT has failed on because of
| overengineering/perfectionism. We've shipped products where
| some processes are fully delegated to humans. And that's
| okay. Not everything has to scale or be automated right
| away. "Grow as we go" is a great mantra for software as a
| service.
|
| I would add, RPA isn't nearly 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.
| enraged_camel wrote:
| 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.
| filoeleven wrote:
| 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 wrote:
| Stories like this make me sad :(
| filoeleven wrote:
| Oh, me too. I wrote a whole rant and erased it before
| submitting the comment because I judged it to be
| unhelpful.
| ajcp wrote:
| 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 wrote:
| Pretty sure kofax road is just KaPow acquisition, but yes.
| tootie wrote:
| Would you say that Zapier is in this space? That seems to be
| the kind of use cases I see in my org.
| ajcp wrote:
| Certainly, I believe any of those API "middleware" tooling
| should be treated as the "new" RPA. IFTTT, Zapier, MuleSoft,
| Appian, etc
| monkeydust wrote:
| Nicely put.
|
| I have always felt RPA was the ' poor mans' option for
| automation.
| ajcp wrote:
| 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.
| ethbr0 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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)
| ajcp wrote:
| >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."
|
| This is the _whole_ life-cycle of a correct RPA
| implementation. The only successful RPA automation is the
| one that gets turned off because it has been solved for
| in the enterprise application level.
| Mister_Snuggles wrote:
| In my experience, the lifecycle is more like:
|
| * Person in the business area implements RPA. Business
| area is happy.
|
| * Person who implemented RPA moves on to greener
| pastures.
|
| * RPA breaks, business area calls IT.
|
| * IT is horrified at the unsupportable mess that's just
| been dropped in their laps.
| jrochkind1 wrote:
| > 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 wrote:
| 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 wrote:
| 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....
| 7952 wrote:
| 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.
| russdpale wrote:
| Ah yes, the one spread sheet that everyone uses but no
| one knows how it works! I've seen that so many times.
| ajcp wrote:
| I agree. I think that's also true of all the cloud
| players these days honestly.
| WorldMaker wrote:
| > What's something that corporate IT is obsessed with?
| Making sure the business isn't creating shadow IT and
| developing enterprise applications.
|
| Though with Power Apps and Power BI all of that starts
| showing up on IT's dashboards (Azure Portal; Microsoft
| 365). Microsoft hasn't been great about messaging that, but
| unlike hidden Excel files in random network shares or
| VB+Access apps in PCs in cupboards, that "amazing CI/CD
| tool for enterprise applications" _also_ means that it can
| 't just live in the shadows and will get seen by IT.
|
| If anything, I've seen "citizen developers" turn away from
| Power BI/Power Apps precisely _because_ their M365 /Azure
| admins are too micro-managing to use the tools for what
| they were intended for and such people just go back to that
| Excel+VBA macros on a network share in a broom closet.
|
| Which yes, gets back to Microsoft is trying too hard to
| meet everyone's use case and in forcing Power BI/Power Apps
| into M365/Azure they've trapped out some of the "I just
| need to get stuff done" "citizen devs" because some IT
| departments are so scared of shadows that they are
| preemptively blocking one of the tools they could use to
| keep an eye on it better. It's a lovely irony.
| haswell wrote:
| 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 wrote:
| 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.
| Havoc wrote:
| > 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
| quyleanh wrote:
| The original article is brilliant but your correction is much
| more valuable. Thank you.
| ajcp wrote:
| Thank you and it's my pleasure!
| aparsons wrote:
| Microsoft has always had the best developer tools. This is an
| exciting step forward for low-code
| ajcp wrote:
| Coming up in the time when MSFT was the "big evil" it's almost
| depressing to see myself now as an actual fan-boy.
| aparsons wrote:
| The thing is, even when they _were_ big evil, they had the
| best developer tooling by a mile. Visual Studio, MSDN, etc
| were novel and leagues ahead of other platform providers'
| equivalents
| trixie_ wrote:
| We really need a revolution in the low code space. The amount of
| code we write - database, backend, api, frontend, etc.. to do the
| simplest CRUD task, makes me feel like compared to future
| programmers we're all cavemen rubbing two sticks together.
| filoeleven wrote:
| Better tooling for data-oriented interfaces is the answer.
| Everything CRUD does is at the interface layer. If you improve
| the semantics and discoverability of the interface, you enable
| better tools and products to grow from that.
|
| https://www.destroyallsoftware.com/talks/boundaries
|
| This talk encapsulates (heh) a lot of the ideals that I agree
| with. Strong guarantees at the interface layer are good, and
| foster better tools and products, whether they are low code or
| not. If you know with great specificity what is required at the
| boundaries, it crystallizes most things inside of any app. It's
| not a silver bullet! But it limits the damage we can do and
| steers us in the right direction.
| ajcp wrote:
| Perhaps, but our StickOps team is actually engaged since we
| moved to Sticks as a Service and implemented our MicroRubbing
| architecture!
| Tarucho wrote:
| The article looks like a paid ad in disguise.
| ARandomerDude wrote:
| The most mind-blowing part of the article was the Teams vs Slack
| screenshot.
|
| https://res.infoq.com/articles/cloud-vendors-low-code/en/res...
| _jal wrote:
| Seems like Microsoft feels threatened about once a decade and
| feels the need to demonstrate how comprehensively it can stomp
| on someone lacking a similar portfolio.
| AtNightWeCode wrote:
| You get Teams accounts with pretty much any MS thing. Teams
| still can't be used for chat in enterprise environments. It is
| laughable.
| Spooky23 wrote:
| Slack had to sell their new way of work. Microsoft just had to
| start turning off the components you already had.
|
| A more real way to portray that market would be to show the 20
| years of them fucking around with LCS/OCS/Skype for Business.
|
| Even then, most teams deployments I've seen are Webex, iMessage
| and work cellphone displacements. The adoption of what people
| do with Slack isn't there.
| paxys wrote:
| That graph really shows the (mostly automatic, forced)
| conversions from existing Lync/Skype for Business users rather
| than brand new Teams ones. Not exactly fair to compare it to
| Slack without including the existing user counts as well.
| tacticalDonut wrote:
| I don't use Teams because I like it, I use it because I have to
| at my company...
| geonic wrote:
| I'm not a Microsoft user, haven't been for over ten years.
|
| Recently I had to install and register for Teams at work. I
| haven't seen an application as clunky and messy as this in a
| long time. Nothing in its UI makes any sense to me.
|
| On top of that the login process is extremely wonky and
| unstable.
|
| To me this Microsoft doing again what it does best. Pushing
| some crappy software into the market by leveraging its market
| position.
| spoonjim wrote:
| Excel spreadsheets, and now low-code platforms, are how non-
| coders write functional specifications.
| dnndev wrote:
| This is addressing a market. I have seen it first hand more than
| once. Highly driven and competent individuals that are not
| programmers for whatever reason and that create a monstrosity
| that works (using some low code solution). It's ugly and buggy
| but gets a job done. This works for as long as they don't hit a
| technical limitation then call devs like myself in to replace it.
| It was a great phase 1 and made money.
|
| They earned a project with developers. Yes it will cost more to
| rewrite it but the old system is still making money while the new
| one rolls out.
|
| At this point a low code solution makes no sense for me as a dev
| - believe me I have tried them.
|
| Kudos to MS.
| jlarocco wrote:
| "Low Code" is a new (to me) buzzword, but Microsoft has
| targeted that niche for a long time. Specifically I'm thinking
| of the older Visual Basics (3-6) and the advanced scripting and
| database features in Office.
| pjmlp wrote:
| I have seen first hand on some lifescience consulting gigs
| how VB.NET takes away people from R, Python and similar
| tools.
|
| It is the Excel experts that have outgrown the macros and VBA
| capabilities, and get IT to install Visual Studio with VB.NET
| on their computers.
|
| They then double down on their VBA skills and somehow get to
| produce something in Windows Forms, or an Excel AddIn for the
| task at hand and then get going with the actual work.
|
| Then one lands on the lab and it is full of such small
| utilities.
| jjkaczor wrote:
| Neither VB, VBA, VBScript nor VB.NET are "low-code" or "no-
| code", they all were rather code heavy... Some VBA 'apps'
| relied heavily on their hosted application object-model
| (Excel, Word, Visio, etc) - but there was still quite a bit
| of code that the average corporate Excel-wizard was never
| truly comfortable with.
|
| In the Microsoft space, historically the true "no-code"
| solutions were Access Web Databases (no VBA allowed - of
| course they axed that whole service in 365, as they could
| not monetize it as well as SQL Azure), or web-capable Excel
| workbooks that rely exclusively on PowerPivot/functions (no
| VBA allowed), or web-enabled InfoPath Forms (also... no VBA
| allowed).
|
| In their modern universe their equivalents are; PowerApps,
| PowerAutomate/Flow, LogicApps and PowerBI - just as the
| article states.
| MattGaiser wrote:
| I think low code works for smaller more routine projects where
| hiring devs is just not all that feasible.
| asdfman123 wrote:
| A lot of people stuck in places like, say, the accounting
| department have the soul of a dev. They like technology and
| want to automate things. And often times when they do that,
| they actually improve their departments quite a bit with
| stuff like VBA and Access projects (as uncool as they may
| seem to some).
|
| It works because "real" programming environments have
| learning curves that are hard to tackle if you have a day
| job, and even if you do tackle them, IT is probably not going
| to give you direct database access.
|
| I had a friend like this, who was bored as shit as an
| accountant. I convinced him to migrate his career to software
| and now he's in a data science master's program.
| Asymmetryk wrote:
| if I may be so bold ( and presumptuous my suggestion is of
| any value) I wondered if your friend would like the risk
| and structured securities aspects of actuarial catastrophe
| risk markets. This pretty much has everything in it, from
| chaos theory to the statistics of the cadence of
| liabilities upon the different kinds of financial
| engineering structure that are used to distribute * the
| liability and fund the most difficult to reinsure policies
| in the capital markets.
|
| edit : * and package, according to a tremendous variety of
| fiscal requirements and risk appetites. And naturally
| covering the most extreme conditions liability payments is
| historically a fascinating insight into how we developed
| our world across and binding together such tenuous links.
| syshum wrote:
| >>It's ugly and buggy but gets a job done. This works for as
| long as they don't hit a technical limitation then call devs
| like myself in to replace it.
|
| Or more likely they leave the company, it breaks and no one
| knows how it worked, how it was suppose to work, or anything
| about it so they need to call in someone either from Internal
| IT, or and outside consultant to figure out what broke, and how
| to fix it...
| brixon wrote:
| No difference than Excel Macro apps today. When Excel Macro
| wiz kid leaves the department or the company and it either
| breaks or needs new features then it goes to IT and they
| don't work on Excel so they will push to rewrite it into a
| web app.
|
| The plus is that the use case and value for the program is
| already proven, so IT is not wasting time creating things
| people will not use.
| F_J_H wrote:
| Yes this happens...sometimes. And, other times, (as reflected
| in comments ITT), there are many cases where a low-code
| solution built by a non-dev have brought huge benefit. (I've
| seen this myself - see below - MS Access apps that saved
| hours and hours of work, but which IT had not time to look
| at.) I've also seen the sentiment in your comment lead to an
| outright ban by IT dept. of all low-code tools, for no other
| reason than the "slippery slope fallacy" that "if we allow
| this, we could potentially have a big mess to sort out one
| day". And in doing so, summarily kill a ton of innovation and
| productivity.
|
| One anecdote I remember - a regulatory change created a major
| issue for a billing department. They went to IT to get their
| help to address it, and were told "sorry, no time to even
| talk to you right now. Come back in six months. Actually,
| make that 8 months." So, a tech. savvy person in the billing
| dept. built something in MS Access that solved the problem.
| They were thrilled. When IT heard about it, they tried to get
| the guy fired. Billing Dept. manager had to go to bat to make
| sure that didn't happen.
| codingdave wrote:
| I've been working in and supporting low-code environments off
| and on since the 90s (Lotus Notes -> Sharepoint -> Salesforce,
| if it matters) I've been the guy who does those re-writes when
| needed. I can confirm that the biggest and worst of them need
| re-writes, but most just need a little cleanup. Most are like
| you said, a non-programmer does something unwise. I spent much
| of my time giving people a "Dev 101" course to help them do it
| better, and they'd build heaps of apps that never needed re-
| writes.
|
| Even when they did need taken over by IT because they scaled to
| a level of being business-critical, they rarely needed a full
| re-write, they most often just needed enhanced. Adding in
| validation, data integrity, backups, UX, testing, and simply
| streamlining the app with features that needed "real" code. And
| once a decade we'd re-platform them all as the underlying
| platforms become outdated and were eclipsed by something new.
|
| It was amazing how well the non-programmers could do if given a
| weekly opportunity to just come in and show their work, ask
| questions, and get advice. Some of the people I coached even
| went on to learn how to code and have become successful
| software engineers in their own right.
|
| If you ever end up supporting such environments again, I'd
| recommend considering yourself a mentor to new developers more
| so than someone who is going to clean up someone else's mess.
| People might surprise you with how much they are capable of.
| leejoramo wrote:
| 100% agree with you.
|
| I really enjoy supporting people who have already built their
| own tool, but need a programmer to take it to another level.
| Such projects tend to be well scoped, and the project owners
| are heavily invested in and understand their actual needs.
|
| In 20+ years of professional programming, projects that
| started with the end user solving their own problems have
| nearly a 100% success rate.
| asdfman123 wrote:
| Yeah, this is pretty much the use case for low-code solutions
| like Access. Being a developer is an exception, rather than the
| rule, and there are a lot of smart BAs out there who know
| software could improve their lives.
|
| I feel like if AI gets really good, low-code is the future. In
| the future we won't eliminate software engineering but it will
| become increasingly less technical until software devs and BAs
| merge as one profession.
|
| But that's decades off if it comes at all.
| stuaxo wrote:
| I'm sure a lot of projects would never make it to developers if
| somebody out in the field wasn't trying to solve a problem like
| this in the first place.
| LeifCarrotson wrote:
| Yes, no-code solutions almost always become ugly, buggy,
| monstrosities, and there are technical limits that mean it
| needs wholesale replacement, but pragmatically I too have seen
| them getting jobs done. I'd also wager it will not cost more to
| rewrite it, especially if you deeply discount the non-developer
| resources that were used to create it (often salaried
| employees' time, and even then those individuals likely came
| out ahead compared to the tedium of doing it manually).
| Consider it a prototype. Also, the functional spec of "do
| exactly what the domain expert made this convoluted Excel
| spreadsheet do for the last 2 years, but with better validation
| of inputs" is often far more accurate than some daydreamed RFQ.
|
| The part that confuses me is why this makes sense as a separate
| enterprise product. Had the original author been interested in
| learning a new tool, they'd have probably been better off
| starting with Python. I recognize that non-developers are
| silently building their own tools, some of which will be a hit
| and later need replacement by developers, but are there really
| sales teams going around to big enterprises suggesting that
| they buy licenses for all their employees to be able to build
| their own tools using their particular low-code solution that
| will eventually be replaced? Seems like a difficult thing to
| sell IMO...
| tolstoshev wrote:
| On the flip side, there's plenty of ugly, buggy, code
| monstrosities that have to be rewritten or refactored. This
| just means the professional developer gets to start with a
| clean codebase with the UI & processes already laid out as an
| example. Almost like the no-code is a working prototype in
| place of a requirements doc.
| bigger_cheese wrote:
| In the last 6 Months my workplace has started heavily using
| Power Apps. The first impression I got was 'holy crap, this
| is MS Access on steroids'. My workplace heavily(ab)used
| Access in the 90's and we got bitten very badly when support
| for Access was discontinued. We also had a lot of VB6 code
| which was similarly orphaned.
|
| In the mid 2000's someone in our IT department decided all
| new business apps were to be written in Java I believe this
| decision was made partially as a reaction to what happened
| with Access and VB6. The result was everything stagnated our
| in house apps became massively bloated, buggy and almost no
| one did anything 'to fix things. Any changes had to go
| through external contractors because no one knew Java or how
| to support these apps. If they had mandated Python like the
| post I'm replying to suggested I am sure the results would
| have been the same. Probably worse because harder to find
| cheap contractors to work on business apps in Python.
|
| You are not going to get HR people, you are not going to get
| Finance Accountants, you are not going to get commercial team
| or legal to learn a full on programming language. That is why
| these products have such a niche in large Enterprise orgs.
|
| Yes you get buggy monstrosities but you can also very rapidly
| develop working tools that solve real business problems.
|
| I think what makes Power Apps attractive is the whole Azure
| ecosystem Microsoft have built around it. There is a whole
| suite of tools that all talk to the same common backends,
| Power Automate, Azure Databricks, Azure ML, Power BI, Power
| Apps etc. From what I've experienced as all of this stuff has
| been rapidly rolled out across my org is it all "just works"
| and seemingly solves real problems.
|
| My real fear is that 5 years down the line it will have all
| be abandoned and we'll be left with MS Access 2.0 and a
| bunched of orphaned unsupported apps again. I hope Microsoft
| have learned from what happened with Access but at the moment
| it remains to be seen.
| nightski wrote:
| Not everything is a large ugly, buggy monstrosity that needs
| to be rewritten into "real software". There are may business
| processes served quite well by excel which might be enhanced
| with a low code solution like this and could stay that way
| for over a decade.
| Spooky23 wrote:
| Usually significant low code stuff is more reflective of
| organizational politics than anything else.
|
| Individual or small team productivity is one thing, the
| bigger low code monstrosities are usually a way for a
| vendor to weasel in and sell services under the IT peoples
| noses. The power automate bullshit cements whatever legacy
| junk it is feeding into and makes Azure the happy path for
| modernization.
| golergka wrote:
| Isn't that survivorship bias in action? Good solutions that not
| only work, but work well and don't hit the tech limitations
| would never be seen like developers like you, because they
| would never need to be rewritten.
| dnndev wrote:
| I am not sure how this comment contributes to the thread. It
| is a bias because I write my real-world experiences? What you
| are saying is true for so many things. Car that does not
| break does not need a mechanic. Of course, and nobody is
| disputing that. This comment just made me laugh so hard I had
| to reply.
| DonHopkins wrote:
| I bet Microsoft's "Low Code" turns out to be "Slow Code".
| _pmf_ wrote:
| Since the competition is Electron and JS, the bar is somewhere
| in the stratosphere.
| beckingz wrote:
| This is my experience. PowerBI especially is painfully slow
| even with tiny data.
| x86_64Ubuntu wrote:
| I'll admit, I'm being a hater. But how is this different from Sun
| Studio of yore, Adobe Flex Designer View or anything else?
| radicalbyte wrote:
| Sharepoint 2.0
| _pmf_ wrote:
| Also: Lotus Notes
| slumdev wrote:
| How is this conceptually any different from InfoPath + SPD
| Workflows?
|
| And if it's not conceptually different, what's going to make it
| work this time?
|
| Aside - it's probably been discussed ad nauseam, but the Teams
| vs. Slack graphic is highly misleading because of the way it's
| bundled and distributed. It'd be like comparing the install base
| of Notepad vs. that of Notepad++.
| brixon wrote:
| InfoPath is end of life and PowerApps is their replacement.
| dboreham wrote:
| All said with a straight face and no mention of proffering a
| lollipop...
| tyingq wrote:
| I would guess the RPA hype wagon will slow down on its own accord
| soon. The big users will start to see the downsides now that
| their implementations have been up a while. Scraping is brittle.
| And I imagine it's not experienced developers writing (or
| point/click generating) the scraping code at the customer
| locations.
___________________________________________________________________
(page generated 2021-06-02 23:00 UTC)