This one is a spin-off from my last post on Captain Gopinath's book, 'Simply Fly',  which provides a shot in the arm for any wannabe entrepreneur and also a lot of food for thought.
For those not in the loop,  Captain Gopinath is the man behind India's first ever low cost airline called Air Deccan.  Prior to Air Deccan, he was running India's largest helicopter charter company called Deccan Aviation.   Air Deccan was launched amidst much speculation that a concept such as that of the low cost carrier would never work in India.  Captain Gopinath and Air Deccan proved detractors otherwise and within a very short period of time,  picked up tremendous momentum.
However,  things started going awry when Air Deccan started gaining a reputation as an airline that failed to live up to its promises especially with respect to punctualitiy and and reliability.  Each delayed/canceled flight meant more bad publicity.  People, including Captain Gopinath largely attributed the logistical failures due to a very strong and sudden expansion  and the software systems they used were largely deemed responsible for the chaos. 
I however think that there was more than glitches with the software that brought Air Deccan down, that the die was cast much prior to the first observed failures of the software, with other mistakes being committed.

I believe that these mistakes when understood properly can help upcoming entrepreneurs to avoid them, as forewarned is being forearmed.
'Fact' refers to information provided by the book, 'General Inference' points out what was perceived by the author/general public , the 'Analysis' is my take on the matter and 'Lessons' are what I feel are points to be noted.


Fact: The contract for developing the software for eticketing (online ticketing) for Air Deccan was given out to a company with no prior experience of developing software for airlines.
General Inference: It was suicidal to not hire the experts.  The software was doomed from the word go.
Analysis: Awarding the contract to a upcoming vendor would have been termed a shrewd move,  one which saved the company millions, had there not been a failure(s),  but reposing full faith in a hitherto unknown company is generally extremely unwise,  no matter how slick their presentations might be.   One could try out a new vendor by putting them onto the development of a small, non-critical module/component for an existing solution or on a standalone software but never onto mission-critical components of the application, let alone the entire application.
Lessons:  Unless you are a charity for upcoming software companies or don't mind losing vast amounts of money in the long run,  trust only established and reliable vendors with orders for their proven software or for mission-critical software development.   The short-term cost difference may be high but it will more than pay itself off in the long-run.  If you wish to use unproven software vendors, use them to develop non-critical 'eye-candy' applications which you can evaluate at length before handing them meatier responsibilies.

Fact: The eticketing software started underperforming and becoming unreliable as popularity/demand started increasing.
General Inference:  The software was substandard and hence the underperformance.
Analysis:  While it appears extremely likely,  this 'fact' cannot be easily proved.  While the failure/underperformance of the software is undisputed,  the reason for the failures/underperformance need not just be substandard software.  It could be a lot more sinister.
A denial-of-service attack (http://en.wikipedia.org/wiki/Denial-of-service_attack), a kind of malicious online activity aimed at crippling certain services, mounted by or at the behest of a competitor could well have the same results. 
Lessons:  The cause needs to be ascertained accurately before attempting to find solutions.

Fact:  AIr Deccan did not have cyber-security/network-security experts on it's payroll.  The only experts were those working for the vendor they had hired.
General Inference:  Money was tight and costs had to be cut.
Analysis:  If hiring a rank newcomer vendor to develop mission critical software was a bad idea,  not having even a single cyber-security/network-security  expert permanently on the payrolls of Air Deccan was an even worse idea.  By doing that,  they were not cutting costs: they were cutting corners,  crucial corners at that.   A network security expert would be able to analyse access patterns and logs and would be able to almost instantly differentiate malicious elements from genuine users,  and provide/deny services accordingly.  A good network security expert can fend off a denial-of-service attack while ensuring that genuine users are not inconvenienced.  Even software of the highest pedigree running on the highest-end servers can come crashing to an abrupt halt, in the absence of an alert network admin, when struck by a denial of service attack.  This meant that Air Deccan could just not afford not to have it's own network/cyber security expert.. 
While a layman like my father need not be aware of the nitty-gritty of denial of service attacks,  an entrepreneur with a business model relying heavily on software components and the internet cannot afford to be unaware.  Any consultant worth the money would have outlined the risks involved and would have recommended having a cyber security expert on the rolls of the company.  If Air Deccan was not so advised,  it's only because they chose a very poor consultant, meaning they were damned.  If they were so advised and chose to ignore it trying to cut costs,  they were doubly damned.  If they'd never hired a consultant trying to cut costs,  they certainly were worse than damned! They were doomed!
Lessons:   Any business with a business model involving online transactions should have a full time network/cyber security expert on it's permanent roles.  If you don't have this expert, don't run the software.


Fact:  Air Deccan possessed neither physical access to the servers nor admin/root/super-user privilege for the software systems.  Crucial transaction data (details of tickets sold and advance reservations) were lost when Air Deccan were forced to change softwares.  This led to utter chaos with each seat on several flights getting sold to multiple passengers.   Further the vendor used  the data related to flight routes and reservations which were available to him  to hurt the interests of Air Deccan.
General Inference: It was assumed to be the duty of the company handling the software development to manage the servers and the day-to-day operations/maintenance of the software.
Analysis:  While Air Deccan bought aircraft from Boeing,  it relied on it's own pilots to fly the aircraft,  so why should it be different for software?  Day-to-day management and administration of the software ought to have been done by in-house staff. while software developers could be entrusted with access to systems and hardware only during scheduled maintenance,  upgrades or during recovery from catastrophic failures.  This would also ensure better data security which minimizing chances of data misuse.  If physically hosting the servers was not a viable option,  secure facilities were available as a commodity resource and could have been hired.  A database adminstrator who could take regular backups of transaction data also had to be on the rolls of Air Deccan.
Lessons:  If a business has sensitive data,  day-to-day operations of its software system and it's maintenance should NEVER be entrusted to any external entity.  Appropriate staff need to be hired and if necessary, trained under the developer,  to effectively use the software system. A database administrator who can take periodic backups of transaction data is extremely vital as the backups are invaluable.  In the Air Deccan case, if they possessed current backups of transaction data,  porting that across to the new software would have required minimal effort and all the confusion that subsequently ensued could have been completely avoided.

Being a software guy  I couldn't miss these glaring errors even if I wanted to,  but they are probably a lot less obvious to those without practical knowledge of software deployment and the issues associated with it.   In Captain Gopi's case,  these mistakes were as damaging to his enterprise as anti-airfcraft guns would have been, against his planes.   I'm sure there were other reasons and factors,  but these were what seemed to stand out the most, at least to me.    Even if these problems might not have directly sunk Air Deccan,  they were instrumental in undermining Air Deccan's reputation which led to decreasing incomes which then led to the requirement for external investments to weather the crisis  which eventually led to the inflow of Mallya's money and that, if nothing else, was the beginning of the end.  Before long,  it was all over.

To sum it all up,  any serious entrepreneur whose business model involves transactions over the internet ought to consider these points which pop out when one goes through Capt Gopi's 'Simply Fly' with a critical eye,  looking out for mistakes that can wreak havoc upon enterprises:-

1) Hire a good consultant to study your business plan and make recommendations about the software, hardware and manpower investments that you need to make.
2) Choose your vendors carefully, going by the advice of your chosen consultants, industry feedback and your own judgement.
3) Don't be wildly adventurous and hope for miracles.   A healthy dose of exuberance is nice, but too much of it means your drunk!  Get sober!
4) Hire a full-time network/cyber security expert.  An absolute must.
5) If your software stores data in a database,  you need to hire a full-time database administrator.  An absolute must.
6) Ensure that the hardware i.e servers and peripherals are on your site or if not,  at a commercial hosting site with you and only you having physical access to the servers and admin/root/superuser access to the software. 
7) Ensure you have staff capable of operating the software on their own.
8) Restrict access to the servers/software to your software vendors, allowing them access only as required like during crucial upgrades and failure recovery.