Is Custom Development Dead?

Is Custom Development dead? After the last two years of custom development’s nuclear winter, (following 2008s Financial Armageddon), one would think the the Grim Reaper did his best in the blast. I really hope not, designing and building strategic systems make the more mudane aspects of software engineering worth enduring the mind-numbing syntactical pain of creation. Nothing like the smell of napalming the competition with a totally new way of doing business in the morning (my view of “Apocalypse Now” with a business bent). Maybe, just maybe, I hope rumors of Custom Development’s death are greatly exaggerated.

Did Custom Development die of natural causes, maybe pulled off of life support by risk-hating Executive Management as a perverse form of parental control after the financial snafu (Custom Development moves from PG-13 to XXX)?  Off-the-Shelf software products and the ever increasing cost of continuing maintenance really hurt Custom Development as a viable systems choice, but is that enough to put it down? Cloud and “nouveau Cloud” technologies (read SaaS, may have provided the coup de grace.  I seriously doubt it, every time I look into the Cloud I get serious PTSD flashbacks to the 70s and 80s IBM Mainframe World Domination (OMG there is a 3270 in the corner!!).  At least there was alot less hype and easier choices back then (Nobody got fired picking IBM!).

It is possible Custom Development died offshore (simple Mickey Finn, bag over the head, Shanghaied and Held for Ransom!)?  While Business Processes and System Maintenance have done reasonably well offshore (Castor Oil of the Corporate world, let Mikey take it!), strategic custom development has had less success.  Quality innovation that can transform a corporation really requires a local team steeped both in the host company and surrounding culture.  Plus, Custom Development tends to have a high infant mortality rate so it is best attempted in short phases supported by an Agile Methodology, definitely not in Offshore’s financial model wheelhouse.  So I don’t think Offshore is implicated.

There is the theory that evolution has spoken and Product-based Solutions have succeeded Custom Development, just as mammals succeeded dinosaurs.  Product companies would like you to believe that, but does that seem plausable (Land of the Lost, Jurassic Park where are you?)?  While Product-based solutions have advantages in success rates and cost, they by their nature lack the true freedom that drives raw creativity and innovation.  Custom Development is that wellspring.

The only thing we have to fear, is fear itself!  Adversity to risk is curbing animal spirits, creativity, and innovation, ….for now.  Custom Development is not dead and will return from its vacation with Puff in the Cave by the Sea when Jackie Paper locks-and-loads and we begin some serious innovation and transformation with strategic custom software systems (BTW thats when the Jobs return too!).

Taking the Plunge into SaaS

saas-penguinUnder pressure to reduce IT budgets, many businesses will make their first attempts at implementing Software as a Service (SaaS) in 2009. While there are real savings to be gained by phasing SaaS into the enterprise architecture, careful planning can help steer around some of the common difficulties.

1. Start with a realistic assessment of your application portfolio to determine where your best SaaS conversion options lie. Customizations are a complicating factor when moving to the SaaS model. It can be done, but manage expectations within the business aggressively to let them know that the SaaS solution will be implemented as close to out-of-the-box as possible.  Your first attempts at moving to SaaS might be best steered towards the applications with fewer points of integration, as these will complicate the implementation (see point #3, below).

2. When doing your initial scan for SaaS solutions, make sure you have second sources lined up for each application, and thoroughly vet out the differences in their offerings from the application functionality, service offering, and cost perspectives.

3. Model your integration points rigorously. Identify all possible interface failure points and document exactly who is responsible for identifying and fixing these failures. Include the failure scenarios in your SaaS migration test plan.

4. Service level agreements are key to making the relationship work. Even some of the oldest SaaS offerings, such as, have outages from time to time that leave users high and dry. Every service component needs several service level agreements explicitly defined in the contract. These include:

  • Application uptime as well as maximum length of downtime per outage episode
  • Time to resolve trouble tickets by email and by phone
  • Required advance notification for scheduled maintenance outages

5. Pre-sale due diligence is not enough. The Satyam scandal has taught us that. Use every means available to stay ahead of news on all your SaaS partners, including monitoring twitter, technorati, Google alerts, and traditional media for hints that they might be experiencing customer satisfaction or business issues that could impact the quality and longevity of their service.