

Ask HN: What does “enterprise software” get right? - christensen_emc

I hear a lot about how enterprise software can learn from startups, is there anything startups can learn from enterprise?
======
6502nerdface
Having built a number of systems for a medium-large enterprise, I often chose
to build on solutions from "enterprise" vendors because they had the best
answers to these questions:

\- 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)

------
mindcrime
This strikes me as false dichotomy. "Startups" and "enterprise software"
aren't two different things. There are, for example, startups who are vendors
_of_ "enterprise software".

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.

~~~
AnimalMuppet
To add to point 1: Let's say the customer is a bank. They cannot lose track of
even one penny, or they're in regulatory trouble. Your software had better be
up to that level of not losing data.

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.

~~~
greenyoda
Both of the above comments are great answers from the technical point of view,
but I'd like to add one more thing: customer service. When people pay a lot of
money for enterprise software, they expect to be able to get competent and
timely help for their questions and problems. A startup that sells products or
services to businesses might need to learn something about customer service if
they want to be able to compete with established players in their field.

~~~
matt_s
Customer service is important especially for tech support. However with some
enterprise software, like ERP systems, you achieve the Vendor Lock-In trophy
pretty quickly after implementation so you may find this to be something a
startup can be very disruptive about: responsive and helpful customer support.

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".

------
MichaelCrawford
wealthy consultants.

