Sorry for the delay in posting, but I’m been flat out here in India as I am getting further up to speed with my new role at Ness Technologies Software Product Labs. Now that the excuses are out of the way, let’s get to the Top 10.

1. I’d be remiss if the first one out of the gate wasn’t the public announcement of Ness SPL’s relationship with travel IT giant Amadeus.  For the past year Ness has built an engineering team in Bangalore, supporting Amadeus’ continued investment in building industry leading software products for the travel industry.  It also signals Ness’ focus on providing software product engineering services to the travel industry.  If we can deliver for Amadeus, we can deliver for anyone.  Call me!
2. GM’s Augmented Reality Windshield: This is potentially very cool. Nice that it can highlight road signs, but better if it could superimpose hi-fi versions of signs I can’t see clearly.  Also the ability to check out where the drivers eyes are looking could be potential liability issues for drivers who crash while texting, dialing or otherwise distracted.
3. Google May Leave China on April 10. I can’t imagine they want to really do this, but their public stand has kind of boxed them in a corner.
4. Priceline Introduces Pay-at-Checkout for hotels.  I guess I didn’t realize that with online travel agencies (OTAs) that you had to pay the hotel fees at the time of booking.  I guess I never booked a hotel through an OTA because this seemed like standard operating procedure.
5. Musings from the Mobile Upfront: Recap from Mobile Upfront and insights from mobile guru @tgruber
6. Security Risks of Multi-tenancy.  Just goes to show that architecture in the wrong hands is dangerous and usually that’s at the core of bad software.
7. Cloud killing the enterprise software market? Hold that thought. I agree that there will probably be a lot of private/hybrid-cloud implementations, although don’t believe that’s a very good strategy, other than trying to recoup existing infrastructure investments.  It’s one thing to get leverage from what you already have, but let’s hope that few are actually thinking about buying a bunch of hardware to build-out new private cloud infrastructure.  This makes me think back to a post from last summer: Who will be the first to offer cash for infrastructure? I still think it’s a good idea.
8. Why RedMonk’s @sogrady is against patents – the system is broken.  But what if the system could be fixed. Then again this is an awful lot like tort reform. Too many special interests to make it happen and too many frivolous lawsuits/patents.
9. Webciety and Enterprise 2.0: A snapshot of today’s social computing conversations.  Notes and perspective from CeBIT on the opportunities and concerns about E20 by the one and only Dion Hinchcliffe
10. Enterprise 2.0: efficiency, effectiveness, blame and responsibility.  More good hard truth from Dennis Howlett.

There was a lot written in the past few days about the service interruptions with Gmail, so let me add my two cents.  In my mind there was a significant over-reaction to the Gmail Fail, mostly by people who for some reason or another are anti-SaaS or anti-Cloud.  I wish someone would do some sort of psychological analysis of that crowd (are they contrarians, do they fear the impact to their own jobs, uniformed), but that’s not going to be the topic of this post.  While many people made like Chicken Little, I think that most drew the wrong conclusions. I look at it like this:

• Gmail isn’t just personal mail: It highlighted how many people are using Gmail for what they consider business-level communication, not just personal email.  With some what I’ve seen regarding Google Wave, this could be a very interesting development and something I’m sure the folks in Redmond are concerned about.
• There is Value in ‘Commercial-Grade’ Release Processes: There is a flawed theory used in much of the online application world which believes that being in perpetual beta is OK.  It’s not.  I understand the desire to get new products and features out to market right away, but letting your users be your testing team — unless it’s a structured beta — is not the right thing to do.  Software companies need to test their products appropriately before releasing it to clients. There is value to a ‘commercial-grade’ release process.  And it’s not like a structured release process means slow time to market. Agile development methods support rapid releases and are pretty mainstream these days. Speed does not excuse sloppiness.
• SaaS and the Cloud Require a Systems Engineering Perspective. Architecture and application design – not just testing – for performance, scalability, reliability and availability is critical. And note that people always talk about PSR testing, not the “A” for availability, which in and of itself is a big miss in thinking about designing and developing systems that are meant to be used by large user communities in unpredictable ways.  But it runs deeper than that.  SaaS requires a systems engineering perspective. It’s not just the software that gets developed it’s how we think about how that software interacts with the underlying infrastructure and how together they deal with internal and external threats — security vulnerabilities, natural disasters, disaster recovery, etc.

Lastly, some of the people I discussed this with have argued that SaaS or Cloud is a good backup to traditional software systems.  It’s not.  SaaS is a choice…and an alternative to other on-premise software. But you don’t choose an Email or CRM or ERP system as a backup to a separate primary system. Of all the issues around SaaS, integration is perhaps the biggest.  So who’s going to take on all those headaches for a something they plan to never use?  Nobody.

A couple of article caught my eye and thought to make sure you saw them:

• 14 Reasons Why Enterprise 2.0 Projects Fail: Good post by Dion Hincliffe, who’s one of my favorite E20 reads.  There were a couple of no brainers on the list like picking the tools before you have a strategy, but also a few that stimulated some thought.  #6 related to delays by IT.  Even at my current company, we started our blog using Hubspot rather than Wordpress because I couldn’t get IT to install it.  Yet it took me all of 6 minutes to get this blog up using BlueHost.  Why can’t IT departments help enable E20 activities by creating automatic scripts to install and provision instances of Wordpress, T-Wikis and other tools the way BlueHost and others do it?  It can’t take that much effort up front, but it would remove a lot of hurdles that slow down E20 adoption.  Seems like that would be a no brainer too.
• Forecasting the Winners in the Cloud Computing/SaaS Market by InterWest Partners’ Bruce Cleveland
• Packaged software, an accident of history: Who new? Interesting. What might the software industry have looked like otherwise. Once again, activist judges at work

I don’t think so.  At first when I saw the story on TechCrunch I thought there was going to be an exciting announcement — something that was going to help open up the Force.com platform in a way that would drive greater adoption of what’s probably the most mature Platform-as-a-Service (PaaS) offering out there.  But much like the Force.com Sites announcement there’s little here to create any excitement.

More importantly, there’s nothing here that makes the platform more inviting to port existing applications from ISVs from the on-premise versions to on-demand.  For all the efficiency that the APEX language and their platform allow, there’s still nothing that makes it easy to move an application to Force.com and, in the unlikely case of a Coghead-like ending, nothing to make it easy to move the application and the data (and this does not even consider all the valuable meta data and clickstream information, but that could be another post on it’s own) back out to another platform — either on-demand or on-premise.

Geva Perry is starting a series called “The Purpose-Driven Cloud” where it appears that he’s trying to address the aforementioned question by evaluating a number of different attributes that are all technology-centric.  It looks like it should be a worthwhile discussion, although it’s mostly written from a developer’s point of view.

But I think his angle is missing some important elements (although in fairness they may get addressed along the way) that are more customer-driven and business-driven:

• Suitability to task: What is the kind of application that you have?  Is it primarily workflow and transaction oriented like an ERP application or are you doing heavy number crunching and using complex algrorithms like a pricing credit default swaps?  Some cloud platforms like Force.com are great for the former, but wouldn’t be good for the latter. And if you are accessing data frequently, cloud storage options like Amazon S3, might not be the right selection.
• Data and Code Portability: When you are deciding what cloud platform to select, you’re not just making that decision for yourself, you’re making it for your customers.  So choosing a platform that doesn’t lock you in to a proprietary codebase or where extracting the data is more of a challenge must be a primary consideration.  Nobody wants to be locked in.  Call it the ‘Hotel California’ effect.  Many companies are wary of the Force.com platform for this very reason, unless they’re building their product in order to take advantage of the Salesforce.com ecosystem.  Also, what kind of protections are you afforded via code escrow?  Think about the challenges that companies who built their businesses — don’t just think about building applications — on Coghead?  For many this was extremely challenging to their business and to some it was fatal.  there’s a financial stability aspect to this as well, so advantage to the mega-vendors like Microsoft, Amazon and Salesforce.
• What Does Existing Code Look Like?: Let’s start out simply: do you have existing code?  If not your choices are much wider.  But if you’re heavily invested in .NET or Java, your choices may be clearer, because the migration path afforded to you will be faster.  And speed does count for a lot.  Here’s one area where Microsoft Azure will have a strong value proposition to existing Microsoft shops.
• Integration: According to Forrester Research, integration is a top concern of clients when selecting SaaS companies.  So does the platform you’re selecting make this challenge any easier on you?  With Force.com, AWS and OpSource Connect you have a lot of existing connectors and modules sitting at the ready that make solving the integration problem easier and significantly reduce the associated coding effort.  Of course there are integration platforms like Boomi and Pervasive Software that you can integrate into your application, but if all else is equal, why not go with the platform that has the integration built in?

What else did I miss?  Please let me know.

Software as a Service is one of the big trends in software today. Just ask the analysts:

• Gartner predicts SaaS revenue to reach $16B by 2013
• IDC predicted 40% growth of SaaS in 2009 because of the economic downturn (zero capex, pay-by-the-drink pricing)

Anyway you slice it, SaaS is a big opportunity. As the SaaS market explodes, some software companies find themselves scrambling to figure out how to ride the wave. Many ISVs, facing declining margins and competitive price pressure from SaaS pure-plays, are thinking they need to make the shift. But the transition from packaged software to SaaS is fraught with complex architectural, delivery and support considerations that are very different than a traditional license business model. If you are planning to adopt a SaaS model, consider the following before plowing ahead:

1. Be clear on the business drivers. What are the specific results you are trying to achieve? Beat back the competition? Increase margins? All the other kids are doing it? Once you define your business objectives you can align your architectural and personnel decisions with them.
2. Recognize the architectural trade-offs in performance v. time to market. SaaS or On Demand means different things to different people. Is the application just accessible over the web, multi-instance, or truly multi-tenant? Your choices will significantly impact customer experience, the leverage you get from your infrastructure and the support structure you?ll need to put in place.
3. Understand the impact on your organization. The delivery and support organization needed for a SaaS model is very different. You have operational issues to manage SLAs for network and application uptime and responsibility for maintaining customer data. In what ways will your organization need to adapt?
4. Be explicit about how you intend to execute. Michael Lombardi from the National Football Post has a great saying: “Don’t confuse hope for a plan”.  Developing your new SaaS product requires you to make R&D resource allocation decisions to ramp up the new offering that could impact support for current customers.  Do you have a clear set of priorities to work from?  Do you have a plan on how you’re going to support the customers who are providing you with current revenue?  How quickly do you want your current customers to adopt your on-demand platform and what incentives are you going to give them to get them to move on your schedule…without them explicitly knowing it?  How do you manage this dual development path without blowing your budget?

SaaS represents tremendous promise. A well thought out transition plan and effective execution will ensure that you capitalize on this important trend.

Dani Shomron had an interesting blog post over the weekend discussing some reasons ‘Why Traditional [On Premise] ISVs Will Fail on SaaS’.  In the post, where he compares traditional ISV’s to dinosaurs, he makes an excellent point that it often comes down to a DNA issue.  ISVs “have a product view, not a service view. Their emphasis is on features not serviceability.”  I think it’s a very valid observation.  Clearly there are significant philosophical and organizational changes that are required when an company shifts from an On Premise to an On Demand model.

But there are a couple of key points that I think Dani misses on.

First, the mastodon in the room to borrow a phrase, is that most ISVs have an overwhelming desire to protect  current revenue streams (i.e. the status quo).  They don’t have the real committment to or belief in SaaS, but offer it as an afterthought, if at all.  And often it’s done under the auspices of opening new market segments (e.g. SAP’s contention that their Business ByDesign SaaS offering is an alternative for small to medium businesses that can’t afford their core product) or as a defensive measure.  With that perspective the organizational changes that Dani talks about will never be achieved.  But that’s OK because the wholesale move to SaaS is not the desired outcome.

In Dani’s example of a company that made the committment to shift to an On Demand model, he highlights the fact that the Board brought in a new CEO and changed almost the entire executive staff — save the VP, Engineering.  I don’t doubt that these moves were criticial to success in that situation.  Now I understand that perhaps there’s a feeling that you need to keep the technical talent that knows the product.  But this is a decision that I think can really kill the transition from OP to OD.  Dani was 100% right about need to to have a “service” view versus a “product” view and understanding the need for “serviceability”.  But this leads me to my second point.

As I had written before, one of the critical philosophical  changes that engineering organizations must make is to move from a purely software engineering mindset to a systems engineering mindset.  It’s so important that the engineering teams architect and design an On Demand system with data and application availability, reliability, security in mind and understand how changes in the application can affect operations.  If the engineering team gets that wrong all the other organizational changes will be for naught.

Time and again as we work with ISVs to evaluate On Premise to On Demand product transition strategies, we see that the evaluation of the current product’s ability to support an On Demand model is under-estimated, resulting in unrealistic expectations.  Therefore, making sure that the engineering organization has the underlying On Demand DNA is extremely critical to a smooth transition.