On 12/18/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > On 18/12/06, 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. > > Completely agree, but REST being "the web" is a big leap as well. > I've done a bunch of Web projects, and know others who have done even > more. None of us followed the principles of the REST paper. I'm not > disagreeing with the 2nd bit Anne, but I think the first bit is one of > those bold claims that don't stack up. So was WWW and HTTP > disruptive... hell yes. But did this REST architectural approach > enable that, or did we all just get on with using a browser as a thin > client... I'd say the later.
REST defines the core architecture of the Web -- URIs, resources, representations, self-describing media types, the idempotent GET operation that enables caching, etc. Although many applications don't follow the REST principles to the letter, the Web would not work if it weren't for REST. > > 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. > > Read that one as well :) Keystone Advantage is an interesting > business book while we are on similar topics! > > > > > > 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]> wrote: > > > >> On 12/15/06, Steve Jones <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > >
