It seems like more and more ISVs these days are claiming that their software is "Enterprise-class." I've never seen a formal definition of what that really means, so I'd like to offer my opinion. I think a lack of understanding in this area is something that bites a lot of companies when they first decide to build and sell software into the Enterprise market.
Enterprise-class software must:
I've seen a lot of companies who have the process backwards. They focus on feature upon feature, and the requirements above tend to suffer as a result—stability in particular is an area that is often hit the hardest. In the end, what often happens is a mad rush to make the product more stable just before it's supposed to go out the door. The QA team gets frustrated because they've been complaining all along about the problem. The dev team is asked to work evenings and weekends. Surprisingly, even in that kind of final push, I've seen projects where new features still manage to creep in—the result is never pleasant.
What's the answer? Focus on the requirements above first. Features come after that. For example, if the product starts to show signs of stability problems, then all work on new features should stop until the stability problems are resolved—regardless of when in the development cycle that happens. It could be on the very first day!
What's interesting (at least in my experience) is that teams that adopt this approach actually tend to get more done than the teams that don't. It might seem counter-intutitive, but there's something about working on a system that's always stable that seems to improve team productivity. I think instability is a big distraction for a lot of teams.
While focusing on stability might seem obvious, some of the other things on the list above might not be. Monitoring, for example, is something that I talk to a lot of my clients about. Monitoring can be used after an application is deployed to help determine why a particular client or server is broken or running slowly. Just as important, it can be used in the same way during development. Being able to quickly identify the cause of anomolies while the application is being built provides a large boost to team productivity and agility.
I'm sure my list isn't complete. If you can think of something I've left off, please let me know!