Yet Another Software Blog

Enterprise software is not like Facebook for a reason

2010-02-25T19:34:00.000-08:00

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

2008-07-07T23:46:00.000-07:00

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

2008-04-13T22:20:00.000-07:00

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

2008-01-03T20:38:00.000-08:00

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

2007-12-04T21:31:00.000-08:00

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?

2007-10-31T21:27:00.000-07:00

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?

2007-09-06T01:13:00.000-07:00

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.

Dissecting the SaaS business model

2007-07-30T10:24:00.000-07:00

Three SaaS companies, Netsuite, Successfactors and Constant Contact are preparing for IPO. This is great news as I get to tick off a “win” on one of my 6 predictions for 2007.

Jason Wood did a stellar writeup of the Netsuite S1 and Jason Corsello did a good note on the Successfactors S1. I thought I'd take a comparative look at all of them.

What struck me with all three companies was the losses. The first order explanation is quite simple: all the companies spend a ton of money on sales & marketing (between 65% and 100% of revenues). Most of these businesses are the farthest thing from the oft discussed but seldom witnessed “pull model” that’s supposed to lead to superior profits.

The root cause for the losses is a little more subtle. In a recent article, McKinsey consultants asserted that the primary cause is scale. In fact they go so far as to say that these scale economies are nearly identical to those of on-premise software companies.

On the surface this appears to be a reasonable explanation. Successfactors had $36m in 2006 revenues and spent roughly 100% of revenues on SG&A. Netsuite is at $65m in 2006 revenues and spent 78% of revenues on SG&A. But I think this is a bit off. Salesforce is at $309m in 2006 revenues and still spent 67% of revenues on SG&A. Rightnow was at $110m in 2006 and still spent 71% of revenues on SG&A. Meanwhile, many smaller on premise companies like Aspen Technology, Quest Software and VMWare keep these costs around 40-50% of revenues and turn an operating profit of 10% or so.

The true factor driving SG&A for these SaaS companies is growth, not scale. This is logically consistent as the economics of most any subscription business is based on the cost to acquire a customer versus the future returns of that customer relationship. I took the financials for all four companies and lined them up not based on year but based on when they are at a comparable size (comparable stage in their evolution). They look like this:

You can see that SG&A spent in the prior year (cost to acquire customers) correlates very well to growth in the subsequent year (returns from customers acquired). So, as long as you believe there’s growth left in your market, keep spending to capture that growth. To prove the point, Successfactors had an interesting period in their fiscal 2004 where they seemed to prematurely press for operating profits by taking SG&A down from 108% to 75% of sales. They were horribly punished in the following year with tepid growth of 35%. They corrected the error the following year and growth sprang back to life.

I created a simple ratio I called “growth efficiency.” This ratio is growth rate in a given year divided by the SG&A % from the prior year. Essentially this evaluates how much growth is generated by a point of margin spent on SG&A in the prior year. I think this ratio is a pretty good indicator both SG&A spend efficiency and is probably also a pretty good indicator of long term profitability. A few observations on the ratios for the 4 companies:

Salesforce had reached a fairly stable equilibrium where a point of margin spent on SG&A returns a point of growth the following year. However this has been deteriorating over the past 2 years. If the high end of Salesforce’s 2008 guidance holds, they will be down to a .69 ratio, equal to or worse than anyone else in the group. Interestingly, this is trending down at a time when Salesforce has been raising prices through various premium offerings that can now drive the user/year fee as high as $2,350. I think there are lots of interesting theories to explore here.

Successfactors’ ratio is all over the map due to their experimentation, but in 2005/2006 a point of margin spent on SG&A returned a point of growth. I think it’s too soon to extrapolate any long term trends for Successfactors.

Netsuite has been a consistently less efficient business. A point of margin spent on SG&A currently returns only 2/3 of a point of growth the following year and this was 1/2 a point of growth a few years back. That reinforces my theory (and persistent rumors) that Netsuite should have a tougher time acquiring customers than a Salesforce. Financials is a more centrally controlled purchase decision and is more likely to go through a comparative evaluation. In their defense, the picture has been steadily improving.

Constant Contact has the best business of the four. A point of margin spent on SG&A gets you 1.4 points of growth. This with a product whose average selling price is just $34/month. This also makes sense as e-mail marketing services for SMB companies has got to be the ultimate impulse buy. Constant Contact uses no direct sales force and generates almost all revenue through marketing campaigns and channel partners.

The pull model is as elusive as ever, but Constant Contact seems to give us a few hints as to how it's supposed to work.

[SaaS], [Business Models]

Software sales & marketing costs

2007-06-24T06:49:00.000-07:00

Periodically I’ll find a post in the blogosphere lamenting the amount of money that enterprise software vendors pour into sales & marketing. In most companies, sales & marketing expenses are 2-3X those applied to product development. While there are countless articles, books, methodologies and consultants available to increase the efficiency of product development, the cupboard is comparatively bare when it comes to efficiency in sales and marketing.

Sales and marketing expenses are, in the abstract economic sense, wasted money. If customers were omniscient they could order whatever they needed on a web site without vendor prompting or encouragement and take vendor sales & marketing costs down to zero.

I believe the root cause of sales & marketing expenditures is a two way street. Reducing these costs would neither be a vendor-only solution nor a customer-only solution.

Where does the money go? If all sales & marketing expenses are 100%, the breakdown for an average enterprise software company might look something like this:

Brand & general awareness building – 10%
Tactical marketing (demand generation, etc) – 20%
Quota carrying salespeople & associated overhead – 35%
Sales specialists (sales engineers and various other specialists) – 35%

I’m sure there is wasted money in marketing, but at 70% of the total, the bigger opportunity for improvement is in sales.

If you were to show sales costs as a simplified function of revenue it might look something like this:

Cost of Sales as a % of revenue = Revenue Per Sale / [ (N * S * T + C) * 1/P(w) ]

N is the average number of people working on a sale

S is the average salary of those people for a month

T is the average amount of time in months it takes for the sale to reach a decision (win or lose)

P is the probability of winning the sale

R is the revenue a company takes in a given year

C is costs associated with the sale (e.g. travel)

Three parts of this equation are relatively uncontrollable:

S is not an opportunity for savings. There is a market rate for good people in any profession. If you pay less than the market rate, you either get bad people or no people at all.

I don’t think there’s a big opportunity to reduce the average number of people working on a sale. You could argue that fewer sales specialists would reduce N, but I’d predict that this would result in salespeople doing this work themselves which would increase N back to the original level. Possibly there’s some optimization to do here but not a ton.

Revenue per deal is a big but I think untouchable lever. Doubling the amount you sell in one shot cuts sales costs nearly in half. Of course customers aren’t too thrilled about paying double and vendors aren’t too thrilled about receiving half, so I think we’ll have to let the market sort out the average deal size.

Three parts of the equation are controllable if everyone (vendor and customer) is willing to do their part.

Time is a big lever. With a similar sales team and win rate, a company with an 18 month sales cycle will spend twice as much on sales as a percent of revenue as a company with a 9 month sales cycle. There are tons of pockets of wasted time throughout the sales/purchase cycle but the first order problem is this:

People are free to waste what is not their own. So vendors frequently waste the customer’s time, and customers frequently waste the vendor’s time.

Some ways vendors waste the customer’s time:

- Avoiding describing what the product or service actually does in favor of abstract marketing and positioning statements like “end to end” or “best in class.”
- Reluctance to disclose product weaknesses.

If you’re a large purchaser of technology, go to one of your vendor’s account managers the day after New Year’s and say:

“Whatever quota you’ve been assigned for me for this year, I’m guaranteeing you’ll make it. Now I just guaranteed your income so you work for me. You will be my savvy shopper. I want to get precise descriptions about what your products do. I want to know about their issues and weaknesses before anyone else does. I want to have access to your company’s expertise as fast, or faster, than anyone else. If you fail to do these things I can ensure you get kicked off this account and probably fired.”

Some ways customers waste the vendor’s time:

- RFP’s. Everything in moderation, but most book-sized RFP’s are huge time & resource drains for vendors with low probability of success.
- Concentrating purchase authority in the hands of one or two people who take months to get access to.

If you work in sales management for a large technology vendor, pulls a customer aside at the end of your first meeting and say:

“On average my company spends 12 months with customers before they reach a decision on our product. If you are willing to commit to a yea or nay decision on my company’s product within 6 months, I will discount the price an additional 7% in addition to whatever discounts you regularly negotiate.”

Sales costs are roughly 25% of revenue so by cutting them in half the customer and the vendor can share the savings equally at a 7% discount.

Win rate is another big lever. If a vendor won 100% of the deals it pursued, its sales & marketing costs would be half that of a vendor that won 50% of the time. This is a big reason why the #1 vendor in a software market typically makes 80% of the profits in the market. If #2 vendor wins half as much as the #1 vendor, their sales & marketing costs as a % of revenue are higher than that of the leader, and this causes them to starve R&D to fund additional sales & marketing. Of course this further reduces the win rate, sending the #2 or #3 vendor into a vicious cycle.

It’s in the technology buyer’s power to increase win rates industry wide, reducing vendor sales & marketing costs. If you’re a shopping for software, how many vendors do you typically evaluate? When do you cut most of them loose so you’re down to the likely two?

Cost associated with the sale is yet another lever. Over a 12 month sales cycle, the airfare, meals and extraneous expenses can add up. I’ve personally never seen a compensation plan that rewards salespeople for saving the company money. I’m not sure why this is but perhaps someone can explain to me why this would not work. A sales manager tells his salespeople:

“On average our company spends 3% of revenue for a sale on travel & miscellaneous expenses (this is a total guess on my part). If you come in below the company average, you can have half of the savings.”

Just as in product development, there’s no silver bullet to reducing sales and marketing costs. But the prize (in the form of increased profits, more money ploughed into R&D, and customer savings) is so great, it seems crazy not to try. So let’s light a candle rather than curse the darkness. Has anyone attempted these or any other approaches to streamlining the enterprise software sales and marketing machine?

Startup fad diets

2007-06-17T14:08:00.000-07:00

Just got through reading this article on Appirio in Forbes online.

Essentially Forbes holds Appirio up as the new paragon of startup thrift. The founder’s taken such overhead reducing steps as:

1. No physical office space except for a rented cube.
2. A team distributed throughout the country, mostly in low-ish cost US states like Arkansas
3. The company owns no hardware. Everything is by the drink from Amazon ECC
4. The company spends no money on PR. Everything is word of mouth.

For all this, Appirio is able to bid for projects at 20% less than competitors (which seems like an underwhelming cost advantage after all that fasting) and often does fixed bids.

O.K.

Let us all agree that being thrifty is good.

Let us also agree that advances in technology and business practices allow startups to run leaner and meaner than they could have 7 years ago.

But some of Appirio’s stuff is just shortsighted, and by the way, it’s been tried before.

Consulting/software hybrid businesses. So many failures in this regard it’s hard to count all of them. ICG Commerce comes to mind as one good example.

Fixed fee consulting projects. This works when you’re a small company but falls apart as you grow because of underbidding which either burns out consultants or creates perverse incentives to under-deliver to clients so they might hit the target budget. Cambridge Technology Partners is a good example.

No physical office space, just a distributed team. A nice over-head saver but typically these sorts of companies have very little cohesion and turnover becomes rampant, especially as you get into crunch time on one of those fixed-fee projects that you underbid. A notable failure example here would be Gemini Consulting that tried to go 100% virtual with just one physical office in New Jersey.

No hardware. Well, this is a matter of degrees in my opinion. Clearly the old days of buying hundreds of thousands of dollars worth of Sun servers is over. But are you so hard up you can’t spend $10,000 on a couple of Dell boxes? Or at least some dedicated servers from a hosting company? The difference is a couple of hundred dollars a month for some added consistency and reliability. Isn’t a business worth at least this much?

No PR. Hard to argue with this one, I don’t recall ever getting much value out of the money I’ve spent on PR.

It seems like every startup era, the business press profiles some startup that takes the current zeitgeist to the perverse extreme like some sort of fad diet.

I recall articles in 2000 during the dot com boom where they’d profile a startup that raised $20 million in the series A and bought a Superbowl ad the next day. Get big fast and build the brand immediately. THAT’S the future of the startup.

A few years later I was reading articles of startups that threw everything to India except a skeleton crew in the US. Quotes from VC’s saying “I’m not interested in any business plan that doesn’t have an India strategy.” Go to India. THAT’S the future of the startup.

Now it’s “buy nothing, own nothing, hire no-one” future of startups.

Every era a number of businesses get weaned on the new fad diet, but just like fad diets, they typically last for a couple of years before becoming dysfunctional and flabby.

P.S. - From when I started writing this post we're apparently already moved onto the new "don't fund anyone over 40" diet.

What are you willing to pay for availability?

2007-06-10T11:17:00.000-07:00

Dan Farber writes up an interesting piece on Salesforce.com's rather extended scheduled downtime. In the process, Dan quotes a fellow Enterprise Irregular Charlie Wood who says:

Does anyone think PayPal could have hours of scheduled downtime and get away with it? Of course not! Why not? Because payment processing is a mission-critical, 24×7 function. Shouldn’t sales and support be no different?

In fact it should be different. People are prone to forget that sales force automation has very little to do with actually securing revenue. If your SFA is down, you may not be able to enter some contact information or update your pipeline, but this is hardly life threatening for a few hours. By contrast if your order entry & fulfillment system goes down for a few hours, you are likely to experience some serious commercial consequences.

None of this is really a SaaS topic. It’s more a matter of not paying for mission-critical availability for a non-mission critical system. For an extra $5/user/month I imagine Salesforce could substantially reduce downtime. But for most customers would prefer to save the money and do without a contact management and pipeline tracking system for a few hours a week. If you were making this same decision for a manufacturing execution system or an order entry system or a telecom OSS system, you’d make a different decision.

There have actually been mission critical systems available as a service for decades now. Payroll through ADP is one example. Also many small community banks get their highly mission critical payment systems as a services from larger banks that can afford to maintain the infrastructure. They just come with mission critical prices.

Enterprise software acquisitions

2007-05-28T16:02:00.000-07:00

The pace of acquisitions has been fast in furious in enterprise software recently. I thought I’d do a quick roundup.

Workbrain acquired by Infor and Kronos taken private by Hellman & Friedman. The major players in workforce management are all off the public market. Around this same time, all the major players in product lifecycle management (PLM) except PTC get taken off the public market as Siemens acquired UGS PLM (granted already private), Dassault acquired MatrixOne and Oracle acquired Agile Software.

The acquisition of the rest of the mid-sized ($100 million - $1 billion in sales) best of breed vendors seems like almost an inevitability at this point. The only categories I’m aware of that still have standalone mid-sized vendors are warehouse management (Red Prarie, Manhattan), procurement (Ariba) and business intelligence (Cognos, Business Objects). I suspect these guys will disappear from the scene shortly.

Spotfire acquired by Tibco. I got a chance to meet Spotfire’s founder & CEO Chris Ahlberg back when I was in grad school. A really smart and likeable guy. Spotfire’s product is a suped up data visualization/BI tool that enables human centric data mining. It’s a great product, a pleasure to use. I’m still scratching my head as to why Tibco is the right acquirer here. Spotfire’s customers are typically scientific types in pharma research, oil & gas exploration and in financial trading shops. This flanges up much better with someone like SAS in my opinion.

SAP acquires Pilot Software and Outlooksoft. Continuing the trend of making relatively small, targeted acquisitions, this rounds out SAP’s portfolio in Corporate Performance Management.

HP acquires BEA. OK, this one hasn’t happened yet, but I think it’s a pretty reasonable prediction. HP has shown commitment to the software industry with its acquisition of Mercury Interactive. If you combine Mercury for testing, BEA for development & runtime, Instinet for the repository and OpenView for monitoring, you have a full lifecycle suite, most of which is already well integrated. HP has enough distribution muscle to pull well out ahead of Oracle and Sun. IBM will be tough to catch thanks to the breadth of the portfolio and the power of Global Services. With its recent quarterly miss, BEA is also looking more affordable. It’s time for this to happen.

[Software Acquisitions]

Vacation reading roundup

2007-05-20T22:47:00.000-07:00

More vacation (honeymoon!) reading. Before I headed off to the beach I picked up a number of books. Here’s the quick blow by blow:

Extreme Programming Refactored is the most extensive treatise against Extreme Programming (and by extension agile development) that I could find. As an avid proponent of agile (in my case Scrum, not XP), I thought this book was a must read. After all, it would be useful to know if what I’ve been doing is completely wrong.

The authors raise a number of good points and many, many more bad ones. The two good points:

1) Constant refactoring as espoused in agile can get out of hand and is difficult to estimate as part of the project schedule.
2) The concept of the “on-site customer” in XP (or agile generally) is fragile and is basically a gap in the methodology.

Without getting into too much detail (it’s a 400 page book), most of the other complaints raised against XP are pretty specious and validated by straw men the authors diligently construct to tear down, typically by taking XP to a perverse extreme and then arguing against the extreme. The authors are also shilling their own methodology (ICONIX) and books but they don’t reveal this fact until chapter 9 which I found very irritating.

Peopleware – Productive Projects and Teams. If you’re a Joel Spolsky devotee as I am, reading this book will be treading over some familiar ground, but there was plenty of new stuff in it for me as well. It is a great summation of a number of key practices that should be in place to manage software projects and teams. The book is nice and short and peppered with some studies to validate key points. This will be useful for you if you’re trying to protect your development team from the latest CMM, Six Sigma, cubicle farm trend running around your company.

Founders at Work. Basically war stories from high tech company founders. I always find these stories to be inspiring and I occasionally pick up a good bit of advice for future reference. Best stories came from Mitch Kapor (personal hero), Steve Wozniak, Max Levchin, Tim Brady, Joel Spolsky, Joe Kraus and Charles Geschke. Only weakness of the book is that it’s a bit like the Actor’s Studio. After the first two seasons, all the good actors were interviewed and Lipton was left interviewing J-Lo. The book has its share of J-Lo’s.

Invisible Engines. A thorough review of the software platform business from a technological and economic viewpoint. I got bored early in because 1) there’s a limited number of companies that are in the platform game 2) There are several chapters of warm-up that, if you are in the platform game (as I happen to be), are very elementary. I suppose the net is the authors didn’t put a whole lot of thought into the intended audience.

Happy reading!

How can you be sure a company is dead?

2007-04-09T22:26:00.000-07:00

Much digital ink has been spilled on Paul Grahm’s “Microsoft is dead” article. Now that the dust has settled, I wanted to throw one more point of view on the pile.

Paul gets some things right. Microsoft does not strike fear in the hearts of startups they way it once did. And there's a significant chance that Windows goes the way of IBM's Z series - a huge cash machine that doesn’t bother anybody except the customers who have to pay the bill. So Microsoft can be alive, but not very relevant. If SAP did nothing but add features to R3, we'd be in a similar boat.

But Paul also gets a lot of things wrong. In many ways, his article reminds me of Mark Andreessen’s famous comment in 1995 that Netscape will “reduce Microsoft to a set of poorly debugged device drivers.”

Back then, as now, a bunch of young engineers fresh out of university were surprising everyone with what was possible on the web.

Back then, as now, someone decided it was a good idea to poke the giant with a stick.

Back then, as now, most of the products the upstarts launched were not all that hard to build. I think it took Microsoft something like 20 people and 6 months to come out with a competing browser.

Back then, as now, a lot of people were confusing “lucky” with “good.”

Back then, Netscape’s stock cratered and the company was sold off to AOL which in turn cratered the following year. Now….?

The point being Paul is willfully blind to history and he is definitely tempting fate, which most people would say is a bad idea.

I also think Paul undersells Microsoft’s accomplishments a bit. The X-Box is looking like it's going to shape up as a big success. The enterprise infrastructure business (e.g. BizTalk, SQL Server, etc) is growing and highly profitable. And out of the 1,000 bets Microsoft has on the table right now, I'm guessing one or two biggies will pan out over the next decade.

Paul bats about .400 with his remaining observations. Yes, broadband is a big deal. Yes, the desktop matters less and less. But then Paul veers off into tin foil hat wearing, “I live in a complete bubble” territory:

Ajax as a Microsoft killer. OK, Ajax is great, but it’s probably the 7th or 8th iteration of web UI technology. There will be a 9th and a 10th before you know it.

OS X is one of the 4 biggest trends contributing to Microsoft’s lack of relevance. I would think OS X’s market share would be ample evidence that this assertion is far off the mark.

Microsoft needs to buy every "good" web 2.0 company out there to become relevant. What Microsoft needs to do is prove it can be as relevant on the web as it is on the server and on the desktop. I don’t know what Paul’s definition of “good” is, but does buying Zillow or Riya or (insert feature here) really help Microsoft reach the goal of web relevance?

Then, in Paul’s “Cliffs notes” he talks about SAP:

"They make a lot of money. But does anyone developing new technology have to worry about them? I doubt it."

Go ask Tom Siebel, Mark Hoffmann, Keith Kratch, Sanjeev Sidhu and Joe Liemandt if "not worrying about SAP" is a good idea. If you have to look up those names to understand what I’m talking about, I rest my case.

Might Microsoft or SAP or Oracle go the way of the IBM mainframe? It’s certainly possible. But the opposite is possible too. History wouldn’t make me nearly as confident as Paul seems to be.

[Microsoft]

No day at the beach for web services standards

2007-04-04T20:02:00.000-07:00

Innoq was kind enough to draw up this nifty map of today’s extant Web Services standards.

This of course was throwing a proverbial softball to WS-* standards cynics like our friends over at MuleSource.

Oh the complexity! So confusing! So hard to learn! What where they thinking???

Standards weenies are an easy target. They’re anal retentive, they spend 5x more time in committees than developing software and more than infrequently, they generate an impractical standard (CORBA anyone?).

But I think the kvetching over the WS-* complexity is pretty overblown. What struck me looking at Innoq’s diagram is how similar it is to the Java class library (or any other major language’s class library for that matter).

There are major categories and sub categories, commonly used categories and more esoteric ones. While Java gets its own share of abuse for complexity, it hasn’t hindered its adoption. In fact Java is an indisputably successful language in terms of adoption. And learning all of the Java libraries is much more extensive than all of the WS-* standards.

My first point is in both cases, you don’t have to learn all the inner workings of either standard to make good use of it. You either:

1) Learn and choose to leverage only the most useful bits of the standard that are relevant for your project. For example, most every Java EE developer has utilized the standard’s messaging, JDBC connectivity, servlet engine and garbage collection. Most everyone skips the container based persistence model. Same thing with WS-*. I think most enterprisey folks would say WSDL is pretty useful and BPEL and WS-RM are getting a lot of pickup. But that doesn’t mean you have to use the other 20. Or you:

2) Utilize some combination of tools and platforms that hide the complexity of the underlying standards. For Java or C#, these are abundant, from app servers of all shapes and sizes to IDE’s to model-driven code generators. For XML and the WS-* stack, it’s still early days, but we’re starting to see tools and runtimes emerge. Sure they’re incomplete, slow and often difficult to use, but does anyone remember Java circa 1997?

My other point is that this evolution of the WS-* stack further reinforces a trend that’s already apparent to some: XML is the platform. Those of you who already read or write about the “programmable web” are probably saying “duh” right now, but I think that’s still a small minority of the tech community. I had a rather extensive discussion on this with my fellow Enterprise Irregulars and I heard back a variety of suppositions like “EC2 is the next major platform” or “Apex could be the next platform.” Nein. XML is the platform. Say it to yourself, think about it, sleep on it and be born again.

When XML fully realizes its potential as the next major platform, it's going to have a much greater impact than what most people anticipate today.

[Platforms], [XML], [WS-*]

Vinnie joins SAP?

2007-04-01T11:32:00.000-07:00

Thomas' April Fools post lasted about 3 hours before Vinnie woke up and negated it. It's a pity, I thought it was quite plausible. We all know negotiating discounts out of vendors no longer presents a challenge to Vinnie. By joining SAP's pricing committee, Vinnie can face the only true remaining challenge: negotiating with himself.

End of an era

2007-03-29T06:41:00.000-07:00

SAP hired me out of graduate school and for reasons unimportant to this story, I had to go through a rather extensive set of interviews to get the job. The final stop on the tour was a 45 minute interview with Shai Agassi. At the time, Shai was responsible for NetWeaver, some xApps and a partner organization.

In the weeks preceding my interview, almost everyone I met at SAP had something to say about Shai. Typically it was something like “We’re so lucky to have a leader like Shai” or “Shai is just so smart that…” I had heard this so frequently that I was starting to doubt that I would take the job as I am extremely suspicious of cults of personality.

My Shai interview started with a few simple questions about SAP’s product strategy that quickly expanded to fill the entire allotted time. He had a rhetorical style, never making statements, just asking questions. You could tell the questions were intended to lead you to a certain place, but at the same time he was hoping you’d produce a surprising answer so he might learn something too. It felt good to be intellectually stretched but also to be respected. By luck or skill, I passed the interview and took the job. Over the course of the past 2 years, I’ve had a handful of other interactions with Shai. He’s technically deep, strategically smart and most importantly has exceptional empathy. It’s been a kick to get some time with him over the past few years and if he made this sort of impression on me, you can imagine how it’s been for those that worked with him day in and day out. I’ll close with a few of the things at SAP that are forever changed because of Shai:

- SAP is a credible player in the market for infrastructure software

- SAP is a platform company

- SAP is the most globalized high tech company in the industry

- SAP has released countless new products in the past 5 years (XI, Duet, CAF, MDM, xRPM, GRC, etc)

- SAP has a new generation of executive talent that will leave a lasting impact on the industry

- SAP has an ecosystem where software partners can thrive and make money

So I’m not going to pretend to bury Ceasar, I’ll just come right out and praise him. For the rest of us, I think the lessons are: 1) Think big. 2) Do your job like you’re not afraid to lose it. 3) Show passion, and the team will be passionate too.

Good luck Shai, you’ll be missed.

Oracle hearts Tangosol

2007-03-26T19:48:00.000-07:00

In other news, Oracle recently acquired Tangosol, a Somerville, MA based middleware software startup. Tangosol is an impressive company with an impressive technology. At its core, Tangosol does data caching and session management for high performance applications. So if you have clustered applications, it enables you retrieve and persist data very quickly and in a way that preserves transactional integrity.

Tangosol was a real Joel Spolsky type company which is why I’m all the more pleased to see it come to a happy ending (minus having to work for Larry). Tangosol started with a bunch of smart geeks and no venture investors. They managed to get several releases of their product out during the technology recession of 2002 and 2003. My sense is most of their customers came from word of mouth through the developers that frequent sites like The Server Side. By the time they were acquired I’m guessing they had well over 100 customers.

I’m not really sure why IBM or BEA didn’t buy Tangosol years ago. In my opinion, they are the rightful owners for a technology like this. But they didn’t get off the dime and now it’s Oracle’s which I think IBM and BEA will come to regret.

Updated (thanks for the correction Geva and Shalom): Tangosol leaves behind a handful of competitors including Gemstone, Gigaspaces and Terracotta Technology. Interestingly, the degree of market traction for these companies seems to be inversely correlated with the amount and prestige of the venture capital raised. Teracotta has since open sourced their product which seems to be the new last resort move when you’re trailing the competition. Like the other companies that have purused this strategy, I'm skeptical this is a viable way to vault ahead of the competition. Meanwhile IBM and BEA could still use this sort of asset so I'm guessing you'll see something play out similar to what happened when the app management vendors (Cyanea, Wily, Xaffire, etc) got snapped up. In this game of musical chairs, why does the market always seem to generate one more startup than there are available chairs? Same story in ESB. Same story in data integration. Same story in app management.

Germany doesnt just make software for great big companies...

2007-02-17T10:41:00.000-08:00

Germany makes great big bunnies too:

Google in the enterprise part deux

2007-02-08T23:05:00.000-08:00

I found this article that Google is planning on charging enterprises for their newly-acquired/built webapps like Google Docs.

I thought this sort-of announcement was pretty poor timing as many are starting to wonder if Google can get anything right besides search. Witness:

Blogger was down for an extended period of time last Wednesday.

Their Groups product has poor performance and almost daily glitches.

Their Gmail periodically seems to drop messages (or possibly munches them in the spam filter). And other people experience rather frequent Gmail outages.

Now their Finance product is also crashing

They lure you in with the sexy front-end and then they disappoint you with terrible reliability. The ever-present “beta” label may work in consumer web, but that’s not going to fly as an excuse in the enterprise.

This stuff is free to me, so I suppose free is as free does and I put up with the erratic performance. But if you start charging customers money they’re going to start, like, expecting things from you. They’ll want you to do really unusual things like fix a bug, keep a system running or stick to a deadline. Given what a drop in the bucket Google Enterprise revenues are for the overall business, I'm skeptical that the tail's going to have permission to wag the dog.

[Google]

What's the big deal about Enterprise 2.0?

2007-01-31T21:26:00.000-08:00

Entire blogs are dedicated to covering the topic, and we can’t forget the exceptionally tortured semantic debate over what would be allowed to live under the Enterprise 2.0 tent.

There are many opinions on what defines “Enterprise 2.0.” I myself lean towards Andrew McAfee’s definition. If Enterprise 2.0 comes to mean “anything new happening in the enterprise,” it becomes a meaningless term.

I fervently believe in the value of collaborative, emergent technologies like blogs, wikis and tagging. I also believe it’s inevitable that this stuff permeates the enterprise. Working for a software company I consider myself to be the quintessential knowledge worker. No accident that many of these tools are already heavily utilized inside of SAP. The underlying philosophy of Enterprise 2.0 strikes me as highly simpatico with the true nature of knowledge work:

- Iterative
- Cross-organization, cross-geography
- Knowledge intensive
- Collaborative

But is Enterprise 2.0 a big deal? Here I’m not as sure. When I hear things like knowledge and collaboration I think Lotus or Microsoft. Does Enterprise 2.0 just mean “groupware 2.0?” This is fine and good, but relatively unexciting. Every 10 years or so a new groupware format takes hold in the marketplace: e-mail and message boards are two good examples of this. If Enterprise 2.0 means “keep your eyes out for the next Lotus,” I’m not sure what all the fuss is about.

Let’s contrast this with the internet which was definitely a big deal in the enterprise. The internet:

- Changed core business practices
- Altered the mix of users of enterprise technology
- Enabled completely new enterprise technology markets to form like SRM, Content Management, SOA, E-Commerce, etc.

You could do the same exercise with client-server and realize this too was a big deal in its day. Apply the same exercise to Enterprise 2.0 and it comes up short.

What in my mind keeps Enterprise 2.0 on the cusp of big deal status is its latent potential to work alongside traditional enterprise applications to enable businesses to do new and cool things. Enterprise applications are typically predicated on rules, constraints, policies, controls and processes. Groupware applications are typically predicated on open workspaces, threads, iterations and tacit knowledge capture. These two domains seem so distinct when you sit down to use the software applications they look as if they came from two different planets. But in fact most of our jobs require us to sustain both modes of work simultaneously. I may be a knowledge worker, but I don’t operate completely outside of policies, processes or budgets. Sometimes those processes and policies actually help me.

The questions in my mind are:

1. Should we combine the emergent with the routine? What significant things can you do for the business if you do?
2. How can you combine these two different paradigms? I think there are a couple of different candidate approaches here that are equally valid.
3. What are the killer apps for this converged world? If we can imagine multiple large markets stemming from this convergence, we’ll know we’re onto something.

I think that’s enough for now. If this sparks some discussion or response, I may flesh out some potential answers to these questions in future posts.

[Enterprise 2.0] [Emergent Software]

One more 2007 prediction on Web 2.0

2006-12-30T09:58:00.000-08:00

I loved this Wall Street Journal article that Sadagopan found. It’s a debate between Todd Dagres (formerly of Battery Ventures, now at Spark Capital) and David Hornik (at August Capital) on whether or not we are in a Web 2.0 bubble.

First and foremost the article is interesting, but the sweetener is how perfectly Todd and David embody the East Coast/West Coast high tech stereotypes.

Todd Dagres’ picture depicts him as the classic masochistic east coast curmudgeon VC. Surprise, surprise, Todd thinks Web 2.0 is overrated and a bubble.

David Hornik has that beatific look that you only see on a guy who experiences 300 days of sunshine per year. Surprise, surprise, David is the optimist who thinks there’s still gas in the Web 2.0 tank.

I think both sides make good points and while I count myself as a crotchety enterprise technology guy, I have to side with David.

Signs it’s a bubble

Investors don’t know what they’re investing in

This was a hallmark of the Web 1.0 bubble and it's back in Web 2.0. Picking winners has never seemed more like guesswork; and when veteran investors with a lifetime of experience in semiconductors start backing web calendaring companies, you should start to fret a bit.

Large incumbents wait in the wings

As the last bubble was bursting, incumbent retailers and enterprise technology vendors started to close the distance between themselves and the upstarts who had been eating their lunch. I have to belive that incumbent media companies have a similar ability to, after a great many years, learn and adapt to this new world. Witness Newscorp and InterActiveCorp.

Signs it’s not a bubble

There’s not very much money at risk

With a few exceptions, individual Web 2.0 companies have take down very little capital, and in many cases none. Moreover the few Web 2.0 companies that have raised big bucks have done so only after they’ve shown tens of millions in revenues with some positive cash flow. This is a stark contrast to the last bubble where $20 million B or C rounds were going to companies with small revenues or a big cash burn.

The Web 2.0 fatality rate looks quite low

In Web 1.0, a company’s fixed costs were relatively high and revenues came from commerce which has low gross margins and can be volatile. When those businesses slowed down, revenue could zero out and fix costs would quickly bury you. With Web 2.0 businesses, your fixed costs are quite low and your primary revenue source (advertising) is high gross margin and less volatile than commerce. I think it’s likely we’ll see a number of Web 2.0 walking dead, but not so many expensive Web 2.0 fatalities.

There do seem to be barriers to entry

You have to ask yourself why no one has challenged MySpace’s user base or revenues. Same question for Facebook, YouTube and Flickr. Then look at Google’s inability to gain market share in areas like e-mail, instant messaging, peer payments, commerce, etc. This stuff does appear to be sticky, either due to user network effects or other forms of lock-in.

Web 2.0 is not an overfunded category

I did a quick and dirty comparision of Web 2.0 to the relatively non-bubbly software industry.

According to VentureOne, in the last 12 months, venture capitalists invested $455 million in Web 2.0 companies. During those same 12 months according to the PWC MoneyTree survey, venture capitalists invested roughly $4,300 million in software companies.

In 2006 worldwide online ad spending was approximately $17 billion (Jupiter) This is projected to grow to $26 billion by 2011.

In 2006 worldwide software spending was approximately $165 billion (extrapolated from SIIA figures). The industry is growing at roughly 5% overall so by 2011 it should be at around $212 billion.

Through the magic of long division you can compare ratios.

So based on today's market sizes, Web 2.0 is sanely funded relative to software. Every dollar of venture investment is chasing roughly 40 dollars of market opportunity. But the future size/state of markets is more salient for long term venture investment. By that yardstick, Web 2.0 is still underfunded relative to software with one dollar of venture investment chasing 63 dollars of market opportunity.

To net it out

I don’t think 2007 will go down as the year the Web 2.0 bubble burst. If venture investing in Web 2.0 doubles during the course of the year, then 2008 is going to get ugly. For now the current pace looks sustainable.

[Web 2.0] [Venture Capital] [2007 Predictions]

A few 2007 predictions

2006-12-27T21:22:00.000-08:00

As we’re in prediction season, I'll indulge in a few of my own:

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

In 2005 and 2006 we’ve seen Fuego, Infravio, Blue Titan, Actional, Collaxa, Systinet, Proactivity, The Mind Electric and Sonic get snapped up. Still at large are Amberpoint, Savvion, Lombardi, Cape Clear, Fiorano and Above All Software.

No open source companies will exit throughout 2007

This will give many VC’s jitters about the $400 million laid out over the course of 2006.

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

This will happen just in time to prevent observers from making the apples-to-apples same quarter comparisons that have been next to impossible for the last 2 years. I know what you're saying right now: "Oracle will acquire someone? Very impressive Nostradamus."

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

Probably NetSuite, Successfactors and at least one more.

Tech boom enterprise applications startups come back to life

It’s been a long, hard, and capital-inefficient road for venture backed enterprise applications companies, most of which got their first funding more than 5 years ago. But customers are wrapping up their cleanup and digestion period and are ready for new products. Pure play vendors in Contract Management, Pricing, and Supply Chain Optimization, will all do solid double digit growth.

That’s all I’ve got for now. I’m looking forward to checking back on everyone's prediction accuracy in 12 months.

[2007 Predictions]

5 things you didn't know about me

2006-12-21T19:46:00.000-08:00

Alright Jason, I’ll take your tag. 5 things about me:

I am an extremely bad but persistent surfer

Favorite local spot is Bolinas, a sleepy surf town for ageing bay area hippies and out of shape yuppies.

Everyone in my family is an economist

Myself (B.A.)

Brother (PhD)

Father (PhD)

Mother (MA)

I’m a bit of a contemporary art buff:

Favorite artists include

Joseph Beuys

Bill Viola

Pipilotti Rist

Miguel Calderon

Andreas Gursky

815 is my lucky number

I was born on August 15th
At 8:15 at night
And weighed 8 pounds, 15 ounces

True story.

I’m a live music fan and try to see as many shows as my work and travel permit

I also needlessly obsess over missing the all time greatest concerts that I was too young or too square to attend:

U2 at Red Rocks

Talking Heads Stop Making Sense tour

Velvet Underground reunion in Prague

The Flaming Lips’ Boombox Experiments

I'll tag Nick Carr, who wrote my all time favorite quote on a blog:

I think the word "delight" should be banned from all business writing.

Amen to that.

Happy hollidays,

Charles

[Charles Zedlewski]

Why I work in enterprise technology

2006-12-18T21:29:00.000-08:00

This article in the weekend’s New York Times sums up perfectly why I work in enterprise technology and not consumer web. If you haven’t read it, the article interviews a few VC’s who are increasingly using feedback from their kids to make investment decisions in consumer web companies.

I haven’t been in too many VC partner meetings (OK, I haven’t been in any), but when I picture a bunch of partners contemplating an enterprise technology investment, I imagine it sounds something like this:

“How many customers have paid money for this product so far?”

“Did they get the return on investment they anticipated?”

“How long did it take them to evaluate and install the product?”

“How many similar customers are out there who could buy this?”

“How likely is it that IBM can get into this market?”

Etc, etc.

The NYTimes article confirms my greatest fear that the same VC partner meeting evaluating a consumer tech investment is more like:

“I dunno, I wouldn’t use it.”

“Yeah, well I would use it.”

“My daughter has 400 friends on MySpace and she wouldn’t use it.”

“Well my nephew has two iPods and a Zune wired into his Lego Mindstorm and he’d use it.”

Consumer is a lot more lucrative than enterprise right now, but the last tech bubble taught me that if you don’t have some comparative advantage to offer, you're probably working on the wrong topic.

[venture capital], [consumer technology]

Failure as a product strategy

2006-11-10T06:37:00.000-08:00

One of the companies I most admire is Zara. The Spanish retailer turned many industry assumptions upside down including:

- Foregoing the 4 season approach to product releases

- Creating a supply chain that can get a sketch into clothes in 100+ stores in 2-4 weeks

- Deciding that stock-outs were a good thing, leading to scarcity and desirability

If you want to learn about Zara, you can read the case study attached here.

One of the less discussed implications of the Zara model is how it changed the traditional concept of merchandizing.

In a typical soft line retailer, you have a bunch of people called merchandisers. Merchandisers are as close as you get to experts in subjects like “what today’s modern woman wants to wear,” or “what’s deck for the 20-25 year olds.” They try to figure out what the consumer wants to buy and then they make a number of decisions about what to put in the retail store. Collectively this is their “line” for a particular season, and this whole planning process might happen 6-12 months before the launch of that season.

Because of the speed and efficiency of its supply chain, Zara makes it cheap to fail. And because it’s cheap to fail, Zara can be much less deliberate with merchandizing. Consequently Zara ships roughly 12,000 different styles each year. Ideas for these styles come less from expert merchandisers and more from suggestions from the stores themselves. It’s OK to throw a bunch of spaghetti on the wall to see what sticks so long as spaghetti is cheap and abundant.

Looking at Zara's financial performance, this seems to work. A dozen cheap experiments, half of which fail, seem to work better than the few careful bets of the expert tastemakers. This is a pretty profound shift in mindset, from “how to we increase our probability of success?” to “how do we decrease our cost of failure?”

I think the software industry is experiencing a similar change in mentality as more and more software development moves to a “brute force” method of product design. This is something that software as a service, open source and agile development have in common: they’re very cheap to fail.

- SaaS products can introduce a new feature and if it fails, can withdraw the feature fairly quickly without much cost for rolling the feature back.

- Open source products get new features all the time from engineers that work for free. Bad feature? Throw it out and it didn’t cost you anything.

- Software products built using agile can course correct mid-project without throwing an entire release out the window.

I think we’re going to find the brute force approach to software product development appearing in more and more places over time. Cheap to fail may become an industry’s new competitive weapon.

[Strategy], [Product Management], [SaaS], [Open Source], [Agile]

On leadership

2006-11-02T23:31:00.000-08:00

Dave Lorenzo’s recent post pointed me to this article on leadership that really struck a chord. I’ll start by saying “read the article,” but I also want to try to paraphrase and extend it a bit because I think the ideas are pretty important.

In business, it’s an unquestioned reflex to say that companies need leaders and good leaders are hard to come by. Why is this?

Herzberg would say leaders help lift people up Maslow’s hierarchy of needs

Peter Senge would say leaders draw people up the ladder of commitment from being simply compliant with their company’s policies, to becoming committed to its mission.

The concept is the same: leaders draw the best out of people around them. So having a leader on your team or in your company is like having a multiplier: the leader produces output, but better still he or she ups the performance of everyone he or she is in contact with. It’s like getting a 2-fer or a 3-fer out of one hire.

OK, so we all agree, leaders = good. I find however that most people disagree on what leadership is and where it comes from. There’s the “are leaders born or made” question or the “leadership vs. management” question or the “can leaders be taught” question or the General Patton model of leadership vs. the Vince Lombardi model of leadership. Just reading the wikipedia entry on leadership gives you a sense as to how many conflicting concepts and models are out there.

But the article gets it right: in its most distilled form, leadership stems from self-knowledge and integrity. The integrity part is pretty simple; people won’t go the extra mile for people they don’t trust. But the self-knowledge bit is less intuitive.

Why does leadership stem from self-knowledge? A few reasons:

- Knowing yourself means you know what fulfills you which makes you confident in your own decisions. This in turn inspires confidence in others.

- Self knowledge implies you have embraced your own weakensses and gaps in thinking. This gets you halfway home to surrounding yourself with people who complement you rather than compliment you.

- Self knowing people are authentic, and other people trust and enjoy being around authentic people. Bill George, a fantastically successful CEO, wrote a book just on this topic.

I think the software industry does worse than most when it comes to identifying and cultivating leaders. I suspect this is because:

1. Our industry is more fixated on tenure and knowledge (e.g. “must have 10 years experience managing engineering teams that develop analytic supply chain software”).

2. Our industry is made up of mostly logical deductive thinkers who, understandably, tend to find this self-knowledge stuff a bit suspect and new-agey.

If you can get past the Tony Robbins speak, there’s a lot to be mined here. As it’s built entirely on people, I’d like to see our industry cultivate its Joel Spolsky of leaders.

Partnering advice

2006-10-17T09:15:00.000-07:00

I’m in Amsterdam this week for SAP’s Enterprise Services Partner Summit and TechEd conferences. In addition to a number of work meetings, I’m spending a fair bit of time in the blogger’s corner along with Dennis Howlett, James Govenor, David Terrar , Sigurd Rinde and Prashanth Rai.

The Partner Summit is a good occasion for a post, as I’ve spent most of this past year working with software companies who want to partner with SAP. Having seen some of the good, the bad and the ugly of this experience, I thought I’d write up some tips for software companies who want to get in good with SAP. I suspect most of this advice is valid for the other big platform companies as well.

Before I begin, when I say partnership, I don’t mean the press release or logo on the website sort of partnership. I mean the really good kind of partnership where SAP sales reps everywhere know the name of your company. I’m a firm believer that these kinds of partnerships are acts of pure hard work and discipline. Contacts, charm and a good game of golf are only marginally useful. OK, on to the tips:

Know when you are ready to partner

If you’re a company with 5 employees and no customers, don’t waste your energy trying to get SAP to help you with your first sales. This is axiomatic for partnering generally: no one will help you sell unless you’ve proven you can sell on your own first.

Power By NetWeaver

Running on the SAP platform is the entry point for almost every other kind of product, marketing or sales collaboration you’d like to do with the company. Hemming and hawing about the urgency to do this will not find a sympathetic ear. Bonus points if you leverage the technology in interesting ways or create usage for less popular parts of the stack.

Find a good champion

You will eventually need lots of people to back your company inside SAP, but get that one enthusiastic champion first. Note that enthusiasm and determination is more important than seniority. A 1 hour meeting and a polite nod from a Senior Vice President is not worth as much as an energetic line manager who will introduce you around and talk to you on a weekly basis.

Don’t try to find “the decision maker”

There is rarely a single unilateral decision maker at SAP for most topics, but not a chance for something as multidisciplinary as partnering. That drives a lot of people batty, but them’s the brakes. No one person can force your partnership through SAP, but many people can stop it. Work with your champion to draw up a list of all the different influencers you need to meet and mollify prior to pressing for a partnership.

Make sales successful

What? I thought I was partnering with SAP to make MY sales successful? Yes, true, and that can still happen, but you need to get some advocates in sales that can associate you with some key customers who need your solution. That’s what elevates your company from a theoretical exercise to a revenue opportunity just waiting to be tapped. I am not saying “bring us a deal” (which I find inconsiderate and arrogant). But you have to find a few customers on your own anyway right (see first axiom)? Why not pursue opportunities that sync with the SAP install base and enrich existing customer investments in SAP products? Why not inform the SAP account executive for that customer while you’re at it?

Commit

If you’re a 50 person company and you’re working on SAP, IBM, Oracle and Microsoft, you’re working 3 companies too many. The big companies are interested in long term, committed relationships. If you’re flitting about, it makes you appear unfocused and spread thin. If you’re a 1,000 person company, that’s a different story. No one will begrudge you for having more than one friend.

Let the real work begin

Many companies underestimate how much work is left to do once the ink on the partnership agreement is dried. Draw up your SAP invasion plan. Let’s say your beachhead is the European automotive team. Do you have that beachhead locked up? Have you met the account execs, the sales engineers, the value engineers, the solution managers and industry principals? If so, then what are your plans to get to North America? How are you going to get into aerospace?

Hopefully there are a few good nuggets in here for those of you who are considering taking a run at SAP. Good luck!

History repeats itself

2006-10-11T00:09:00.000-07:00

Blue Steel? Ferrari? Le Tigra? They're the same face! Doesn't anybody notice this? I feel like I'm taking crazy pills!
- Mugatu

Salesforce.com recently announced the launch of Apex, and judging by the early response from the industry, this Apex thing is nothing short of the second coming:

Marc Benioff calls it “the most important announcement Salesforce has ever made.”

In fact, says Benioff: “Now that anything can be built on demand, no corner of enterprise software is safe.” Muah ha ha ha! (added for effect)

Mark Gorenberg at Hummer Winblad called it “the biggest thing since the stored procedure.”

Nick Carr says “what Salesforce is doing is certainly part of a big tsunami in business computing”

Dan Farber says it represents a “shift in the software landscape.”

Phil Wainewright says “The conventional licensed software market hasn't seen anything like this.”

Forget waiting in line to pre-order a Playstation 3, I’m going to run down to the Moscone Center with cash in hand to get myself some of this Apex! Wait, what exactly am I supposed to be buying?

A programming language.

Based on an 8 year old technology (Java & SQL).

That’s not in beta yet.

Well, maybe that’s still big news. Just to be sure, I jumped into my way back machine to see if our industry has every seen anything like it before:

Oracle has PL/SQL
PeopleSoft has PeopleTools
Siebel has Siebel VB
SAP has ABAP
Now Salesforce has Apex… but somehow this is the biggest thing since client-server.

I whipped up a quick comparison of Apex to a few of today's many application specific languages. I'm not an engineer by trade so any and all corrections are appreciated:

And all of these languages are procedural. None of them are portable to other application platforms.

Mind you I have nothing against Apex, but hearing leaders who average 25 years in the industry promptly ignore their own 25 years of experience leaves me scratching my head.

To Apex itself, credit where credit is due:

Apex is arguably cooler than its predecessors. Things that are shiny and new always are. Of course things that are shiny and new also have no developer community, install base or ecosystem, but who am I to bring facts into the discussion (they call it Dreamforce for a reason I suppose)?

The runtime for Apex purportedly does some nifty stuff to enable developers to write customizations, run code in a multi-tenant architecture, all while preserving upgradeability. This is not easy to do. Over the course of the next year, we’ll learn more about how confining Parker Harris made his sandbox to achieve this and how easy it is to build different types of castles.

Apex makes Salesforce applications much more customizable than before and this will increase their viability in more demanding environments. It will also increase their cost and complexity. Hate to be the guy who says "I told you so," but 6 months ago I wrote how the closer SaaS got to meeting the needs to the large enterprise, the less distinct it would become from on premise.

This was a necessary step for Salesforce to take and I suspect it will make them more attractive in the large enterprise. I seriously doubt however that Marc will get many takers for those $20,000 cubicles. The reason why there are very few blockbuster startups built on ABAP or Siebel VB or PeopleCode is the same reason why you won’t find many on Apex.

IBM's patent play

2006-09-27T18:39:00.000-07:00

IBM announced yesterday it was going to increase the transparency associated with its patent activity including publicizing patent filings, refraining from using dummy corporations to conceal the true patent filer and refraining from patenting generic “business methods” patents.

I was going to post a kudos to IBM for taking these steps but there were already so many positive comments I thought I wouldn’t be writing anything new. Today however blogging buddy Jason Wood takes a lashing from Jim Moore who informs us Jason has been “sucked in by corporate Amerika.” (why this goofy spelling of America!?!?)

Reacting to a post on patents from blog with a url of “law.harvard.edu” means I’m putting my head in the lion’s mouth, but here goes:

I think Jim Moore’s critique is pretty far off the mark in several areas:

1. Jim calls IBM’s move “conspiracy disguised as reform.”

First, Jim never clearly articulates what this supposed conspiracy is.

Second, it’s difficult to see how added transparency can ever be construed as a conspiracy.

Third, if this is some sinister trap on the part of IBM, other industry players can easily escape Mr. Palmisano’s clutches: don’t play. IBM is making this move unilaterally, with no obligation on the part of its competitors or collaborators.

2. Jim thinks our patent system is not broken.

I’d recommend Jim read “Innovation and Its Discontents” by Adam Jaffe and Josh Lerner. There are several real problems with our patent system, at least for the information technology industry:

- The resource imbalance between industry and the US Patent Office. Industry has a lot more money to spend on patent filing than our government has to review. Currently there are 500,000 patent filings in backlog and that backlog is growing at the rate of 100,000 per year.

- The issue of uniqueness. Today many patents get through the PTO that are of questionable uniqueness. The PTO should filter these out but they’re so heavily outgunned by industry both in staff count, time and domain specific pedigree that it’s difficult to catch many of them. Once a company gets a non-unique patent through the PTO, it takes millions of dollars of litigation to un-ring the bell.

3. Jim thinks patent trolls are a myth.

Most companies are not patent trolls. But if you:

- Hold a patent of questionable uniqueness and
- have not made any attempt to commercialize the patent ten years since you filed it and
- have no ongoing business activities and
- exist as a holding company that does nothing but sue other companies

Then yes, you are a patent troll…

Does anyone remember Rambus? Or Unisys and the GIF format? I just heard of a patent that was approved for a software technology to print information found on the web. Come now. How can we possibly say the patent system is on good shape with examples like these?

4. Jim casts IBM’s move as a “big guy vs. little guy” attack.

Believe me, under today’s patent system, the little guy has a lot more reason to be afraid of IBM than the other way around. IBM has over 40,000 patents today. If you’re starting a software, hardware or semiconductor company tomorrow, chances are IBM can find a way to call you out for violating one of their patents. Wouldn’t transparency into IBM’s patent portfolio help new companies avoid this?

Moreover, why not read the links Jason posted to his blog? You see that the entrepreneurs themselves are asking for this increased transparency, as are the investors.

The little guy seems to disagree with Jim. Let's allow him to speak for himself.

5. Jim notes that given the high rate of innovation in the US, the patent system must work really well.

I’m pretty happy with the rate of innovation in the US too. Does our current patent system necessarily deserve the credit? How about the university system? Or the venture capital community? Or the ease with which you can start a business in the US? Or the rewards of the public capital markets? Or the flexible labor laws? Or the (formerly) attractive US immigration policies? I’d like to find causation between US innovation and when I was born, but somehow I don’t think that’s the case…

6. Jim argues patents can’t be too big of an issue because corporations don’t spend more than 1% of revenues on IP litigation.

Lawyer’s fees are a small fraction of the true costs of distortions in the patent system. How many billions of dollars in valuation did RIM lose because of threat of a shutdown? How much damage can you do to a company when you file an injunction a few weeks before its IPO?

IBM’s decision was not just admirable because it’s a step in the right direction for the patent system, but because IBM demonstrated what leaders in the tech industry need to do: show leadership. Kudos are still deserved.

SaaScon 2006

2006-09-25T20:34:00.000-07:00

I attended a few of the morning sessions of the Software as a Service Convention currently under way in San Francisco. The primary attractor for me was the “Emerging SaaS Trends” panel discussion with Anne Winblad of Hummer Winblad Venture Partners, Tod Loofburrow of Authoria and Robert Jurkowski of Intacct.

The panel was light on contrarian views, so I found you needed to do some filtering to find the unique SaaS insights from the straw men the panelists enjoyed picking on.

What was eye opening:

I didn’t recognize 80% of the SaaS vendors mentioned. I like to think I’m pretty up on who’s doing what, and of course I know Salesforce, NetSuite and RightNow. Behind these more hypey SaaS vendors is a larger array of companies that are almost under the radar by comparison despite having strong revenues and customer lists. A number of these were in the HCM area including Authoria, Employease and Concur.

The capital markets are sending a clear signal to the venture firms that better exits await SaaS companies. Anne Winblad mentioned that several SaaS vendors are making it through the IPO window today and their stocks are holding up post the IPO. This is a striking contrast to on premise perpetual license vendors who are having a tough time getting liquidity. Consequently Hummer Winblad has to date funded 13 SaaS companies.

A benefit I had not thought of for SaaS is a new take on the "one throat to choke" factor. When something goes wrong with your on premise software, you spend a lot of time figuring out if it’s a hardware problem, a database problem, an application problem or a network problem. With SaaS, this all becomes the vendor’s problem which is a nice perk for the customer.

The channel is still trying to figure out what to make of SaaS. Historically the channel profits from complexity, and SaaS tries to shun complexity. It will be a few more years before SaaS resolves its relationship with the channel.

What was predictable:

There was an audience poll at the beginning of the session. One question was “how big is your company.” True to the stereotype, about 20 hands went up for companies under $50 million in revenue. About 5 hands went up for companies over $50 million.

CEO of Intacct stating that on premise vendors can’t succeed in the SaaS market because “we are the disruptors” whereas the incumbents “have the wrong DNA." Note to Robert - Siebel, I2 and Ariba all made similar claims 6-7 years ago.

SaaS companies build for and sell to the user whereas on premise companies build for and sell to the buyer (e.g. someone at corporate like IT or the CFO). The two “camps” serve somewhat different masters and this drives their R&D priorities.

What was panelist overreaching:

A supposed SaaS advantage is "best practices and templates." This has been part of on premise business applications for 7 or 8 years now.

Another supposed SaaS advantage is multi-entity (e.g. a parent corp and subsidiaries) support. This has been part of on premise applications for more than 10 years.

Yet another claim was that SaaS vendors are more accountable. “If you don’t like what your SaaS vendor is doing, just turn it off,” says Tod Loofburrow. Really now. It’s no easier to shut down a mission critical SaaS implementation than a mission critical on premise implementation. It’s very, very painful any way you slice it.

Overall, time well spent. Phil Wainewright also has a post up from the conference. Hopefully there will be more in the next day or two.

SOA and the business application vendors

2006-09-05T14:09:00.000-07:00

A fun little meme popped up recently reacting to Bruce Richardson’s “SOA is ERP’s doomsday scenario” note. Joe McKendrick and Prashanth Rai proceded to jump on the same bandwagon of prognostication.

What’s so entertaining about this discussion is Bruce’s scenario is actually SAP’s intended strategy just labeled as “doomsday.” I don’t mind Bruce doing this. As an analyst, giving press-worthy quotes is his stock in trade. But thank you Bruce for explaining to everyone that the future state of the enterprise IT environment is exactly the same as what SAP has been preaching for the past 3 years:

There will be a customer IT backbone built by a large applications vendor
It will be exposed to customers through a repository of enterprise services
Customers will extend these services to create all kinds of differentiated apps

Now the part Bruce forgot to add:

The more apps that leverage these core services, the more value SAP delivers to its customers So: customer is happy, SAP is happy, ISV’s are happy

The question remaining is who is meant to play which roles?

Who will create the new applications that extend enterprise services?

Some speculate offshore vendors. Others speculate startups. Still others speculate internal development groups. What’s noticeable is no one speculates the large application vendors will do the majority of this, including the major applications themselves.

Rather than presume that SAP can have a monopoly on all the bright ideas in the software industry, it’s a much smarter bet to cultivate a community of other companies, consultants and professionals that can have 100,000 as many bright ideas. Hence you see big SAP investments in the internal development groups and in the ISV community that will utilize these services. In short, we’re already taking all comers.

If THIS is doomsday according to Bruce Richardson, clearly SAP is saying: "bring it on."

Who will create the services middleware?

Here everyone in the vendor community is getting into everyone else’s business; from WebSphere, to NetWeaver, to WebLogic, to .Net to Fusion. I could (Shai would probably say should) make many arguments for the SAP camp, but let’s let the market share reports do the talking over time.

Who will create the services?

A mix of internal development groups, systems integrators and large application vendors all believe they’re service creators. In the end, all 3 groups will contribute but IMO, not equally.

Customers and SI’s have several disadvantages if they were to build up a large services library on their own:

1. Creating 3 or 4 services per incremental project has a limited value. Again, it’s all about the value of the network effect. I said it a few months ago. Jeff Schneider also did a good job of explaining why this is so.

2. Creating services has limited intrinsic ROI for the business and so it’s difficult to argue for funding for a large service creation exercise. Christopher Koch at CIO magazine explains why.

3. Doing service creation is easy. Doing service creation well is very hard. You really do have to understand geeky stuff like service granularity, standards, semantic interoperability and the like. Here’s an explanation from the same CIO article on why this matters.

Maybe we’re just terribly inefficient, but this process has cost SAP more than two billion dollars to date according to Merril Lynch. Some companies can afford to make a comparable investment, but not many.

I'll take Bruce Richardson's doomsday note as a backhanded compliment. Thanks for the well wishes!

Open source inches closer to traditional software

2006-09-02T08:36:00.000-07:00

You could cut the cynicism with a knife in Marc Fleury’s recent post on the Jboss blog. Marc covers a number of topics in his post but a large percentage is dedicated to evaluating the potential of Oracle to enter the Linux market and potentially distribute and support Red Hat’s Linux. In the process he does a great job of explaining why professional open source has as much vendor lock-in as proprietary software.

Questioning if Oracle could successfully distribute Red Hat Enterprise Linux (RHEL) Marc suggests:

“See, nowhere in the GPL is it said that we must distribute the software to you in the first place. Dion Cornett likes saying GPL != Public Domain. In fact, in the case of RHEL, RedHat doesn’t distribute it to anybody, not for free that is.”

Translation: “Linux is open! Unless it’s RedHat Linux in which case it’s mine, all mine.”

Marc goes on to say:

“If you want to have the software, you must subscribe to RedHat Network (RHN) and if you redistribute the patches or RHEL (which you can) you must pay us for every instance, if you don’t, well, we are under no obligation to give you the future patches and upgrades, in other words, we cancel the RHN distribution to you and you are technically /forking/ RHEL.”

Translation: “You know how frequent patching to improve quality was one of the benefits from the open source community? We own that now too. Share it and you're out in the cold."

“Ok so let’s assume Oracle forks RHEL instead of assembling a new distribution, which would bypass the cost and time described in the above paragraph. IT IS STILL A NEW DISTRIBUTION, technically it is not RHEL and the second he does this, it is not the same product. In fact, the applications that are certified on RHEL will not be certified on the fork.”

Translation: “Even think about moving off our certified distribution and all your apps running on Linux will start to break.”

The open source revolution is apparently proceeding as planned…

Truly great software development

2006-08-19T15:09:00.000-07:00

It’s vacation time, and a happy byproduct of vacation is a chance to catch up on my reading. I’ve always been fascinated with the seminal software systems development projects that have taken place over the history of the industry.

The History of Software has a good retelling of the development of the first real time air defense system (SAGE) which at one point employed more than half of all of the software engineers working in the United States.

I’ve read The Mythical Man Month several times over, which is a collection of lessons learned from IBM’s OS 360.

This vacation I recently finished Showstopper!, an inside view of the development of Windows NT, led by the widely respected Dave Cutler. Four years and over a $ hundred million in the making, NT was a moonshot effort that’s shown incredible longevity. Now 15 years old, the kernel of Windows NT is still essentially the core of today’s Windows Server and Windows XP operating systems. The book does a great job of describing the different key contributors, their personalities and how they intermeshed, which neatly sums up pretty much all there is to learn about successfully creating a great software product.

The author had an excellent observation towards the end of the book that struck me as an important reminder with today’s mindset of “Anything worth doing can be done with three engineers and some Ruby on Rails.”

"A quarter century since the first fissures were spotted in the edifice of Bigness, it is now fashionable to dismiss big organizations and dinosaurs, incapable of managing complexity. It is hard to argue against specific examples. But this does not mean that small organizations are by definition to the answer to the challenge of complexity. While the entrepreneur and lone genius are rightly celebrated as engines of creative destruction, “small is beautiful” is a false cure for the Bigness disease. The really grand dreams of humanity increasingly require immense resources and armies of skilled people; however nimble, small agencies are ill equipped to marshal the required people and resources."

I’ve still got The Soul of a New Machine and Rebel Code to read. Please let me know if there are other great books about software projects that I should know about.

Where India goes from here

2006-08-14T16:42:00.000-07:00

The high tech industry’s fixation on India seems to have reached a new peak recently. First there was a string of announcements as various large high tech companies announced multi-billion investments in offices in the region. Then the cover of Time magazine. Now there’s another string of announcements, this time by venture capital firms raising dedicated funds for India including Matrix Partners and NEA.

Clearly India is a land of opportunity, but I do wonder if the opportunity is as limitless as these investments seem to assume. As a basis for discussion, I want to suggest three questions about India in the next 5 years.

How big is the Indian talent pool?

It’s indisputable that you can draw very impressive people out of the IIT system or high-tech hubs like Bangalore and Hyberbad. But at the rate the large companies are hiring, these groups get exhausted very quickly. The Indian government recognizes this and is moving aggressively to expand the university system to generate more IIT or IIT-like graduates to meet growing demand, but one has to question the impact on quality.

In the US or in Europe or Israel, if there are a million people working in the IT industry and we need to grow the pool, it’s not difficult to get the 1,000,001st person to enter the labor market (switching from some other industry most likely) and with a minimal degradation of quality. With a country whose literacy rate is at 60% and whose poverty rate is at 80%, it’s not so automatic an assumption that the 1,000,001st Indian citizen to join the IT industry is as much a boon as the 500,001st one was. The signs of this supply constraint are evident in the double digit growth in salaries and double digit turnover reported in the Indian high tech industry.

What does CMM really get you?

“Ah, but don’t mind the rising cost, go there for the quality” say the boosters. Look, 75% of the world’s CMM level 5 software development organizations are based in India! But isn’t CMM is a once good idea that’s long since been turned into a giant marketing ploy? The reason why India has such a high percentage of the world’s CMM companies is because it was a great confidence-inspiring badge for the Indian outsourcers to show off to their clients. In point of fact I can’t think of a single highly successful software product that was developed in a CMM 5 organization. Lotus, Microsoft, vmWare, SAP, Google, Oracle, Siebel, IBM and Intuit all developed their flagship products with development teams that deviated substantially from CMM 5 orthodoxy. A process and procedure heavy approach that works for client CYA is counterproductive to creating great repeatable software products that are embraced by customers.

What sort of software startups will India create?

In the end, (physical and psychic) closeness to your customers is what defines success in the software business. It doesn’t matter how inexpensively you generate a thousand lines of code if the customer didn’t want it in the first place. This is one of the biggest advantages of US startups: proximity to the world’s largest and most flush group of software buyers. How will Indian startups cope with this?

One possibility would be Indian software startups follow the Israeli model: build yourself around the US market It’s quite common for a software company founded in Israel to hire the plurality of its employees in the US and even move their headquarters. In fact if you sift through the software portfolio companies of the leading Israeli VC funds, you’ll find that 70% of more of the portfolio now have US headquarters. This is a fine and good way to build companies, but it’s a recipe for a limited size startup ecosystem. Keeping with Israel as the example, the country probably has 3-4 good feeder universities and 7 or 8 venture capital funds. If this is the way the Indian startup community goes, I don’t think it’s going to justify the level of involvement that Matrix, NEA, Battery and others are contemplating.

Another possibility would be to build Indian software companies for the Indian companies. To go this way is to create a true challenger to Silicon Valley primacy because you now have a self-sustaining market to nurture startups in the early years. This in my mind, it the big outcome that the VC funds are counting on. I’m just not aware of an Indian software company that’s successfully executed this model.

As NEA, Matrix and other firms get established, I’ll be curious to read about the types of software companies they fund, their go to market model and from where they draw their employees. Maybe there will be a new startup model for Indian companies that we've yet to see.

HP acquires Mercury

2006-07-25T14:45:00.000-07:00

Agressive play on the part of HP to renew its commitment to the software industry. Its management turmoils aside, Mercury Interactive always been one of the shining stars of the software industry. Mercury positively dominates the testing market and has gone on to great success in the IT governance market with the acquisition of Kintana.

I think this is a pretty smart decision on HP’s part.

Fairly reasonable price

Based on their Q3 2005 run rate, Mercury was somewhere around $800 million in annual sales meaning HP purchased them at around 5.5x revenues. This would seem rich for many software companies, especially a de-listed one, but recall that prior to the options scandal, Mercury was traded at a much more expensive multiple based on its profitability and growth rate.

Management premium

Mark Hurd has earned a reputation as a consistent executer. A steady hand at the rudder will likely add incremental value to Mercury as it puts its ESOP problems behind.

Leading assets

Mercury is #1 in every segment it competes in, often by a wide margin.

#1 in testing
#1 in IT governance
#1 in services repositories

Strong synergy

IT governance is a good fit with HP’s OpenView monitoring and management assets.

You can argue that managing a services repository (Systinet) is also a governance/monitoring exercise so this is a fit with OpenView too.

Better channels for the testing business. As I understand it, the testing business is very channel-dependent. That is, Mercury testing got a lot of sales by following on after IBM, SAP, Microsoft, Oracle and BEA sold their software and projects. HP has arguably stronger, more senior level relationships with all of these companies than Mercury does (based on its size and breadth of product portfolio). HP will probably be able to help up the level of the relationships Mercury currently enjoys with these companies.

Demonstrates commitment

No one’s going to ask again if HP’s serious about being in the software business.

Gutsy move by Mark Hurd. Congratulations.

Thriving as a mid-sized software vendor

2006-07-23T14:58:00.000-07:00

Accenture’s Philippe Vincent writes one of the better analyses I’ve read on the enterprise software industry in quite a while. His article on Sandhill.com is long, but let me summarize very quickly: it today’s market, it’s tough to be a mid-sized enterprise software vendor, especially a midsize enterprise apps vendor. The big players have often times caught up most of the way and they’ve got better distribution. Disruption from the low end abounds. Chances are you’re also publicly traded and it’s more expensive than ever to be public.

While I really like his analysis, I’m not a fan of all of Philppe’s advice. I think diversifying your way out of a problem in your core business is usually throwing good money after bad. Forward integration into services has a number of problems too including channel conflict with your services partners and the need to move into lower margin service lines (business ISV’s typically skim the highest value added services work).

The central piece of advice I’d offer most mid-sized enterprise apps companies is to find and isolate the hidden gems in their businesses. Cassatt’s Bill Coleman had a clever comment about Sun to the effect of: “There’s a really great $1-2 billion company lurking inside that $11 billion company.” In the same vein, there’s probably a $25 to $75 million a year growth business lurking inside many of these $100 - $250 million mid-sized software companies. For most of these companies it’s a combination of:
- Some unique technology assets that are wrapped inside a lot of functionality that overlaps with the large integrated suite vendors
- A ton of process and domain know-how on a specific topic area

I’m convinced if most customers could buy just these two things from a mid-sized ISV without all the baggage of duplicative functionality, extensive implementation projects and a costly sales channel, you’d see some very happy customers.

I wouldn’t be surprised to see some aggressive private equity firms try to unbury these gems. The formula might look something like:
- Buy a mid-sized software company valued at 1-2X revenues
- Carve out the maintenance revenue business and lever it up to improve returns
- Extract the unique technology assets and monetize them separately from the original product (for example what Ariba has done with its Supplier Network)
- Package the topic expertise as licensable best practices (e.g. Corporate Executive Board)
- Complement with a high-margin consulting business that complements Big 5 integrator offerings
- Revamp the channel model to just sell the differentiated technology and know-how at a sub-seven figure sticker price with a much shorter sales cycle

I think it’s inevitable that some of the mid-sized vendors try some alternate strategies to the 7 figure direct sell enterprisey approach. I'd like to think the above (with or without outside investors) is a good alternative, but only time will tell.

The new product manager

2006-07-08T14:01:00.000-07:00

I was excited to see Brad reference this new blog on agile product management. I had a post percolating on this very topic and I’ve enjoyed Brian’s first posts.

For the most part the product management role in software has remained pretty static over the past 15 years or if anything, become further specialized with special designations like product strategy, product definition, product marketing, technical product manager, partner product manager, etc.

The “established” thinking on product management is pretty well encapsulated in this chart developed by Pragmatic Marketing.

I think it would be a missed opportunity not to reexamine the role of the product manager. Changes in technology and process have almost necessitated it. Web applications with their short release cycles and quick user feedback, and agile with its focus on incremental development, change the nature of product management. Some of these changes need to happen to accommodate agile development cycles. Other changes needed to happen anyways and the aforementioned trends have just accelerated them.

So what’s different today?

Well in this new agile world, a product manager needs to be:

A priority setter. At any point in time there should be a #1, #2, and #3 priority for the development team. The product manager should be able to clarify those priorities on a weekly or even daily basis.

An information gatherer/disseminator. The old product manager outlined a feature set for a whole release at a time. That meant while the release was in development, the product manager was almost antagonistic to new ideas. “Let’s just get this release done, no new ideas now please.” With agile, that constraint is lifted. A new idea is an opportunity to improve the ROI of the development team that very month. Product managers need to spend a lot more energy getting new ideas into the queue to improve the probability of increasing ROI. This also means that the product manager will come up with fewer of these ideas on his own. More likely he’ll solicit them from users and developers and do less editing/filtering.

A salesperson. Selling the vision of the product to the development team is essential. How else can they come up with lots of good feature ideas or believe in the priorities? More energy is spent explaining the “why” of the product versus the “what.”

This also means a product manager should not be:

A document generator. Why bother to generate that 100 page PRD? It’s going to change a month into the project anyhow.

The final word on what makes it into a product. Control is an illusion.

The sole expert on the product topic. Appeal to authority just encourages everyone else to turn their brains off.

These shifts in focus also change the psychic rewards for the product manager. Most product managers I’ve known love being the satisfaction of being resident expert. They also enjoy being the George Bush of their product.

The new product managers get their kicks by helping the development team be successful. They also enjoy the tinkering, trial and error and quick feedback that comes with agile product management. Before: “I’ve pulled this lever 50 times. I have 11 years of experience pulling this lever in a best of breed environment.” After: “Hey, what does this other lever do? Let’s pull it and see what happens.”

Looking forward to more posts from Grillin' in the Storm.

Private company spotlight: Mark Logic

2006-06-26T21:40:00.000-07:00

Jason Wood is starting to show a pretty good batting average with his “private company spotlight” posts. First Wily was bought by CA, now Akimbi (a brilliantly useful testing technology) has been acquired by EMC’s vmWare subsidiary. Feeling the peer pressure, I wanted to do a spotlight on Mark Logic which I think is a tremendously interesting software company.

Product / Applications

In business since 2003, Mark Logic is defining a new market category for “XML Content Servers.” What this means specifically is a server that lets a customer can take some type of content (a document, a manual, a web page, etc) transform it into XML, store it, support various queries/manipulations of the content and eventually export it back out into various formats.

Why is this cool? Well, most important business content requires lots of rules and stakeholders to develop and maintain it. For example if Jet Blue needs to update its flight operations manual, it might need someone from EH&S to develop/maintain certain sections on takeoff procedures but someone from the pilot’s union to work on the section related to working hours. Similarly, when IBM develops an RFP response for a major customer, someone from Global Services needs to develop the description of their implementation capabilities but someone from the software division to write about Tivoli. Quite often there are policies that enforce what stakeholders can touch what bits of content. Because Mark Logic handles all the content as XML-native, you can do clever things like take the entire flight manual and identify a section as a “safety expert section” or a “union section.” In this way you can decompose a big, complex piece of content, apply rules to various sections and allow them to get updated independently.

This also means you can find and reuse content much more easily. Today when IBM has a new RFP, it’s a pain to find reusable content because no one wants to sift through 200 pages of some former RFP to find the good bits. If all the past RFP’s are XML-native you can just query: “show me all the Tivoli descriptions we’ve sent to insurance customers” and get back a list of just those sections, ideally with some added context like whether or not that deal closed.

Traditional content management is more of a “version control engine” that does check-in, check-out, access rights and the like. This misses the higher order capabilities described above that can make content management useful for applications other than archiving.

Mark Logic’s product is the classic “thneed.” It has little intrinsic value, but applied to one of a thousand different applications (like the ones above), it becomes quite useful. This makes it a product marketer’s paradise, having to create the “whole product” for each new application area. No accident then that Mark Logic is led by David Kellogg, former head of Product Marketing for Business Objects. David also writes a great blog that’s equal parts technology, product/market strategy and industry observation.

Momentum

Today Mark Logic has about 25 customers which is not a bad showing for 3 years in business. They’re mostly “power users” with nichey applications for the extremely complex content needs of technical journals or large regulated chunks of content like flight manuals. If Mark Logic crosses the chasm, you’ll start to see it in all sorts of different more “everyday” business scenarios like the RFP example I mentioned. I suspect it will take a channel heavy approach to let Mark Logic hit this kind of mainstream usage.

Competition

What’s particularly nice about Mark Logic is they seem to have a tremendous amount of free air. While I can easily name 10 photo sharing companies or 8 enterprise information integration companies, I can’t think of another XML content server company. This is pretty surprising in today’s world of over-funding and hypercompetition.

Improvements

Being an enterprise apps guy, I’ve got users, roles and processes on the brain. I wish I saw a little more of this in Mark Logic. Unifying XML content management with business rules, authorizations and BPM seem like an essential step to make this sort of content management relevant for more mainstream applications.

Final Analysis

Ultimately I think content management will go the way of business intelligence: out of the realm of the back-office specialist and instead surreptitiously inserted in between different steps and actions in larger business processes. Mark Logic seems to understand this shift and Kellogg makes frequent reference to Mark Logic’s platform aspirations. With their team, technology and investors, I think Mark Logic has a good shot of becoming the vendor that helps this transition toward the ubiquity of content in the enterprise.

Rules for software startups?

2006-06-20T21:57:00.000-07:00

If you want to see a quick snapshot of the famed “silicon valley herd mentality” check out the number of trackbacks to Don Dodge’s post on “7 rules for software startups.” Kleiner said it, Don Dodge posted it, and now a dozen other blogs repeat it, almost none of which question the underlying logic.

The rules originally came from Kleiner Perkins’ Ajit Nazre. So I took a look at Ajit’s investments. He has 3 software investments: Virsa Systems, Spike Source and Visible Path. Let’s see how they do relative to the rules.

Instant Value to customers - solve a problem or create value with the first use

Definitely not the case with Visible Path. Visible Path only works if there’s a critical mass of users to connect to for contacts and introductions. Virsa requires multiple users to deliver value too. Kind of hard to say with Spike Source.

Viral adoption - Pull, not push. No direct sales force required.

Visible Path, Virsa and Spike all rely on a direct sales model. Perhaps Spike gets partial credit for this rule since they have a few free downloads.

Minimum IT footprint, preferably none.

Spike is on premise. In fact there’s a picture of a giant data center on their web site. Virsa is on premise. Visible path has a client, but unknown if the server side is on-premise.

Personalized user experience

I’m pretty sure for Visible, Virsa and Spike the answer is no, no and no.

The rest of the rules (intuitive user experience, configurable, context aware) aren’t really binary so I can’t evaluate these companies relative to the last 3 rules. But otherwise Ajit’s own investments seem to violate all the rules we can objectively evaluate.

I guess rules are made to be broken.

Thoughts on the pull model

2006-06-15T22:58:00.000-07:00

There have been a couple of good posts around a growing trend towards grassroots, user-driven purchasing of software in the enterprise. Both on Sandhill.com, Erik Keller called this a new “pull model” where Jotspot’s CEO Joe Krause dubs it “consumer in the enterprise.”

The points are similar: the internet has enabled users or departments in the enterprise to consume software applications on their own, independent of a central IT organization.

Others have likened this “pull model” to a redux of the PC software market of the 1980’s where the IT departments were left behind to play with their mainframes while corporate departments went out to Babbages to purchase new desktop productivity apps like Harvard Graphics.

I buy that this is happening. During Software 2006, one CIO spoke of an internal survey he did to assess the use of on demand applications in his company. Before the survey, he was aware of 1 or 2. The survey indicated there were actually currently more than 80 such applications in use in his company under his nose.

Generally the startup community has greeted this trend with glee, as you could tell if you’ve seen Ray Lane’s presentations. This is understandable as most of our industry is a little tired of the $300,000 a year direct sales rep. When Siebel was coming up in the world it seemed like a stroke of genius to staff up a startup with a bunch of well paid “elephant hunters” to drive revenue fast. Companies like Ariba further reinforced that this was the key to success. 10 years after the rise of Siebel, there have been a few hundred software companies that were started based on the direct sales model. It’s proven to be more expensive and less consistent than many founders expected. I think a lot of this is just that too many companies have imitated the same approach and they’ve all cancelled each other out (bidding up salaries, over-bombarding customers, etc).

Is the devil we don’t know going to be better than the devil we do? I’m not so sure. On the surface the “pull model” seems to cut out the proverbial middlemen: no more CIO, no more sales rep, just developers and users. That’s got to be cheaper right?

In actuality, “pull based companies” do a LOT of marketing to generate the user interest that creates the coveted “pull.” And marketing tends to be even more hit or miss than direct sales. So far I’ve yet to see a pull driven company (like Salesforce or Red Hat or Surveymonkey or JotSpot) that’s nearly as profitable as a classic direct sell company. I chalk much of this up to the marketing money these companies have to shell out quarter after quarter to get the supposedly spontaneous “pull.”

More importantly, the “neutralize each other’s efforts” effect will probably be even more powerful in the pull model than in direct sales. Mark Benioff or Joe Krause look like geniuses because they were early to recognize ahead of most of us that there was a different consumption model out there for enterprise software that could also turn a profit.

More than a few people have now caught on now however, and today I’d guess there are 40-60 new “pull driven” software companies out there. In two years I predict we’ll have 200-300 such companies. Watch the same ad words get bid up, the same tele-sales teams get built and the enterprise users get bombarded with direct marketing pitches cajoling them to “pull” some vendor’s software.

With every new channel, there are usually a few vendors that seem to master it and make megabucks (look at Microsoft with hardware OEM’s or retail, Adobe with catalog sales, IBM with direct sales). Then there are a ton of followers who lose their shirts imitating the channel innovator.

In the end, it can only be a good thing that there’s an alternate sales/consumption model for our industry. But if you’re writing that business plan right now for the next great pull-driven software company, consider at this stage if you’re founding the next Siebel or the next Niku.

Build versus buy

2006-05-30T20:47:00.000-07:00

Here's a very good article (minus the sensationalistic title) by Erik Keller on the growth in custom software development. The gist of his post is:

- In house software development is growing
- More enterprises are opting to “build” vs. “buy”
- The reasons for this trend are SOA, open source, offshoring and general underperformance by the packaged apps vendors
- Software companies should respond by leveraging more open source, leveraging more offshoring, and improving their services groups.

I agree with but want to qualify Erik’s description of this trend. Custom development is definitely on the rise, but it’s coming at the expense of 3rd party services (i.e. consultants), not software applications. Erik’s own data shows this pretty clearly.
That said, custom dev is growing much faster than software applications, so application companies should take note.

I only partly agree with Erik’s assessment of the drivers for this trend.

I don’t see how open source biases customers to custom dev over packaged apps. The middleware costs associated with custom development are a tiny fraction of total development expense.

I’m also skeptical of offshore consulting’s influence on custom development. Again, Erik’s own data shows IT services dramatically shrinking, not growing. It’s IN HOUSE custom development that’s on the rise.

The trend towards custom development is underpinned by:

- Service oriented architecture
- Industry sales & marketing costs

SOA, with its associated improvements in middleware/dev tools is far and away the biggest driver of the current custom development trend. Here’s one of my favorite charts depicting progress in the software industry:

Every so many years, a new technology or framework enables a significant improvement in developer productivity as measured by lines of machine code generated per line of code written. This has happened every 4-6 years for the past 40 years. SOA is the new technology that has a powerful effect on developer productivity.

If this isn’t the first improvement in developer productivity, why is custom development out pacing packaged applications now? In fact new software development technologies move in cycles. The lead users for new technology frameworks like SOA are typically custom dev groups. Mainframe operating systems, databases, object oriented languages, 4GL’s, web servers and component development languages were all adopted by custom developers first.

The custom developers work the kinks out, mature the frameworks/technologies and discover clever new uses for those technologies. Application companies typically sit on the sidelines. If the new technology doesn’t work so well early on (and they never work well early on), the custom developers just lose the time they invested in a project. An application vendor risks missing a major release, annoying customers and possibly cratering the business.

Sad to say, the applications companies get the newest coolest toys years after the custom developers do. But they catch up eventually as they did with the first database apps, OO applications or web applications. Each time the application vendors catch up, the spend pendulum swings back to packaged apps. Every time a new technology framework comes out, the pendulum swings back to custom development. Scrutinizing Erik’s graph, you can even see this cycle play out as packaged apps level off or shrink for a few years and then resurge.

This is consistent with anecdotal evidence too. There are very few packaged applications companies in the market today with SOA-native applications. The new framework is here, but only the custom developers are benefiting. In time, this will change and I predict the mix of build vs. buy will re-balance.

Industry sales & marketing costs are the other big contributor to the custom development trend. If the buy decision requires an account executive, a sales engineer, a pre-sales specialist, a webinar, an executive seminar, a conference and a TV commercial; and if a build decision requires a walk down the hall to talk to the IT department, the economics of build start to look very attractive. This is why it’s in-house custom development growing and not 3rd party custom development: in-house is the low transaction cost option.

For the most part I agree with Erik’s recommendations. Application vendors should move faster to leverage the same technologies their custom development counterparts use today. But I also think addressing the vicious cycle of sales & marketing costs is essential to rebalancing the packaged vs. custom mix.

Nick Carr will write a post about this article in the next 4 hours (probability .8)

2006-05-15T08:14:00.000-07:00

Update: Woo hoo!

Well Nick didn’t post on this article (update, see above) which either means the observer effect is at work or I’d make a lousy Gartner analyst. Anyhow, the highlights of this article on IT spending growth:

- Gartner released its latest IT spend survey and project corporate IT spending will grow at 2.7% this year
- Gartner analyst Ken McGee proceeds to chalk this modest growth rate up to a fundamental lack of faith in IT spending on the part of business executives
- Moreover according to Ken, “This trend could put the future of the CIO and the existence of the IT department under threat.”

Yikes. One projection and the whole high tech industry fell apart.

This analysis is so goofy it’s hard to choose where to begin. Well, let’s try:

1) Gartner stands alone in its projections. Morgan Stanley’s most recent CIO survey projected IT spending will grow more than twice (6%) as fast as what Gartner predicts. CIO Magazine is predicting close to triple (7.8%). Forrester is also going for 7%.

2) Even if Gartner has the most accurate prediction, the histrionic comments that ensue about the downfall of the IT industry and the CIO represent huge logical leaps that are not really substantiated (at least in this Silicon.com article) by anything except Ken McGee's quotes.

3) Mid single digit growth is actually a big success. Let’s not forget IT is now over $1 trillion; one of the world’s largest economic sectors. IT is also highly deflationary, so the volume of IT consumption grows much faster than IT spend. This implies our industry is continuing to generate enormous amounts of new value for customers and users.

4) Unless we can start eating and wearing computer chips, it’s inevitable that IT spending growth starts tracking closer and closer to overall world economic growth. That’s not failure, that’s just a mathematical fact.

5) Looking at overall growth rates in a $ trillion market is a pretty meaningless exercise to begin with. Hardware spend is aggressively shifting from RISC/Unix to CISC/Linux. Virtualization is on the rise. The application server market is bouncing back. The IT services industry getting completely recomposed. All the important stuff that’s happening in this industry is completely lost with these sorts of studies. I’d really like to see these research resources shifted over to some more value-added thinking.

Google in the enterprise

2006-05-07T23:18:00.000-07:00

Nick Carr put up an interesting set of related posts about Google’s desired entrée into the enterprise.

I’m more than willing to see a future where Google in the enterprise, but the notion that Google will be the primary user interface for enterprise technology is severely overreaching.

Here are some job titles of typical enterprise technology users:
- Controller
- Accounts payable
- Operations manager
- Product design engineer
- Account executive
- Marketing campaign manager

When these individuals sit down in font of the monitor to use an enterprise application, “look for information,” is actually pretty far down on their list of things to do. More likely they are:
- Entering data
- Uploading a document
- Making a decision
- Analyzing an outcome
- Running a report

The search interface has next to nothing to do with any of these activities. This is the life of the “power user,” still the mainstay of the enterprise applications business.

Now if you’ve got a job in management or some role that doesn’t fit neatly into some function like accounting or operations, you typically want to do just two things:

- Approve/disapprove of something
- Look for information

It’s this second type of user where Google may have a role. So in a perfect world, Google could help with a fracition of the activity of a large fraction of the applicable users in the enterprise. This would still be a pretty impressive accomplishment, but it’s far from the “UI for everything.”

Moreover, as Sadagopan points out, Google is a long ways away from even this more constrained ambition. Enterprise search bears little resemblance to consumer search. The information is stored in different ways, used in different contexts and much more tightly controlled. This is why more than 10 years after Yahoo and Excite pioneered the search business, Verity and Endeca still have a job. The good news for Google is today’s enterprise search is pretty crummy, while Google is pretty smart and has a great brand.

More important to note, is unlike in consumer technology, “owning the UI” isn’t as important in enterprise technology. Many of us inadvertently use an Oracle database but we never see the Oracle UI. This has not stopped Larry from becoming one of the richest people in the world. In the same way if you look at all the partnerships SAP has struck recently, it’s safe to say “owning the UI” is not a very high priority. Ultimately enterprise technology vendors want lots of usage of their products. If Google drives more usage to SAP's applications or someone else’s database though some clever new interface, more power to them.

Repeat after me: SaaS is not magic

2006-05-02T19:59:00.000-07:00

Phil Wanewright is far more prolific than I have time to be, but I had to clear up some misconceptions that he insists on propagating in his recent post on the large enterprise applications vendors.

Phil continued to preach the on-demand gospel in his latest post. Many of his comments are completely fair and accurate, but a few overreach and inaccurately depict the state of the industry.

“The architecture of on-demand software is such that customization is declarative rather than programmatic, and therefore it's far easier to adapt processes to new business conditions — often it's possible for business users to make changes for themselves without having to call on anyone else at all.”

This sounds like a software architect who is just starting to learn business applications. I have several issues with this claim:

1) I don’t see how it’s possible to claim generally that all on-demand apps automatically are customizable in a declarative fashion.

2) It’s impossible for anyone to prove a particular approach is the most flexible as there’s no objective "flexibility scale.” So by default Phil’s statement can’t be true.

3) There are really two aspects to flexibility: degree of flexibility (how much can you customize) and cost of flexibility (how easy is it to customize). There’s no way a single instance, multi-tenant application can be superior in degree of flexibility to on premise because you can’t crack into the underlying code. I think cost of flexibilty is probably a wash, but it's highly case-specific.

4) SOA is the breakthrough that enables higher overall flexibility (degree + cost), not on demand. On premise apps can be SOA, on demand apps can be SOA.

5) While I hate to self reference, 99% of SaaS installs are pretty simple. If you only have 19 users (which is Salesforce.com’s current average), all customizations look pretty easy to me. Call me when you’ve got 10,000 live users on a single SaaS install with 30 unique roles and three times as many business processes. Then we’ll see what can be easily customized. Oh wait, we already can.

“On-demand providers suffer less downtime overall than the majority of enterprises”

Please provide statistics to prove this. The stats I know of major SAP customers (the really big ones that granted throw tons of money at this issue) do not experience a fraction of the downtime that Salesforce has had recently. To give you a sense, here’s what true uptime means to “enterprise class” customers with “enterprise wide” systems .

Most importantly for me, what Phil did not answer was Jeff’s or my issues with his original take on Oracle’s declining license revenue:

“by allowing Oracle's license revenues to decline, Ellison is reducing the company's dependence on a shrinking revenue source.”

This is not some master stroke on the part of Oracle, it’s bait and switch. Oracle’s venture into applications is wasting away so they’re pointing to their legacy revenue (maintenance, not SaaS subscriptions), to pretend they’re still a growth company when they're actually shrinking. Oracle doesn’t even have a SaaS ERP, so how could they possibly be trying to allow perpetual licenses to decline in favor of subscriptions???

I’m not a big fan of SaaS FUD-throwing either. I think SaaS is a great deployment model that allows our industry to approach segments of the market that have been grossly underserved to date (SMB and departments). Some day, SaaS will be ready for heavy-duty large enterprise installs. It isn’t right now. When it is, we’ll wonder what all the fuss was about because it won’t look much different from how on-premise works today. In the end, enterprise applications are all about people who have to change their work habits and get better control of their processes. Doing this over dozens of processes and thousands of people doesn’t magically get easier with SaaS, and Phil’s proselytizing to the contrary just undermines his own credibility when he’s got many good observations to offer as well.

Reducing your dependence

2006-04-21T10:55:00.000-07:00

Jeff will probably follow up with a more complete analysis later, but I couldn’t resist a quick response to Phil Wainewright’s post:

So by allowing Oracle's license revenues to decline, Ellison is reducing the company's dependence on a shrinking revenue source.

So now losing is something to be congratulated for. I get it….. In that same vein:

- When a company loses money, they're reducing their dependence on profits.

- Free Jeff Skilling. He should be applauded for reducing Enron’s dependence on employees.

- Let's also thank Larry for reducing his shareholder's dependence on returns.

Phil has been mesmerised with with Oracle’s version of three card monty. Find the growth! Is it under maintenance? Under service? Under database? Under middleware? Did we buy it? Did we earn it? Anyone can win! Put your credibility down and find the growth!

Phil, the way you win 3 card monty is by not playing it in the first place.

The Software Sales Arms Race

2006-04-19T23:20:00.000-07:00

I had a post brewing on the topic of software sales & marketing when Erik Keller beat me to the punch with a great analysis of software economics.

Vinnie seized upon Erik’s post to hammer on his favorite topic that software companies spend an insufficient amount on R&D and too much on sales and marketing. I believe this is true too, but I don’t think Vinnie appreciates why this is the case and why he himself is part of the problem.

The ballpark economics of your average successful enterprise software company looks something like this:

100% sales
80% gross margin
15% R&D
35% Sales & marketing
10% General & administrative
20% Operating margin

Sales & marketing spend has fairly strong economies of scale because investments made in brand building and customer relationships can be amortized across a wide variety of products. This is why the mid-sized vendors in Erik’s analysis have worse margins.

Interestingly, software R&D is exactly the opposite: it has strong diseconomies of scale. The bigger the development organization gets, the more coordination work is required and the more cost per line of code developed grows.

The whole sales & marketing mechanism, and the parallel decision making buffers and gatekeepers in the customer organization, is what Coase would call a transaction cost. That is, these activities exist because commercial software application development and application consumption live in separate companies. Mr. Customer doesn’t immediately grok or trust what Mr. Vendor creates and so they both erect staffs of people to manage the interaction so they’re both sufficiently protected.

In the ideal world, vendors would build products and leave them at their doorstep where customers would costlessly find them and consume them. Similarly the customers’ economics would greatly improve if they could readily find products and consume them with a high degree of trust and rapidly realize their value.

In reality, this is not the way our industry works, and instead we have an unnecessarily adversarial relationship between vendor and customer as well as a whole lot of money wasted doing what Reagan called “trust but verify.”

This isn’t just theory, it’s what most in the software industry have experienced for the last 20 years. From personal experience in competitive sales opportunities, I’ve seen the company with superior products lose to the company with superior salesmanship. If you’re the CEO of a software company and you see this too, how can you afford not to spend that extra dollar on sales and marketing when it produces a superior return?

What we’re really seeing is a prisoner’s dilemma for software vendors where the payoff matrix looks something like this:
(eat your heart out David Cowan)

The end result is we’re all in jail. CIO’s are positively bombarded by the vendor community. Cold calls, warm calls, mailings, webinars, partner referrals, trade shows, you name it. In response, CIO gatekeeping and evaluation has become more and more sophisticated (enter Vinnie). Thomas Otter gives a great description of what this looks like today for vendors. All of this costs a ton of money for everyone involved and for the most part everyone’s investments (vendor, competitor and customer) cancels each other’s out.

Meanwhile the line of business in an enterprise has become quite put off by all of this. The just wanted some technology to solve a problem. The “pull model” Erik describes in his post is basically a way for the department or the line of business to circumvent this whole exercise. That means they’re finding their way around the software vendor’s sales force AND their own IT department (Vinnie’s clients).

I think the pull model is one way to cut the sales & marketing Gordian knot, but it comes at the cost of a proliferation of point applications across the IT environment which is the world we came from just a few years ago.

The other solution to the problem that I’m surprised Erik didn’t mention is for the industry to consolidate around fewer channels. Credit to McKinsey’s Ken Berryman who has often predicted that the enterprise software industry is not now, but may soon start, to look more like the pharmaceutical industry. A few big companies build and maintain the sales and marketing machines and the smaller biotech startups develop innovative treatments while leveraging the larger company’s channels.

In this same way, a few of the major enterprise software vendors will keep the big sales & marketing machines running while the smaller vendors leverage that infrastructure. Take advantage of the sales & marketing economies of scale. Avoid the R&D diseconomies of scale. Sadagopan made a reference to this value chain desegregation in his post on the same topic.

In the end, I think both of these models will grow in popularity. Departments will consume more open source and on-demand applications to circumvent both vendor sales and the IT department. At the same time, the big software vendors will play more of a trusted advisor role to the central IT groups and reduce the sales & marketing costs of smaller companies. In either or both scenarios, the solution to our industry’s problem is a little more complex than “cut your SG&A spend so you can cut my price.”

Yet another Jboss post

2006-04-11T13:54:00.000-07:00

So many good comments on the Jboss acquisition, I’ll try to pick some of the best and add a few of my own.

1) I’m with Jason that a big catalyst for this deal was the fact that Red Hat was the only company out there that could pay this price and still keep it accretive to their revenue multiple.

2) Based on Mark Fleury’s 2004 blog post, I think all the bloggers out there can sleep a little easier knowing that you can insult a company publicly and still get them to give you $350 million.

3) I’m curious to see what the channel conflict implications are. Red Hat has always been in a fantastic position where they are liked by almost everyone and offend next to no one. This has given them a lot of free channels including IBM, HP, Oracle, BEA, SAP and Dell among others. That is really unprecedented in high tech to have so much free sales and marketing goodwill. Jboss has friends too (HP and Novell notably) but nowhere near as many as Red Hat. In fact Jboss competes with many of the aforementioned. This could prompt IBM, Oracle and BEA to look at alternate Linux distributions now that Red Hat is fielding competing products. A few articles are starting to hash out how these issues will start to surface.

4) My biggest concern from the rumored Oracle acquisition of Jboss was it would trigger a flood of venture capitalist ambulance chasers who would fund free alternatives of other successful software franchises in the hope they could get bought out by the player with the most to lose. Red Hat’s acquisition does not send such a clear market signal. So far Red Hat is the only player with both the interest and the currency to pay these sorts of prices. With just one major buyer out there, VC's have the hope but not the assurance that an open source investment will get competitive bids when it’s exit time. Contrast this with the consumer space where a VC almost always has 4 or 5 doors to knock on.

5) Whither Red Hat?

More than a little prone to hyperbole, Dana Garnder's post points out that between Linux, its partnership with Xensource, Jboss' acqusition of some Sun/Netscape products, and Jboss' core product portfolio, Red Hat is almost in the stack business, competing with the majors. If so, that's a massive business model shift for Red Hat. Some have questioned whether such a transition can be accomplished just by acquisition:

Although they both seek to sell to high-level IT executives, Red Hat's software is generally used by Linux systems administrators while JBoss' software is aimed squarely at Java developers.
"They haven't been chasing the same customers, which can be a challenge," said Dave Gynn, director of enterprise tools and frameworks at open source services firm Optaros. "It's good in that it opens up opportunities, but at same time, they haven't been selling to same customer."

Dana Blankenhor gets the last and best word on this subject:

Either this deal will blow up in Red Hat's face or Fleury just bought Red Hat.

Many thanks to all involved for keeping enterprise software interesting.

Open source presentations at Software 2006

2006-04-09T21:51:00.000-07:00

Software 2006 continues to provide good fodder for posts. Five companies presented in the Open Source Software Showcase last week:

- Collabnet (development community tools)
- Digium (PBX software)
- Ingres (database)
- Zimbra (e-mail server)
- Compiere (ERP)

The presenters had markedly different takes on what it meant to be an open source business both in terms of their product development models and their business models. For others at this session please correct any characterizations I’ve gotten wrong.

Product Development Models

Collabnet seems to have developed their product in a pretty traditional salaried development team/release schedule model. This was ironic considering the product itself is supposed to enable companies to emulate the open source development model which looks nothing like the aforementioned.

Digium felt the most like the Linux development model. A number of volunteer developers suggesting additions to the code and a few strong editors deciding what made it in to the release.

Ingres was developed much like some of Sun’s new open source products: several releases under a closed, dedicated staff approach, later launched as an open source app.

Zimbra was developed by a crack, single site, salaried startup development team. Their open source development model looked most like a Jboss or SugarCRM where development is mostly captive but testing/bug-fixing comes from the open source community.

Compiere’s development model seemed similar to Digium. Some degree of actual new functionality is coming from the open source community.

Business Models

Collabnet was predominantly hosted with a subscription fee. In addition, they have a free community edition. While Collabnet was in the Open Source Showcase, the development and business models appeared pretty similar to a Salesforce.com. Of course that’s a perfectly good business to be in, but not particularly open source.

Digium gives the software away but charges for the PBX hardware and licenses the software to competing PBX manufacturers.

Ingres’ revenue model seemed like the Red Hat approach: free for the GNU license but it’s possible to license “certified binaries” that comes with some extra perks like indemnification.

A funny moment in the Zimbra presentation was when the presenter said: “You can have the basic version for free, but if you want to use Microsoft Outlook, cluster, do backup, or patches, we’ll charge for that version.” Gotcha. You can also have my car for free, but if you want a door, a steering wheel, an engine and some seats, I’m going to have to charge you for that. That said, the demo itself was really slick.

I couldn’t figure out how Compiere was making money (they claim to be profitable). All versions of the product were free and the implementation was done by partners. They only have 8 or 9 customers, so that seemed like an insufficient maintenance base to keep the lights on. I’m guessing there’s some freelance consulting work that flows back to Compiere.

So like many of the big trends in software, because open source is invoked so often, it has come to mean everything and so now it has almost no specific meaning. With five “open source” companies as diverse as these, I think it’s officially impossible to be “for” or “against” open source or believe it’s the “way of the future” or a “flash in the pan.” Rob's feedback from LinuxWorld was quite similar to this takeaway.

Software 2006 part 2 - customer panel

2006-04-05T16:00:00.000-07:00

A fun discussion with two senior IT execs: Motorola’s Toby Redshaw and Shell’s Con Goedman.

My favorite part of the session was some great validation statements on my earlier post on the value proposition for SOA/ESA.

Toby Redshaw: “We’re getting some fantastic results from web services. Projects that took 6-8 months and an army of people before are down to a day or two.”

Con Goedman: “The biggest innovation we’re seeing are those that get the technology people closer to the business user’s needs.”

Toby also mentioned a few of the next gen appliance vendors I cited in this post was mentioned by Motrola’s CIO (Cassatt, Netezza).

The two big admonitions for SAP and peers came through loud and clear:

1) Shorten implementations. Customers want 30-50 days to get to value, not 9-12 months.
2) Focus on business user value (not just CIO/IT buyer value)

Another great quote:

“Toby, what do you see as the trend in software pricing: License? Maintenance? Subscription? SaaS? Success fee?”

“You know Eric, we just don’t care. Money is money.”

Jeff called that one about a year ago (on his old blog).

Software 2006 part 1

2006-04-04T19:44:00.000-07:00

Ask and ye shall receive Jason. I attended the first day of Software 2006 as well, so I thought I’d add my voice to that of Will Price, Jeff, Zoli, Sadagopan and others who are also here. Some observations:

Interest and Interaction

Echoing Zoli’s comments, we enterprise software folks aren’t a very lively bunch are we? The conference is very well attended by all corners of the software community, but between presentations there was only the most grudging, perfunctory applause. Also the low interaction between the audience and speakers implies to me we’re still a ways from a participatory web 2.0 ethos in the enterprise.

Trend Surfing

MR Rangaswami kicked the conference off by reviewing the big themes of the past two conferences: offshoring and industry consolidation (this year it’s the ecosystem). It struck me how quick our industry is to jump on the latest trend and believe it’s going to sweep the market. A year passes, we forget about the old trend and move onto the next one, without much of a post mortem.

The irony of MR’s trend review is it was immediately followed by a host of presentations that proceeded to compete on who could interchange the same 4 buzzwords in the most creative way. “InnovationSaaSOpenSource?” “OpenSourceSOASaaSInnovation!” “InnovationInnovationOpenSourceSOASOA…” Every once in a while someone would throw in a “web 2.0” just to mix it up.

These are all big important trends in our industry but sometimes they were interchanged indiscriminately despite the fact that they’re extremely conceptually dissimilar. It was like a screenwriter pitching a Hollywood producer with: “Hey, it’s Batman meets Brokeback Mountain meets Pimp My Car!”

My favorite of the keynotes/panelists was Goldman Sach’s Rick Scherlund. He was exceptionally thoughtful and did a great job articulating how many of the new hot trends will co-exist with the status quo they’re meant to tear down:

- multi-tenancy and on-premise
- open source and proprietary
- bottom-up, user based purchasing and centralized, “buyer’s circle” based purchasing

I also attended both of the software showcases on open source and enterprise applications. Each session was comprised of 5 companies doing rapid fire 10 minute presentations/demos. These were very thought provoking and will be the subject of a future post.

IBM's new service hub

2006-04-03T20:18:00.000-07:00

A few weeks back I referred Jeff to this article describing IBM’s move to develop a “service development hub" in India thanks to a new $200 million investment. The general idea seems to be that IBM Global Services teams will identify enterprise services that customers need during an engagement, spec the services, create them in India, and reserve the right to reuse them for future client engagements.

I find this move to be intensely smart which is typical of IBM when they choose to break out the big checkbook. I also think this investment is a harbinger of several larger trends in enterprise technology, many of which can be traced back to the onset of SOA.

1) A new way to build a business in IT services

IT services has never had a particularly good business model. It has high fixed costs, low barriers to entry and relatively low operating margins.

The advent of the Indian players (Wipro, Tata, Infosys, etc) have made this an even worse business for the incumbents, challenging the classical model of large, on-site engagements with high daily rates.

IBM’s investment in a SOA development center shows us that reusable intellectual property is the only thing that will separate many an IT consulting business from a glorified temp agency.

If IBM builds up a repository of reusable enterprise services created during various client engagements, they’ll be able to bid for new customer projects at the same prices as an Accenture or Wipro but execute them with fewer resources thanks to the reuse. This has been made possible because of SOA: IT assets created in one project can be reused only because their documentation is inherent in their functionality (i.e. they’re self-describing).

2) The beginning of the end of enterprise software’s own “Bretton Woods system”

In the mid-1990’s, life was pretty straightforward in enterprise software. You lived in 1 (and only 1) of the following 3 camps:

- You could be in the applications camp, which at the time was JBOPS, plus a growing number of e-business application vendors.

- You could be in the technology platform camp, which at the time was Sun, IBM, Oracle, BEA, and Microsoft. Every application vendor would pick one or more of these platforms to build on.

- You could be in the systems integration camp (Accenture, EY, and the rest of the big 5) and implement the technologies of the aforementioned two camps.

Each camp played a unique role in the ecosystem. The apps vendors understood customer processes, the systems integrators were the honest brokers & client confidants, and the technology platform vendors tried to create a common denominator of skills and technology for everyone to build on.

In today’s emerging SOA world, enterprise services are nether application nor infrastructure, and SOA applications are neither custom nor packaged. As these old product and service distinctions start to blur everyone is getting back into everyone else’s business. IBM has been in the systems integration business for some time, and thanks to NetWeaver, many of the major application vendors are now in the technology platform business.

Because of this SOA hub announcement, IBM isn’t back in the applications business per se, but it is in the repeatable business logic business which isn’t so far away. I’d be surprised if we didn’t see Accenture, CGEY and the rest follow suit with pre-packaged enterprise services or process patterns becoming a differentiator for client engagements.

3) A new take on the offshoring model

I’m always been something of an offshoring skeptic. I think the benefits that come from low labor costs and 24x7 development are usually offset by added coordination costs and the number of extra links in communication path between the developer and the end user.

With a SOA approach, one can keep the process and user interface creation work close to the users in their respective markets. But since the enterprise service creation is so tightly specified (via WSDL’s), it can be offshored with a minimum of coordination costs. Hence IBM’s ability to centralize service creation in one site versus the 17 they have today.

In this way, organization can follow architecture, versus today’s offshoring model which tends to segregate work along steps in the development process (e.g. someone codes, someone else tests or maintains).

Whether you believe SOA is revolutionary, evolutionary or neither, it does seem to be changing the economics of the enterprise technology business and the roles of the different players in the ecosystem.

What to do about that top 1%...

2006-03-21T10:05:00.000-08:00

My friend David runs what has to be the most comprehensive blog out there on the video game industry. In it, he pointed to this article.

Take Two Interactive is setting aside $25 million for key members of the team who develops Grand Theft Auto. Take Two doesn't say how many key members there are, but I’d doubt there are more than 10. Even spread across a few years of vesting, this is a hefty payday for each person on the team.

Of course Grand Theft Auto underpins over 50% of Take Two’s entire market value according to some analyses. In this light, $25 million seems like a pittance.

The truism in software is the very top developers are as productive or valuable to a company as 50-100 average developers. Yet in most companies, the variation of developer salaries is quite low, perhaps +/- 50%. It strikes me the more the labor market moves to free agency, the less likely this discrepancy between performance variance and pay variance can last.

This raises several questions:

1) Will the software industry enter a new phase in terms of how it values and rewards its developers?
2) Have we reached the limits of what free soda, casual dress and foosball tables can do to retain the very top talent?
3) Will free market economics start to penetrate the internal labor market at software companies?

In the same vein as the Take Two announcement, Google has famously set aside stock for a Founder’s Award, a bonus to individuals or teams at Google who have done something truly innovative. These Founders Awards are worth between several hundred thousand and a few million dollars per developer.

Also on the Google front, some have noted that many of the startups Google is acquiring are barely startups. They’re more like large, code-based resumes of some very sharp developers. Their products are barely in beta when Google snaps them up for $5 – 15 million which, shared among 3-5 developers, is not such a bad paycheck.

I don’t see why enterprise software shouldn’t experience the same phenomenon. After all, our corner of the industry has its share of rock star developers too.

Companies have historically balked at huge pay discrepancies in the development organization for various reasons:

- Managers usually aren’t comfortable with the idea of someone on their staff getting paid 3x their own salary (sales managers are an exception here).
- Compensation policies are very focused on classifying and “banding” employees. Wide pay discrepancies throws that system of job strata, averages and market benchmarks out of whack.
- The Lake Woebegon effect: once word gets out that a few engineers are earning such large pay packages, everyone believes they are “above average” and will expect similar incomes.
- The longer companies can forestall these pay discrepancies, the more profits flow directly to the companies and not to the employees. We saw this in the movie industry before the end of the studio system.

But just because rewarding the top 1% is tricky doesn’t mean you can pretend you don’t have to do it.

It’s fascinating that this is happening at the same time that offshoring (to India, Russia, Ukraine, China, etc) has become prevalent. At the same time that certain development jobs are at risk of commoditization, we’re throwing gobs of money at others.

This all feels like another step down the path towards our Winner Take All Society.

The killer app for SOA

2006-03-16T13:38:00.000-08:00

Vinnie posted a blog entry that echoed something Jeff wrote about a few weeks back: what’s the big value proposition for this whole SOA thing and how hard or easy is it going to be for customers to “be SOA?”

It’s a pity that more than 4 years into this SOA trend, these are still open issues but clearly they are.

I think the general issue is SOA has a real “eat your spinach” feel to it. It doesn’t taste all that good and when you’re done eating it, you can’t instantly do anything practical with it like run faster or lift a heavy object.

Where the big bucks are for a customer who moves to SOA

My belief is the benefits SOA promises for custom application development can by themselves justify almost any SOA investment. Currently companies spend $ several hundred billion each year on custom application development. You’ll see these expenses in:

- Staff (hundreds or thousands of employees)
- Infrastructure software (various middleware)
- Tools (IDE’s, source code management, testing, etc)
- Processes (Rational, et al)
- 3rd party consultants (IBM, Wipro, Accenture, etc)

In fact today on average customers spend more on custom development than they do on all packaged applications combined.

If a customer has made the requisite investments (more on those in a moment) and transitioned to a SOA environment, I can safely claim that companies would double their productivity when it comes to developing custom applications for the business. Whether you’re looking at a large enterprise that seldom “rolls its own” or the kind that lives to cut code, this benefit is worth tens to hundreds of millions a year in hard dollar benefits.

This doubling (I actually think it’s much more than double but I’ll round down) is possible because SOA provides you with a new, highly abstracted development platform & toolset that beats the socks off the ones we have today. In the SOA future, even fairly hairy custom application development projects will likely be 80% coding free, built off of pre-existing enterprise services, orchestrated and composed by this newfangled SOA middleware everyone’s talking about. The remaining 20% will probably still require custom coding but with each coding job we’ll be adding to our repository of services so even this becomes less and less necessary.

Not only will custom development be dramatically cheaper, but the applications that get produced will be of a higher quality than those most companies create today.

The applications will much more closely fit the needs of the requesting division

These new apps will be developed by business users (because they’re mostly coding free), for business users. This means the communication path between a business division and application development will shorten dramatically. Less links in the communication chain means fewer chances for mis-communication between business and IT and a greater chance you’ll actually get what you asked for.

The new applications will be auto-integrated into essential, mission-critical “backbone” applications

Today, custom development means coding what the business asks for and then going through some sort of integration exercise to sync with key production systems. In the future the distinction between these two activities will go away. The lack of such auto-integration today is one of the key reasons why we have 4 different definitions of “customer” or 3 different definitions of “employee” today.

The new applications will be much more changeable

Today’s custom developed applications were coded by someone who has long since left the company or at least the department that built it. Companies spend a fortune trying to maintain these and change these (see Niel’s recent post for an explication of the costs of PeopleSoft customizations). These new composed applications will have the original process models and flows auto-archived in such a way that anyone can pick up where someone else left off.

Great, I’m buying, now how do I get to this nirvana you speak of?

The other part to Vinnie’s question is a request for some straight talk regarding what kind of investment is really required to harvest the benefits described above. My answer is a decisive “it depends.”

The value of enterprise services has a classic network effect. Check out this image describing the network effect of the telephone system.

It’s a similar situation with enterprise services.

If you have just one enterprise service working, the benefit of that service is pretty small. It’s like giving a kid exactly one Lego block for Christmas.

If you have ten enterprise services working, that’s marginally interesting. You’ve got ten Lego blocks now and can likely build a very boxy car...

...and not much else. If I give you a thousand enterprise services, you’ve definitely found nirvana. You’ve got a big box of Legos you can use to build a castle, a pirate ship, a Formula 1 racer or pretty much anything else you want.

All in this highly abstracted, pre-integrated, business user friendly way.

So, on a project by project basis, you can definitely do SOA lightweight and “on the cheap,” and no, you don’t need 13 Websphere products to do it.

The downside of this approach is you’ll start with just 3 or 4 Lego blocks and won’t benefit from much of the network effect.

The reason why SAP’s (and a few years after us, Oracle’s) pitch to move to SOA sounds like a much longer and more arduous journey is because we’re trying to give customers that big box of Legos all in one shot. The beauty of this is the customer experiences the network effects right away whereas with the project by project approach, you’re going to be eating that spinach for a looong time before you start to feel the benefits (though you eventually will). Obviously the downside of this approach is it’s an upgrade, or in Oracle’s case, something more than an upgrade. No doubt this upgrade costs money and takes time, and judging from prior experience, Shai’s prediction will probably prove accurate. But these investments are dwarfed by the upside.

There are a lot of other benefits to SOA as well:

- Getting to a single version of the truth. The sooner you have a “get customer record” service everyone can leverage, the sooner you’ll get to that elusive single view of the customer (or vendor, product, part, employee, etc).
- Future upgrades of your packaged applications will take a lot less time and cost less
- Smaller software vendors will build innovative new applications that extend from the customer’s SOA platform

But if you ask me where the “hard dollars” are, I’m hanging my hat on custom development.

Nasayers, please fire away.

Still No Silver Bullet

2006-03-08T18:48:00.000-08:00

A great series of posts around Salesforce the past few days by Vinnie Mirchandani, Phil Wanewright, Nick Carr and Dan Farber. The primary focus for the posts was Salesforce’s announced pricing for a new “Unlimited Edition.” The consensus is this stuff is starting to get expensive and a little complex.

A question Nick Carr asks in his Salesforce post is a good point of departure for a broader SaaS question I’m curious about:

So which way will the SaaS ramp go? Will it be just another on-ramp to traditional corporate software, as SAP hopes, or will it be an off-ramp to a purely on-demand future, as Salesforce.com assumes?

Is this really the essential question? After the Salesforce pricing announcement, the question that struck me was: IF we ever reached a “purely on-demand future,” will it look or feel any different than the on-premise reality we live today?

The touted customer advantages of Salesforce.com-type SaaS are:
- Quick to get started – up and running in a day or two
- Cheap to install – no 12 month Big 4 implementation project
- Simple, no-haggle pricing - $xx per user, per month, all-in
- Simple to manage/monitor – i.e. hardware, datacenter, storage issues taken care of
- Always current – customers are always on the latest release of the product

This is all great stuff, but how many of these benefits are a function of Salesforce and its brethren being SaaS, and how many of them are a function of their doing small deals? Taking it point by point:

Quick to get started – When you’re talking about 5 or 10 users, I’m sure it is quick to get started. I don’t think it’s the same story when you’re talking about 1,000 users, 5 different major business processes and 3-4 different user types across these processes.

Cheap to install – Sure, provided you don’t configure, extend or customize the application, which most small businesses or departments don’t have the time, money or interest to do. Try convincing a $ multi-billion corporation that they should change their core processes to accommodate the vanilla implementation of a software package. To move up-market, Salesforce has been investing in customization capabilities for this very reason. The better those capabilities get, the more large deals they’ll qualify for and the more complex and costly the implementations will get.

Simple no-haggle pricing – I bet if I’m selling a single product to a 100 employee company, there’s little complexity or haggling. We’re already seeing how life gets complex when you’ve got a few dozen functional modules. Now let’s add the wrinkle of pricing these modules for a large, multi-user sale. You think a Fortune 500 company accepts $100/user/month for 2,000 users without negotiating? What do you think Vinnie gets paid to do?

Simple to manage/monitor – I imagine this benefit should carry forward whether you’re looking at a large/complex implementation or a simple one.

Always current – Again, as long as you keep everyone on a plain vanilla implementation or within a very tightly proscribed configuration sandbox, this is easy to do, SaaS or no SaaS. The more you permit customization and extensions, the harder this is going to be to support.

The leading SaaS vendors have built up impressive franchises, but my sense is much of their success is a function of the unique ways they profitably sell to, service and support small, 1-30 seat installations at a high volume. It’s a very impressive channel and support model that’s working wonders for a previously underserved segment of the market. I’m not convinced yet that being SaaS means vendors have suspended the laws of gravity and inertia for the large enterprise installations that Nick and others are so excited to see them progress to.

Doom! Doom I say!

2006-02-28T18:24:00.000-08:00

Classic Nicholas Carr post yesterday. Big sensational headline to grab attention, followed by some specious reasoning.

The headline is “Is the server industry doomed?” Much like the title of his book, Nick Carr isn’t really asking the question; he’s already got the answer. And for Nick the answer is yes.

I couldn’t disagree more. While the server industry is definitely changing, it’s by no means dead, dying or doomed. Let’s walk through Nick’s argument, debunk it, then consider a few other data points as well.

First argument: Virtualization wrings more utilization out of a single server. Thus companies need fewer servers. The server industry is doomed.

It’s indisputable that virtualization dramatically increases server utilization. On average you may get from 15% to 60% utilization out of an x86 server using virtualization. The technology is wildly popular and I think most would agree it’s also reached the mainstream. With a 4x gain in utilization, by Nick’s logic shouldn’t the server market have fallen to ¼ of its 2002 size (when virtualization hit its growth spurt)? In actuality, this past year the server market grew by 5%, capping off 8th consecutive quarters of growth. This, on a $50 billion base, is no small feat. In fact, the advent of virtualization seems to be correlated with when the server market resumed its growth.

Let’s be charitable and assume we’ve just been in the early adopter phase of virtualization. Shouldn’t we have at least seen the server market shrink by 10% given some early utilization gains?

The reason we aren’t seeing market shrinkage after an increase in server utilization is the same reason we never heard Ross Perot’s “giant sucking sound.” We found a way to do more with less of a particular item. This makes that item more valuable to us because it’s become more productive. Thus we want more of this highly productive thing. This happens all the time when new technologies like virtualization are introduced. For example:

When word processors took off, everyone thought it would crater the employment of administrative assistants. Today there are more administrative assistants working than before because they are so much more productive (i.e. valuable).

When personal computers took off, everyone predicted the paperless office. Instead today offices consume more paper than ever. Why? Because all those electronic files are so darn easy to print!

Why do you think the #1 server vendor (IBM) is also the #1 virtualization software distributor?

Second argument: Computation will move to brand-less collections of chips and drives arrayed in a grid. Clever software will orchestrate all of this. Google showed us this can be done. The server industry is doomed.

This is basically a pitch for “grid computing,” a term IBM coined 5 years ago that has yet to bear fruit in the marketplace. The grid is not virtualization. Virtualization makes one server appear as many. A grid makes many servers act as one which is also what Google does. The question is, who really needs many servers to act as one? After all, we’ve just said your average application can barely utilize 20% of an Intel processor. What’s the rush to stitch all these processors together to serve a single application? It turns out, almost NO ONE needs to do this at a grid level. If you’re going to simulate nuclear explosions or serve up a billion searches a day, go buy or build a grid. Everyone else can sit tight with their 2-8 processor boxes which they can now get 80% utilization out of. And if you have an applications you think might require a grid, just wait a year longer and Moore’s law will save you the trouble.

Third Argument: Utility grids will supplant “sub-scale” corporate data centers. The server industry is doomed.

Prove it. Show me a spreadsheet that demonstrates how a grid costs materially less than in-house alternatives with a comparable quality of service. I think you’ll find that there’s little evidence that your typical Global 2000 company is sub-scale. Compared to electricity (Nick’s favorite analogy), what are the big, up-front overhead costs in corporate computing that need to be amortized across a user base that’s larger than the corporation? In the cases of electricity this is fairly obvious, a power plant costs a ton of dough. By contrast there isn’t much in computing that costs you more than $ 1 or 2 million up front. This is a trivial amount to amortize away in a large corporation.

Where are the computing utility economies of scale coming from? Purchasing power? Know-how? Let’s end the hand waving and pragmatically lay this out. Otherwise, let’s drop the topic and wait another decade until there's more substance behind the rhetoric.

The contra-example

I’ll cut Nick Carr a little slack due to his frequent use of the subjunctive “may,” but otherwise that post was pretty far off the mark. What’s even more interesting is today we’re actually witnessing the OPPOSITE of what Nick is predicting. He says it’s all going to commodity hardware run by clever software. In fact the reverse is happening as vendors push software tasks back down into the server layer. Witness:

Azul
Cassatt
Datapower (now IBM)
Egenera
Fabric7
Netezza
Netscreen (now Juniper)
Tacit Networks

Or you can read about it in BusinessWeek and the Mercury News.

Buying open source companies

2006-02-15T18:56:00.000-08:00

A few days ago the first rumors surfaced that Oracle might buy open source vendors Sleepycat, Zend and JBoss. Given the likely price (cheap), the technology (embedded), and the dual-license approach, buying Sleepcat didn’t seem like such a bad idea to me. Neither does Zend who builds licensable “closed source” tools to work with the open source PHP. But I thought Oracle would be in-freaking-sane to pay $400 million for JBoss. Sadly, Oracle might not be as crazy as everyone thinks (sigh). With each day, it looks more likely that Oracle could pass on JBoss, meaning there are still a few sound minds floating around Redwood Shores.

For those who don’t know, JBoss is the leading open source J2EE application server company. Application servers are currently a billion dollar market for IBM, BEA, Oracle and others.

JBoss is, by objective standards, not a successful software business. Its application server is heavily downloaded, but JBoss never seems to make any money from it. We’ll never get objective figures on this because Mark Fleury’s reality distortion field is even more powerful than Larry’s, but the word is JBoss’ revenues from support contracts for their app server (i.e. revenue tied to product) are somewhere in the low single digit millions. JBoss’ total revenues are somewhere in the double digits, but the rest is just consulting and training revenues, the same as hundreds of other J2EE VAR’s in our industry typically valued at 1.5x sales.

Perhaps this is why JBoss has been rumored to be shopping itself around. BEA says they took a gander a year ago and passed when the price was $100 million. This article indicates JBoss was also in talks with Novell, IBM and HP.

Meanwhile it’s been 2 years since JBoss raised its last venture round. Given JBoss’ penchant for expensive self-promotion, it’s not hard to imagine them running through $10 million in the past 24 months.

Despite its business failings, according to most reviews, JBoss is a fairly successful product.

Pretty good, plus free, has resulted in 16 million downloads (according to JBoss). All that free software floating around had started to shrink the app server market (down 8% in 2003 according to Gartner). I think lightweight alternatives to J2EE like Spring, Rails and PHP are also partly to blame here.

So JBoss triggered a phenomenon that they can’t seem to profit from. What to do? Well, one strategy might be to rely on the greater fool theory: get someone to buy you before anyone’s the wiser that there isn’t a business here. So far, BEA, Novell, HP, IBM and Oracle seem unwilling to play that role. Doing this professional open source stuff is harder than it initially looks!

In related news, Xensource announced it was hiring a new CEO and doing a few layoffs. Xen is an open source virtualization software that competes with VMware. Xen has had enormous industry attention, blue chip VC backers and a 3.0 version product; but we’re still waiting for some visible market momentum (e.g. customer announcements) from the company. Meanwhile VMware did $100 million last quarter. Who’s in the better business here folks?

I’m not trying to say that all open source related businesses are destined to be failures.

I think there’s likely a great business in stack certification like SpikeSource and Sourcelabs.
Open source code inspection like Black Duck and Palamida seems to be a real business too.
Paid-for tools to “enterprise-ify” open source technology like Zend make sense to me as well.

But this “professional open source” phenomenon where companies take an established product paradigm (like database, app servers, virtualization, CRM) and try giving it away makes no sense to me. If JBoss withers on the vine along with Xensource, I’ll be very gratified to see some data back up my hunch.

Whither HP Software?

2006-02-05T14:41:00.000-08:00

As Jason Wood pointed out earlier, the former CEO of Vignette is leaving to head HP’s software division. I agree with Jason this is a development to watch. The HP software division has lived in a state of some ambiguity for many years now.

When HP bought Bluestone in 2000, the company’s software strategy seemed directed squarely against IBM. It looked like Bluestone could be the basis of a middleware portfolio that might become comparable to IBM’s WebSphere. Let's call this strategy: “get in there and beat ‘em!”

Just two years later, Bluestone was shelved, as HP realized the app server war was already settled (not in their favor).

After Bluestone, HP software shifted to a “if you can’t beat ‘em, join ‘em” strategy as the company deepened its relationship with BEA Systems. This seemed promising and most of the software industry hoped HP + BEA could provide a counterweight to the IBM freight train.

IBM’s share gains in the app server and related markets continued irrespective the BEA alliance, so in 2004 HP software shifted to a new “let’s not beat ‘em or join ‘em, let’s commoditize ‘em” strategy. HP announced two big distribution partnerships with open source vendors MySQL (RDBMS) and Jboss (application server); two open source trends IBM would prefer to see stillborn.

In the background of its shifts in middleware strategy, HP software has always maintained a good franchise in systems management with Openview. Still, with limited appetite for new R&D investment or acquisitions, the consensus is Openview has been getting a bit long in the tooth.

From 2000 – 2005, the direction of HP software had been overshadowed by the broader and more public controversy over HP’s general strategy and Carly Fiorina’s leadership in particular. Are we trying to out-IBM IBM? Are we trying to out-Dell Dell? Are we going to be an Apple with better distribution? With all these open questions, doubling down the company’s investment in software was an almost impossible decision to make.

Now it’s 2006 and the good news is things can only get better. Mark Hurd has shown everyone he’s a patient CEO, and succeeding in the big game requires a lot more patience than many people appreciate.

Who’s your best friend?

All the great enterprise software franchises today exist because they dedicated themselves to keeping a specific person in the enterprise happy. New products, acquisitions or investments, the best software companies don’t have to expand up the stack or to adjacent technologies, they have to look for new ways to keep their best friend happy. This makes eminent sense because if your best friend likes you, trusts you and has budget, you've got a home for add-on products, faster sales cycles and general love and understanding when times invariably get tough.

A few examples of software companies and their best friends:

- Hyperion: friend of the CFO.
- BEA: friend of the in-house developer
- Mercury: friend of the quality manager
- Business Objects: friend of the business analyst

When you get to be really big like IBM or Microsoft, you’re allowed to have more than one best friend, but until you’re several billion dollars in revenue, it’s best to focus on one.

HP’s software group needs to pick and stick with a best friend. Based on the current state of affairs, HP seems ill-equipped to be friend of the custom developer. There’s just too much ground to make up in terms of product portfolio (app server, portal, etc), IDE’s, test suites and the consulting services. HP’s partnerships with Jboss and MySQL aren’t inherently bad, but with all these complementary assets missing, the partnerships are something of a moot point.

You know where this is headed right?

HP: friend of the Systems Manager

The Systems Manager is the person HP software has always managed to keep happy throughout the years. And outside of software, HP actually sells systems! I smell synergy….

“HP insiders” more than hinted at a renewed focus on the systems manager when they emerged from the company’s offsite a week ago.

So if you’re going to grow HP’s software business in service of its re-discovered best friend the systems manager, where do you expand?

- Virtualization. There’s room for a strong #2 to vmWare. HP might look at Xensource or Virtual Iron for this.
- Server management – Blade Logic would be an expensive but leading candidate here
- Storage automation – HP already started this process by acquiring AppIQ. More related acquisitions are probably needed to better take advantage of Veritas’s merger distractions.
- Systems security – Maybe someone like Determina?

HP might also consider leveraging the strong relationships its hardware groups have built up with the chip and drive vendors. They might be able to create some unique chip and drive-specific extensions in the management software that would be difficult for the pure play software companies to replicate.

Great turnarounds in software start with teams, not technologies.

Alfred Chuang once told me the most significant acquisitions for BEA have been those that allowed the company to think and do things in ways they couldn’t have before. Almost no actual software was salvageable from Crossgain, but Adam Bosworth & co effected much deeper changes at BEA. Same for SAP and TopTier. It’s nice SAP got some portal software from the acquisition, but everyone can agree that’s not where the real value came from. Similarly, Groove had some interesting collaboration tools but is that really what Microsoft had its eye on?

There are lots of companies HP could acquire to help out their friend the Systems Manager, but most important is the first acquisition be a company with a great team that won’t just rest and vest but stick around to re-energize HP’s software unit.

Happy hunting!

Organization, open source and software architecture

2006-01-31T12:46:00.000-08:00

Nick Carr cites an interesting Harvard study that raises some important topics. The highlights of the study are:

Researchers tried to test if a software product's architecture reflected the organizations that created it.

To test this proposition, they compared the architecture of Linux (built by a highly distributed organization) to the architecture of Mozilla (the first cut when Netscape released it to the open source community).

The observation of the study is the Linux architecture is more modular.

Nick’s conclusion is the distributed open source organizational model will therefore produce superior architectures.

I arrived at my own take independently, but it summarizes some of the comments already associated with Nick’s post:

You don’t have to even do a study to convince me that software architecture reflects the organization that created the software. This phenomenon is usually a bad thing and software companies go to great lengths to avoid it. At a minimum, companies institute coordinating mechanisms to buff away the organizational fissures that would otherwise be reflected in a software product’s design. Some companies even do a high level architecture of a software product first then and organize around the architecture.

Modularity is not a benefit in and of itself. There are degrees of modularity. At the low end, no modularity means spaghetti code which is quite bad. At the extreme other end, a highly modular piece of software is very extensible but often comes at the expense of a seamless user experience (a notorious issue for Linux sans Red Hat) or high performance. Where a product needs to fall along this spectrum is a function of the market needs it attempts to satisfy. Thus I reject the logical leap that says: open source teams are distributed, therefore they produce modular software and therefore produce superior software. This is a possible conclusion in some markets and organizations but is by no means always true or obvious.

Comparing first generation Mozilla to Linux is a poor approach for two reasons.

The obvious reason is they’re totally different products with different design goals. In addition, they’re products at different stages of maturity in their respective lifecycles. If you wanted to do an apples-to-apples comparison, you might compare the architecture of Linux, 5 years into its lifecycle to the architecture of Solaris, 5 years into its lifecycle. You’ll still see differences in design that reflect their respective organizations, but you’ll have a much better vantage point to see which product arrived at a superior architecture (or more importantly, superior customer outcomes based on benchmarks and the like).

Second, Netscape was in many ways a successful company, but it’s also known as a negative example of what happens when you let smart, young hackers create a product in haste that later has to live through multiple release cycles and extend to support lots of different needs and complementary technologies. In this way, Mozilla is a poor straw man to compare Linux to.

Standardized, modular, extensible, seamless experience, scalable, inexpensive and fast are all noble design goals but they're often in apposition to one another. The black art of good software strategy is managing these tradeoffs where market dynamics meet customer needs meet product architecture. I know great software companies can practice this balancing act successfully (I'll admit many do a poor job). I'm willing to belive open source communities can achieve this same result but we can't take the community model as some "magic cloud" that automatically does this balancing act better.

On neglect, blogging and enterprise technology

2006-01-27T19:24:00.000-08:00

“Marty: The last time (Spinal) Tap toured America, they where, uh, booked into 10,000 seat arenas, and 15,000 seat venues, and it seems that now, on their current tour they're being booked into 1,200 seat arenas, 1,500 seat arenas, and uh I was just wondering, does this mean uh...the popularity of the group is waning?

Ian: Oh, no, no, no, no, no, no...no, no, not at all. I, I, I just think that the.. uh.. their appeal is becoming more selective.”

Vinnie’s been posting about the dearth of enterprise technology blogging / attention relative to the consumer/web folks. This is apparently manifest in the lack of enterprise tech headlines in something called Tech Memeorandum.

If there was any doubt before, I will now betray how uncool and un-web 2.0 I am in the next few statements.

What is Memeorandum and why should I care? Seriously, I’ve never heard of this site before. Does it have a particularly large readership among enterprise tech people that I should care about?

It looks like Memeorandum promotes blog posts based on how many bloggers cross-link to them? That’s very Google-esque but isn’t this rewarding the echo chamber effect that keeps everyone circling around the same 2 or 3 topics today anyways? That’s what it seemslike. At the moment it’s reading:

“Google China! Google China! Google China!” and:

“Web 2.0 boom! Web 2.0 boom! Web 2.0 boom!”

Yawn! Yawn! Yawn!

I also echo Dennis Howlett’s reference to bias. Some of these stories are getting on Memeorandum with 1 or 2 links. Niel’s post has three links already (now 4!), and it’s nowhere to be found. What’s the mechanism actually running this thing?

Memeorandum aside, should any of us enterprise techers care about how uncool we are at the moment? If the current zeitgeist is for web 2.0 and not enterprise tech, am I or this industry any worse off? I’m not so sure. I do worry that the flow of entrepreneurial talent and venture money is getting a bit misdirected at this point. But then, how many people are out there saying “For the last 7 years I led the storage automation division for Veritas, but now I’m going to chuck it all and build a Meebo-killer?” Hmm… I thought all the tourists had left the ‘valley?

I’m going to muster up my best Nick Carr / Paul Kedrosky haughtiness and say I’ll sleep just fine tonight knowing I’ll never make it onto Memeorandum. I’ve long since resigned myself to my blog’s spot on the long tail:

A Business Guy's Take on Agile Development

2006-01-26T18:09:00.000-08:00

For some time now I’ve been working with several product development teams here at SAP that are developing their products via agile practices; specifically Scrum. Agile, and Scrum in particular, is getting a lot of press lately as you can find here, here, here and here.

Agile is not new. For the most part this press is thanks to a few of the large, blue chip software companies (Microsoft, Yahoo, SAP) who are starting to talk about agile. The business press tends to listen to them more readily than they do the startups.

I’ve mentioned earlier that I come from the “business side” of the software industry. Because of this, in many ways agile is contra to my natural instincts. I’m the one typically saying “commit to what I’m going to get 12 months from now,” and when I don’t like the answer saying “why can’t we just work harder and get more done?” For this reason I thought my own perspective on agile would be a little different than those of the methodologists or some engineers who tend to take a more religious perspective. Here’s what I’ve seen in agile so far:

Agile makes teams more productive.

Not “order of magnitude” more productive mind you, as there’s still no silver bullet. Still, teams tend to be at least somewhat more productive than they were before because agile projects tend to recover a lot of the time that’s currently lost over-planning and over-defining things in the early stages of waterfall.

Agile takes risk out of projects & lets you know where you’re really at.

The really funny part about the “Oracle is halfway to Fusion” announcement is Oracle established they’re “halfway done” based on a bunch of documents they wrote (high level architecture, functional map, etc). This is a common practice in waterfall development. In waterfall, if the project plan says the halfway mark is when the functional map is written, well darnit the plan must be right so we’re officially halfway done. Let’s hold a press conference! Anyone who’s been developing software for more than a few years know this is complete horsepucky. A document is not software and until you get in there and start writing and testing the code, you have only the faintest idea how close you are to done.

Because you have to keep your software in a releasable state on a month to month basis, 50% done on an agile project actually means 50%. You can physically use 50% of the functionality and if 50% was all you wanted, you could take the software home with you right then and there.

Agile teams have more fun.

Being on a title-less team building the product and working in a flexible, transparent development process is just a lot more fun. A product manager doesn’t have to pretend he knows everything there is to know about the customer’s needs (he never does) and the developers don’t have to pretend they can predict with any degree of accuracy what they can deliver 9 months out (they really can’t). As soon as those false promises go away, the associated gamesmanship goes away too and everyone’s left in a much happier and less adversarial place.

Agile is not for everyone.

Without getting into too much detail, this stuff won’t work for all teams or projects. Agile offers teams more degrees of freedom than typical projects. Teams need to start in a situationally and psychically good place to take advantage of this additional freedom & flexibility or things can head in dangerous directions.

Scrum is a fad.

Anything with a title that requires capitalization, specific terminology (Scrum Masters, sprints, etc) and wild claims (30x productivity improvement, boost your stock price, etc) is just begging to have darts thrown at it. The nature of this method’s popularity and marketing means it’s due for a fall from grace much like RUP, XP and CMMI have already experienced (though these all had good ideas). For the companies that have to deliver revenue generating software every day, this is no great loss. You take the best ideas of the approach and move on, labels or no labels. It’s more a harbinger for the ecosystem of supporting books, tools and consultants that always materialize whenever a new trend hits.

So if you’re a business type and development’s request to “go agile” seems disconcerting or faddish, you’re right about the latter, but my advice is to hear them out and give it an honest try for a few months. I think you’ll be pleasantly surprised.

Interesting new company in user management

2006-01-21T15:28:00.000-08:00

Venture capitalists often talk about investing in terms of risk mitigation. Generally startups have some combination of “market risk” or “technology risk,” that needs to be mitigated over time (or avoided altogether if they choose not to invest).

A pure technology risk company might be a company trying to invent rechargeable batteries that last twice as long as the ones we have today. Well if they figure out how to create this, it doesn’t take a lot of imagination to realize there’s a market for such a product.

Generally, software startups are mostly “market risk” kind of companies. Given enough time and enough smart people, most software products are build-able, the question is more market related like: “will anyone buy this?” or “is market defensible?”

Identity & user management strikes me as one of the rare software markets that is more technical risk than market risk. The problem area is:

- Companies have lots of applications (purchased and homegrown)
- These applications have lots of users who have to log in and have very finely grained permissions as to what they’re allowed to do in an application (e.g. purchasing limits or access to certain kinds of sensitive data)
- Every application has its own way of handling users. So in a company with all these different applications there are as many different approaches to roles and permissions
- Most of these approaches aren’t very good because they’re based on computer-centric modes of thinking like hierarchical trees or inherited permissions. In reality organizations of people don’t work this way. We work on projects, cross-functional groups, etc. Who we report to and what permissions we need to have are only marginally related.

Simplifying and centralizing this mess seems like a no-brainer from a “market risk” perspective. Many companies have been built trying to crack this problem like Netegrity, Oblix and Business Layers, but their solutions the problem leave you cold. I can remember the disappointment I felt when I got a presentation of what Netegrity’s technology actually did (just passed user passwords to web applications via http).

Typically these companies solve the single-sign-on problem which is my mind wasn’t a very hard problem to begin with. They don’t come close to solving the permissions and relationships problems described above which in my mind are the hard, expensive and interesting problems.

There’s a third generation entrant into this market called Bridgestream. Like its predecessors, Bridgestream describes the problem area very well. If their solution delivers the goods in practice, it will be a first for this market and very exciting.

SOA and Applications

2006-01-17T18:56:00.000-08:00

Andy Thaler has an interesting article on SOA trends within the big apps vendors. From the outside in, it’s a good analysis, but in my opinion, it arrives at incorrect conclusions.

“Yet CIOs are demanding, as he puts it, ‘hot pluggable’ applications, which is another way of saying easy inter-operability between applications”

OK, I buy this.

“If SOA actually works, then they will be enabling customers to easily switch out the bits of their applications that customers dislike in favor of others, which is not in their (big vendor’s) interest.”

This is theoretically possible, but unlikely. Companies almost never swap out whole systems let along key services that dozens of other systems rely upon. The technical risk of doing this is very high, and the potential benefit (where’s the ROI for a slightly better service?) is pretty low.

“Customers need to be very aware of the desire by the application vendors to lock them into their offerings through their middleware, and should question how genuine the commitment of application vendors to true inter-operability really is.”

This is a novel comment, usually only big companies get accused of spreading FUD. I think trying to win in middleware through lock-in is a fool’s errand. The last time deeply proprietary middleware succeeded was back in the early 1990’s with proprietary messaging software like MQ Series and Rendezvous. Since then we've seen what happens to proprietary efforts like DCOM, and I think we've come out the other end older and wiser.

The key misconception I belive Andy's post contains is the idea that opening up application services will result in service level competition or replacement. The much more likely outcome is this action will result in services extending into new composite applications.

So when the application opens up the “get quote” service, will customers say:

“Great, I was never really happy with that 'get quote' service, now I can swap it out with a best of breed ‘get quote’ service?”

Or will customers say “Great, they opened up the ‘get quote’ service. I have several applications I wanted to build/buy that need this service and it seemed like a waste of time to build it for the 11th time.”

The axiom in software is answers to software problems lie in higher orders of abstraction, not from rewriting/replacing software that’s already working.

Innovation in Enterprise Software

2006-01-08T09:02:00.000-08:00

There’s been a resurgence of comments/questions about the state of innovation and/or growth in the enterprise software industry, correlated somewhat with the wave of year-in-review posts.

Bill Burnham looks at the public markets and sees a shrinking number of companies, a shrinking market capitalization of the sector. This has received numerous reinforcing links/comments.

Here’s another commentary by Goldman Sachs that leads with the “maturing” software industry.

The industry’s only full-time curmudgeon has been telling us IT doesn’t matter for some time now (which means you can save $18 and skip his book which poses the same question).

Oft quoted pundits like Erik Keller and Vinnie Mirchandi are apparently podcasting about same.

Perhaps it’s time to throw in the towel? I’m working in the software industry by choice so obviously I don’t think so.

There’s a very simple model of high tech industry evolution that I saw at MIT. I’m forgetting the name of the specific professor who first drew it up but anyone who knows please tell me and I’ll update the attribution. The model looked something like this:

Pretty basic right? But it’s very accurate and no one seems to make this distinction in terms of WHERE innovation is occurring.

What did we see from 1995 – 2002? A proliferation of new applications (E-procurement, Portals, PLM, SCM and others). What are we seeing from 2002 – present? An incredible amount of innovation in infrastructure including: server virtualization, storage virtualization, application management, BPM, enterprise services bus, RFID, web services management and many more.

As best as I can tell this model holds pretty well going back to the 70's. We've had waves of mainframe & minicomputer applications followed by some of the first discrete infrastructure markets like databases. Follow this up in the late 1980’s with a wave of databased oriented client-server applications and following this, a growth in EAI and OLTP vendors.

How people are not impressed/excited by the current innovation at the infrastructure layer is beyond me. Compared to the previous era(s) of EAI and systems management we've made tremendous strides. For whatever reason, people seem to discount this innovation at the infrastructure layer and run with their stories/commentary about a shrinking or compacting or maturing or less-than-innovative enterprise software industry. So be it.

But what exciting state we’ll be left with when this most recent infrastructure cycle runs its course. When most companies have a sizeable stock of enterprise class services up and running in production quality with a good service layer runtime, everything about today’s enterprise software market is going to change. I think customers are going to be thrilled with the results.

If the timing of the previous cycle is any guide, we’ve got a few more years of this infrastructure era left to go. Apparently this is unsatisfactory to the pundits and industry press. I want Christmas to come early too, but like the menu says: “Good cooking takes time. If you are made to wait, it is to serve you better and to please you.”

CA Buys Wily

2006-01-05T19:18:00.000-08:00

This acquisition was a timely addendum to my earlier post. I had just highlighted CA as a large software company who for the most part sat on the startup acquisition sidelines in 2005. Purchasing Wily is clearly a big step for CA.

What’s great about this acquisition is it gives you comfort that companies will still pay a premium for a leader in a market. 2005 saw a lot of acquisitions of “2^nd best players” in their respective areas. Wily was always ahead of Cyanea in N-tier app management, but IBM snapped up Cyanea for a good price ($100 mil I think) more than a year before Wily got taken out. Similar story with BEA buying Connectera which is behind Oatsystems (still private) in RFID middleware.

Wily’s acquisition is a vindication that you still can build a leading company, raise that tricky series C/D round and still get an exit at a price that justifies all the hard work you put in (didn’t look this way in 2005). Wily really has a fantastic set of products that have had great critical acclaim. Wily board member Peter Fenton at Accel Partners has been investing like a madman in important and interesting areas of enterprise technology in recent years while many of his VC peers dropped enterprise investing to chase the Web 2.0 hype.

It’s nice to see the good guys win.

The Year in Review: Enterprise Software Acquisitions

2005-12-27T14:53:00.000-08:00

Tis the season for “year in review” posts. Here’s my year in review for enterprise software acquisitions.

I don’t want to spend any time on the Oracle/PSFT/SEBL/RETK story because it’s been so well covered by others. What I find more interesting is the acquisitions of the classical venture backed enterprise software startups. When I say “classical venture backed software startups,” I’m talking about those software companies that raised $x million in various rounds of venture capital to build a product, get some customers, build the channel, etc.

Here’s a list of 2005 acquisitions that I could think of. I’m a little chagrined to do this list because VC’s have nifty access to services like VentureSource that make their lists more complete than what I can come up with on my own. I’ll add to the list and correct any errors as I learn about them. Please go easy. Acquirers are in parentheses.

Bowstreet (IBM)
Callixa (SAP)
Collation (IBM)
Collaxa (Oracle)
Compoze (BEA)
Connecterra (BEA)
Cyota (RSA)
Datapower (IBM)
Gluecode (IBM)
Groove Networks (Microsoft)
Infommersion (Business Objects)
Innobase (Oracle)
Khimerics (SAP)
M7 (BEA)
Oblix (Oracle)
Open Network (BMC)
TimesTen (Oracle)
Velosel (Tibco)

Some observations looking at this list:

In approximately 30% of these acquisitions, the venture investors almost definitely lost money (Bowstreet, Groove, Oblix, OpenNetwork, TimesTen). I'm determining this based on the cumulative funding raised relative to the (presumed or stated) acquisition price. This probably also means the founders’ shares and employees’ options were crammed down to close to zero. When so few venture backed software companies reach the promised land of a exit in a given year, it’s sobering to see the promised land isn’t as great as it’s cracked up to be.

Of the companies acquired post series C (Cyota, Bowstreet, Groove, Oblix, OpenNetwork, TimesTen, Velosel), nearly all were money losing propositions for venture investors. Cyota is a clear exception to this rule. I don't know about Velosel. There were poor rewards in 2005 for company stakeholders who had chosen to double down their bets and expand their business with equity capital. By contrast almost 100% of the companies acquired series A were bought at some premium to the A round (which rarely exceeds $15 million post money). These companies exited with (presumably) happy founders, investors and employees.

A few big acquirers sat on the sidelines in 2005 when it came to enterprise software acquisitions including CA and HP. Not all of these companies are typical acquirers of “next big thing” venture backed startups, but most of them are on a good day. Also absent are most of the mid-sized enterprise software acquirers like Parametric, Mercury Interactive, Ariba, Cognos, Hyperion Sybase and webMethods.

I think it will take a year or two to see if these observations turn into full-blown trends.

I'd be interested in other people's "predictions for 2006" on this same topic.

A Controlled Experiment For Open Source?

2005-12-21T19:04:00.000-08:00

I have a lot of strongly held conclusions about open source but rather than add the 90th long op-ed on the topic, I thought we could let the data do the talking.

Intalio recently announced it is open sourcing their BPM product.

Like many “professional open source” companies, the company is open sourcing the low-end version while charging for a professional license for a functionally similar but “enterprisified” upscale version.

For those not familiar, Intalio is one of a number of business process management (BPM) software companies. The other names that usually get said in the same “pure play BPM” breath are Savvion, Lombardi, Fuego and Handysoft.

So I titled this post "a controlled experiment" because we have a nice control group here. 1 BPM company has moved to open source, 4 (the control group) have not.

Let's see if professional open source makes a difference in Intalio’s relative market position. Currently Intalio is behind Savvion, Lombardi and Handysoft in terms of customer traction.

With the benefit of hindsight, will this be seen as a master stroke or a hail-mary pass?

Some facts about the compacting of utility IT spend? Please?

2005-12-20T17:31:00.000-08:00

A number of smart folks have talked about the CIO trend of compacting their “utility” or “infrastructure” IT spend. Examples include George Colony, Vinnie Merchandi and Nilofer Merchant.

The logic goes something like this:

1) Corporate IT groups spend money on two types of IT: “utility” and “new.”

Utility might include:

Replacement purchases of hardware (PC refresh, sever capacity, etc)
Incremental purchases of established software vendor licenses. For example, I need 20 more CPU’s (or is that cores?) of Oracle.
Software license maintenance fees
Internal maintenance. Namely all the resources required to bug fix, upkeep, modify, sustain all the applications a company has custom developed over the years.
Legacy systems maintenance. I.e. keeping those COBOL or AS400 skills fresh because you still have production systems running on both.

New might include:

New licensed and custom developed applications.
New enabling hardware technologies like mesh, RFID, etc.

2) Companies want to spend as little money on the utility piece as is reasonable. Makes sense right? The utility stuff is pure SG&A while the new stuff is CAPEX that portends some future growth or savings. Moreover the utility stuff is just boring. When we first bought that NAS box in 2001 it was just the coolest thing ever. Now it’s just a box and it costs money to keep around. Show us the new toys!

3) There’s some consensus that the large majority of the IT spend is spent on maintenance, not new stuff. I’ve heard anywhere between 70% to 90% depending on who you talk to. By the way that’s quite a range when global IT spend is around $1 trillion. That means people are saying total new IT investment is somewhere between $100 billion and $300 billion per year. I’ve yet to see anyone cite a credible study (actually any study) when they throw these percentages out. Still let’s leave the precise percentage alone for now.

4) There’s further consensus that customers are trying (and getting good at) compacting the utility spend to make more room for the new stuff. Anecdotally I buy the compacting bit. I see:

Virtualization technology saving incredible amounts of money in the data center
Linux dropping the cost of an enterprise sever from $500,000 to $50,000
Offshoring & outsourcing of some of the internal maintenance work
Business process outsourcing of non-strategic processes like payroll
Open source? (I’ll let this one dangle here for another post)

Here’s what I don’t get. Where is all this saved money going?

Option 1: It’s getting returned to the CEO.

“Mr. CEO, we found a way to do it all better, faster and cheaper. Here’s your refund for the year. Please reduce our IT budgets by the same amount for next year.” Hrm, just writing that sentence makes me think this is not happening. IDC doesn’t think this is happening either.

Plus if it did happen that way, the CEO would probably want to invest more in IT because the CIO is demonstrating they can produce a higher return on that invested capital than previously believed.

Option 2: It’s getting reinvested.

If this is true, I find it hard to account for the money. Worldwide IT spend is around $1 trillion right now according to IDC. Let’s take the average of the guesses and assume 80% of that can currently be categorized as utility. Now let’s further assume that due to smarts and hard work, the CIO’s of the world on average drop that percentage to 75% in 2006 (very conservative relative to everyone's predictions). That means $50 billion is incrementally available next year for “new stuff” above and beyond the $200 billion already earmarked.

I’m not sure I see this in the forecasts. I mentally add up every “must have, hot new” IT spend category like RFID, SOA, BPM, MDM and Analytics and I don’t think I get anywhere near $50 billion. Looking at it a different way, a 5 point shift would represent a 25% year over year growth in new IT project investment.

I think compressing 5 percentage points of utility and shipping it over to new projects, on a $1 trillion base, would create a new product bonanza for established vendors and startups that would make 1999 seem like a recession.

Option 3: IT compacting is just an idea and a few experiments at this stage. The utility percentage is actually flat or growing.

Sadagopan’s blog actually inferred this, thought it’s also short on citable studies. This is possible but the compacting activities I listed in a few minutes of brainstorming represent big bucks. I’m not ready to believe utility is so untouchable.

So I’m at a loss. A Snickers bar for anyone who can account for how much compacting is really going on right now and where the compacted funds are headed.

MBA’s: a great way to spoil a perfectly good software company?

2005-12-17T15:09:00.000-08:00

Poking fun at MBA’s or “suits” and their corrosive effect on software companies has been a sport of the software industry for years now. It does seem to me the “suit versus geek” debate has risen in volume in recent years.

A few of my favorite examples:

Lotus: Rendered irrelevant. Formerly run by suits.

Joel Spolsky, whose blog I thoroughly enjoy reading, referred to the influx of MBA’s a major contribution to the death of Lotus, calling former CEO Jim Manzi as “the suit who let the MBAs take over Lotus.”

Google: Riding high, doesn’t like suits.

Numerous stories have surfaced about Google’s allergic reaction to business types. In a recent BusinessWeek article a suit complains:

"They just aren't very focused," says the prospective hire, who didn't get the job. "They're biased against businesspeople, and their deal strategy is pretty much, 'O.K., if we see something, then we'll look at it."'

This is actually followed by Google (surprisingly) declaring its affection for MBA’s:

”Drummond rejects the accusations that Google is anti-businesspeople. He says Google has hired many MBAs and bankers…”

Oracle: Wasted over $16 billion on acquisitions. Stock has since dropped 25%. Run by suits.

Bill Gates gave great quote a few weeks back when an interviewer asked him about Oracle’s recent acquisition binge:

“If the next three people under you don't write code but they do deals, what do you get? You get deals. They will probably do more deals than anybody, and we'll write more code than anybody.”

Microsoft: Fallen on hard times. Gave the CEO job to an MBA 5 years ago.

Much ink has been spilled outlining Microsoft’s missteps and talent flight in recent years.

Some have gone so far as to suggest these missteps can be correlated back to when the CEO job was handed over to a suit. Ballmer denies this is the case.

I’ll add a one more to the list too….

Siebel: in decline since 2001, now gone. Single greatest per-capita hirer of MBA's of any software company.

From 1998 to 2002 Siebel hired hundreds of MBA’s. A suit himself, Tom Siebel placed great stock in the MBA background and has been kind enough to pay for some of my friends’ MBA tuitions.

I remember visiting the Siebel cafeteria in 2003. The sheer mass of MBA’s combined with Siebel’s strict dress code made me think Tom had managed to construct Gattaca in San Mateo a hundred years before its time. Soon after the large influx of MBA’s, Siebel’s revenue and stock went into a tailspin.

By the way, I myself am a complete suit. I’ve got an MBA, I’ve never written a line of code and I own several Banana Republic corporate casual shirts including one in that nice “business development blue” that was in fashion during the dot com boom.

By rights I should be offended by all these anti-business/MBA quips but for the most part I think they’re spot on. There does seem to be an unmistakable correlation between a software company’s decline and the preponderance of MBA’s/suits. But correlation is not causation right?

Here’s what I think is actually going on here:

1) Autocorrelation

For the most part, the onset of MBA’s in a software company and the company’s decline are autocorrelated events. They’re both stem from the inevitable decline of a software company’s core business. When you first invent the killer app, everyone’s going to line up to buy one. You don’t really need an MBA for much except to organize the line. Once most customers have bought the killer app and competition arrives, you’re killer app isn’t going to sell itself anymore. Companies bring in the MBA’s to find clever business-like ways to protect the franchise (product versioning, segmentation, clever pricing, novel channel approaches, etc). These tricks work but they’re usually poor substitutes for the old days of a killer app in an unsaturated market with few substitutes. So MBA’s didn’t cause the decline, but they have a knack for showing up right as the decline begins.

2) Too much of a good thing

Too many MBA’s can be a dangerous thing, but too many anything is a dangerous thing. The MBA mindset (I contend there is such a thing) provides a valuable perspective for companies but it’s just one perspective. If you stock your company to the rafters with any one type of perspective, you get way too much agreement and groupthink and this blinds companies to seeing the critical turns in the road. DEC is a notorious example of engineer-led groupthink much as Siebel might be an example of MBA-led groupthink.

3) What do do about it

For both of the reasons above, I’d argue software companies should hire more MBA’s earlier in the life of a software company (to better prepare for the day when the core business declines) but fewer MBA’s across the overall life of the company (to prevent groupthink).

So to pull out an overused trope, “The suit is dead, long live the suit.”

Introduction

2005-12-17T12:12:00.000-08:00

So I decided to take the plunge and start a blog. Why I'm doing this:

Curiosity – A blog seems like a potential way to attract some smart people to focus their brains on specific topics I’m interested in.

Relevancy - I work for a big software company. For the most part my days are spent figuring on how to build more/better SAP software or sell more SAP software. This is great stuff, but it doesn't keep you as current on the market as the pundit/VC types who get to keep up on industry trends for a living. The blog is a way for me to force myself to stay current.

Accuracy – I feel like some fallacies on our industry get unduly propagated through the tech/blog/VC echo chamber. I’d like to try provide some counterweight to these misconceptions.

Ego – Hey, at least I’m honest about it.

Two guiding principles for this blog:

Quality over quantity – I’d like to keep this a little less frequent and a little more analytical than some of the higher volume blogs I read. I think both types of blogs are good, the former is just one I'm better suited for.

Keep it to enterprise software – I actually believe I have a halfway decent taste in books, music, electronic gadgets, etc but I’m not sure anyone else would agree. I can prove I know a thing or two about enterprise software, so I’ll keep this blog to that.

Happy reading,

Charles