newsmaker Mercury Interactive has evolved since it began providing software quality testing products in 1991. Today, the company is most known for its Business Technology Optimization (BTO) strategy, which focuses on helping enterprises align IT with business objectives.
Mercury's BTO offerings for application delivery, application management, and IT governance tout the value of helping customers maximize the business value of IT.
The company continues to actively engage organizations to put a business spin on everything IT.
The company's chief technology officer, Oren Ariel, tells ZDNet Asia, why, even after spending five years fine-tuning the BTO framework, Mercury is not yet done helping customers balance the task of optimizing application quality, performance, and availability, and managing IT costs, risks, and compliance.
Having been with Mercury since 2000, how would you describe the changes that has culminated in the company's BTO strategy today?
In general, Mercury is a very customer-driven company. We fine-tune our roadmap with a lot of our customers. We feel that it is part of our day job, whether you are a technical person with the company or you are a field person, that the customer is whom we listen to. So whenever we set foot in the field we try to facilitate that interaction.
This is the agenda that we've been driving several years now and it is unfolding in stages. The first step we took was in 2000 when we took our core technology from the testing side of the [company] and we had a hunch that this technology was incredibly valuable to our customers. They could do ongoing [application] testing 24 by 7 in production. But in production, we discovered a slew of new issues--we had the Internet, real customers that had different patterns of usage, and so on. We produced more and more functionality into that side of the house until we found ourselves five years later actually connecting it all together into a single suite. On the way, we picked up a few missing pieces like IT governance. And five years later, we are now launching an agenda which talks about aligning IT organizations with business goals [formulated] around the core products that we already have in place.
How far are you away from completing that agenda?
We still have a long way to go, and my job in the company is really to make sure that from a product standpoint, we can really look at the product as a single integrated suite with a common set of technologies. This will allow us, for example, to offer a single view point into reports and metrics that are being collected by the products, using dashboards.
As chief technology officer, what do you have to do to fill in those gaps that you've just talked about?
A lot of what I do is to look at the 'blind' spots in the strategy that we have to go out and fill in terms of external acquisitions and internal development. When I first joined the company, it was a very successful medium-sized company with one-third of the revenues and one-third of the number of employees it has today. It just shows you how much the company has grown in the last five or six years. The roots of the company were in quality management, of which the fundamentals are measure, manage, maximize, which is what we're applying today in different areas, not just in quality assurance but also on managing requirements, managing demand, and managing production systems.
How would you convince those customers that are not yet sold on aligning IT with business goals, that that is the way to go?
The question varies because we have younger businesses as well as more established businesses coming under the umbrella of business technology optimization. We're seeing more of the newer customers in the IT governance and the application management areas. The Mercury approach allows you to leverage what you already have and what you've invested in, and offers the link between those and the actual business. There are a lot of catalysts that lead people to this direction. Compliance is one, and once you have to start to document, you begin to think about the need to automate things. Another good catalyst is the whole outsourcing and off-shoring issue, which is about taking some of the non-core functionalities of IT and handing them off to somebody who would do it at lower costs.
This creates a lot of management overhead because now you need to work with an organization that is remote [in some ways]. So I think in a way, the evolution of IT from the technology shop of the enterprise to the organization that automates 80 percent of the critical business processes for customers, suppliers, the enterprise itself, puts a lot of pressure on IT to be much better aligned and to report back in business metrics. This is exactly what Mercury brings to the table--the ability to look at all these sets of IT activities and to translate them into meaningful business measurable items.
For any organization, aligning IT with business outcomes from scratch seems complex and involves a lot of changes. How do you help people cope with that?
Change is part of the business. A lot of these changes have equal weight. But if you spend the same amount of time for each and every change, you would never complete them all within the designated time period. So the immediate conclusion is how to prioritize [these changes]. Let's put on the top stack the changes that are most important to the business and let's flag those that are most dangerous to the business.
|Change is part of the business... But if you spend the same amount of time for each and every change, you would never complete them all within the designated time period.|
What are some examples of managing these changes that you've just talked about?
Imagine yourself and the infrastructure, everything is connected to everything. So let's say you want to make a change to a storage device, and there are computers that use files on the storage devices and these computers have other computers that are connected to them. And so what happens when I touch the storage device? Who's in jeopardy? When you have such a complex and convoluted infrastructure, without automation, it's really hard to understand what will be the impact of that change. You really have to get all the people in the room, the storage people, the network people, the database people, the systems people, in order to build the whole puzzle.
What are some of the key tools in Mercury's suite of software that could smoothen this process of change management in organizations?
The big problem is when I have an outage, I want to know immediately what has changed so that I can go back and either undo this change or I can go back to the particular area of the system and try to analyze the problem. So once change has happened, you would want to go and refer back to what changes were made.
What I'm describing here is really something that people have been resolving manually with a lot of energy and exchange of information between people. It's not scalable and it's not sustainable and it takes a lot time just to deal with those changes. You can bring in automation and hand them a lot of this data on a silver platter so that they can make a better decision. You're going to be saving them a lot of time, giving them extra time to do something more productive.
So what we do with our application mapping product is we discover all these relationships. We produce maps and these maps are continuously updated so if anything changes, we would know. And we can use this map to simulate what will happen if you change this particular device, such as finding out who are those dependent on this particular device that you're going to modify or this piece of software that you're going to be updating. This is just an example for those on the production side to understand who gets affected when you roll out a change. This is what I mean by introducing automation.
What are some of the trends today that you foresee would have an impact on your business going forward?
What's happening now is that there's a move towards service-oriented architecture. People are now dividing their business functionalities and assigning them to different software components. Each software component is now inter-related and interdependent. This creates on top of the infrastructure, an additional level of complexity that not only [affects the infrastructure]--now you have to manage every service that you touch and it may have four, five, 10 dependents that rely on it. Every change that you make now has a double link on it.
I don't think we've seen the worst of the growing problems of managing changes to a complex environment.