Thank you, Anne, for an excellent summary of the preceding "debate"!
--- In [email protected], "Anne Thomas Manes" <[EMAIL PROTECTED]> wrote: > > NOTE: REST *is* a disruptive innovation. I can't think of too many other > innovations that have been as disruptive as the hypermedia architecture that > has enabled the Web. I'm less convinced that the application of REST to > application integration will be quite as disruptive. The key to disruptive > innovations is that they change the value proposition. In most cases, > disruptive innovations address new requirements (easier, smaller, lighter, > portable, etc), but in exchange they adopt a "good enough" stance in regards > to traditional requirements (speed, power, capacity, durability, etc). > > In order for a disruptive innovation to really be successful, its new value > proposition must be really compelling and highly differentiated from the > traditional solution. This is where REST fails to grab attention away from > RPC or MOM based middleware solutions. > 1- Most people don't understand what REST is (they confuse it with POX > over HTTP) > 2- Although REST is simple, it's really hard to fully grok > 3- The benefits of REST over RPC when used for integration are not readily > apparent > > In conjuction with "The Innovator's Dilemma" (which I strongly recommend > everyone read), I also recommend you read Malcolm Gladwell's "The Tipping > Point", which talks about adoption cycles. > > Anne > > On 12/17/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: > > > > On Dec 15, 2006, at 11:07 AM, Steve Jones wrote: > > > > > On 15/12/06, Mark Baker <[EMAIL PROTECTED] <distobj%40acm.org>> wrote: > > >> On 12/15/06, Steve Jones <[EMAIL PROTECTED]<jones.steveg%40gmail.com>> > > wrote: > > >>> or c) start an underground movement > > >>> of people using it in the belief that "everyone will come to > > >>> realise". > > >>> > > >>> The later is often the worst of the two as it tends to explode in a > > >>> mess, where as the first can often be ignored by good software > > >>> architects and designers. > > >> > > >> Hmm, so how are people supposed to distinguish between that > > >> situation, > > >> and an honest-to-goodness improvement on the status quo? Or do you > > >> believe that if it was an improvement, that everybody would > > >> immediately recognize it as such and adopt it, despite the fact that > > >> it is likely to be disruptive to vendors with entrenched > > >> positions in > > >> the market? > > > > > > No I think if it was a genuine improvement they would be able to > > > _demonstrate_ the improvement to _communicate_ why the change was > > > required. > > > > Maybe, maybe not. Mark mentioned Clayton Christensen's "The > > Innovator's Dilemma" elsewhere in this thread. I strongly urge you to > > read it, otherwise you won't ever understand Mark's point or the > > point I'm about to make. > > > > Whether an improvement can be "demonstrated" or "communicated" > > depends not only on the demonstrators/communicators, but also on > > those receiving the demonstration and communications. If the latter > > fall into the risk-averse category when it comes to technology > > adoption while the former fall into the risk-taking category, they > > can talk all they want, and they'll *never* understand each other. > > That, in fact, explains a lot of the miscommunication and > > misunderstandings that have plagued this thread. You're viewing REST > > as just another sustaining innovation, but for enterprise > > integration, it isn't a sustaining innovation, but it's a potentially > > disruptive one. Go read the book. > > > > --steve > > > > >
