This made me realize that there’s a distinction hiding in “Enterprise software”, between
In-house software serving generic business functions for large companies (payroll, etc).
Reusable (typically SaaS these days) software sold to enterprises, whether it’s handling one of those generic business functions or not.
Both have some features in common–the buyers are often very checklist driven, the end users may not be the ones choosing to buy the software, etc. In spite of that, there are differences. The old examples of object modeling with “Person” and “Employee” classes, or talking about creating a grand unified database for the entire enterprise are part of #1, not #2. So although I work in enterprise software, I’ve never dealt with that.[0]
[0] My primary codebase does have a Person object, but no Employee object, and the Person object really is a poorly named container for contact methods.
This made me realize that there’s a distinction hiding in “Enterprise software”, between
Both have some features in common–the buyers are often very checklist driven, the end users may not be the ones choosing to buy the software, etc. In spite of that, there are differences. The old examples of object modeling with “Person” and “Employee” classes, or talking about creating a grand unified database for the entire enterprise are part of #1, not #2. So although I work in enterprise software, I’ve never dealt with that.[0]
[0] My primary codebase does have a Person object, but no Employee object, and the Person object really is a poorly named container for contact methods.