View post: More Reasons to Adopt JBoss Enterprise Platforms
Navigation
Recent posts from all feeds
- esbgen: An easy way to create JBoss ESB Projects
- IBM Websphere - officially better than anything, ever
- Book review and NHibernate Search
- Red Hat Launches New JBoss SOA Assessment Tool
- Thank you !
- Jbpm Mail delivery
- JBoss Marshalling Framework 1.0.0.Beta1 Released
- Performance Comparison between NIO Frameworks
- Mobicents Metamorphosis
- JBoss Jbpm superstates
- « Back to feed: Andrig's JBoss Blog
More Reasons to Adopt JBoss Enterprise Platforms
In my last post, I talked about some reasons to adopt JBoss enterprise platforms, versus our jboss.org software. My main focus was on the additional testing that we do for the software, and I mentioned the stability and support as an aside. In this post, I would like to address the issue of stability and support.
So, what do you get as a subscriber in terms of stability and support? Let's start by addressing stability. For a lot of customers, stability is very important. They make a large investment in a custom developed application, and it is expected to be used in production for many years. Some companies capitalize this work, from an accounting perspective, and then amortize it over three, five or even seven years! Over that time period, even if they are doing regular upgrade releases to the software, they need the middle-ware to be as stable as possible. API and even configuration incompatibilities, can cause major problems. Typical cycles for upgrading middle-ware in an enterprise setting can also take six to nine months, or longer! With these types of cycle times in mind, our products have to be stable.
So, just how do we keep the products stable? We have instituted a quarterly cumulative patch process within the enterprise platforms. On a quarterly basis, we take defects and fix them and roll them together in a release (no new features). Some of these defects might have been delivered to customers prior to the quarterly cycle as hot fixes, depending on severity. We leverage the test suites that I detailed in my earlier post, and make sure there are no regressions. Also, the defects come from our customers, as a priority, but we may also fix issues that we know affect the enterprise platform that may have been caught in our upstream jboss.org releases. This gives us a measure of additional stability, that even though a customer has not seen this issue, we have proactively fixed it knowing that it will probably crop up down the road. Of course, this is the real power of an open source model. You have the widest and most varied deployments to flush out issues, and address them proactively. This cumulative patch process goes on for three full years, where customers can be assured that if they upgrade to any of these releases their applications will not break. For another two years, we will still produce these cumulative patch releases, but they will contain only security errata. This is vastly different than the jboss.org releases that we used to support in the old model, where an upgrade from one release to another might have feature enhancements, configuration changes, and occasionally API changes between dot dot dot releases, making it very difficult for customers. So, what does this mean for support?
Without going into details of exactly how we structure our support organization (there are better people than me to explain that), the model of supplying cumulative patch releases, and not changing API's and configuration, makes the support engineers jobs a lot easier. This, in turn, leads to much higher quality support. With this model, the support engineers don't have to wonder what possible combination of components have been thrown together. They don't have to worry about configuration or API changes that may be different from customer to customer. This all makes reproducing and fixing issues much simpler. In fact, its a win-win situation for us as a company and for the customer. It allows us to scale our business much more affectively, and at the same time delivers a much better customer experience. Customers don't have to worry about support quality suffering as we grow (and we are growing rapidly).
In summary, stability and quality support is important to our customers, and we deliver that better than any other vendor! I know this from personal experience as well, as I was a JBoss customer prior to joining the company.
So, what do you get as a subscriber in terms of stability and support? Let's start by addressing stability. For a lot of customers, stability is very important. They make a large investment in a custom developed application, and it is expected to be used in production for many years. Some companies capitalize this work, from an accounting perspective, and then amortize it over three, five or even seven years! Over that time period, even if they are doing regular upgrade releases to the software, they need the middle-ware to be as stable as possible. API and even configuration incompatibilities, can cause major problems. Typical cycles for upgrading middle-ware in an enterprise setting can also take six to nine months, or longer! With these types of cycle times in mind, our products have to be stable.
So, just how do we keep the products stable? We have instituted a quarterly cumulative patch process within the enterprise platforms. On a quarterly basis, we take defects and fix them and roll them together in a release (no new features). Some of these defects might have been delivered to customers prior to the quarterly cycle as hot fixes, depending on severity. We leverage the test suites that I detailed in my earlier post, and make sure there are no regressions. Also, the defects come from our customers, as a priority, but we may also fix issues that we know affect the enterprise platform that may have been caught in our upstream jboss.org releases. This gives us a measure of additional stability, that even though a customer has not seen this issue, we have proactively fixed it knowing that it will probably crop up down the road. Of course, this is the real power of an open source model. You have the widest and most varied deployments to flush out issues, and address them proactively. This cumulative patch process goes on for three full years, where customers can be assured that if they upgrade to any of these releases their applications will not break. For another two years, we will still produce these cumulative patch releases, but they will contain only security errata. This is vastly different than the jboss.org releases that we used to support in the old model, where an upgrade from one release to another might have feature enhancements, configuration changes, and occasionally API changes between dot dot dot releases, making it very difficult for customers. So, what does this mean for support?
Without going into details of exactly how we structure our support organization (there are better people than me to explain that), the model of supplying cumulative patch releases, and not changing API's and configuration, makes the support engineers jobs a lot easier. This, in turn, leads to much higher quality support. With this model, the support engineers don't have to wonder what possible combination of components have been thrown together. They don't have to worry about configuration or API changes that may be different from customer to customer. This all makes reproducing and fixing issues much simpler. In fact, its a win-win situation for us as a company and for the customer. It allows us to scale our business much more affectively, and at the same time delivers a much better customer experience. Customers don't have to worry about support quality suffering as we grow (and we are growing rapidly).
In summary, stability and quality support is important to our customers, and we deliver that better than any other vendor! I know this from personal experience as well, as I was a JBoss customer prior to joining the company.