There's a world of difference between a prototype hammered out over a weekend, and an enterprise app ready for the harsh world of production. Here's a somewhat random brainstorm. In general (there's always an exception), Enterprise apps:
- Are scalable - they handle large loads and can be called many times.
- Have a retry strategy - for example, it tries pinging the external service three times before "failing".
- Have a failover strategy, like an active-passive machine cluster for maximum uptime, and a disaster recovery site.
- Send notifications.
- Handles invalid data (like states, zip codes, and numbers).
- Can integrate with other systems (perhaps providing web service wrappers, or command line APIs, or publicly accessible data repositories that other apps can modify) .
- Are deployable - "it works on my machine" absolutely does not cut it.
- Have Logging - this is especially useful for debugging in production, or measuring how many errors (and which types) are thrown.
- Have long-running process (hours, days, or even weeks) - not just a single thread in memory.
- Have async processes, which usually means concurrency and threading problems.
- Support multiple instances of the app running. You can open two copies of word, or run two MSBuild scripts at the same time.
- Handle product versioning.
- Care about the hardware it's running on (enough CPU and memory).
- Have a pluggable architecture - You may need to switch data providers (Oracle/SQL/Xml).
- Have external data sources (web services, ftp file dumps, external databases).
- Can scale out, such as adding more web servers, or splitting the database across multiple servers.
- Have security constraints (both hacking, and functional).
- Have process that are documented (not just for training, but also for legal auditing and compliance issues).
Much of this code isn't the fun, "glamorous" stuff. However, it's this kind of robustness that separates the "toys" from the enterprise workhorses.
See also: Enterprise Data Access, Enterprise Caching
Post a Comment