It’s more about “trying to get stuff done in a reasonable time frame” and yes, this can often be seen as shallow from an academical point of view. Wish I had the time to give proper attention to many interesting ideas but alas, we have to juggle a lot of balls to live decently these days. 
dimitarvp
1
MrDoops
Where BPM sorts of solutions can be very powerful is when you have somewhat technical domain experts who can’t code, but can model or read a business process diagram. Spreadsheet wizards tend to find this kind of pseudo-coding easy. I walked through an accountant responsible for our sales commissions how to use Process Builder (Salesforce tool) and sent him some documentation to reference. It took him a couple weeks, but he automated a lot of the headache in that process without me having to spend the time to learn the domain in depth to code up a solution. I’ll have to rebuild that piece pretty soon anyway (it is a Salesforce tool after all), but it has provided a lot of value in the mean time, and now I have something to reference when scoping the long-term solution out.
Poorly/cheaply/quickly built applications can run into the issue of requiring a developer resource to make changes to processes, and that can be very problematic for a business. It can get worse when the business hacks together some other solution with spreadsheets and now the source of truth is spread-out (pun intended). As much as I dislike solutions like Salesforce, they do allow for quick, point-and-click changes which is something that Rails/Phoenix approaches which require a developer resource aren’t very good at unless the change is designed for.
BPM / declarative business process modeling solutions would be good for communication and frequently changing domains. That being said I think the line where a business should just call up an experienced consultant and have them build it is sooner than typical.
3
dimitarvp
Hm. A few points:
-
Poor domain specialist in a suit pretending to be an expert can be very problematic for a business as well. It all depends on where do you choose to place your trust.
-
Domain experts using Excel or executable charts tools can work quite well of course. It’s just that I cannot see any evidence this is quicker or cheaper than hiring a senior programmer for a year and have them sit and talk with your experts so he can (a) solve most of the problems, and (b) devise a DSL syntax with which the domain experts can extend / augment the system. Maybe I am wrong (as I said several times
) but I simply cannot find good articles to convince me. I have read a few and they seem to address very niche problems. -
I do wonder if hiring a programmer won’t be cheaper in the long run, provided they know what exactly must be done (not always easy). I was consulting for an org that fired all of its domain experts and failed to listen to me when I told them that they should not lay off certain two of them for a while because without their knowledge I would not be able to actually continue working on their systems! They did not bother to answer at all and I guess they assumed I am a cretin because shortly after they fired the mediator through which I was consulting for them (and thus fired me as well). My point here is that I heard their CFO once say “we have way too many suits in here” which is cynical and ugly but what I extracted from this was that the CFO found them useless. Maybe they would have been deemed useful if they knew how to make executable charts? Maybe.
I agree that point-and-click and executable charts solutions are sometimes necessary. I just question how often. A programmer can very quickly find themselves irrelevant in today’s market and while I am very okay with learning FP and reducing my hiring opportunities a bit, I am absolutely not okay with working on enabling executable charts culture and tech in a company and find myself unemployable in a few short years because I haven’t kept up with the market in the meantime.
0
MrDoops
I definitely agree most of what you said except
If I can automate myself out of a job I’d consider that a win! Now I learn something new and work on some other interesting problem. There’s always more interesting problems and topics than anyone ever has time for. Sales Commission applications are boring - better to automate that away so there’s time for better things.
Figure it out. Make it right. Make it easy. Train someone else to do it. Find another problem. Repeat.
I also doubt the likelihood that a capable developer/engineer could automate themselves out of a job. Good software architecture is not simply simple. I’d say the self-automated-destruction scenario is more likely to occur from gate-keeping or information hoarding type approaches to a job. Designing oneself to be indispensable when unnecessary is more likely to lead to that scenario of finding oneself unemployed and out of date. It might work in dysfunctional organizations, or just temporarily, but if there’s any justice - not forever.
Of course technology advancement is accelerating, so maybe the real solution is less jobs, more gigs, and systems to make that a viable living.
2
dimitarvp
Oh, 100% with you here. Exactly what I think as well. I was just expressing concern that if I keep my head buried in such niche problems like the Salesforce tools you mentioned, then I might find myself unemployable if I don’t keep up. Outside of that, you said it better than I could!
True. A really good programmer can solve a plethora of problems for their entire career. We should not try making ourselves irreplaceable, that’s not what I meant. I mean that we should (1) automate the boring stuff and (2) keep ourselves current and our minds sharp.
Yep. If only there was not so much artificial inhibition of economical and political models…
1
StefanHoutzager
I do not know salesforce and it’s process builder. I fear salesforce will use a proprietary DSL for modeling flows. BPMN is used by a lot/most specialized BPMS’s, making the models portable (no vendor lock-in). Bpmn is not like a spreadsheet, it is a visual programming language (external dsl) with blocks representing usertasks (with a pointer to a form), servicetasks (with a pointer to a service, input and output params), decision elements for processflow like arrows with decisions (salary > 100000) and decisiontasks (containing a pointer to a decisiontable - spreadsheet like, see DMN1.1), events etc. a BPMS is an orchestrator, not a development tool for services, forms (for these you could use a separate low code solution of course) etc. a BPM consultant is just a programmer. And it is not difficult to learn for regular programmers like us. There are people like that Bernd Rücker that I mentioned who find that the BPM modellers they design are intended for programmers, not “citizen developers”. I agree with his reasoning. Non-technical people are not developers. But blocks and arrows + spreadsheets are more understandable for business people so it eases communication, moreover the programmer also gets an easier grasp / overview of (complicated) processes. These DSL’s being executable by an interpreter is a pre.
BPM is not only about modeling, it is about improving processes also Process mining - Wikipedia . During the execution of a process you record all sorts of info that you can analyse automated and use to improve. It is a tool for easing collaboration between users in a company. Users see usertasks to be fulfilled popping up realtime with a timeframe (set in the BPMN usertask element) wherein the task should be done, if they have a role that permits it (defined by the “swimming lane” BPMN element wherein the usertask resides) . They can follow the progress of a workflow instance. Etc.
0
MrDoops
This is definitely true. I’d say vendor lock-in is a pillar of their business model. I’d love to see an Elixir solution take on Salesforce - there’s a lot of slow-moving cruft in their product that’s ripe for disruption.
1
StefanHoutzager
MrDoops
I guess I mean a comparable platform for the common business software needs Salesforce provides.
Features like user-management, permissions/authorization, admin interfaces, reports, forms, approval-processes, etc. It’s also used to build custom applications or install packages from a marketplace and network users with consultants. Problem is that to develop on the platform you’re giving up version control, open-source, and developer experience - a lot of this due to the vendor lock-in tendencies over time. It’s a slow moving Java business platform, and when they eventually get around to integrating crucial features that have been around for a while it tends to be limited due the technical debt incurred from this approach over time.
For a variety of reasons Elixir makes sense as an alternative building block for a product like Salesforce.
- Salesforce has a fairly robust metadata system to define “objects” and configure things like page layouts, defaults, field-level permissions, etc. It’s simple enough to store this meta-data in a database, but Elixir has ETS for very capable in-memory caching which would put this kind of capability on steroids, or at least make it significantly more flexible. There are a lot of abstractions built on top of the meta-data system that allow for the point-and-click management of this sort of system, so it’s a very core part their success.
- Salesforce has an add-on marketplace much like Shopify except there’s a lot more overhead to getting your package approved and available. I don’t see why add-ons couldn’t just be another Elixir application/component/service/what-have-you. Separate database, separate logic, etc. Just point-and-click integration of a new business capability. I was reading recently in this forum that they recommend developing Shopify add-ons in Elixir rather than Ruby for these sorts of reasons. I’m not really a fan of the SaaS approach where your data is being handled by an external service, so I really like the idea of running the software on your own machines.
- Most of the complicated nature of developing with Salesforce is due to their multi-tenancy model which requires an unnatural bulkification of imperative Java 6-like code and a lot of work-arounds for various limits. Salesforce’s multi-tenancy approach could be circumvented entirely by just spinning up a new container/server with the software. The limits are there to prevent service disruption of other customers on a server, so it’s understandable, but completely unnecessary in the age of containers. Even in the same multi-tenant environment it would be trivial to manage those sorts of concerns in a functional language with the concurrency support Elixir has.
The difficult part is designing something of this size with all the point-and-click conveniences. The golden-feature is when a somewhat-technical domain expert or administrator type can put together a maintainable business process flow without needing years of development experience. So not at all a trivial undertaking, but Elixir is what I’d pick to build a comparable business application platform given the chance.
0
jeremyjh
Most BPM products are a vehicle to sell consulting and training. I’ve seen them waste millions and millions of dollars. Haven’t really seen them work outside domains like Salesforce. I have found myself thinking about an Elixirish way to “solve” this though - what I’d like is a DSL that can yield rules/flows that can be reviewed and marked up by a business expert, but implemented by a programmer.
2