Be careful of shortcuts

We have all had that time when there is an quick and easy way to get something done and then there is a longer way. 

I always advocate the fastest, most efficient route that does not jeopardize business processes. This is mostly because in large shops the ability to audit actions against applications is about as important as actually fixing the problem. This is due to the fact that most large shops have regulatory obligations to meet certain auditing levels. Not doing so means significant penalties.

It is in these environments that taking short cuts can hurt, especially when trying to correct data issues. Now admittedly in theory validation has been all thought out via rigorous and meticulous requirements, design, coding and quality reviews. However we are all human and at least one will slip once under a blue moon if you are lucky. Hence any application should have a way to process low level business unit functionality in the form of basic update functionality or more specifically corrective action. 

I mean corrective action because by it's nature it is a transaction designed to "correct" a mistake within the business process. Yes it can be corrected via updates, inserts, or whatever, but more importantly corrective actions allow for less than a full design review and more than just a simple set of prgoram functions, scripts, SQL statements or whatever. Basically a corrective action helps to answer the question of what happens when something goes wrong. I akin it to the business processing equivalent to exception handling within programming languages. It is higher than a single coding unit but again smaller than a full business transaction. It can be as simple as combining a rollback transaction with a submit new action. However in most cases it can be a specialized set of tasks due to various business constraints. 

For many large shops, when something goes wrong related to business transactions what I call "Happy path" logic tends to be a prevailing mentality. Happy path logic means that whoever designed the processes expressed the possibility of anything going wrong as remote, non-existent, inconsequential or a combination of these with the result usually being "do something manual". This sort of reasoning sneaks in when designers look at just potential fallout with an incorrect volume baseline. For example having a .02%, yes that is point-zero-two percent, may be insignificant with a volume of say 100 test cases, but in a production application with over 600M transactions that is a pretty large number of transactions to handle manually. Even if the company has the manpower, the labor costs of such an effort is pretty darned high. 

It is remarkable to note that internet website companies have an opposite approach to most corporate applications in that they assume things will go wrong and design accordingly. From a holistic application approach such a philosophy is equally important to corporate applications as it is to the internt companies. I have been involved in far too many projects where taking just a little more time to adopt this philosophy would have saved millions of dollars over the life of an application.

So when implementing your next big project make sure to take the time to design it right. It may seem trivial or perhaps insignificant, but for any application in today's world being able to handle problems at scale is absolutely critical for success for big applications.