SmoothSpan Blog

When I read Phil Wainewright’s smoldering excoriation of SAP relative to SaaS competitors, I had to write another post today.  Wainewright compares the two after SAP announces they’ve had to can their SRM update and persuade people who aren’t already far along the adoption process to turn back to the 2005 version.  Whoa!  Back to 2 year old software.  Whatever could have happened? 

This is where the over-engineering monster rears its ugly head, and it certainly won’t be the first time for SAP (or other big Enterprise vendors).  Add to that a healthy dose of being afraid not to cover every possible check-off item lest another Big Enterprise like vendor sense weakness.  Meanwhile, SaaS competitors in this space just keep churning out new releases.

In the same way that the Unreasonable Men have argued that SaaS prevents too much customization to the good, I wonder if it doesn’t also prevent too much over-engineering.  Big Enterprise is used to taking so long to build their next release that it is almost completely incompatible with the last and will require an expensive update process to move on to.  This is not exclusively the domain of Big Enterprise either: we see Microsoft’s Vista laboring after 5 years to show that it really is better than Windows XP.  What’s the problem here?

Borrow a page from Agile software development.  The Agile approach is all about iterative development with short iteration cycles and lots of face to face contact with the “customers” who will use the software to verify that each iteration is never too far off the track.  Isn’t that exactly what happens in SaaS when it’s practiced properly?  Aren’t SaaS companies iterating on much shorter cycles and getting those cycles in front of all the users of their multitenant systems very quickly?  Don’t SaaS companies avoid these giant boil-the-ocean projects because it would be impossible to do gigantic updates to their whole customer base?

Phil Wainewright likens this whole process to the Innovator’s Dilemma, which I think is right, but he points to the complicity of the customers in an interesting way too.  Phil worries that big enterprise customers ladle on so many requirements that it is impossible for a new category to ever get mature.  New requirements are being added faster than the software can be written.

Here again, I think SaaS brings an enormous advantage.  Seeing something working today, solving real business problems, and delivering real ROI with minimal IT commitment helps business users push through initiatives without waiting for so much functionality to be amassed.  Customers know the product can come along quickly in the SaaS environment,  but just as importantly, they know they can have value today.  Not in 2 years when the package may be cancelled anyway.  Not in a year after an expensive customization process. Right now.

Perhaps SaaS is the moral equivalent of agile programming for Enterprise software.  It could certainly use it!

Related Article

Wainewright points out it isn’t just SAP:  Microsoft is doing the same thing with their Dynamics CRM offering, delaying it over a year.  Doh!  The new plan of record calls for releases every 2 years.  The delay is supposedly to retrofit .NET to the software?!??  How could a Microsoft product not have .NET to start with?  Decidely not Agile.