Q. What is your technology differentiator?
A. We don’t have numerous different components or modules that are hard to connect; we link the relationships between artifacts, requirements, feature specifications and test plans. We’ve always supported code reuse, which is a pretty standard goal these days.
Q. What’s new in the latest release, Integrity 2007?
A. We’ve been getting deeper into requirements management and test management: reuse of code is great but people want to reuse all of the different bits, something they have not been able to do before. We help create reusability across every kind of artifact, as well as rich text items and composite items. Or you can assemble multiple documents, to update a lot of the configurations in requirements management and test management.
Q. You added packaged application support also.
A. Yes, for years we have done custom applications, but we have spent a couple of years adding our capabilities to packaged applications too. We did SAP and PeopleSoft first; our tools can massively reduce the cost and burden of packaged application change.
Systems integrators are dying for this: the various SAP versions that companies own change but there is not much SCM [software configuration management] control. PeopleSoft’s own tools don’t really address process change enforcement very well, for instance, but systems integrators have had to keep on top of things using spreadsheets, so they are deeply interested in this.
We keep track of requirements, test plans, defects, and display them all in a single document if desired. But although you view them in a document, we do not create a separate instance: you see the actual live items on the screen. In our system you can create a requirement, then a test plan, and you can always see which requirements have test plans or uncompleted test plans.
Q. How far would you say you have come with ease-of-use?
A. There is no particular effort involved – that’s inherent because we use a single data model in the first place. Some vendors talk about the idea of integration between all these different elements, the different facets of the lifecycle; but their technology does not really support their message.
Q. Such as?
A. [IBM] Telelogic, for instance, never went far with an integration message – they had four or five customer bases and four or five different products. Borland on the other hand talks all about a single lifecycle approach but it can’t deliver it technically: there is still the Together technology, StarTeam etcetera etcetera. There are others where it is just way too much work or way too difficult.
That’s the thing about the ALF project [an open source integration project started by Serena, and with around 16 vendor supporters, designed to enable interoperability between their various tools. MKS has not joined the project.] It’s easy for those vendors to make a case for the need of a project like ALF because each of their own products are all so different and hard to integrate. We have an integrated platform so we have no problem there, we don’t need ALF to help us integrate our own product set. We won’t participate in any of the hype there.
Take Rational. They have a bunch of users on Doors, a bunch on ClearCase, but they can’t see an integrated workflow because it is not on the desktop. Collaboration is, as a result, pretty difficult to do. Our rivals have very loose integrations. Customers buy into the message and then find the integration is not there. There are a lot of companies chucking out Mercury for that reason.
Q. But many companies will already have a tool for test management, or requirements management.
A. With us it’s like SAP — people had inventory management but they still bought SAP. We can solve problems in any area because of our integrated platform — that is so strong that it would have been overkill if it was behind just one product, but it’s not.
Q. But can you integrate with third-party ALM tools if that is what the customer wants?
A. We can integrate with Mercury, [IBM Rational] Doors or ClearCase, but we would advise customers that it is not the best way to do it.
Q. Do you think there is scope for software as a service (SaaS) ALM products?
A. We have discussed offering our product as a service, and we would be happy to do it, if anyone asked for it, but they want to keep their software assets internally. We already have the ability to view it in thin-client mode, and there are a lot of larger developer organizations going that route, looking at services-based architectures. Lots of companies have half their developers internally and half in distributed teams, for instance.
Q. What about SOA, is that something you advocate?
A. Everyone has to address SOA, but it all comes down to reuse. You need to have a very collaborative platform and for example promote things in your inventory to create services. To us though, all of these things are business initiatives. Or there might be an application rationalization strategy, so you need a single platform for application change so you can start to do collaboration across a group.
Take Verizon Wireless – they bought 15 cell-phone companies giving them 15 different billing systems which they wanted to consolidate down to one system. [Using MKS to help in the consolidation] they cut their costs in half, and in doing so saved billions. The Verizon Wireless CIO is considered one of the top CIOs now as you can imagine.
Q. In your latest financial year sales were roughly flat, but you have some impressive companies on your customer roster.
A. Yes, we have around 700 customer accounts, equating to 200,000 seats deployed since 2001. Our largest customer is HSBC, and we have other big customers like NCR in the UK and a bunch of Formula 1 racing teams like Honda, Benetton and Renault.
Prior to joining MKS, Philip Deck was chairman and CEO of cryptographic technology firm Certicom from April 1993 to November 1999. He is on the board of directors with The Bank of Canada and the Canadian Opera Company, and holds a degree in economics and mathematics from Queens University, Kingston.
Our View
It’s a familiar argument — that a smaller firm is better because it has a more tightly integrated product set and has not put it together by making numerous acquisitions. With the number of disparate roles that need to collaborate in a distributed application development team, the argument does make a certain amount of sense.
The opposite view of course is that larger vendors have been able to buy best-in-class tools and have a deeper services and support network on hand.
Yet with a decent number of blue-chip companies on its roster, and its focus on application lifecycle management, MKS is surely worth putting on a shortlist of ALM contenders.
MKS is certainly a smaller firm – full year revenue ended April 30 came to $48.3m. Knowing the acquisition habits of the bigger players in the space – IBM, Compuware, HP, BEA and Oracle, to name a few – it would not be surprising to see MKS ultimately swallowed for its technology, customer base, or both.
