10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Stefan Tilkov on Nov 21, 2006
With a very funny blog post, written in the form of a dialogue between a Web services expert and a hypothetical developer, Pete Lacey has started an amazing chain of postings. Here is quick excerpt, but be sure to read the whole post ("SG" stands for "SOAP guy"):
SG: Forget what I said. From here on in we pass around coarse-grained messages—you like that term, coarse-grained?. Messages that conform to an XML Schema. We call the new style Document/Literal and the old style RPC/Encoded.
Dev: XML Schema?
SG: Oh, it’s all the rage. Next big thing. Take a look.
Dev: (Reads XML Schema spec). Saints preserve us! Alexander the Great couldn’t unravel that.
Among the many industry luminaries linking to Pete's post are Nelson Minar, who designed the SOAP-based Google APIs for both Google's search AdWords and says he'd never choose SOAP and WSDL again, IBM's Sam Ruby, who shows that REST as an alternative to SOAP is not without (fixable) problems, Sun's Tim Bray, and Ruby on Rails creator David Heinemeier Hansson.
Bill de hÓra's comment is a nice RESTafarian summary:
Which is worse, that everyone gets it now and we'll have REST startups in Q207, or that it took half a decade?
>Which is worse, that everyone gets it now and we'll have REST startups in Q207, or that it took half a decade?
Unfortunately, even that may be a false choice. My experience is that not everyone gets it now... so it's actually worse than either of those alternatives, sadly.
I'm not suggesting that SOAP is the wrong choice for all cases (sometimes you don't control the choice of protocol between you and your collaborators), but it's just that when it clearly *is* the wrong choice, it's still too often the first tool to come out of the toolbox, as if it were the only one available.
While you're certainly right that there is still a lot of people who don't "get it", I do think that there's a lot more acceptance than, say, two years ago. Back then, even considering REST was considered weird ...
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
2 comments
Watch Thread Reply