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!).

Best Practice: Cloud Computing

Red sky at morning, sailor take warning.

Here’s a forecast: clouds are rolling in. Architecting for cloud computing will, very soon, become a conscious best practice.

There are lots of handy objections to Cloud Computing: Regulatory compliance, geographic containment requirements, taxes, liability, vendor lock-ins and lack of standards. Many are brushing off cloud technologies as a result, and maybe rightly so… for about another minute, anyway.

Last year, I was involved in a client’s effort to re-provision an application from an in-house infrastructure to a SaaS vendor. All told, the effort was risky and enormous. The administration of it took a year. It took a team of talented engineers from several different companies over six months to implement the transfer. When it was done, everyone breathed a sigh of relief.

The amazing part was that it wasn’t about changing applications. It was just changing who hosted the application. Simply put, no one had the fore-sight to architect for a transition of this nature, and so the ROI was heavily diluted.

Market fluctuations, re-focused specialization, business units changing hands, economic right-sizing, disaster recovery; there are many reasons agile infrastructures can be useful. Cloud computing technology is evolving quickly and has the very real potential to offer agility at a dramatically lower cost, if you’re prepared to leverage it. You don’t have to go in to the cloud to see what you might gain from it. The important part is preparing for it so you can use it when it makes sense for you. And, you could even go green at the same time.

I won’t try to predict what your organization has to gain by architecting around cloud technology. It’s more about what your organization is at risk of losing if you don’t.

Cloud Computing Trends: Thinking Ahead (Part 1)

The aim of this three part series is to gain insight into the capabilities of cloud computing, some of the major vendors involved, and assessment of their offerings.  This series will help you assess whether cloud computing makes sense for your organization today and how it can help or hurt you. The first part focuses on defining cloud computing and its various flavors, the second part focuses on offerings from some of the major players, and the third part talks about how it can be used today and possible future directions.

Today cloud computing and its sub-categories do not have precise definitions. Different groups and companies define them in different and overlapping ways. While it is hard to find a single useful definition of the term “cloud computing” it is somewhat easier to dissect some of its better known sub-categories such as:

• SaaS (software as a service)
• PaaS (platform as a service)
• IaaS (infrastructure as a service)
• HaaS (hardware as a service)

Among these categories SaaS is the most well known, since it has been around for a while, and enjoys a well established reputation as a solid way of providing enterprise quality business software and services. Well known examples include: SalesForce.com, Google Apps, SAP, etc. HaaS is the older term used to describe IaaS and is typically considered synonymous with IaaS.  Compared to SaaS, PaaS and IaaS are relatively new, less understood, and less used today. In this series we will mostly focus on PaaS on IaaS as the up and coming forms of cloud computing for the enterprise.

The aim of IaaS is to abstract away the hardware (network, servers, etc.) and allow applications to run virtual instances of servers without ever touching a piece of hardware. PaaS takes the abstraction further eliminates the need to worry about the operating system and other foundational software. If the aim of virtualization is to make a single large computer appear as multiple small dedicated computers, one of the aims of PaaS is to make multiple computers appear as one and make it simple to scale from a single server to many. PaaS aims to abstract away the complexity of the platform and allow your application to automatically scale as the load grows without worrying about adding more servers, disks, or bandwidth. PaaS presents significant benefits for companies that are poised for aggressive organic growth or growth by acquisition.

Cloud Computing: Abstraction Layers

So which category/abstraction level (IaaS, Paas, SaaS) of the cloud is right for you? The answer to this question depends on many factors such as: what kind of applications your organization runs on (proprietary vs. commodity), the development stage of these applications (legacy vs. newly developed), time and cost of deployment (immediate/low, long/high), scalability requirements (low vs. high), and vendor lock-in (low vs. high). PaaS is highly suited for applications that inherently have seasonal or highly variable demand and thus require high degree of scalability.  However, PaaS may require a major rewrite or redesign of the application to fit the vendor’s framework and as a result it may cost more and cause vendor lock-in. IaaS is great if your application’s scalability needs are predictable and can be fully satisfied with a single instance. SaaS has been a tried and true way of getting access to software and services that follow industry standards. If you are looking for a good CRM, HR management, or leads management system, etc. your best bet is to go with a SaaS vendor. The relative strengths and weaknesses of these categories are summarized in the following table.

	App Type Prop. vs. Commodity	Scalability	Vendor Lock-in	Development Stage	Time & Cost (of deployment)
IaaS	Proprietary	Low	Low	Late/Legacy	Low
PaaS	Proprietary	High	High	Early	High
SaaS	Commodity	High	High	NA	Low

Cloud Computing: Category Comparison

Taking the Plunge into SaaS

Under 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.