Enterprise software is not like Facebook for a reason

Salesforce’s Marc Benioff was his usual provocateur self with his post on Techcrunch “The Facebook Imperative” where he asserted that “Why isn’t all enterprise software like Facebook?” is the important question he will wrestle with this decade. Let me humbly submit that we can probably wrap this up a little faster than that.

1. Facebook is designed for entertainment, not productivity.

The more often users come to Facebook and the more time they spend there, the more they view advertisements, the more money Facebook makes.

Thus the objective behind Facebook’s design paradigm is get people to spend as much free time as possible on Facebook. To this end they have created some wonderfully addictive features: trolling through your friends’ updates, playing games, creating lists of things you like, acquiring virtual currency and thinking of witty things to say for your own status update.

I’m not so sure that “spend as much time on the site as possible” is a useful design paradigm for the enterprise. So to ask “why isn’t all Enterprise software like Facebook” is a bit like asking “why isn’t all Enterprise software like the final season of Lost.”

2. I do not have the same social relationships with my co-workers that I do with my Facebook friends.

Across various teams, projects and organizations that I’m a part of, I probably interact with ~100 different people at my company.

The percentage of these 100 colleagues that would want to hear my general stream of consciousness updates on what I’m doing in a personal context is very small. That small percentage are already my friends on Facebook.

The percentage of these 100 colleagues who would like my general stream of consciousness updates on what I’m doing in a professional context is a bit larger but still a fraction of the 100. That small percentage are already my connections on LinkedIn.

Get where I’m going with this?

3. Facebook is not another better Lotus Notes

I think it would be a real mistake to think of Facebook as another groupware modality, following the path of e-mail, portals, instant messenger and wiki’s.

The features in Facebook that most look like productivity / groupware are ones that have been around for a long time (e-mail, file upload, notifications). What is new about Facebook is the voyeurism and the followership and the lengths people are willing to go to in order to acquire both. Will fostering voyeurism or followership in the workplace lead to a happier or more productive outcomes?

Stick with the Amazon analogy

“Why isn’t enterprise software a lot more like Amazon” is a much more sensible question to me. From when you land on Amazon’s splash page, the less time it takes you to get through checkout, the more money for Amazon.

And so Amazon’s user design paradigm is designed around that business model: find what you’re looking for, transact your business, get out. That doesn’t mean Amazon doesn’t have community features like favorite lists or reviews or collaborative filtering, but they’re designed in service of useful outcomes for the consumer and the business.

For both employees, managers and shareholders, I think that’s a lot more along the lines of what people are trying to accomplish at work and a more worthy model to aspire to.

Handicapping PaaS

I was thinking of cooking up a post on platforms in the cloud when Abhijit Dubey, Junaid Mohiuddin and Aadarsh Baijal at McKinsey & Company (and several pundits by now) beat me to it.

The report outlines this new market for SaaS platforms that provide some combination of:

1. Traditional software stack components (e.g. OS, app server, DB)
2. Unique SaaS components (e.g. billing, SaaS dev tools, )
3. Hardware as a service (pay by the drink CPU/storage usage)

The report goes on to categorize different PaaS plays into categories based on what cocktail of components they offer today (e.g. Amazon’s EC3 is just hardware whereas Force.com is a full dev environment and runtime).

Good. Fine. Agree.

Then the report goes onto describe how lucrative the market for PaaS will be based on the notion that lots of SaaS ISV’s are getting started and much of their revenue will get paid back to the PaaS vendor for providing the infrastructure, with 30% of the PaaS value then getting passed onto the underlying database vendors and the like.

Strongly disagree. More on this later.

The paper goes onto make a few more predictions, namely:

1. The data center/rack space vendors will coexist with the Amazon EC3 types for a while as they serve somewhat different needs.
2. On premise development platforms (e.g. J2EE, .Net, etc) and on demand development platforms will start competing immediately.
3. Application focused PaaS offerings will fragment into several purpose built sub-markets (e.g. for UI intensive apps vs. transaction intensive apps)

More disagreement.

I think the team does an excellent job cataloging and categorizing the various PaaS plays in the market but mis-reads the market and competitive trends that will drive the evolution of these businesses.

In enterprise software, the real platform money is in the enterprise in-house developer, not the ISV.

In fact for most enterprise software vendors, the ISV is a break even venture at best. This is for several reasons:

1. ISV’s are cheapskates. Most of them are losing money or breaking even themselves and so they cannot afford to pay much.
2. ISV’s are technically savvy and so they are very savvy platform shoppers.
3. ISV’s are fickle. They are afraid of holdup costs and so they want to play on multiple platforms at the same time.
4. ISV’s go out of business often.

Basically champagne tastes on a beer budget. The main reason why platform vendors cater to these developers is they create ubiquity for the platform which encourages the enterprise vendors to pay the serious money for the platform. The checks that Citibank’s CIO writes to IBM Websphere dwarf what any ISV will write.

So focusing on who will win the ISVs is (nearly) a moot point. A PaaS company whose business model is built around monetizing ISV customers will most likely change their business model or go broke.

PaaS offerings of all types and flavors will compete with traditional on-premise development environments and runtimes for the hearts and minds of the enterprise developer. If you look at Force.com and Coghead for example both focus their marketing squarely at this audience.

It is very early days, but I think development and application oriented PaaS offerings will face an uphill battle to win the hearts and minds of the internal IT developers currently using WebSphere, .Net or LAMP. The simple reason being customers who buy SaaS are usually choosing to outsource some IT project they find to be distracting or problematic while choosing to develop in house is in many ways a choice to embrace a project that they believe is important or solvable.

This all sounds like I’m a PaaS pessimist when I am not entirely. More to come in my next post…

Determining success in software product development

My blogging has slowed to a crawl in the past few months. This is in large part because my group (SAP Governance, Risk and Compliance) has been on the verge of releasing two new versions of its flagship products Access Control and Process Control. Like a marathon, it’s that last mile that hurts the most.

During this past year and especially during the past few months, I’ve spent a lot of time thinking about what defines success when one delivers software products. It’s very difficult to know when to say “job well done” and I think many experienced software executives still make this call incorrectly.

False Measures of Success

If you work in software, you can understand why this assessment is hard. Software development is a tricky activity to measure, and the measurements you can make are very context dependent. Thus results are typically useless when comparing one product or release to another.

For example, you cannot say you have been successful if you “delivered the product on time.” After all it is easy to deliver a product on time if you cut back on scope or skimp on quality. This basic product delivery loophole is a byproduct of what project managers refer to as the “iron triangle” of scope, cost and quality. To move one variable up you must decrease the others and these relationships are for the most part fixed.

You also cannot say you are successful if you “delivered the product on time, on scope on quality.” While this sounds impressive on the surface, it is really more a function of good expectation management. Time, scope and quality are things you set targets for (i.e. fixed values). Whether you arrive ahead of or behind a target value has a lot to do with the target itself. Delivering on time, on scope, on quality is more often the result of a successful negotiation on the part of the project manager.

Any Hope to Judge Success?

I’ve come to understand that there are actually two triangles and, given the right timeframe, neither one of them is iron.

Let us call one the “execution triangle.” This is essentially the same stuff as the iron triangle: scope, time/resources, and quality. In software, this triangle is truly iron for short periods of time (e.g. 3-12 months), but you can push and pull at it when you look beyond that time horizon as you have more freedom to change processes, practices and technologies.

The other more strategic triangle is the “context triangle.” It is comprised of change, waste and innovation.

Change – how rapidly is the context changing while the product is being built? If you decide to simultaneously change the architecture, the people, the technology and the requirements, the size of the execution triangle will get very, very small.

People – how many good people do you have on the team? Product managers that write first rate requirements? Engineers with years of experience with the tools and technology? Architects that are not astronauts? If you want to accept more change with the same level of waste, you need better people on the team.

Waste – What percentage of the time and money you spent on release was put to productive use (i.e. working code that someone wants) and how much was lost to confusion and dead ends? If you want more change with the same people who built the last release, you must accept more waste.

The relationships between the elements of the context triangle are also fixed (e.g. the same release with a higher rate of change will result in greater waste). In addition, the context triangle drives the size of the execution triangle. If you have great people, low waste and a low rate of change, you can deliver some 5-10 more functionality with the same amount of time and same level quality as you otherwise could have.

Many people, executives in particular, are willfully blind to the context triangle. They do not want to believe it exists because it takes away strategic choices. To understand the context triangle is to understand for example that one cannot enter a new market with a new product on a new technology platform with a newly hired team.


So What’s Your Point?

Like most things in business, it is important to distinguish between lucky and good, circumstance and success, however tricky it may be. And so, true success in software development is the execution you achieve given your context, because the context is almost never under your control. Change, waste and innovation are the cards you are dealt and how much scope and quality you derive from these circumstances are how you played them.

P.S.

If you're in the market, please take the time to check out the newest releases of SAP GRC Process Control and Access Control. They’re both excellent. I should know :-)

The enterprise software industry in 2007

Happy New Year to everyone!

I wanted to jump into 2008 predictions but only seems fair to review my track record from 2007. 2007 predictions included:

The last of the SOA middleware vendors get merged, acquired or shut down

I was almost completely wrong here. Savvion is still around as is Amberpoint and the rest of the gang. Above All Software seems to have shut down which was a real pity because Roger Sippl is something of a role model for me.

No open source companies will exit throughout 2007

I almost got this right but the acquisition of Xensource by Citrix killed this one. Much like Red Hat’s acquisition of Jboss, I can safely predict this deal will never turn accretive and will not transform the acquiring company’s prospects.

Oracle will acquire one or more sizeable application software companies within the first half of the year

OK, not such a hard prediction to make right? But keep in mind Oracle’s acquisition of Hyperion happened right at the end of the 1st half of 2008 and as predicted, just in time to keep analysts from determining if Oracle is achieving any real growth outside of the growth it acquires.

A significant handful of SaaS companies will make it through the IPO window

For sure this happened. Successfactors made it out as did Netsuite, Constant Contact and probably more I’m not tracking at the moment.

Tech boom enterprise applications startups come back to life

Big miss on this one as far as I can tell. The rich keep getting richer in enterprise applications as conservative customer buying patterns and a lack of innovation in the startup apps community prevents the new companies from taking off.

2007 will not go down as the year the Web 2.0 bubble burst.

True! Companies grew, ad revenues were up, bankruptcies were few. 2007 was another banner year for the web 2.0 trend.

In conclusion

So my batting average for 2007 was 3.5 / 6 or 58%. Does this mean I’m ready for analyst fame or infamy? Let’s see if I can get this up to 70% next year.

A new wrinkle on SaaS

Salesforce announced an interesting new capability to facilitate the sharing of specific types of information between different SFDC subscribers. An early example would include something like sales leads. So, for example if one SFDC customer sells a complementary product to another SFDC customer, they can share information like leads among one another.

This is in retrospect a pretty obvious capability for an enterprise SaaS vendor and I'm a little surprised that no one has thought of it before. While SaaS has cost efficiencies for the vendor, I think it's been a struggle to say that SaaS itself provides competitive advantage for a software vendor. But this is something that would be difficult for on-premise vendors to replicate: an application network effect that's could be genuinely beneficial to the user. The consumer web companies have all figured this out some time ago, perhaps because consumers are more fickle than enterprises.

In the case of Salesforce, I doubt it the feature will be very utilized as few companies share leads frequently enough to make this an often-used feature. It feels a bit forced and after the thought. But it does spark some thought as to what the next generation of SaaS vendors may portend. They say that with every architectural shift, the first generation of new companies uses the new architecture to ape the old paradigm. But the second generation uses the new architecture to accomplish something truly novel.

Where is it all headed? What does it all mean?

I’ve let the blog go a bit cold! It’s been a very busy past few months and feeding the beast has been tricky despite a busy tech news season.

A few weeks ago, Oracle announced a semi-hostile takeover bid for my former employer BEA Systems.

The Wall Street Journal put the offer in context with an article that portrayed Alfred Chuang as one of the last of a dying breed – the founder/CEO of an independent mid-sized software company.

The data supporting this assertion are actually mixed.

1. Many mid-sized enterprise software companies are still alive and kicking including TIBCO, SAS, Kronos, Cognos, Manhattan and Parametric.

2. However many mid-sized software companies have left the scene including Siebel, Hyperion, Agile, Retek, PeopleSoft, webMethods, Mercury, and now possibly BEA.

3. However many newcomers seem poised to replace those that have left. For example Salesforce, Successfactors, vmWare, Red Hat, Netsuite and Rearden Commerce.

4. However many of these newcomers are struggling to sustain growth as public companies or are struggling to get public in the first place. And the aggregate revenues & employment of the new companies is far less than the companies they are replacing.

So what does it all mean?

Since inception the high tech industry has moved in cycles. But I don’t think all parts of the industry follow the same frequency. The frequency many of us think of the system architecture cycle. We’ve heard this dozens of times before: first there were mainframes, followed by minicomputers, followed by client-server, followed by N-tier apps, perhaps now followed by something more grand that lives in the cloud. If you look at the history of this evolution, it would lead you to believe high tech has roughly a 7 year clock cycle from boom to bust and back again.

But if you look just at consumer software applications, it would look quite different. First there were many desktop application companies, then there was Microsoft, then there was more Microsoft, then there was more Microsoft and well, you get the point. Microsoft launched Office as a suite in 1989 and it has taken roughly 16 years before anyone or anything managed to mount a credible assault on its hegemony. Much slower clock cycle.

So, whither enterprise software? Is our industry consolidating? If so, is it the consolidation before the next big bang? I’m pretty unsure of both points at this stage.

Software Product Marketing 2.0?

One pet peeve I have with the enterprise software industry is the marketing. I find most software product marketing to fluctuate between the puerile to the abstruse.

The abstruse bit actually gets me more than the puerile does. For example, most product brochures do an amazing job filling 2-4 pages with words and the obligatory marketecture diagram, but still saying next to nothing about what the product actually does or how it will specifically benefit the buyer. My belief is this is a contributor to sales inefficiencies because now it takes 2 flights from a sales rep and a demo from a sales engineer until the customer has the first clue what the product does or what to compare it to.

Can we throw out the product marketing slick? What would replace it? I was pondering the idea of a product marketing slick wiki. The idea would be that for each product you start with a normal 2 page product description but then readers could comment on it or ask questions and the product managers, marketers or users can clarify and enhance until all the marketing-speak is scrubbed out and you're left with a lucid description. I’d be curious to get any comments if this sort of thing has been tried before.