4 ms·

The company I worked for before ~ 8 years (a bank) was using Appian for a bunch of its non-core workflows and actually was in the process of using it even more.

The company I worked for before ~ 8 years (a bank) was using Appian for a bunch of its non-core workflows and actually was in the process of using it even more. Appian is a strange beast: It's a BPMS written as a Java web application that has an in-memory kdb (the db of the K programming language which is well-known in HN) for storing all process data. The greatest advantage of Appian as compared to other workflow systems I've used (Activiti, jBPM etc) is that it offers a really complete environment for creating a more or less complete workflow without the need to write code. So you can actually teach non-technical people to do it. I remember we had a couple of Business Analysts that were creating very complex workflows back then. The didn't have any technical knowledge; their background was mostly on economics. Of course, for integration with legacy systems or relational databases or doing some tricky UI you'd still need a developer. But most of the work could be done by a not so tehnical guy which is the holy grail of such systems. Also, it was a really complete system where you could rather easily implement all your workflow needs (workflow design, user tasks, notifications, exceptions, integrations, reporting, authorizations, business rules, subprocessing, parallel execution etc). After some initial configuration you'd rarely need to touch code unless you needed some custom bpm nodes. Appian was also claiming that because it was using the kdb as a database backend it was very fast. I don't have an opinion on this; it wasn't slow but wasn't blazing fast. And also when the kdb size grew too much (we're talking some tens of GBs) it was taking a really long time to start (half an hour or something) and needed the same amount of memory from the server (IIRC we had 64GB back then) because it needed to load the kdbs into memory. Also I remember that we had a constant fear that the kdbs will be compromised somehow (for example if the server rebooted unnormally) and we'll lose data. Or maybe I had that fear; I was never able to "trust" it as I could trust the good-old IBM DB2 database the bank had. Concerning data-loss, we had a bunch of incidents that were related to having configured appian as a cluster; after we switched to a single server it was better. The good thing (or maybe bad because I was never able to learn K) is that it had a complete API in Java so we didn't actually need to touch the kdbs; I remember with awe however when we had a support request where an Appian engineer was using K to actually query the kdb and see the status of our server. In any case, the main drawback of Appian is how expensive it was. I don't remember how much but I remember that the bank had a special agreement to have a low price for Appian (don't exaclty now the details); buying it fully was too expensive even for the bank (!) (especially if it was to be used by all employees since it had a per user fee). Beyond all these, I belive that Appian is a solid product and deserves its success in the enterprise world.

bob1029 6y ago
We are providing similar services to several financial institutions using a first-party solution we have developed over the course of the last 5 years. Our approach for enabling non-technical people to impact the business is on a radically-different side of the spectrum though. Instead of "no/low" code with fancy UIs and modules, we went in the other direction. We asked the following question: "Can we reorganize the codebase in order to expose common business concerns in such a way that non-technical people can reason with them simply by viewing the source code?" The answer so far has been a resounding "Yes". We proved that there was extreme amounts of value in non-technical people being able to read the current state of the business implementation. Using functional business rules instead of imperative ones makes all the difference in the world. E.g. "if(CustomerIsAMinor) {...}" vs "if(customer.Age<MinorLimit && someothercondition) {...}". Using C#8 and having the ability to use functional paradigms as well as things like pattern matching also enable us to write highly expressive code that non-technical people enjoy reading. Also, really basic stuff like splitting important points of focus into class partials can make it 10x easier for non-developers to get into that 1 focused file and understand what is going on (e.g. MyBankWorkflow.CustomerValidations.cs). But we didn't stop there. We then asked this question: "Could non-developers make changes to certain areas of the codebase?" We have done a few trials with our project managers and are finding that they are more than capable of: turning a new branch in GitHub, checking it out locally, opening Visual Studio, updating a parameter listing or resource file, making a commit, and then submitting a PR for review (typically by an actual developer). As confidence with this practice grows, we will further expand the "safe" areas of the codebase (i.e. what non-developers are allowed to edit). Ultimately, we are trying to move into a direction where the development team is more of an internal consulting group rather than the means by which every line of code must be authored. The other view of this is that highly-intelligible source code is also useful for quickly ramping new employees and growing the team. We are beginning to view our codebase as not just a tool for the developers, but something that anyone in the organization should be able to work with in some useful way. If you think more broadly about this cyberpunk reality we are sliding into, this is the only reasonable path. You have to enable everyone in your organization relative to the technology. You cant afford to slap a Fisher Price UI around every scary technical thing you run into. Tear down your silos and do not be afraid to show code to your project managers or even customers. Start writing your new business apps with these ideas in mind and you may reap some very unexpected benefits down the road.

bob1029 6y ago

We are providing similar services to several financial institutions using a first-party solution we have developed over the course of the last 5 years. Our approach for enabling non-technical people to impact the business is on a radically-different side of the spectrum though. Instead of "no/low" code with fancy UIs and modules, we went in the other direction. We asked the following question: "Can we reorganize the codebase in order to expose common business concerns in such a way that non-technical people can reason with them simply by viewing the source code?" The answer so far has been a resounding "Yes". We proved that there was extreme amounts of value in non-technical people being able to read the current state of the business implementation. Using functional business rules instead of imperative ones makes all the difference in the world. E.g. "if(CustomerIsAMinor) {...}" vs "if(customer.Age<MinorLimit && someothercondition) {...}". Using C#8 and having the ability to use functional paradigms as well as things like pattern matching also enable us to write highly expressive code that non-technical people enjoy reading. Also, really basic stuff like splitting important points of focus into class partials can make it 10x easier for non-developers to get into that 1 focused file and understand what is going on (e.g. MyBankWorkflow.CustomerValidations.cs). But we didn't stop there. We then asked this question: "Could non-developers make changes to certain areas of the codebase?" We have done a few trials with our project managers and are finding that they are more than capable of: turning a new branch in GitHub, checking it out locally, opening Visual Studio, updating a parameter listing or resource file, making a commit, and then submitting a PR for review (typically by an actual developer). As confidence with this practice grows, we will further expand the "safe" areas of the codebase (i.e. what non-developers are allowed to edit). Ultimately, we are trying to move into a direction where the development team is more of an internal consulting group rather than the means by which every line of code must be authored. The other view of this is that highly-intelligible source code is also useful for quickly ramping new employees and growing the team. We are beginning to view our codebase as not just a tool for the developers, but something that anyone in the organization should be able to work with in some useful way. If you think more broadly about this cyberpunk reality we are sliding into, this is the only reasonable path. You have to enable everyone in your organization relative to the technology. You cant afford to slap a Fisher Price UI around every scary technical thing you run into. Tear down your silos and do not be afraid to show code to your project managers or even customers. Start writing your new business apps with these ideas in mind and you may reap some very unexpected benefits down the road.