Tom Kemp's Centrify Blog

Why was Centrify formed? Part 1 of 3

Wednesday, February 28, 2007

As CEO and a co-founder of Centrify, I am sometimes asked what the inspiration was behind the formation of Centrify. So I figured that would be a good topic for my first blog entry.

Like many entrepreneurs in Silicon Valley and beyond, I really love working with a great bunch of people and building something from scratch that delivers lasting value to employees, customers and shareholders. There is nothing cooler than having your startup company and its product just suddenly appear in the market after being in stealth mode, and then if you execute and hit a sweet spot in the market, having in a relatively short span of time 100s of customers.

It was such a positive and exhilarating experience (and often times very nerve-wracking) that I thought it would be fun and challenging to create another startup and build it into something meaningful. Over my 18-year career I have been in the infrastructure software business, so it was a natural place for me to focus on. So in early 2004 I embarked on my third startup. I was fortunate to hook up with my fellow co-founders Adam Au and Paul Moore to form Centrify, and so far after about three years into it we are pleased to see Centrify exceed our initial expectations.

But going into this venture we did not want to start another software company for the sake of starting a company. We wanted to make sure that our software solution addressed real customer pain (i.e. it had to be a "must have" vs. a "nice-to-have" solution to problems that most enterprises were dealing with) and part of a large and growing market so we could build something big. We also wanted our technology to take a significantly new approach, one that existing vendors in the space would find very difficult to adopt. Finally, it was also important to us to be able to leverage significant emerging trends that would work to our advantage vis-a-vis legacy approaches and vendors.

One such trend we felt we could leverage was the growth of Linux in the datacenter. We felt that Linux represented a new mission-critical platform with its own unique characteristics vis-a-vis pre-existing platforms (e.g. the Open Source development model, a UNIX-like technology that was deployed more like Windows in terms of being deployed on a scale-out basis versus scale-up, etc.). We felt this new emerging platform would in turn give opportunities to new infrastructure management startups to build something that was optimized for that platform, and that legacy vendors would have a hard time adopting their old technology to this new platform. I saw this phenomena occur a number of times over the last 15 years with companies like Tivoli (with UNIX), NetIQ (with Windows) and Wily (with Java/J2EE) being the first to market delivering infrastructure management solutions for a new major platform.

The Linux market seemed ripe for having robust infrastructure management tools available that were optimized for this platform, and it was clear that the market was underserved given that the existing tools in the market were either command-line oriented or could manage only a single system at a time versus managing a group of systems simultaneously (I believe it was Meta Group that said in 2003 that the "most common Linux management tool is still an editor."). But what market segment to focus on within the Linux management market? After some research, it became clear that one of the large glaring holes in Linux infrastructure management had to do with Identity and Access Management ("IdM") as well as policy and configuration management.

Like the Linux market as a whole, the Identity and Access Management market was definitely a large and fast-growing market, being driven by government and industry regulations such as Sarbanes-Oxley (SOX), HIPAA, PCI Data Security Standard, etc. We also knew that, unlike Windows with Active Directory, Linux did not have a LDAP-based directory built-in and enabled right "out-of-the-box." and instead, like UNIX, primarily relied on local text files (e.g. /etc/passwd) that forced management on a system-by-system basis. In some cases, Linux customers were relying on old and no-longer-supported technologies such as NIS and NIS+ to address their identity management needs. In addition, while Open Source directories such as OpenLDAP were available for Linux, they did not provide built-in Kerberos support for network authentication, nor did they have Group Policy-like capabilities to enable mass configuration changes across groups of Linux systems (which will be a key capability if Linux is ever to be a popular desktop for enterprises that are required to centrally lock down desktops).

So a market need was identified, but what we actually came up to address this "point of pain" is covered in Part 2 of "Why was Centrify formed?"

Categories: Centrify, All

< Previous Article: My blog's README file
> Next Article: Why was Centrify formed? Part 2 of 3