In-Depth

Q&A: BMC on IBM's Candle Acquisition, Licensing Costs, and Cost of Ownership Issues

BMC's director of its MainView product discusses IBM's takeover of Candle, plus getting the best value from licensing

• By Stephen Swoyer
• 04/27/2004

We spoke with Fred Johannessen, director of the MainView product line for BMC Software Corp., itself no stranger to mainframe-related acquisitions, having picked up the former Boole & Babbage in 1998. In a wide-ranging interview, Johannessen talked about IBM’s Candle acquisition, mainframe market trends, the high cost of mainframe software licenses and maintenance, and BMC’s own strategies for reducing costs.

Let’s start by rewinding a few weeks to when IBM acquired Candle. What’s your take on the backstory to that acquisition?

We’re seeing a bit of consolidation in the space. What you’re seeing is [that] for some vendors, keeping it best of breed is very difficult. We saw some of that difficulty with Candle in terms of just keeping pace with the platform, which I think they acknowledged [at the time of the acquisition].

Is a combined IBM/Candle something that worries you?

It’s a cause for concern in the long run, but I think that right now, any customer should be concerned about what I call vendor lock-in, because for customers what creates a healthy environment is competition. We consider ourselves extremely competitive, and that only benefits the customers, so if there’s too much consolidation in the space, especially with a company as big as IBM, where they basically can sell across every stack, in terms of hardware, software and software, that concerns us.

Because you’re also competing with them.

Yes, because we compete. We have pretty much—on the mainframe, our customers are common. A BMC customer is an IBM customer by default on the mainframe, and those customers that we share tend to be extremely large enterprises, in the telecommunications business, and so on. And there is still the customer-leveraged aspect that customers are going to demand that IBM provide us the information and support that we need to make sure that their systems are up and running.

Is there some concern—on your part or among your customers—that IBM won’t do that?

Not right now, but it’s a thing to watch for the future. It appears at least externally like they’re putting Candle in the Tivoli organization, and we’ve been competing with Tivoli for some time now. We’ve competed very effectively against Tivoli’s mainframe products. At first look, it appears that we’ll just continue competing at that level and IBM just has a broader portfolio. Long term, we’ve had a good relationship in terms of getting information about hardware, operating system and so on, so the question is, will we continue to get this?

One constant complaint from mainframe operators concerns software-licensing costs. What is BMC doing, or what has BMC done, to make its software more affordable for shops that are trying to justify the mainframe’s TCO in comparison to cheaper distributed systems?

Well, if you just take a rough look at our pricing on the mainframe, it’s consistently gone down year over year for the past few years, so we’ve been consistently lowering our prices over time. The other key aspect is that … where [customers are] upgrading the mainframe as far as adding workload capacity, [it] hasn’t necessarily been in an area that impacts our products, so they haven’t necessarily been adding capacity for IMS, for example. We’re making it a lot easier for them to isolate, down to charging for what they’re using and what they’re managing, and that includes providing rental and leasing models, and even sub-capacity licenses.

That may be the case, but I think a lot of customers are still unhappy with how much they’re paying, in up-front licensing fees and maintenance, for mainframe software. Will there be any kind of downward pressure on licensing fees, do you think, or will the mainframe always be a more expensive proposition?

I think it’s yes and no. When you think about it, there [are] a couple of reasons why you actually are putting software on the mainframe, and it’s because you have the performance and availability capabilities of the platform itself. It’s also because you have processes and procedures in place that help support the resiliency of the platform, and you have this management software infrastructure that helps to ensure that it’s a completely bullet-proof environment.

From an overall total cost of ownership of the platform, we think we help reduce that cost, even in comparison to distributed systems. But when you add up the management costs over 2,000 servers, suddenly your total cost of ownership can be higher for the mainframe, especially when you’re comparing mission-critical applications. But when you’re comparing 2,000 distributed servers running file and print applications, maybe your management costs are lower, but those aren’t necessarily mission-critical applications. It really is a case where you’re getting what you’re paying for.

It’s possible that customers have reached this same conclusion, as there’s been encouraging news, revenue-wise from IBM, as well as from you folks. Your mainframe-related revenues have demonstrated strong year-over-year growth, as have IBM’s. Are you optimistic that this is a trend that will continue?

Well, MIPS growth has been growing at about 58 percent growth (aggregate), and IBM last week reported that they had 100 percent growth year-over-year on MIPS. That kind of growth says that customers are not just doing what you might call legacy growth, but they’re very likely hosting new applications on the mainframe.

It gives us some indicators that there’s still quite a bit of growth in the mainframe going forward. Part of it is that for a customer with a COBOL CICS application, using IMS or DB2, what is it going to take them to re-host that application? It’s going to be a huge effort, and you’re taking a huge amount of risk in doing that. That’s generally your key corporate data that’s being managed on the mainframe. That’s kind of the risk/reward thing. Is it worth taking the risk of losing data, or downtime, or application downtime, for going to a platform that some analysts say isn’t necessarily [less costly] to manage? So [customers] are asking themselves these questions. Some of them are trying other things to reduce [these management costs].

Such as?

We’ve seen customers who’ve been melding together their IT operations so that rather than having a separate mainframe or distributed [environment], they’re saying, “Let’s organize people by their functional areas.”

So DBAs manage databases, for example, right? Even if they’re a mainframe DB2 DBA, or an IMS DBA, they’re expected to manage databases on distributed systems, too? That ties in nicely with your SmartDBA product.

That’s right. We have SmartDBA --- it was originally called Project Goldengate, and now the technology is called SmartDBA—but you’re going to see a significant roll-out of the SmartDBA technology across the mainframe products, and that includes DB2 and IMS management products. Even if you’re not doing heterogeneous management, it helps the productivity of your current workforce, plus it helps make the platform more viable.

To close, how important is the mainframe for BMC going forward?

For us, mainframe is a critical platform for BMC, I think you’ll see that we’ve invested significantly in the platform and continue to invest and expect it to be a robust opportunity for BMC in the near- and long-term future. It’s something also that we think we’ve got a critical differentiator in being able to tie mainframe to the enterprise story, with our Business Service Management (BSM) [strategy].

There [are] two levels [in BSM]. One is event correlation, where you have a problem on DB2—what is the business service impacting? The other is metrics correlation, where you’re collecting data from the different subsystems. We’re doing work today that you’ll see us [later this year] demonstrating tying in mainframes to our BSM strategy, so that you can do enterprise-wide event correlation, enterprise-wide data correlation.