SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for October 23rd, 2007

SaaS Limits Over-Engineering Too By Forcing Agile Development

Posted by Bob Warfield on October 23, 2007

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.

Posted in business, saas, strategy, Web 2.0 | Leave a Comment »

More on Microsoft’s Rift With the Web

Posted by Bob Warfield on October 23, 2007

My post on  Microsoft’s Rift With the Web generated some lively commentary including a blog post from Tim Anderson and a similar-sounding comment from a confessed Microsoft employee.  The problem I have with both is they’ve painted my original post with the same brush that has gotten Microsoft into trouble.  There seems to be a tendency to want to make it a totally black or white conclusion.  Here are some choice quotes:

“Microsoft had little-to-nothing to do with Java’s demise; and Java is not “the web”.  Java was rejected by the web because it was antithetical to the web.”

Wow!  Who knew Java had met it’s “demise” and had been “rejected by the web”?  Why wasn’t this on TechMeme?

“since enterprises did not want to bet on a single language/runtime that was controlled by a single vendor. Again, MSFT gave people a choice; you can’t blame us for them choosing open standards and interop.”

There is giving a choice, and there is forcing people to make a choice.  Microsoft favors the latter strategy because if you invest totally in their choice they lock you up.  They’ll play for the long term assuming they can add to that locked in base over time.  But having a choice is much different than forcing a choice.  Forcing a choice is black or white.  Having a choice is, “I want both, I want gray.”  Lots of folks out there are mixing lots of the open web tools together including Java.  Most of these tools are built for it.  I know very very few that mix .NET with that world.  Shops tend to go all .NET.  The exception would be for example SQL Server, but that’s a pretty weak counter example.

“MSFT was a good-faith promoter and participant in the relevant W3C standards sinc day 1.”

My recollection is different, but forget recollections.  Let’s look at the present and Microsoft’s standards-based activities around OOXML.  Apparently, Microsoft tried to stack the committee to get their way, which brought progress to a grinding halt and had Tim O’Reilly writing:  This is a great victory for advocates of openness.  Now is this any way to behave as a good-faith promoter? 

“Warfield does not quite say, but strongly implies, that .NET is failing in the market.”

Failure is a strong word, and not one I would choose.  What I did say is that Microsoft is making themselves an island, and on that, the writer evidently agrees:

“Now, I do partially agree with Warfield. Microsoft is an island…”

 .NET hasn’t failed, but Microsoft’s insistence on .NET to the exclusion of the other platforms is what’s placed it on an island.  The web at large is actually a pretty forgiving place, notwithstanding the frequent flame wars one sees.  The latter are just good-natured barroom fisticuffs.  But the web is intolerant of too much dogma, and in particular, it is intolerant of walled gardens, which is exactly what Microsoft wants from .NET.  You can’t blame Microsoft for trying to create a walled garden, only for misunderstanding the ramifications of doing so in a world that is well aware of what walled gardens are and what they mean.  By insisting, they’ve been banished to this island.

Tim Anderson (and others) dislike my use of Google results to bring perspective.  He presented some interesting data that shows IIS gaining on Apache.  The trouble is, if we read the fine print on that page, netcraft conclude that the apparent improvement in IIS relative to Apache is due to the fastest growing sites being MySpace, Microsoft Live.com, and Google’s Blogger.  MySpace and Microsoft Live both run IIS.  But is the number of servers in use a meaningful metric to this discussion?  No, not really.  The fact the gap closed because of just 3 sites, one of them Microsoft’s own site, only emphasizes my point even more strongly.  The island has a couple of great big peaks out there and one is home to Microsoft itself, which is surely another source of skew, and a worse one from my perspective if you’re talking about community and developer mindshare.

Tim makes a couple of other comments on my Google statistics:

“so by the same logic PHP is vastly more important than Java.”

I can live with that, and in fact, I’ve written about it.  I’m not sure why it would be controversial.  It doesn’t mean there aren’t a whole lot of folks who love Java, nor that Java isn’t a far better tool for many uses.  But PHP is a great tool too, and the world has proven that a number of times now.  The Lamp stack has become extremely successful among web startups.

Here is another:

“we must conclude that MySQL is far more important in the Enterprise than Oracle”

Tim has gold plated his case by inserting the word “Enterprise” there.  Not a word I used in my analysis.  In fact, it seems to me we were talking about the web, not the Enterprise.  Turnabout would be for me to say, “Tim Anderson says Oracle is much more important to the web than mySQL.”  In fact, if we add the word “enterprise” to the Google search, we get the following:

Oracle+enterprise:  10,500,000

mySQL+enterprise:  1,940,000

Oracle beats mySQL 5:1 in the Enterprise by this metric.  Tim, are you sure you don’t like this Google diving approach?  It seems to agree with your points of view.

Last point of clarification involves this statement:

“Should Microsoft drop .NET and embrace Java or PHP, as Warfield kind-of implies?”

We are again attempting to force a black and white choice instead of offering choices.  My exact recommendation to Microsoft was this:

“Microsoft needs to repair their rift and start embracing some of the other technologies out there. “

Frankly, things were pretty good before Microsoft went to war over Java.  I’m not interested in eliminating Microsoft or .NET!  I want to seal the rift because a bigger, more unified ecosysem will be good for all concerned.  I read where Sun is now increasingly using Python in lieu of Java  on apps they are shipping.  Sun has “cultivated and vigorously supported” Ruby.  When will we read something similar to either announcement from Microsoft, instead of reading things like they’re going to quit shipping the JVM at the end of the year?

It’s really not that hard.  It won’t hurt .NET, honest, and it will improve Microsoft’s ability to engage the ecosystem that is the web.  It means giving up on having a monopoly on web development, but come on, that just isn’t going to happen.  Move on.

Or, to paraphrase a famous Cold War era quote:

Mr. Ballmer, tear down this wall! 

(And stop the monopoly building foolishness: it won’t work, it’s hurting you, and it’s making your enemies grow stronger.)

Posted in business, strategy | 12 Comments »

Does SaaS Limit Over-Customization?

Posted by Bob Warfield on October 23, 2007

One of the things I like about the Unreasonable Men blog is their propensity to throw the oddest ingredients into a stew just to see how it tastes.  Nothing unreasonable about that at all: it’s how we learn new and interesting things.

The stew this time is all about customization, or rather “over” customization.  Unreasonable sees clamoring about the difficulties of customization for SaaS.  This gets the juices flowing, and pretty soon we’re wondering whether:

If you took you’re on-prem code vanilla, wouldn’t that attack one of the core value propositions of SaaS – speed to market and easy upgrades? I could finance all the bits and give you a monthly rental. I’m being provocative but am genuinely interested in the answer… please if you’re a lurker give me you’re comments.

Fascinating question!

I’ll throw a log on the fire:  Robert Youngjohns, my recent ex-boss, commented that while he was the VP of Worldwide Sales at Sun, they were having a terrible time getting Siebel installed on-premises, and all because of customization.  Eventually they finished.  Some time later there was a discussion with Siebel about Salesforce being a lot easier, and Siebel responded, “If you’d just installed our software out of the box we would have been easier too!”  That’s exactly Unreasonable’s point.

Perhaps SaaS has accidentally stumbled onto the benefits of just saying “no”.  I’ll go a step further.  SaaS provides a politically safer outside-the-organization reason to say “no” to unnecessary customization.  But, in the spirit of the request for lurkers to come out and comment, let me offer some counterpoints, because some business processes have to be customized

Let me give a prime example from my last gig:  sales compensation.  Everyone does sales compensation a little bit differently.  Why?  There are lots of reasons.  Sometimes an industry has created a different model.  Insurance sales people are paid radically differently than car sales people.  If one company tries to change that, they will lose their salespeople.  Worse, in most insurance, the sales people don’t work for the insurance company.  They work for independent bureaus.  The sales comp becomes a means of attracting new brokers to sell your product.  As such, the offering must be fluid.

I’m sure others can give other examples.

You may have also heard my diatribe that IT must continually introduce change if it is to add value.  I put it a little more eloquently by saying that the IT productivity curve must continuously be replenished.  A failure to allow for customization dooms the particular software package and its customers to the commoditization of that module and its business process.  This is Ben Kepes fear when he talks about “a slippery slope to mass-homogenization where there really is nothing different between one enterprise and another.” 

There are some modules where commoditization and homogenization makes sense.  I’ve heard a number of Sales VP’s opine that Salesforce with minimal or no customization is fine because the business process it deals with doesn’t benefit much when you customize it.  In the worst case they view it as a system of record for the opinions of salespeople on what might happen.  But there are other business processes where customization matters. 

There is also simple customization that can be done fast and isn’t really so much about business benefit as identity.  I want to  put my logo on the screens.  I want to use my terminology as the way I think about my business.  I want to add a few new fields to various objects so I can track more information.  I need to be able to do ad hoc reporting on the data.  Every SaaS app should accomodate this kind of basic metadata functionality.

SaaS vendors need to understand whether their domain requires real customization or not.  If it does, they’re going to have to find a way to deliver that customization at a price and implementation time frame that makes sense relative to the rest of the SaaS model.  This means building more technology, at least until a platform comes along that addresses customization.  If the domain doesn’t require the customization, let’s try to get by without.  Help your customers control themselves.

Posted in saas | 2 Comments »

 
%d bloggers like this: