The perfect business application

Cost is becoming an ever increasing player on the market. Total cost, not just project cost. Time-to-market is good, but time-in-market is better, so to say

In the end, there are questions that need to be answered. 70% of those questions are asked after the go-live of a project, not during
A project might be successful but maintenance might turn out to be a disaster (or anything in that grey area in between). Fill in the blanks for a project and run, a build and test, a design and build
For the 30% of the questions that get asked during the project, the same principle applies: the farther down the chain these get asked, the more costly they are

So, how can costs be minimized? Well, just by making an existing application perfect, or by creating a perfect application

What makes an application perfect? Great ease-of-use, splendid user interaction, and availability

That is achieved by a humane (sic) approach, a fault-proof approach, and a resilient approach. The word approach is used, because there are several phases in which the timeline between beginning and end of an application can be divided. Design, build, test, run, use, maintain. The perfect application should be perfect during all those phases

• The humane approach is achieved by approaching the application as if it were our own, used only by ourselves
• The fault-proof approach is achieved by approaching the application as if it were everyone else's
• The resilient approach is achieved by approaching the application as if it were everyone's application, used everywhere

A perfect application can be measured from the end, backwards to the beginning

• Is it hard to maintain? Then the technical documentation is not complete enough, or the code is not legible enough. It is not fault-proof for the maintenance phase
• Is it hard to use? Then the presentation is not intuitive enough, at least not for the users that have to work with it. It is not humane for the use phase
• Is it hard to run? Then the technical operation is not easy enough, or too costly. It is not humane nor fault-proof nor resilient for the run phase
• Is it hard to test? Then the functional design is not clear enough, or the technical design is way off to the functional design. It is not fault-proof for the test phase
• Is it hard to build? Then the technical design is not clear enough, or the functional design not clear enough in order to draw a technical design. It is not fault-proof for the build phase
• Is it hard to design? Then the business specifications are not clear enough. It is not fault-proof for the design phase

Everything starts with the business specifications. They draw the lines for the business application that serves a business goal

It seems that the overall answer is easy: every question needs an elaborate and documented answer as soon as possible, and it all starts with the business design

• For every business rule, there is a business exception. Embed that into the business specifications, so the scope is clear
• In the functional design: for every business rule, there is a functional exception, and an appropriate user interaction message. Embed that into the functional design
• In the technical design: for every functional rule, there is a technical exception, and an appropriate user interaction message. Embed that into the technical design
• In the build: for every technical rule, there is a technical exception, and an appropriate user interaction message. Embed that into the build

Is this rocket science? Certainly not. Are details of this overlooked every now and then? They sure are
Is this a handy checklist? I sure hope so.