Recently, I have been contemplating the way people view our subscriptions for the enterprise platforms, and what they think the value proposition is. In fact, there was a recent comment, that really made me think. That comment was about cost per incident. In thinking this way, the customer was wondering what value they were getting from the subscription when their cost per incident was so high.
In dealing with that comment directly, I think this is a totally flawed way of thinking about the value of a subscription. The subscription costs are already low, when you compare it to our competitors license costs plus maintenance costs, or even their maintenance costs alone. Having said that, if you have paid for a large deployment, and you don't have very many incidents, and in this context, we are talking about the number of times that the customer has to engage our support. Then the cost per incident could be quite high. Now, why is this way of looking at value flawed?
Well, you are basically arguing for deploying low quality software in your production environment! Is that really what customers want? If they were asked this question directly, they would say no. So, cost per incident is not a good way to look at whether you are paying too much for a subscription, or whether you should subscribe at all, versus using the jboss.org bits for free. So, this leads us what is the value of a subscription for the enterprise platforms.
For me personally, when I deployed infrastructure software into the enterprise (I was in IT for 21 years prior to joining JBoss), my first concern was stability of that infrastructure. I didn't want to constantly be dealing with failures in my operating system, middle-ware, databases, etc. If you will, I wanted my incident rate to be very low. When I did have a problem, I wanted to be able to solve that problem in the shortest amount of time possible. So, cost was not my first concern, quality was.
With our enterprise platforms, quality is second to none. When you consider the network affect of the open source development model, plus the hardening process that we go through with the enterprise platforms, the result is software with unparallel quality. This results in production deployments with low incident rates. I like to think about this cost per incident, not in the sense of how much is being paid for the subscription divided by the number of incidents, but by the lost opportunity cost of having my internal staff working on middle-ware issues, versus working on something that might actually deliver value from a business perspective. This is what Geoffrey A. Moore, author of "Living on the Fault Line, Managing for Shareholder Value in ANY Economy", would call core versus context.
If you ask yourself a simple question about what is core to your business versus what is context to your business, I would expect that virtually everybody would say that middle-ware support is not core to their business, its context. It might be mission critical context, don't get me wrong, but it is still context nontheless. So, should you really be spending the brain power of the organization on figuring out problems with middle-ware, or building that next great feature or application that generates more revenue?
Therefore, the value proposition is both in the quality of the support given, and the quality of the software delivered. When I deployed JBoss in mission critical environments, I also experienced superior support from the JBoss support organization. We never had an issue that went unresolved in five years of production usage (prior to me leaving), I couldn't say that about any other vendor we worked with. While this was my own personal experience, and is certainly a microcosm of all customer experiences, it was one of the reasons I felt very comfortable joining an organization in making such a big career change.
Remember the value of the subscription is not just in the support but in the quality of the software as well. You don't have to pay a big upfront license cost to get value, and in fact I would argue why should the customer absorb all that risk. The vendor that produces and supports that software should be taking that risk, not you the customer!
In dealing with that comment directly, I think this is a totally flawed way of thinking about the value of a subscription. The subscription costs are already low, when you compare it to our competitors license costs plus maintenance costs, or even their maintenance costs alone. Having said that, if you have paid for a large deployment, and you don't have very many incidents, and in this context, we are talking about the number of times that the customer has to engage our support. Then the cost per incident could be quite high. Now, why is this way of looking at value flawed?
Well, you are basically arguing for deploying low quality software in your production environment! Is that really what customers want? If they were asked this question directly, they would say no. So, cost per incident is not a good way to look at whether you are paying too much for a subscription, or whether you should subscribe at all, versus using the jboss.org bits for free. So, this leads us what is the value of a subscription for the enterprise platforms.
For me personally, when I deployed infrastructure software into the enterprise (I was in IT for 21 years prior to joining JBoss), my first concern was stability of that infrastructure. I didn't want to constantly be dealing with failures in my operating system, middle-ware, databases, etc. If you will, I wanted my incident rate to be very low. When I did have a problem, I wanted to be able to solve that problem in the shortest amount of time possible. So, cost was not my first concern, quality was.
With our enterprise platforms, quality is second to none. When you consider the network affect of the open source development model, plus the hardening process that we go through with the enterprise platforms, the result is software with unparallel quality. This results in production deployments with low incident rates. I like to think about this cost per incident, not in the sense of how much is being paid for the subscription divided by the number of incidents, but by the lost opportunity cost of having my internal staff working on middle-ware issues, versus working on something that might actually deliver value from a business perspective. This is what Geoffrey A. Moore, author of "Living on the Fault Line, Managing for Shareholder Value in ANY Economy", would call core versus context.
If you ask yourself a simple question about what is core to your business versus what is context to your business, I would expect that virtually everybody would say that middle-ware support is not core to their business, its context. It might be mission critical context, don't get me wrong, but it is still context nontheless. So, should you really be spending the brain power of the organization on figuring out problems with middle-ware, or building that next great feature or application that generates more revenue?
Therefore, the value proposition is both in the quality of the support given, and the quality of the software delivered. When I deployed JBoss in mission critical environments, I also experienced superior support from the JBoss support organization. We never had an issue that went unresolved in five years of production usage (prior to me leaving), I couldn't say that about any other vendor we worked with. While this was my own personal experience, and is certainly a microcosm of all customer experiences, it was one of the reasons I felt very comfortable joining an organization in making such a big career change.
Remember the value of the subscription is not just in the support but in the quality of the software as well. You don't have to pay a big upfront license cost to get value, and in fact I would argue why should the customer absorb all that risk. The vendor that produces and supports that software should be taking that risk, not you the customer!
2 comments:
So in my organization right now we're struggling with where the responsibility for jboss suupport comes...server admins overtaxed, application support-no knowledge of "server side apps" and developers who really should be developing...any thoughts?
When I was a customer, I was the VP of Technical Architecture. It was a CTO type role, and I had several teams, one of which we called technical architecture. That team drove technology evaluations, and was responsible for picking the middle-ware to be used by developers and supported by the application support team. In that, we didn't just pick the technologies we directly supported it as well.
We actually would be on call for production issues that may be middle-ware related, we helped train the developers and application support folks as well. In some cases we also provided customer built tools/scripts to make certain tasks easier.
I never believed in the "ivory tower" type of architecture organization, and all my folks needed to be expert in the usage and management of whatever technologies we rolled out to the organization. Of course, we extensively used the support subscription in helping us as well, because you will never build the expertise to truly support everything on your own.
I'm not sure this answers your question, but if you describe your organization to me, maybe I can help point you in the right direction.
Post a Comment