Ask HN: What does “enterprise software” get right?
I hear a lot about how enterprise software can learn from startups, is there anything startups can learn from enterprise?
- will it integrate easily with our existing LDAP database of users and groups?
- can it authenticate users using our existing Kerberos infrastructure, via SPNEGO, HTTP Negotiate, or whatever is appropriate?
- were authentication and authorization more than afterthoughts in its design? Is authorization fine grained enough?
- can non-technical users administer it without bugging me all the time?
- if it needs to talk to the outside internet (updates, plugins, whatever), can I make it do so through a Kerberos/Negotiate authenticating HTTP proxy that MITMs everything? Will its outbound requests leak sensitive internal information (Referrer headers, internal host names, etc.)?
- can I get a license for perpetual use, with source code? (If the vendor goes bankrupt, at least I still have the source)
That said, to the extent that I kinda get what you're asking, I'd say that software typically classified as "enterprise" tends to excel at certain things:
1. Stability. Now this ideal isn't held up as much as it used to be, but for the most part, high quality enterprise systems are designed to never go down, or if they do go down, they have failover mechanisms or some other means of making sure that transactions don't get lost, etc. There's definitely a dichotomy here in terms of pushing for the opposite of "move fast and break stuff" in that "breaking stuff" is not supposed to happen and people are willing to sacrifice some nearness to the bleeding edge, in order to not break systems that the business depends on.
2. Integration. Many "enterprise" systems live in complex environments that have accreted all sorts of cruft and complexity over the decades, possibly as a result of mergers and acquisitions, regime change, etc. As a result an "enterprise" system often has to be able to "talk to" a HUGE array of disparate systems with many protocols, formats and interfaces.
3. Flexibility. Rule #1 is "business requirements change". And when the requirements change, the software has to change. This is why "enterprise" systems have things like the oft-derided "incredibly dense XML configuration files that allow the system to be reconfigured to do something completely different" or have embedded programming languages built right into the system, or have radically denormalized database schemas, etc. It's all about making it possibly to mold the system to fit the new requirements without having to rewrite it from scratch.
Of course, as you can imagine, when you combine those factors, you can get some pretty complex, impenetrable and obtuse stuff as a result. This is largely why "enterprise sofware" gets a bad name. But really, it's all about trying to write software to deal with the messy complexity of the real world.
Anyway, what can a startup learn from that? Well, I think all three of the factors mentioned above are actually important for any software company / service. It's just a question of how much you weight each one. In theory, if you're building a "cat sharing photo social network site", then maybe you don't need the same degree of stability as if you're building the order processing system for Amazon.com. But if your site is down too often, your users will gravitate to some other site. You can probably work out how the other factors have to be analyzed in similar fashion.
Similar to your points 2 and 3, I would say "customizability". Customer A wants different things than customer B, because A has a different set of other systems it has to integrate with, and a different set of procedures built around those systems, and lives in a different regulatory environment, so they have different reporting requirements...
I would add one other point: Scalability. Enterprise software can't depend on any one computer being up, or any one data link. It needs to be able to cluster, and failover, and replicate data between clusters. It also needs to be able to handle large amounts of throughput, and enormous data tables, and so on.
A typical scenario may play out where you have to put a ticket in, wait for a rep to contact you and they ask basic info, log files, etc. then it gets handed off at shift change to another rep, then you need to escalate to a manager who actually knows stuff and can solve your problem quickly.
Not all vendors are like this though. If it is software you have built - a good policy would be to have the software committers rotate into tech support shifts regularly. Can you imagine the joy a frustrated IT admin would have if the customer support person has the right answers quickly? Or utters the phrase "yeah, I helped write that module, let me look at your log files and we'll get to the bottom of this".