Software service networks, not product stacks

The other day there was an article in CNET titled “Software’s Stack Wars” and in reading it my first thought was to be a little irked that they labeled NetWeaver as simply middleware, however a little bit later I was thinking about it and it occurred me that the entire premise of this article is just wrong. Every single company mentioned in the table is a partner with every other company in the list, and you could include EMC and Cisco as well as they have their own legitimate platform aspirations. Nobody is really expecting to get into a position that locks out any other other companies, the reality is much more that various components interoperate in our client’s datacenter.

We are well past the days when stacks were truly monolithic in nature and static in their linkages, in fact you could reasonably suggest that the forward thinkers in this business stopped thinking that way as early as the CORBA days and more broadly following the advent of true web applications. It used to be a big deal for application vendors to publish their API’s, even though they were little more than naming the objects and methods the app was built with and some external port to call them; today people expect a full blown services layer that is analogous RPC on steroids, in other words actually driving an application component remotely instead of just getting/giving some data.

REST has further uncomplicated the software business, even though most established vendors have yet to realize the quantum leap in capabilities that it brings to them. Too much of enterprise software is still client/server with the client stuffed inside of a web browser. REST, along with scripting, opens up some incredible capabilities for application developers and those people deploying and using them, it frees up the requirement for “state” in an application workflow and realizes what the early proponents of web architectures advocated, an application that is highly personal and delivers just the functionality that a user requires instead of what the app vendor packages together.

At the ES Forum (will try to find a link) that SAP hosted the other day for partners, Shai said emphatically that “we are not a platform company, we’re an application company”. I dismissed that initially as “well yeah, we’re an app company that happened to also build a platform” but upon further reflection I think I see where he is going with it, which is ironically coming full circle with the CNET piece I started on. What the CNET author didn’t realize or think to explore is actually exactly where application vendors are going, and I can’t sum it up any better than the first commenter to the CNET article itself.

TalkBack: Best of breed – ancient history | reader response on CNET

Yessir, in tomorrow’s world value will come from leverage of software service networks, not software product stacks.

Technorati Tags:

More on this topic (What's this?)
Emotional Prosthetics
Web-based office software
Does Distributed Software Development Work?
Wall St research suffers since Spitzer deal
Read more on Computer Software, CNET Networks at Wikinvest

4 thoughts on Software service networks, not product stacks

  1. Pingback » Software service networks | Between the Lines |
  2. Pingback AccMan Pro - Dennis Howlett on innovation for professional accountants » Vendor messaging and Tom Raftery
  3. I agree with your points, Jeff. Even though it’s nice to see that Microsoft was the only vendor portrayed as having a ‘complete stack’ it’s clear that a) having an OS would help SAP not at all; and b) more importantly, the dynamics (no pun intended) of enterprise software are changing dramatically. Ultimately the winners will be whose services (and embedded IP) are clearly superior, whose services can be most fluidly composed into highly customized apps, and whose services have the most flexible hosting (and charging) configurations. … Barry

  4. Pingback » Wither Oracle, SAP, et al? (Pt 2) | Software as services |

Comments are closed