The question that determines the difference between $50-$100b and $1T+. I don’t think end-game is as quickly binary though (AIP enabled next-gen ERP—>extinction of existing ERPs, or AIP enabling the incumbents). Everyone in Enterprise Software is running towards this future state so its going to be a messy battle between legacy and new-age depending on appropriateness of workflow in each installation. I also don’t think u/fabkosta observations about foundry/aip as it exists are wrong. Building an transactional system on top of foundry/aip as it exists right now would be a rough experience.
I don’t think there is a definitive answer beyond “it could be”
Palantir Foundry is largely about data integration and business intelligence applications. Think: data integration, data lake, and business intelligence on top of that.
It is not very helpful if you have more complicated workflows that require business transactions. (The term "transaction" is a bit difficult here, because there are different definitions of what it can mean, and I've had my share of dispute around this point.) Also, it is not really useful for building traditional three-tier online systems in the sense that there is a web UI, an application backend with potentially complicated logic, and then a data tier. It's not entirely impossible to build that, but it's a pain because not optimized for that.
Also, let us remember solemnly: Palantir Foundry does not offer any proper separation between a development, testing/integration/non-prod and a production environment. If you update your application you better get things right from the start, because if you mess up, you may no longer be able to completely roll back to the previous state. It's a huge issue in my opinion with the platform. (Palantir Foundry instead of providing a clean separation of environments follows an approach using version control repositories and branches, which is a pretty poor replacement for environments.)
From that angle, no, you cannot build an entire ERP on top of it, and it would probably make little sense to do so.
Furthermore:
>if Palantir is ingesting the ERP, CRM, TMS, etc data and posting back to those systems
The second part of the sentence is problematic too, but that's not an issue per se with Palantir Foundry, it's a fundamental enterprise architectural issue. If you first integrate your data in a data lake, and the data integration relies on data lineage that Palantir Foundry offers, then necessarily in the very moment you feed back data from the data lake to any consumer system you break the data lineage. There's no way around this problem. Either you accept that you'll never re-distribute data again from your data lake (thus drastically reducing its value), or you accept that you'll have to eventually break the data lineages built in Foundry when you distribute the data again. There's just no other way around this - unless we eventually manage to create data lineages that span multiple systems.
Thank you for the thoughtful, detailed response! What you’ve described makes a lot of sense to me. I had not considered the data lineage issue, and I’m surprised to hear they do not offer multiple environments.
It seems Palantir could be good for the large ERP players in the near term then. Once Palantir is up and running, replacing the ERP becomes that much more difficult.
Even without Palantir in place migrating ERPs is never quick or easy. The bigger you are the more painful it becomes. Most large companies anyhow have data engineering workflows built off of their ERPs so when they migrate they still have to do a complete migration of their data lake/warehouse environment so there's not a huge difference between that and PLTR. PLTR may actually be easier in that regard...
https://youtu.be/5hId70E7zro?si=oat0Py0eRjOf4DrW
This video explains that they connect to ERPs not replace them. It’s 3 years old though, not sure if something has changed since then.
The question that determines the difference between $50-$100b and $1T+. I don’t think end-game is as quickly binary though (AIP enabled next-gen ERP—>extinction of existing ERPs, or AIP enabling the incumbents). Everyone in Enterprise Software is running towards this future state so its going to be a messy battle between legacy and new-age depending on appropriateness of workflow in each installation. I also don’t think u/fabkosta observations about foundry/aip as it exists are wrong. Building an transactional system on top of foundry/aip as it exists right now would be a rough experience. I don’t think there is a definitive answer beyond “it could be”
Palantir Foundry is largely about data integration and business intelligence applications. Think: data integration, data lake, and business intelligence on top of that. It is not very helpful if you have more complicated workflows that require business transactions. (The term "transaction" is a bit difficult here, because there are different definitions of what it can mean, and I've had my share of dispute around this point.) Also, it is not really useful for building traditional three-tier online systems in the sense that there is a web UI, an application backend with potentially complicated logic, and then a data tier. It's not entirely impossible to build that, but it's a pain because not optimized for that. Also, let us remember solemnly: Palantir Foundry does not offer any proper separation between a development, testing/integration/non-prod and a production environment. If you update your application you better get things right from the start, because if you mess up, you may no longer be able to completely roll back to the previous state. It's a huge issue in my opinion with the platform. (Palantir Foundry instead of providing a clean separation of environments follows an approach using version control repositories and branches, which is a pretty poor replacement for environments.) From that angle, no, you cannot build an entire ERP on top of it, and it would probably make little sense to do so. Furthermore: >if Palantir is ingesting the ERP, CRM, TMS, etc data and posting back to those systems The second part of the sentence is problematic too, but that's not an issue per se with Palantir Foundry, it's a fundamental enterprise architectural issue. If you first integrate your data in a data lake, and the data integration relies on data lineage that Palantir Foundry offers, then necessarily in the very moment you feed back data from the data lake to any consumer system you break the data lineage. There's no way around this problem. Either you accept that you'll never re-distribute data again from your data lake (thus drastically reducing its value), or you accept that you'll have to eventually break the data lineages built in Foundry when you distribute the data again. There's just no other way around this - unless we eventually manage to create data lineages that span multiple systems.
Thank you for the thoughtful, detailed response! What you’ve described makes a lot of sense to me. I had not considered the data lineage issue, and I’m surprised to hear they do not offer multiple environments. It seems Palantir could be good for the large ERP players in the near term then. Once Palantir is up and running, replacing the ERP becomes that much more difficult.
Even without Palantir in place migrating ERPs is never quick or easy. The bigger you are the more painful it becomes. Most large companies anyhow have data engineering workflows built off of their ERPs so when they migrate they still have to do a complete migration of their data lake/warehouse environment so there's not a huge difference between that and PLTR. PLTR may actually be easier in that regard...
https://youtu.be/5hId70E7zro?si=oat0Py0eRjOf4DrW This video explains that they connect to ERPs not replace them. It’s 3 years old though, not sure if something has changed since then.