Product-based Solutions Versus Custom Solutions : Tomb Raider or Genesis?

The Product-based Solution is where most of Corporate America is going for IT today.  The talent required to povide a successful implementation (one you actually renew license maintenance on rather than let let quietly die an ignominious death) requires the tenacity, deep specialized product  knowlege (read arcane dark arts), and courage of a cinema Tomb Raider.  The team required has to know the target product as well as Indiana Jones knows Egyptology; with equivalent courage, problem-solving skills, and morals (one can’t be squeamish hacking a solution into submission) to be able to achieve a usable solution versus an embarrassing product snap-in.   In addition to their product skills the team must be able to quickly navigate the jungle of existing applications with their mysterious artifacts to get the proper integration points and data (Gold! Gold! I say!).

What if the team can’t or don’t navigate your jungle of existing applications or do not know all of the idiosyncracies of the product to be installed?  Well you get an Embarrassing Product Snap-In (Do Not Pass Go, Do Not Collect $200, Do Flush Career).  Every seasoned IT professional has seen one of these puppies, they are the applications you can’t get anyone to use.  Usually because the do not connect to anything users currently work with, or have real usability issues (Harry Potter vs. MIT interface).  Yes, the product is in.  Yes, it tests to the test plan criteria.  Yes, it looks like post-apocalypse Siberia as far as users are concerned (What if we install CRM and no one comes? Ouch! no renewal for Microsoft/Oracle, bummer).

Custom Solutions are more like Genesis, Let there be Light! (ERP, CRM, Order-Entry, you get the picture).  It is a Greenfield Opportunity!  The team you need is just as talented as a Product-based Solution, but very different.  They need to be able to create a blueprint of your desires, like a rock star architect for a signature building.  The team needs to be experts in software engineering and technology best practice.  As well, the team needs to be able to translate your user’s meandering descriptions of what they do (or not) into rational features resembling business process best practice.  That was Easy!

In the case of custom the risk is creating Frankenstein, rather than new life (It’s Alive!, It’s Alive!).  Again, every seasoned IT professional has seen one of these embarrassing creations (Master, the peasants/users are at the gate with pitchforks and torches!).  The end result of one of these bad trips (Fear and Loathing in ERP) is the same, but usually more expensive, than the Product-based alternatives.

Debby Downer what should I do?  Reality is as simple as it is hard; pick the right solution for the organization, Product-based or Custom.  Then get the right team, Tomb Raider or the Great Architect of Giza.

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, SalesForce.com) 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!).

If you’re thinking of acquiring a software startup

IT due diligence on a software startup may seem unnecessary if the core product offering represents a significant new advancement.  It really can’t be overlooked, however, as there are many technology risks lurking within the product and within the company itself.

As far as the core technology offering(s), it’s important to conduct code reviews, architecture reviews, security audits, application performance assessments (especially in light of the projected growth in the business plan) and an assessment of the company’s software development lifecycle methodology.

There are other hidden risks, some of them far removed from the core product offering, that may impact your future acquisition’s ability to achieve its goals.  Many of them stem from the need to be both chief cook and bottle washer during the very earliest days of the company’s existence. Here are the top three:manyhats1

  1. Inappropriate software development practices: My favorite example here is a startup I was advising during its search for first round investors. They could not resist the urge to keep “improving” the code, so they never segmented or froze their brainchild into discrete releases. The night before I had scheduled a potential investor for a demo, they thought of four new “must-have” features to add, and were actually debugging during a demo that failed to execute.
  2. Tendency to re-invent the wheel: Software entrepreneurs are often skeptical of packaged enterprise software to the extent that they will build their own backoffice, CRM, or other applications. The risk this imposes to potential investors is twofold: you are retaining dedicated staff to support those applications, and any migration off of these applications may be difficult because they are often built “on the side” without sufficient documentation.
  3. Project management immaturity:  It’s unusual for a startup to hire real project managers very early on in their lifecycle. While PM discipline could certainly help them during the concept phase, it’s absolutely necessary as they are attempting their first deployments to clients.  Weaknesses in this area are easy to spot as you conduct due diligence interviews with their customers.

So even if the product has no competition in the market place, and you’re convinced it can sustain competitive advantage, please make sure you have qualified resources do some deep probing to help you understand where the hidden problems may lie.

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 Salesforce.com, 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.