Some things that I think are useful for an enterprise app:
- Integrate with the organisation's authentication system, usually LDAP would suffice (sso is a plus but not really required)
- Replicate the organisation's structure (directorates, departments, job titles, who reports to who etc). Some of this may be in LDAP but usually it is not enough and you need to integrate with another system like PeopleSoft
- Auditing. Every action should be fully audited. Who and when did that?
- Very strict access to raw data (databases or servers). Be friends with the admins because you'll need them.
- No need for fancy interfaces, don't lose any time with that. A bunch of traditional request response pages would suffice. People don't really have a problem using command line interfaces without mouse supports (you navigate using tab and the fn keys)
- Error handling. Be very careful on stale data. Under no circumstances your database should be left in an inconsistent state. Especially when money is involved.
- Security is not usually a big problem because enterprise apps should be accessible only from the organisation's internal network. Many organizations use internet explorer 6 (through citrix) to access old apps. External apps are a very different thing of course.
- Web services. Forget json, rest and the like. Only way to consume or offer data to other services in enterprise is through soap based web services using wsdl.
- No open source databases. Enterprise mainly uses oracle, ms sql server and even ibm db2!
- Nobody wants to try new things unless they are offered by a big company.
If you're SaaS, enterprise doesn't necessarily care what database you're using -- and some of them may be a polyglot even internally. (My dayjob is a SaaS that's old enough to have started on Oracle in part because we thought it would make us look "serious" to enterprise clients, which include some fairly large financial institutions. We just finally turned off the last Oracle server, after switching to Postgres; no one cared.)
Unfortunately, you can't count on the enterprise's pre-existing DB to support all of ANSI SQL well. Oracle in particular deviates from ANSI in a whole bunch of well-known ways (messed-up date types, treating the empty string, '', as the same thing as NULL, etc., etc.), which are almost certain to trip up SQL which hasn't been tested against it.
- Integrate with the organisation's authentication system, usually LDAP would suffice (sso is a plus but not really required)
- Replicate the organisation's structure (directorates, departments, job titles, who reports to who etc). Some of this may be in LDAP but usually it is not enough and you need to integrate with another system like PeopleSoft
- Auditing. Every action should be fully audited. Who and when did that?
- Very strict access to raw data (databases or servers). Be friends with the admins because you'll need them.
- No need for fancy interfaces, don't lose any time with that. A bunch of traditional request response pages would suffice. People don't really have a problem using command line interfaces without mouse supports (you navigate using tab and the fn keys)
- Error handling. Be very careful on stale data. Under no circumstances your database should be left in an inconsistent state. Especially when money is involved.
- Security is not usually a big problem because enterprise apps should be accessible only from the organisation's internal network. Many organizations use internet explorer 6 (through citrix) to access old apps. External apps are a very different thing of course.
- Web services. Forget json, rest and the like. Only way to consume or offer data to other services in enterprise is through soap based web services using wsdl.
- No open source databases. Enterprise mainly uses oracle, ms sql server and even ibm db2!
- Nobody wants to try new things unless they are offered by a big company.