Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Rob Thornton on Apr 24, 2007
Red Hat made two big announcements today at a press conference about their middleware strategy. First, they're separating JBoss into two branches, similar to what they did with Red Hat Enterprise Linux and Fedora. Secondly, they have acquired all the assets of MetaMatrix, provider of federated data services and metadata management to boost their SOA offerings.
Splitting the development branches of JBoss will result in JBoss.org housing the community branch and redhat.com/jboss holding the enterprise branch. Dennis Byron was at the press conference and believes it was motivated by JBoss not providing the expected revenue boost. Red Hat will only be supporting the enterprise branch, but they will support that for seven years. Sacha Labourey explains the split and how it will function, including the differences from the RHEL / Fedora split:
While this new development, distribution and support model looks and smells a lot like the good old RHEL/Fedora model applied to Red Hat's Linux distribution, it is not exactly the same. While the rules are the same with regard to the binaries, the JBoss source code will remain public and accessible during the complete Enterprise lifecycle activity, not just for specific release snapshots.
The second announcement was the acquisition of all of the assets of MetaMatrix. Some questions about the acquisition are answered by Red Hat, including that the motivation was to build out their SOA stack. The addition of MetaMatrix's assets will allow them to better support data-intensive workloads. The MetaMatrix products will be integrated into the JBoss line and while initially be available only via subscription, will be open-sourced eventually.
If someone want to know what will happen with this Jboss split, just look at RHEL and Fedora ... Fedora is for community and it is not recommended for enterprise.
May be we'd better think about creating "enterprise Community" and "community Community" !
Hardly surprising, as Red Hat have been successful with the Fedora/RHEL model in their bread and butter Linux space. It's perhaps surprising it took so long for this change to happen. It's also probably significant that, now Marc Fleury has left and Rob Bearden, Bob Bickel, Brad Murdoch and other key execs at JBoss Group are long gone (as well as the VCs, who contributed a lot to the strategy), the architects of the original JBoss model are no longer with Red Hat.
Rob, thanks for the reference to my blog.
Just FYI, I did not mean to imply that Red Hat specifically made this organizational change because the revenue numbers were lower than expected, only that it updated its overall JBoss strategy for that reason. Probably more important in terms of getting the numbers where they want them is the announcement of the stack integration and the new development tools.
Dennis
What is significant is that JBoss continues to be core to the Red Hat value proposition and the announcement supports the initial attempt to make JBoss the default middleware layer for Linux. I wonder how much will this limit the attempts to make it cross-OS, such as Longhorn and Solaris-next, with so much of the resources being put in to support models that are conducive to the Red Hat business model of Linux-only.
I wonder what this means for the app server market in general, as more of the 'owners' of OS platforms come out with tightly integrated or at least strategicly integrated app server platforms. I guess WebSphere will continue to be all-purpose, but if you're a Red Hat customer, and new to app servers, what would you buy JBoss or WebLogic? If you're a Solaris customer, and new to app servers, what would you buy Glassfish or WebLogic?
It makes one wonder where the oxygen comes from for certain vendors...
Historically there has been very little linkage between app server choice and OS--witness the ubiquity of Solaris and the relatively low market share of Sun app servers in the past. Now Glassfish probably will get traction, but that's because it's a good product, not because it comes from the OS vendor.
Being that dependent on one vendor isn't necessarily good, either. Microsoft is always likely to win that battle, anyway: they can provide the OS, the app server, the language, tools and database as well.I wonder how much will this limit the attempts to make it cross-OS, such as Longhorn and Solaris-next, with so much of the resources being put in to support models that are conducive to the Red Hat business model of Linux-only.
I wouldn't expect it to limit JBoss on other platforms. It would be a grave mistake to do so.
The infamous one-throat-to-choke is a bit over-the-top as euphimsms go, but it does become a reality for corporations that have heavily invested in production sites. And don't tell Oracle that this model won't work, because they just spent $25B to prove that consolidation, and that one line of support is the best allotment of resources will be the prevailing model.
I would argue that in order to begin any process of innovation, that you first need to standardize your infrastructure, and begin simplifying your IT environment, which is exactly what Red Hat, Sun, IBM, and Oracle are betting on, although I don't see OC4J to be sufficient for this excercise which is why they need to buy BEA, and BEA needs to sell to ORCL in order to be considered in enterprise-wide deployments.
JBoss recognized the writing on the wall, not that they could not scale for developers, which they can do via jboss.org, but how they would scale for enterprise support. I am not convinced that BEA, and I am sorry to say, Interface 21/Spring, can scale to take-on enterprise deployments without a parent with relationships and expertise with Fortune 2000 companies.
I am not convinced that BEA, and I am sorry to say, Interface 21/Spring, can scale to take-on enterprise deployments without a parent with relationships and expertise with Fortune 2000 companies.
Are you saying that BEA does not has relationships and expertise with Fortune 2000 companies?? WebLogic has long been one of the market leaders in the enterprise space. And BEA's product line is broadening.
As for Interface21, we have dozens of Fortune 2000 clients with many large Spring deployments. Including nearly all of the world's top 10 banks. No, we do not claim to satisfy every IT need across an organization: just that we offer the best solutions for what we do, and understand the need to integrate with solutions from other vendors. We are not convinced that a one stop shop is in the best interests of customers, in any case.
There can never be a one stop shop in large enterprises. For example, most of our large customers use .NET extensively, as well as Java.
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
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.
7 comments
Watch Thread Reply