Q&A with MKS CEO Philip Deck: Automating the Automaters

Q&A with MKS CEO Philip Deck: Automating the Automaters

As the chairman and chief executive officer of application lifecycle management software maker MKS, Philip Deck spends a lot of time thinking about how other people and his own company create and manage software. Deck joined the Canadian and publicly traded software firm in 1999 after running a company called Certicom, a maker of cryptographic hardware and software, but he is clearly at home in the ALM software space and clearly enjoys his job, as this interview shows.

MKS, of course, was founded in 1984 as Mortice Kern Systems, and became known for its MKS Toolkit, a collection of Unix tools and utilities that was instrumental in helping Unix vendors eventually port their applications to Windows. The company’s focus on software change management–and the broader ALM idea–began when MKS made the decision to port its Source Integrity version control system to Java and to make it multi-tiered so it could scale from small companies to large enterprises, managing the breadth of software development and related activities. We know this product today as MKS Integrity, and it is the heart of the company.

Timothy Prickett Morgan: There’s something that I have been trying to get my brain wrapped around. What makes the application lifecycle management software market different from other markets? I know that high availability software plays out a little differently in the IT space than, say, application development tools do in the System i market and in other platform markets as well. I think that the sales pitch you make for ALM is different, right?

Philip Deck: It is, and I think that one of the interesting things about it is that it is a younger market. The whole software development space got to resist all of the systems management tools and processes that everyone else in their companies had built in during the 1990s. ERP and CRM happened, and large scale enterprises ended up with systems that managed their activities and work items throughout the whole company–except for software development. These guys were still using whatever tools they wanted to pick up through the channel or downloading whatever they wanted.

Philip Deck

The idea of managing them centrally, enforcing their work, managing processes, or expecting any kind of quality didn’t really exist. And I think that is partly because in the 1990s, everyone was bowing down to software developers, who could threaten to go work at a dot-com or somewhere else if they were forced to use ALM software. So, management said, “Wait, wait. Don’t do that. Fine. Do whatever you want. We don’t really understand what you guys do anyway. Here’s some more money–go nuts. Tell us what you need.”

TPM: Which is exactly where hardware was in the 1970s and 1980s and, at some companies at least, maybe still today. I had a guy tell me that running a data center was a bit like being locked in the basement and every now and then the managers threw down big chunks of money and stock options to chew on; all they expected was for the screens to be up and the bills to go out and no one asked too many questions.

PD: It happened differently in the host system world, because in the host world people did have pretty good processes and they were accustomed to thinking the process right through to deployment. But when you intersected those who were in the basement to what was happening thanks to Bill Gates, who said to just do everything on PCs and Windows, then the whole idea of process and the integrity of the management of development items went out the window.

We, as a company, came partly from the host side because we had a lot of AS/400 customers. The guy who runs product management at MKS wrote Implementer–it was one of his first jobs. A lot of our background was in thinking about process and the way that people in the host side of the world–not the PC network work–think about process, and kind of deploring the complete lack of control that people on the distributed side of the world seemed to have.

So I think development departments are a few generations behind compared to other areas of their companies. When you have things like on-demand systems, that seems to be a later development. Once people have established how they want to use those systems internally, then they can think about outsourcing the infrastructure part. But so much of putting in an ALM system right now is coming to grips with how you want to manage process and organize your departments. And they are a long way behind. These guys still have a long way to go when it comes to process, and it is ironic in that they are supporting all of these other systems–and they managed to get everyone else in the organization managed with systems–but have avoided it in their own department.

TPM: So that’s a bit like the cobbler not having shoes, or the IRS not wanting to be audited.

PD: I think that is the main way that ALM is different. But there are others. For instance, we have tried on-demand a bunch of times with our customers. No one has actually been able to persuade anyone that on-demand–hosting and administering the software–is a good approach for ALM. And I think all of us have thought at one time or another that if it works somewhere else, like Salesforce.com, then it should work with ALM. But we talk to our customers and they tell us that they don’t want to do that. Maybe that will be a later development.

But I think that right now, we are still struggling to persuade a lot of the market that customers should have a single system that manages workflow in general across the organization. And that is still a bit of a radical notion in software development departments. You would never get that kind of push back in an accounting department–of course you should only have one system. What a nightmare to have multiple systems. Well, that is what we have in software development.

Our whole value-add is this: We have built an application from the ground up that is a single platform that goes from end to end and through all of the different disciplines–requirements management, development, testing, deployment, and all that stuff–to have it done in one system with one approach to how you manage artifacts, how you manage process, do your portfolio management, and drive your metrics.

Well, as it turns out, this is a totally radical notion. Partly because these are still individual markets. We get pushback from the analyst community, for instance. We had this surreal discussion with one of the requirements analysts at one of the name-brand IT consultancies, and he told us that we didn’t have a requirements management product. And we explained that we did–look at all of the requirements capability we put in. And he then asked, what is the requirements product, and we would answer, MKS Integrity. And then he would tell us that MKS Integrity is an ALM product. And I would say yes, it is, but it is also insane to have a separate product for RM. And then the analyst would say that if we didn’t have a separate SKU, we were, therefore, not in the RM business.

TPM: Third base.

PD: I explained that I did not want to give my customers a separate SKU, and that they benefit from being able to buy a single license that anyone can use for any discipline across their entire software development organization. Now, this analyst is smart, loves what we are doing, and he would be the first one to admit that we are actually the first company doing proper reuse for requirements, and the first person who would say that this a truly scalable, reusable, branchable, artifact-based requirements management system–and oh, you have all of the benefits of a document approach to requirements. That we are doing stuff in requirements that no one has ever done. But he still has trouble admitting that we are in the requirements management market.

Of course, analysts have an interest in requirements management staying a separate area, because that is their job. If you took all of the ALM analysts, and said this is all one market, well, who gets to stay?

TPM: I can understand that. I have the same feeling about server and operating system platforms. . . .

PD: And individual departments within large companies are the same way. If you have a group of people writing requirements at a big bank, and they want to keep doing what they are doing and they do not want to deal with the developers or the testers, it can be a problem when MKS comes in and says, “Wouldn’t it be easier if this was all one system?” And usually people reply, “But then other people could see what we are doing.”

Now, why would that be a benefit?

To them, it is not always a benefit. It requires someone who is more senior to say, “Wait a minute. There is a benefit if we can get visibility between everyone developing and everything developed across the life cycle. If we can actually get the testers to see the requirements developing before their eyes and starting in development right before their eyes, it could do a lot of good.” But it would break down a whole lot of political barriers that have existed for a while and this is deeply disconcerting to a lot of people.

So, the only people who are pursuing a more unified approach are at fairly senior levels who decide that having this kind of collaboration is a good thing. And then they are going to have to persuade the people who work in software development that this is a good thing, and not be completely threatened, and then life will go on.

TPM: What kind of customer makes that decision? Are these large organizations? I assume they have to have fairly complex applications for ALM to make sense.

PD: We got it wrong on that score originally. We thought naively enough–and maybe because we live up here in our igloos–that if you were doing basic development workflow in a big company, then it would be so blindingly obvious that you should also do requirements management in the same system. After we got everyone happy doing development, we could then talk to the sister division that writes all the requirements for the applications and put them on the same system–it would be really cool and you could collaborate.

Well, it is not obvious to development organizations, and that has been a very slow transition. Our success in large companies tends to be among engineering companies that realize that they have to do artifact reuse. They have to rationalize product lines. Software companies, embedded systems, firmware, electronics. One of our big customers is a major electronics manufacturer. Everyone has built their companies through acquisitions, so there is a lot of diversity, first of all. But there is a huge need for reuse, and as engineering companies try to get their costs down to compete better, they are trying to figure out how to take the same group of basic components and spin them into different models and get products out the door really fast.

But you have to reuse more than just code. You have to reuse requirements, test plans, documentation–you have to be able to take the whole connected series of development artifacts and branch the whole thing and then be able to reuse in a sophisticated way. What I mean is this: when the original product gets updated, you can migrate changes to the products that have already been customized. This sophisticated reuse is really hard to do, and no one does it except us, and we are just rolling it out in our software because we can actually support it. There are technical advantages that we have that allow us to do large-scale component reuse that are helping us on the engineering side.

Where the interdisciplinary collaboration seems to be really hot is among engineering firms that are more mid-sized. They are not so big that they are all balkanized into separate warring divisions, and they are actually still working together as a company. And when you say to them, “Wouldn’t it be easier if when someone starts writing requirements a developer can see them and contribute, and then the test plan can be created?” And they say, “That would be really cool. We can see what everyone is doing.” These companies are buying it from day one as a single system and implementing it end to end, right away.

TPM: Which gives them a competitive advantage against balkanized, larger manufacturers. It becomes a competitive edge.

PD: Absolutely. But in the big ones, where reuse is the primary thing, we find–and again, this has been an education to us–it is starting in requirements. The amount of requirements reuse that has to be done. It may be because no other requirements products do requirements reuse in this sophisticated way, but as soon as we get the requirements implementation in, they quite quickly come to the conclusion that they should do development and workflow in the same place because it would be stupid to support these things in another system. So the marketing is pretty easy from that standpoint. Once you start doing really sophisticated requirements, you are going to roll it all the way forward through development and testing. But it hasn’t gone the other way that much and that was a bit of a surprise to us.

Requirements management is in some ways the whole driving force to our business right now.

TPM: So are people trying to cobble requirements, workflow, and other things together?

PD: All of our competitors have tried to do that, and some companies have tried to do that, but integrations are always pretty unsuccessful. Every program out there has some kind of API, and you can do some kind of import-export and field synchronization. But what do you get from that? Just because I can dump a requirement out of one system and import it into my development system, what happens when something changes? How do I backcast changes? Now I also have to deal with security on two products instead of one. How do I get audit trails for this?

So, yes, you can get the information exchanged, but that is not really the value. What one of our major electronics customers talks about–and I am hoping that I will be able to start talking publicly with their name soon–is seeing their intellectual property as code plus all of these other interlinked artifacts. When they can actually hit on a component and see the linked source code, documentation, all the defects that got posted and resolved, all the requirements going back–that really helps build their intellectual property. It becomes a much more valuable asset than a bunch of source code. What is a bunch of source code worth without all of the documentation and requirements that goes with it? It is worth nothing, because you cannot actually get into it and manage it and maintain it. The real benefit is to be able to get in control of intellectual property.

TPM: What platforms do you run your ALM software on at this point?

PD: It is all Java, so it will run on anything. It has both a Web GUI and a command line, part of our heritage. We started off making the MKS Toolkit, which allowed you to do Unix command line stuff on a PC. Until recently, we had probably half of our developers using the command line on our product. So we are multi-tiered from that standpoint. We integrate pretty well with all of the mainframe version management systems, and of course we have Implementer, our own System i platform, and we’re the company you go to if you want to bring all of those platforms together and manage their applications as one.

HSBC, for instance, has over 10,000 developers–that’s more programmers than Microsoft has–on our software. It has a ton of Endeavor and a ton of Implementer.

TPM: Historically, HSBC has been a big AS/400 shop.

PD: That’s how we got in there. They standardized on Implementer across all of their AS/400s. We showed them that with a single change package, they could manage changes across platforms and they could do release management on a cross-platform basis. So they could approve a release that would simultaneously deploy a mainframe change and an iSeries change and a distributed change and a Web system change and they would be managed by one common system. Ours is a system that is really designed for highly complex, distributed development environments. And HSBC does it around the world, and it has a “follow-the-sun” development department that never shuts down. This is expensive to us because they end up reusing the licenses three times around the globe, but that is their right

TPM: Maybe you need to invent a global software license with time zone tiers?

Anyway, another reason I wanted to get on the phone and chat is that I wanted to find out how business is going for MKS. What is your strategy, and what markets are you chasing? How have you managed to not be acquired and why haven’t you acquired?

PD: This has been a quickly consolidating market. We keep such a low stock price that people just sort of look at it and laugh. [Editor’s Note to the Toronto Stock Exchange: That was a joke.] We trade at under one times revenue. All the mergers and acquisitions out there are for three, four, or five times revenue.

But seriously, instead of doing M&A, our strategy has been to just have a single product. And that means buying other companies and bolting on their products doesn’t make a lot of sense to us.

Since 2001, when we launched this strategy, we have built our ALM business that this year will do about $50 million in revenue and all purely organically. We haven’t grown in a dead straight line, but we have grown pretty steadily along the way, and we’ll grow a lot this year. So business is good.

We have been recently hit very hard by the currency, because the U.S. dollar has moved from 70 cents Canadian to $1.10 Canadian, and that just inflates all of our costs. We have really had to manage that, but the problem seems to be easing now.

TPM: You could convince the OPEC nations to price oil against the Looney instead of the Greenback, and then your currency could deflate a bit.

PD: Well, there’s so much oil in Canada, that it is really driving our currency. That has probably held back some of our sales and marketing efforts, but as it eases and as our business grows and our maintenance grows past the excess costs of the currency, we will invest more heavily in our sales and marketing. We have averaged 35 percent over the past six years, and we’re just keen to keep growing.

RELATED STORIES

State of the System i: Other Software Makers Weigh In

MKS Swings to a Profit on Revenue Growth in Fiscal 2008 Second Quarter

Product Transitions Affect Financials at MKS During Fiscal Q2

MKS Sees Software Licensing Downturn in Q4, Gears Up for Rebound

MKS Signs Japanese Partner

MKS Updates ALM Tools for iSeries, Distributed Systems

MKS Says Business Is Booming Enough to Give Dividends

MKS Refreshes Change Management Suite, Adds ‘Dashboard’ View

MKS Integrates Workflow Application with WDSc

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot