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.
How would you like to view the presentation?
Getting Started with Stratos - an Open Source Cloud Platform
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Monitor your Production Java App - includes JMX! Low Overhead - Free download
18 agile and lean practices for effective software development governance
I mean, sure, you can (and should be) skeptical and critical about stuff that isn't finalized yet and I do get they have commercial agendas but still. There were two types of sentences
I think even a person who didn't speak English could have sorted those out ;-)
But well, the topic was Spring and EE 6 so I guess he did cover it from their point of view
While I do see an unmistakable marketing/self-promotion aspect to this talk, it is refreshing in some ways if you ignore some of the body language (which is subjective) - it looks at the competition between Java EE and Spring as something good for the community, it acknowledges that both camps influence each other in positive ways and that there is indeed a gradual convergence...
Cheers,
Reza
----------------------------------
Independent Consultant
Expert Group Member, EJB 3.1 and Java EE 6
Author EJB 3 in Action
Resin EJB 3.1 Lite Container Contributor
I'm a Seam developer for over 2 years now but I try to stay as objective and unbiased as possible. The only JSR that he seemed very enthusiastic about was Bean Validations and possibly JSF 2 but did not seem very enthusiastic about the clashing of responsibilities in the EGs for EJB 3.1 and JSR299 and the fact that 299 is constantly changing. If you think about it, do we really need possibly (or partially?) two component models in EE 6 (EJB 3.1 and 299)? I think that 299 (or JCDI) can be used in a SE or EE environment, which is what makes it all-encompassing and difficult to design/plan/deal with. It's analogous to a brake system that may be configured to be used in different types of vehicles (i.e. not just cars).
It seems very obvious that EE 6 and Spring 3 are basically converging in terms of functionalities and design and the advantage that the Spring stack has over the EE 6 stack is that most likely the Spring core design/dev team is not as disparate and possibly isolated as the EGs for EE 6.
EE 5/6 seems like a hydra whereas Spring is very well orchestrated in terms of planning and organization. At least that's what I have observed from a high level. If EE 5 was better planned and orchestrated *amongst* the EGs, then maybe there would have been no need for Seam in the first place.
In any event, I am looking forward to the RI for EE 6 in 2010 or whenever it may be released (and yes, I know Glassfish V3 is a preview of EE 6 but does it include 299)?
An interesting point he made was the fact that the JSF RI libraries are embedded in the EE 5/6 app server (I know JBoss is like that anyways) so how does one go about upgrading basically a single module like JSF 1.2 to JSF 2.0 libraries without upgrading/replacing the entire app server with the newer version? Modularization is critical and I think JBoss 5 has implemented and/or adopted some OSGi ideas in their design/implementation but I'm not familiar enough to comment on that.
Anyways, thanks to JHoller for his perspectives and feedback, it was all pretty interesting.
I haven't managed to listen to presentation (shame there is no transcript) yet. Arbi - GlassFish V3 final release is the Java EE 6 reference implementation. GlassFish V3 today includes CDI, and we are finalizing the integration at the moment.
I think there is a lot of FUD around how the JCP works. As someone working inside the JCP, I see a far greater sense of common goals and camaraderie there than I see on projects on my consulting assignments. As to Spring developers, I find the homogeneity of thought quite disturbing and unnatural, even somewhat Orwellian. I see the managed bean/CDI spec as very reasonable and a naturally complementary JSR to EJB 3.1. Moreover, unlike what the presentation claims, there is no particularly fractious disagreements in any of the JSRs beyond healthy debate about complex issues. There is certainly no great rift between the JSR 299 and EJB 3.1 EGs.
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.
5 comments
Watch Thread Reply