No, I am not going to talk about how to design a system, I am going to take it as granted that you are aware on all the traditional checklists for good design and are actively applying them. What I wold like to talk about are the parts that a lot of people tend to forget until they find out about it after the system is already at the hands of the users.

I am going to talk about Rhino Security as an example to that. The predecessor for Rhino Security was a proprietary piece of software that worked on top of some incredibly confusing set of business rules. (You may not see a product vNext if you have a contract for vPrev in the last year over some dollar value, as an example). Rhino Security's design was heavily influenced by that project, including the inclusion, as a first level concept, of the "explain the reasons for this security decision". The hours I spent debugging the security system only to find out that it was absolutely correct has thought me that much, if nothing else.

So the hooks for make the system understandable are built in, they are explicit and the design and are a major advantage when it comes the time to implement, experiment and deploy the system.

Another important concern is handling errors, logging, tracing and alerts are all important concepts. Do you have a backup procedure? Do it have a way to SHOUT that the backup have failed? Do you have scheduled jobs? Do you get NOTIFIED when they do? (A lot of the problem in software occur when a scheduled job hasn't been running for three months straight)

You ask the system to do some operation. In any sort of non trivial system, figuring out why it reached this decision is as important, if not more so, than the decision / operation made. Do you plan for that? Logging isn't it. I am talking about planing for that at the infrastructure and operation levels, exposing this as a first level ability/feature in the user interface and making this visible. Give the user control over what the system is doing. You'll find that the level of understanding that they gain from it will enable them to get a far higher productivity.

As an aside, it is extremely helpful in troubleshooting, but that is beside the point.

Is your system stable? Stable in the sense that new features don't break old ones, that deploying a new version is a straightforward process. Stable in the sense that the approaches you take in the beginning of the project are stable enough to last the lifetime of the project (another way of putting this, avoid hacks in the infrastructure).

The development environment. Have you given it any thought? Do you have a well defined process for developing new functionality? (Well defined process == you have thought it out, not documented it in excruciating details). Did you consider the source control story? Did you consider the ability to split the system into independent parts?

Versioning concerns - do you need to run in a multi version environment? Do you need to support just upgrade from old version?

Tracing / auditing - this is BAM, but I don't like the term. Do you have the ability to see what the system is doing?

As you can see, we have a few separate grouping here. One is visibility and transparency of the system, second is operational issues, and last is the developer environment story. I find that all too often people are ignoring those issues completely, in favor of complete focus on architecture and application design. Those are important, but they are only part of the story.