-by David J. Easter, Product Line Manager, BMC Remedy Action Request System
Does AR System support ABC version 1.2.3?
One of the most common topics I'm asked is about compatibility. It's also one of the most complex topics to answer because it isn't completely under control of one vendor. As a product manager, I can drive the direction of features and functionality within a BMC product - or even a complete solution made up of multiple BMC products - but it's a challenge to have significant influence on what 3rd party vendors do with their own products.
BMC Remedy AR System 7.1.00 has very broad 3rd party vendor support including 8 Operating Systems, 5 databases, 3 Java(tm) vendors, 9 web/app servers, 7 servlet engines, and 4 browsers. There's also the support for reporting, screen readers, E-mail engines, terminal servers, source control and other auxiliary integrations. Now throw in a multi-tier architecture of server, Mid-Tier and two different clients. Couple that with a tradition of ensuring that components are backwards compatible, so that multi-tier architecture could include different versions of the server, Mid-Tier and clients - and different versions of the sub-components found in AR System (E-mail Engine, Approval Server, et. al.)
Once you've got your head around that, think about 3rd party versions. We try to support the current version of a 3rd party product and one version back where possible. And just to make life more interesting, vendors over the past decade have begun to provide "editions" of a product to segment their available market. Microsoft Vista, for example, has Home Basic, Home Premium, Business, Ultimate, Enterprise, and Starter editions.
Oh, and don't forget "standards" like SOAP, HTML, ODBC and such. And just to add additional seasoning, through in regulatory compliance like 508, 21 CFR Part 11, FDCC or Common Criteria.
And if you think you've got a handle on it all, you'll find that next week a new version of a vendor product will come out, a standard will revision (or a new standard will be created), or a brand new product concept will be debuted that has to work properly with your system. How can any of us keep up?
What's been done so far?
Here's what we've tried to do about it so far in AR System.
In AR System 7.1.00
We introduced a policy whereby we trust our vendors to provide backwards compatibility when patches, maintenance releases, service packs, updates or other similar level of changes are released. Unless otherwise stipulated by written communication from BMC Software, such maintenance level changes are by default supported and do not require further certification from BMC.
We also trust that if we work properly with individual components within a combination, we should work properly with all of the components together. For example, if we support the Apache web server, Tomcat servlet engine, Sun Microsystems' Java SDK, and the Japanese language set on Red Hat Linux - then we should support a Red Hat Linux system running Apache, Tomcat, Sun Java against the Japanese language without having to list out that exact combination. You can see this approach in the revised look and feel of the Compatibility Matrix for 7.1.00 compared to 7.0.00. This also had the positive effect of making the compatibility matrix much easier to read.
We introduced an "or higher" approach to browsers. As long as you have a minimum version of a browser listed in the compatibility matrix, we expect that later versions will also work.
What's on the horizon?
In AR System 7.5.00, we're currently planning to take these policies even further. First off, it is our intention to remove any checking of "edition" during the installation of AR System. This means that it should be possible to install AR System even if the "edition" of the 3rd party product is not officially supported. This may be useful in situations where an independent consultant or small sales team wants to demonstrate or do a small test of functionality using a free edition of a vendor product (e.g. Oracle(tm) 10g Express Edition, Microsoft(r) SQL Server(r) 2005 Express Edition, et. al.).
In even bigger news, for AR System compatibility, it will be expected that a vendor will retain full backwards compatibility with existing major or minor versions of released products. If vendors can hold true to that requirement, then BMC Remedy AR System is expected to support a listed minimum version of vendor products or higher. This will apply to:
Server operating systems
Desktop operating systems
Databases
Web or application servers
Servlet engines
Browsers
So, for these vendor products, you can expect to see the compatibility matrix state "AR System supports the listed version of vendor products or higher". That means if, for example, Microsoft Windows(tm) 2003 is listed as the minimum version, then AR System would support Microsoft Windows 2003 and 2008. Plus, if Microsoft (hypothetically) came out with a Windows 2009 next year, that would be supported also.
An "or higher" approach is nothing new in the software industry, but it is BMC's hope that by implementing this even broader reaching policy, that our customers will be able to keep up with their company and customer demands for new technologies. So with that in mind, what are the customer benefits to this approach?
It reduces or eliminates the delay in supporting new 3rd party products on "day one". Customers wishing to move to recently released products will not have to wait for BMC to test and certify the 3rd party product.
It provides increased access to BMC Support and development resources. In the past, if a product did not yet appear on the compatibility matrix, support was not formally available. While support personnel will always do what they can to assist BMC customers, this enables those support personnel to work cases involving new 3rd party products in more depth.
It enables higher quality focus on product features. When partner vendor products work properly in a backwards compatible environment, BMC development and testing resources can concentrate even more on adding customer value to BMC products.
There are going to be a few trade offs on this approach, though. Some things to keep in mind as a customer or partner are:
3rd party vendor compatibility statements trump BMC. For example, If IBM has stated that it does not support Java 5.0 with WebSphere(tm)6.0, then BMC would not support that combination either - even though we support both Java 5.0 and WebSphere 6.0.. Or if Oracle Corporation states that it will not support an Oracle 10gR2 32-bit database client running on a 64-bit Red Hat(tm) Linux operating system then such a configuration isn't supported by BMC either - even if not explicitly called out on a BMC compatibility matrix. Where and when BMC finds out about such issues and confirms their accuracy, the matrix will be updated, of course - but the bottom line is that the 3rd party vendors have their own compatibility requirements and BMC will honor those limitations.
With trust comes risk - and there will be a minor risk that a given vendor may choose not to provide backwards compatibility between versions. If this happens, there are four basic options:
BMC reserves the right to rescind support for a specified version of a vendor's product and document such incompatibilities once confirmed.
BMC may make business reasonable effort to work with the 3rd party vendor to encourage changes to the 3rd party product to restore backwards compatibility without a need to further modify BMC products.
BMC may, at BMC's discretion, attempt to address a discovered incompatibility by modifying the current version of AR System.
If major architectural changes in a vendor product require significant BMC development to achieve tolerance, support for the vendor product may be deferred to a later version of AR System.
What does all this really mean?
So there's the definition and the pros/cons. Here are some questions that typically came up during this proposal:
Q: What happens if a new version of a 3rd party product comes out, a customer tries to use it, and it's found not to be backwards compatible?
A: Before I answer that, I should comment that best practices for upgrading a product should include trying it out in a non-production environment to ensure that everything works as expected. So one would hope that no customers run into such a situation in a production environment. That being said, if backwards incompatibility is found between 3rd party vendor product versions, then BMC would do one (or more) of the 4 options listed above - i.e. document it, reach out to the vendor to have them correct their product, try to fix AR System code in a patch, or defer support out to a later AR System release.
Q: Isn't that just making customers do your QA for you?
A: That's certainly not the intent. Geoffrey A. Moore, in his book "Crossing the Chasm", defined 5 types of customers: Innovators, Early Adopters, Early Majority, Late Majority, and Laggards. Innovators and Early Adopters are generally keen to try out new technologies - and this includes the latest version of products. This policy is being put in place to try and address the needs of those customers who adopt new technology very quickly after it becomes available. Today, those customers must typically wait until the next major or minor release of AR System (or at minimum, wait for a patch) to get official support for newer 3rd party products.
Q: I don't want to use the latest version of a 3rd party product. Are you forcing me to upgrade to the latest?
A: Not at all. As part of the new compatibility matrix, BMC will publish the minimum version of 3rd party products that are supported. This minimum will remain in line with market and customer demand. For example, the matrix will make statements like "Solaris 9 or higher" or "Apache Tomcat 5.5.x or higher". As long as your environment is using the minimum version, you'll still be supported. That means if you're in the Early/Late Majority - or even a Laggard - you can wait to move to newer versions until you are comfortable to do so.
Q: If the minimum is changed in a new release of AR System, would you stop supporting the "dropped" version of that 3rd party product in older versions of AR System?
A: If that were to happen, it would be an exception and not the norm. While such a situation might occur, BMC would make business reasonable effort to avoid doing so. Historically, BMC has continued to support whatever 3rd party product versions were listed at the time a version of AR System became Generally Available and has not dropped support against that version of AR System. However, BMC does have a posted Product Support Policy that will continue to be enforced.
Q: Would BMC stop testing against newer versions of 3rd party products?
A: No. Today's general goal of testing the current version of a 3rd party product and one revision back will continue to be true. During the release of a new version of AR System, BMC will test against those 3rd party product versions that are generally available. Since this policy is being put into place with the release of 7.5.00, I'll give a hypothetical example. When AR System 7.5.00 releases, SuSE(tm) Enterprise Linux 10 may be the latest version of SuSE Enterprise Linux available. After the release of AR System 7.5.00, Novell may release SuSE Enterprise Linux 11. During testing of the next version of AR System, SuSE Enterprise Linux 11 would be included in the testing process.
Q: How will BMC confirm incompatibility if it hasn't been tested?
A: In the unlikely case where a 3rd party vendor does not provide backwards compatibility and this is reported to BMC, BMC will make a business reasonable effort to test against the new version of the 3rd party product as part of the issue resolution - even between releases. If the incompatibility is confirmed, results of this testing would then drive one of the four options listed above.
Q: How do I know which actual versions of products have been tested by BMC?
A: Even today, BMC doesn't publish that information publicly. As you can see from the preamble in this blog, the number of actual configurations possible is astronomical and BMC would never be able to test every one of them. So today, BMC Quality Assurance tests a representative sample of different configurations to ensure that the chances of an incompatibility being found in the field are extremely low. What is on the compatibility matrix represents what BMC pledges to support even if a customer's exact configuration wasn't one of the ones specifically tested as part of the QA process. So, if an incompatibility is found (even today), then BMC would follow one or more of the 4 options listed above.
Q: You're dodging the question...
A: To a certain extent, yes. There is a perception by some that by duplicating the exact environment that a vendor used for compatibility testing, that the risks of encountering critical defects during their own deployment will be drastically reduced. And while I do not debate that using a configuration tested by others could potentially reduce the risks, even those configurations tested during the BMC QA process will differ from a customer's environment when all of the variables are taken into account. What is of overriding importance is knowing that the configuration that your company chooses based on all the technical and business requirements that meet your needs will be supported by BMC - no matter what the reason for an issue to have occurred. This shift in more openness of support is reflected in the compatibility matrix for 7.1.00 and will continue forward in 7.5.00. By adopting this policy, development and QA resources have been further focused on delivering value added features and functionality within AR System.
Q: Will this policy be retroactively applied to AR System 7.1.00 or earlier versions?
A: No. This policy is expected to be introduced in the same time frame as 7.5.00 and would only apply to AR System 7.5.00 or later.
Q: Does this mean that the minimum 3rd party product versions won't change in newer versions of AR System?
A: No. BMC will continue to concentrate on the newest versions of technology as AR System itself revisions. When appropriate, an older version of a 3rd party product will be dropped from the support matrix and a later version will become the minimum. The general goal is to support the current version of a vendor product and one revision back. Based on this policy, there may be a stretch of time between releases where we are supporting the newest version and two back (i.e. the original two that were supported at release time and a new version released after the General Availability date of AR System). In those cases, it's a good bet that the oldest version would be dropped in the next AR System release.
Q: Will you stop supporting an old version between AR System releases?
A: If that were to happen, it would be an exception and not the norm. While such a situation might occur, BMC would make business reasonable effort to avoid doing so.
So, what do you think?
That's the current plan. My hope (obviously) is that folks will see the positive effect this will have on the Innovators and Early Adopters without taking anything away from the Early/Late Majority or Laggards. But the release of AR System 7.5.00 isn't until early 2009, so here's your chance to discuss this among yourselves, post some clarifying questions, and comment.
Note: BMC, BMC Software, the BMC logos, and other BMC marks are trademarks or registered trademarks of BMC Software, Inc. in the U.S. and/or certain other countries. WEBSPHERE and IBM are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. Java and Sun are trademarks or registered trademarks of Sun Microsystems, Inc., in the U.S. and other countries. Oracle is a registered trademark of Oracle Corporation. All other registered trademarks or trademarks belong to their respective companies. ©2008 BMC Software, Inc. All rights reserved.
The postings in this blog are my own and don't necessarily represent BMC's opinion or position.
