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 Jon Rose on Apr 08, 2008
We at SitePen are very strongly in favor of the Open Web concept, because it’s the Open Web that has gotten us what we have today and will ultimately lead us to the best “web of the future”. I think that Brad does a good job laying out the characteristics that have made the web successful thus far.Dangoor goes on to criticize Adobe Flex in context of the open web, although does not clearly quantify what he sees as the “downsides.”
The “is it the Open Web?” question comes up with Adobe Flex. One could always build entire sites in Flash, but doing so was almost entirely filled with downsides.Ryan Stewart, a Flex evangelist for Adobe, responded on his blog arguing:
Adobe is an incredibly open company. We've released the Tamarin project, the VM for the Flash Player, as an open source project. We've open sourced Flex. We've open sourced BlazeDS which enables rich, real time data communication. And we've opened up the AMF specification which is a much faster way to transfer data between clients and servers. We've been a long time supporter of our runtimes on Linux which includes a public beta of Adobe AIR. We continually solicit feedback from our community, our customers, and our partners in making sure that we innovate on our tools and our platform.Dangoor goes on to conclude his assessment of Adobe Flex by asking a key question:
Furthermore, we want to engage with the open web. We think that it benefits everyone if Adobe's rich platform and the browsers/standards committee all continue working towards a richer web.
With Adobe providing free Flash players for Windows, Mac and Linux, the tempting question to ask is “why care if SWF is open?”Dangoor’s ultimate conclusion is that developers will decide:
There is no standards body that can truly dictate what the web of tomorrow looks like. Developers will choose their tools as they build their apps, and users will pick the apps that they like the best. For those of us who are web developers, we should strive to ensure that the web of tomorrow remains open so that we have freedom in how we build our apps.For developers and architects in the InfoQ.com community, does the power of Adobe Flex trump the openness concerns? Do Adobe’s efforts outlined by Ryan Stewarts help to eliminate this concern?
Free Gartner Cloud Service Brokerage Report
Monitor your Production Java App - includes JMX! Low Overhead - Free download
18 agile and lean practices for effective software development governance
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
There are three problems with your article:
This certainly looks like a slapped together attempt at traffic generation.
When I referred to Flash, I was referring to the SWF file player that Adobe produces. Flex is a tool for creating SWF files and a set of ActionScript runtime classes.
Lead ins like this: "Dangoor goes on to conclude his assessment of Adobe Flex" for a quote like this: "With Adobe providing free Flash players for Windows, Mac and Linux, the tempting question to ask is “why care if SWF is open?”" are annoying because in the part of my article you quoted I didn't mention Flex at all.
As I point out above, I do realize that Flex is related to Flash in that Flash is the runtime environment for Flex applications. But the way you quoted my article and Ryan's implies that I was referring to Flex itself as being closed.
In my article, I talk specifically about how Flex can be viewed as an evolution of the web and that Flex is open source. And that Adobe opened up the AMF spec.
So, Flex is not at all the issue.
The point of my article was to test Brad Neuberg's "Open Web" definition to see how Flash and Silverlight fit in. They actually come close to Brad's definition as he has outlined it. All I said about Flash, ultimately, is that Adobe produces an SDK/spec for SWF files but explicitly forbids people from making alternative player implementations. Since the point is to talk about the definition of "Open Web", you cannot call something "open" and yet still have it closed off for experimentation by third parties. (More useful stuff appears in the comments on Ryan's blog... like the role of trademark, etc.)
Sorry about that formatting...
There are three problems with your article:
This certainly looks like a slapped together attempt at traffic generation.
When I referred to Flash, I was referring to the SWF file player that Adobe produces. Flex is a tool for creating SWF files and a set of ActionScript runtime classes.
Lead ins like this: "Dangoor goes on to conclude his assessment of Adobe Flex" for a quote like this: "With Adobe providing free Flash players for Windows, Mac and Linux, the tempting question to ask is “why care if SWF is open?”" are annoying because in the part of my article you quoted I didn't mention Flex at all.
As I point out above, I do realize that Flex is related to Flash in that Flash is the runtime environment for Flex applications.
In my article, I talk specifically about how Flex can be viewed as an evolution of the web and that Flex is open source. And that Adobe opened up the AMF spec.
So, Flex is not at all the issue.
The point of my article was to test Brad Neuberg's "Open Web" definition to see how Flash and Silverlight fit in. They actually come close to Brad's definition as he has outlined it. All I said about Flash, ultimately, is that Adobe produces an SDK/spec for SWF files but explicitly forbids people from making alternative player implementations. Since the point is to talk about the definition of "Open Web", you cannot call something "open" and yet still have it closed off for experimentation by third parties. (More useful stuff appears in the comments on Ryan's blog... like the role of trademark, etc.)
Yes, as Kevin says, this post on InfoQ does seem to miss the original points. Advice, go read the original article at sitepen, to get more insight.
BTW: One of the points of Kevin is that flash is closed. I couldn't agree more. Actually, I wrote a piece on that not that long ago, called flash is still closed and proprietary technology, to try and warn about that at that time.
While I do like the sudden openness of Adobe on some areas, I don't quite buy all their marketing talk about it. For instance, it is not at all true, that Adobe has been a long time supporter of flashplayer on linux. Actually, I see that as a slap in the face, of the many linux users, that were without a working, official, flashplayer for years. The history says, that they (Adobe) have been *really bad* supporters of their runtime on linux. It is better now. Will it continue to be? Who knows, it is closed!
Hi Kevin,
I read your blog, but haven't read Ryan's yet. I'm curious what other aspects of Flash Player / SWF (besides the restriction on using the SWF spec to build your own SWF player) would you consider conflicting with the "open web" philosophy. (Do you call it a philosophy?)
BTW: Did you see that there is now a public bug db for Flash Player.
Also, in your article you say:For those of us who are web developers, we should strive to ensure that the web of tomorrow remains open so that we have freedom in how we build our apps.
Could you explain more about what those freedoms are? I'm curious because when I became a Flex developer I don't feel like I really gave up much of my freedom. I actually feel that I gained freedom in response to trusting Adobe. I cover this in more depth in my blog "How I Overcame My Fear of Flash". To me this is the same sort of trust I put in Google, Apple, and many others when I use their software / services. No matter what technology we choose we must trust someone. Over the past few years Adobe has done many things that make them more trustworthy (ie. Open Source Tamarin, Flex, & BlazeDS, open the AMF spec, public bug DBs, etc). Despite the good things Adobe, Google, Apple, etc have done any company can do things that would cause me to no longer trust them - but then they would lose their customers. So it is in companies best interests to build and maintain trust with their customers.
Do proponents of the "open web" have a "trust no one" mentality?
-James
Hi James,
I can't speak for all of the "Open Web" people, of course. My original article was really all about seeing how Flash and Silverlight stood up to the principles laid down by someone else for the Open Web. You know me, so you know that I'm actually quite a pragmatic sort.
I agree with you that you do have to trust other companies at some level in order to get anything done. But, the rise of open source of the past decade has changed my thinking a bit about platforms and what kinds of lock-in I feel comfortable with. When it comes to libraries, for example, I strongly prefer open source because I've been bitten in the past by problems that I could have fixed had I only had the source.
From what I've seen, most Open Web proponents believe in the "Open Web" because of how successful the web has been, in large part due to open formats and protocols. I think that there has been a tremendous amount of innovation and interesting work as a result of the standards and protocols.
My perspective is this: I don't personally find any aspect of Flash/Flex in opposition to the notion of "Open Web" beyond the SWF spec licensing. I think that Adobe could benefit from open sourcing the Flash Player, but I certainly don't think that's a requirement to being "open".
Kevin
Thanks Kevin. That is exactly the pragmatic response I expected from you. :)
I'm curious what other proponents of the "open web" think.
-James
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.
6 comments
Watch Thread Reply