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.
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.
The segue from winning at board games -> winning at business is great, but then it goes into slightly too much detail about Appian.
I‘ve accepted that native advertising & PR are everywhere, but still... I wish it could just be a cool story about a billionaire board game champ (awesome!) without the embedded enterprise software ad (lame!).
Sekigahara, as a board game duel, is an experience approaching the divine. It is a very, very, very fine game.
Pictured behind him is a fine collection. A lot of great and interesting games, though I would have expected more war games...stuff like Fire In The Lake, Sword of Rome, etc.
Sekigahara is excellent, and yeah, I am surprised there is not more of a GMT collection behind him. After having designed Sekigahara, it seems like most everything they publish would be up his alley.
Which reminds me, I need to go look at what GMT has in P500 now. It's been a few months...
Heh, this article also prompted me to order some new things, like the new edition of Labyrinth and the P500 for Sword of Rome, which I've wanted for a while.
That Risk is present in the photo but not Diplomacy is a tragedy. :D
The fact he has Gloomhaven to the right of him made me chuckle. I've only had one chance to play it, and it took hours of fumbling around with the instructions with my friends (who also hadn't played it) but once we got the hang of the instructions it was very, very fun.
I liked that, to his left, he had Fortress America, Shogun, and what I think is Conquest of the Empire, the three other games in the same series as Axis and Allies.
There are a lot of large strategy board games that are much nicer than Risk these days. The world has come a long way since Risk was created. Risk 2210 A.D. is much greater, and there are other games even greater than that. I think large co-op board games can be especially fun.
BoardGameGeeks rankings push it way down, which seems to be a common theme for popular mainstream games. Though the ones at the bottom like Monopoly and Game of Life are truly horrible and give board games a bad rap: fulling deserving of their ranking.
To the right of Risk looks to be Stratego which was a fun game when I was a kid.
Is it hate? Or is it just the truth that board games have really evolved over time? I can still enjoy a game of Risk, but it's difficult to say that I'd prefer a game of Risk compared to a game with more complex dynamics. That doesn't mean I disrespect Risk or hate it. But difficult to enjoy skiing green circle after you've gotten used to black diamond, no?
Nothing wrong with Risk, so I don't get why it gets downvoted - especially given the influence it has had on gaming over the years. Maybe it is simply a wish to push people more towards the independent games rather than those owned by a corporate.
Some people have different tastes, like asking what’s wrong with vanilla ice cream.
I like board game geek, but it has a bit of a movie critic problem in that the most popular, most played, and most fun games aren’t necessarily highest rated.
It is also very well known, so any negative reviews have the added bonus of extra attention. And the criticism was novel a few years ago.
When I first read an article criticising Monopoly, I realised I didn’t know how to play it. We’d been house ruling it all this whole time! If you had fun playing it when you were younger, I’d question if you even know how to play it.
Sure, the house rules can make it more fun. But I’d argue, if you are just changing the rules, do you actually like Monopoly? Why not buy a game with rules you like?
The problem with Monopoly was it was originally designed to not be fun except for the one person winning. You thought you were playing a game, but instead it was educating you on how the haves end up having more.
Being simple and linear doesn't make it bad: I can equally enjoy playing super mario and Fallout,even though they are quite different in terms of gameplay.
The linearity and randomness aren’t the main problems. Play length and run-away winner are far worse issues. It’s possible to lose the game in the first couple of trips round the board and still have a couple of hours of slowly being ground down. One person might have fun no one else does.
Possibly, but I’ve only had people refuse to play Risk with me without suggesting any alternatives, so I have to assume it’s aversion to that kind of genre in general.
My biggest problem with risk is the huge element of chance.
I really like Mansions of Madness as well as Dead of Winter. Both are co-op but both have a mechanic where it’s possible one of the players is actually a betrayer out to defeat the others.
My problem with pure co-op, especially pandemic, is that what usually happens is one player ends up doing most of the actual “playing” and the others just provide a few suggestions here and there.
Both MoM and DoW limit the things you are allowed to share with the other players too, which makes this happen less often, and in DoW every player has a unique hidden agenda in addition to the group goal - which gets fun if they do something weird because you have to work out if they are a betrayer or just have a weird agenda.
It’s fun with even two players but it’s definitely more interesting with four or more.
The expansions allow twelve players, which I strongly recommend only doing with experienced players - it takes a whole day and people give up if you have to explain all the rules over and over.
Risk is a terrible game for anyone who cares about strategy because it has a kingmaker problem. Someone who is terrible at the game can still easily get mad and cause one player to lose by throwing all their armies at them. Monopoly has a similar problem with the ability to trade all your properties to someone for a dollar because someone else pissed you off.
I'd reach for Empire Builder or Nippon Rails or something like that before Risk. Even though it's a different theme, they end up being much better games.
Well there was his company DeepMind developing a Go AI (AlphaGo / AlphaZero) that can beat pros, at least 10 years before anyone though it would be possible.
He doesn't strike me as the kind to cheat at tournaments, being one of the best general game players of all time as I recall.
It seems a fair few tech entrepreneurs and folks in the software industry are also into designing games. I have several in the works, and one that’s very slowly building a following: https://www.drtomallen.com/half-the-battle.html
I'm in the software industry and I design board games. Of course I used to develop video games before that, so it wasn't a huge leap, although I didn't really have the urge to start doing it until I had gone down the board game rabbit hole for a few years and played hundreds of modern board games.
I have one game signed, but not yet released, by a publisher, and another game was selected as a finalist in the Cardboard Edison design contest this year.
It's basically a lot more fun way to do system design. You can take a lot of the same processes and apply it to board game design.
I guess it helps enforce the importance of certain aspects of the process that don't necessarily get hammered in, especially with large projects that can take a year or more to make (whereas I sometimes design 2 games and make prototypes for both of them in a single day).
One thing I never was really good about doing with system design was getting it out in front of actual users to test things as soon as possible, and the companies I work for often overdesign on the front end before getting it in front of users.
I recently was brought over to help on a project in a different department at work, and that project is now in UAT testing after about 2 years of design and development, and they're in the middle of redesigning a bunch of things right now, because the users finally got to sit in front of it and basically said, "Thanks, I hate it."
Like with board game design, you don't usually need to make things polished and good, just get something really basic made so you can show it to other people.
I always knew that was important before, but getting into the habit of doing it with board game design (and watching many things that I come up with and think are brilliant just bomb when getting in front of users) really hammered home that I can't always trust my instincts, especially since the software I'm making is really not for my use (I never use the enterprise software I'm working on right now, except to fix things), whereas some games I design I really do enjoy playing them myself as well.
Another thing with feedback is the concept of 'If multiple people are complaining about something, they're pretty much always right that it sucks. They're also almost always wrong about whatever idea they suggest on how to fix it.' Or basically 'The feeling is right, their solution is wrong.'
Many times I have designed a game just to see it crash and burn when it gets in front of other players (and other designers). They'll tell me they didn't like something and make suggestions on how to fix it, and often my brain will go 'yeah, but that kind of violates the core idea' or 'i'll try it' and you try it and it breaks further. But they're right that it's not fun, or that it gets too hard, or that it feels like they're not making interesting choices, or whatever. And you take all that feedback, you reflect on it, and often will come up with a better solution that addresses their concerns but is also more elegant and doesn't violate some principle of the design.
The same can be true with users of a software system. They can be right that something feels wrong, but there is a good chance the solution they suggest won't work for some reason. Either it technically can't be done, or it's clunky, or it'll violate some business requirements, or maybe it's an 'ok' solution but there's a better one that you can find if you think about it.
Another thing is that game designers can be very valuable to give feedback on the design, and can really point out some major issues with a design, but you have to take their feedback with a grain of salt, because they're not your target audience, and they also have their own particular design preferences and most of their suggestions will reflect that (I do it too, and have seen myself do it). If you incorporate too much of their feedback into the game, it will probably take the game into a very different direction and might not fit your audience anymore (one big thing is game designers tend to be big game players, and especially like more strategic games, so you have to be careful getting their feedback for casual games, that have a lot of luck in them. They'll complain about how much luck is in the game, and make suggestions to remove that luck, and if you did too much of that your game is no longer a light family or kids game anymore).
How that applies to system design is that other engineers probably have very useful feedback to give for your system, especially pointing out structural issues, but they are a lot more technically savvy, and their suggestions will probably lead to a more confusing and complicated (but more powerful) product that might not appeal to a mass audience because it's just too much going on, and a simple design would appeal to them more.
I'm sure I could probably sit down and come up with more. Maybe I should write a short Kindle book about it :).
I just realized I kind of wrote this backwards, i.e. things learned in board games applied to system design, but I think I first saw these ideas in software, and got to apply them more with the faster iteration process of board game design.
I followed links to find out more about the games referenced and I’m astonished to see a two player game that advertises 180 minute duration. Anything that long would have to be multiplayer to justify its existence in my schedule. Terra mystica is hitting the multiplayer sweet spot at 90ish minutes, and I’m a beginner.
It's a war game. War games are allowed to be that long.
I've played games of Terra Mystica that have taken 3+ hours, just depends on the group. Although they were at least 4 player games.
Twilight Struggle can easily take that long, and it's only a 2 player game. If it doesn't take that long, someone probably lost early on, or both players know the game really well and can play it quickly.
Longest multiplayer game I've ever played was Diplomacy. We played for 12 hours, and had to call it early at that point. Even with it being that long, I felt the game was going at a breakneck pace and I didn't feel like I had hardly any time to grab food or go to the bathroom, because I had to talk to everyone and figure out what the hell to do for my next turn (and make sure I heard as much as I could from other people talking). It was an awesome experience I'm not in a hurry to do again anytime soon.
In college we would have marathon weekends where we'd stay up for three days and play multiple games of Diplomacy, Big Two and Mahjong.
We generally ended up with a 2 or 3 player victory in Dip after about 7 or 8 hours. Very rarely did we push those solo victory games, but we would play a few times a week besides those weekends.
I must have played 50 in-person Diplomacy games in one year and another 100 or so online. It became an addiction. Lost thousands playing mj too.
A lot of two player war games are a full 8 hours of play for experienced players, if not multi-session.
In my Battletech tabletop (which is a very simple game...) group, with 6 players around the table and a full day we can usually only get 12-15 turns in, without advanced rules.
That's partly why the "Grinder" format is so fun. If there's such an event at any conventions you attend, I strongly suggest trying it.
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.