Surrupiei e postei abaixo um trecho de um artigo de Phil Wainewright, do blog Loosely Coupled. Trata-se de uma outra dimensão de alterações que SOA, mesmo que indiretamente, pode causar no mercado de software. Sexta eu mostrei uma perpectiva diferente, comentando uma notícia sobre a Siebel. Ali era uma questão técnica. Agora a dimensão comercial:

The software industry has always been useless at understanding what it's selling. Over the years this effect has been compounded because many of the IT managers it sells to have been contaminated by the same lack of real-world perspective. Vendors get understandably excited about the technology they have on offer, and eventually a whole ecosystem of sales and marketing teams, industry analysts, journalists and technology-focused buyers ends up getting totally absorbed into a closed debate about which product, system or architecture is better than another.

When someone finally comes along and points out that there's a wider context in which all of this operates, it's been so long that anyone's noticed that it seems like a breath of fresh air rather than simply stating the bleeding obvious. Over on the SOA blog on ZDNet, Britton Manasco last week cited an Economist article about software pricing and business models, concluding: "Could it be that software-based value models are all doomed? Could it be that software companies will have to begin charging for — dare I say it — business results?"

The issue of value-based pricing has come to the fore because of a confluence of industry trends, of which the advent of dual-core processors has become the final straw. The sudden uncertainty as to how many processors there are in a single processor chip has fatally undermined the existing pricing model used by software vendors, which bears absolutely no relation to the utility of the software to an individual customer, being completely arbitrarily based on the number of processors it is installed on. Thus for example one customer lumbered with a badly designed implementation that scales poorly could easily pay four or five times as much as another for the same features and performance. Whereas hundreds of customers of an on-demand application provider like salesforce.com might share the lower of the two costs between all of them, reducing it to a fraction of the on-premises equivalent. The software-as-services example clearly shows up the absurdity of the model. Emerging service-oriented architectures and grid computing will soon make processor-based pricing universally untenable.

Richard Veryard at CBDI has taken up the same theme in a commentary this week on Service Economics, arguing that no form of resource-based or input-based pricing is going to work as we become more service-oriented: "For the service economy, output-based pricing makes much more sense. Consumers pay for what they actually get, rather than what the service provider uses. There are various ways of calculating this, at different levels of granularity, with different distribution of risk." I'm sure this sort of talk fills software vendors with horror, but if airlines can manage value-based pricing, why not the software industry?
The problem of course is that software vendors have been doing what they've been doing for so long that they've forgotten what it's really all about. To adapt Ted Levitt's famous formulation from his HBR article on Marketing Myopia, they think they're in the software business when really they're in the business automation business. No enterprise buys software for the sake of owning software (or none should, at least). The true reason for buying software is to have some element of your business operations run better, faster or more cheaply. That, after all, is the supposed justification for making elaborate return on investment (ROI) calculations: in order to estimate when (if ever) the anticipated business results will actually deliver a payback.

"...software vendors have been doing what they've been doing for so long that they've forgotten what it's really all about."

O q dizer então dos serviços de desenvolvimento de sistemas? Dos modelos atuais, particularmente aqueles (vários: 2) predominantes em Pindorama?