Identity consolidation and privileged access management across Windows, Linux, and UNIXEnterprise Edition
Detailed auditing of privileged user sessions on Windows, Linux and UNIXPlatinum Edition
Dynamic segmentation and isolation of cross-platform systemsApplication Edition
Secure, centralized single sign-on to on-premises business applications
Single sign-on and unified management for cloud and mobile apps and devicesMac Edition
Centralized security and management for Macs and mobile devicesPremium Edition
SaaS and Mac Editions combined with mobile security management
Tuesday, March 20, 2007
Welcome to the third post in my Entrepreneurship in the Infrastructure Software Market (EISM) blog. In these initial set of postings I am blogging on what I think are some of the key DNA elements required to be successful in this market. As expected, luck of course is DNA element #1. In my last post I discussed DNA element #2, which is your solution must be considered by the customer as being "must have," and discussed the importance of vetting this well before full-blown development of your product has begun and really determining how likely customers would be willing to replace an existing piece of infrastructure for your solution.
In this post I will discuss key DNA element #3, which is you should ensure that whatever infrastructure software solution that you build and release has the ability to morph fairly rapidly and easily beyond what can be perceived as a feature of the underlying platform and into something that can become a mini-platform unto itself. Notice I did not say "make sure you build a product, not a feature" — I am saying that DNA element #3 is make sure your solution has the flexibility to evolve into a "mini-platform."
I will explain what I mean by mini-platform below, but let me first set the proverbial table by saying that most infrastructure software lives within an ecosystem that is built around one or more major underlying platforms (e.g. Oracle RDBMS, Microsoft Windows, Cisco routers, etc.). Obviously there is nothing worse than spending a lot of time and money building a great solution that addresses a key point of pain (i.e., it passes the "must have" test) around a particular platform, but then with the next version from that platform vendor the need for your third-party solution to solve that pain point goes away. Badda-bing badda-boom, you are now in Plan B mode, which means either "we gotta do something completely new" and/or you are forced to have your solution play in a smaller ecosystem around a much smaller underlying platform that does not yet have your product's capability.
On the flip side, the reality is that, to a large infrastructure vendor such as Microsoft, Cisco, Oracle, etc., just about everything is a feature; e.g., "backup and recovery" is a feature to Microsoft Windows. But you can build a nice software business out of that "feature," and so it is OK to build something that is initially a "feature." But have a vision and technology path so that it can graduate from being a feature to something more so you minimize the risk of having your functionality roll into the base platform.
[Side note: this whole "is your solution a product or feature?" is a very common VC question to entrepreneurs, so be prepared ahead of time to have a crisp answer to this question, just as I said in the last post I that you need to be prepared to crisply answer the "is your product a must have?" question. This whole "feature vs. product" issue is probably the easiest excuse for a VC to tell you "No," because at the end of the day everything is a feature to a large platform vendor. But in fairness, VCs have been burned by this happening to their portfolio companies in the past. If a VC tells you they are concerned that your solution is just a feature, when it is clear to a bunch of other VCs that this is not the case, just chalk it up to the fact this guy does not get it or does not want to tell you the real reason he is saying No, so save yourself the time of trying to convince this guy and move on to someone who does get it.]
So what should that "something more" be? The usual answer is it should be "a product" vs. "a feature" of the underlying platform. OK … but … big infrastructure vendors all the time come out with new products for their platform. Take Microsoft. They are getting real serious about the systems management space. They always had Systems Management Server (SMS) for inventory and software distribution, but over the last five years they have come out with an event and performance management product (MOM — which the prior company I co-founded licensed to Microsoft) and are now doing helpdesk and backup software. Microsoft is also extending their reach in the identity management market — they plan to come out in early 2008 with a robust workflow-based provisioning solution, a password reset product, etc. Sure, you can bet on the fact they won't get it right in their V1, but that is a big risk, and even if they don't get it right you will encounter sales friction because most customers will want to at least see if the platform vendor did get it right initially.
Build a mini-platform
So given that any product or feature could in theory be taken over by a large platform vendor, what to do? My advice is to go ahead and solve the point of pain, but minimize the risk of having your feature and/or product's functionality swallowed up by a platform vendor. You do that from the get-go by building into the DNA of your solution the ability from a technical and economic perspective for it to quickly evolve into a mini-platform unto itself. So what do I mean by "mini-platform" as it relates to infrastructure software? Besides sounding a lot cooler than saying you are building a product or a feature, it has some of the following characteristics:
(a)is not solely tied to one major underlying platform
I experienced this one first hand with NetIQ and AppManager. AppManager in the early days focused primarily on performance monitoring of Microsoft Windows Server and the classic Microsoft BackOffice servers (Exchange, SQL, IIS, etc.) , and grew to a $100 million per year product line in 5-6 years of being on the market. NetIQ licensed Operations Manager to Microsoft (which became MOM) in 2000, and Microsoft evolved the product by MOM release "2005" to compete more head-to-head with AppManager, causing revenue to go sidewise. But at least AppManager was designed from the start to be flexible enough to support other platforms to give it a fighting chance to diversify, and there are other platforms it can go after. So the point is, it is OK if your "solution" is just a remora-like feature or product to a single whale, but make it flexible enough so that it can easily attach to other large whales in case the original whale starts to think it wants to eat you.
[There can be an exception to this case: you do build a solution that can really only work with a single platform, but you pick a space that you have very high degree of certainty that the platform vendor will never ever get into In the case of Centrify, our initial flagship product DirectControl extends Active Directory to non-Microsoft systems through software that runs on UNIX, Linux and Mac systems, and we also enable non-Microsoft applications such as Oracle, SAP, WebLogic, etc. to tie into Active Directory. Jeez, you may say, won't Microsoft do that? It is possible, but Microsoft has publicly and consistently articulated it won't build software for any other platforms besides Windows (Mac Office is the sole exception), so the risk is low. I just don't see Microsoft doing + ports of UNIX/Linux/Mac like we do. At the same time, Centrify has diversified its product line to include user-level auditing for UNIX/Linux platforms through our new DirectAudit product (which is not as closely tied to the Active Directory platform vis a vis DirectControl), so one could argue we also support other major platforms such as Linux and have branched beyond the core authentication that Active Directory provides (and that we extend to non-Microsoft platforms) to new functional areas.]
(b)is easily extended by customers and partners to build custom solutions, so that an ecosystem around your solution develops
Most infrastructure software companies (startups or large companies) are constrained by the amount of development resources they can put into their product to deliver new functionality. The reality is that a large platform vendor, if it wants to get in your space, can outspend you R&D-wise. But if you can harness a greater set of developers to help you extend your solution (be it via Open Source, easy-to-use APIs and SDKs, based on an open database for custom reporting, etc.) you can not only level the playing field resource-wise but make your solution more sticky as it will become more tailored for the customer's environment. At the same time, if you design your product from the beginning to be extensible and open for customization, you have the advantage of seeing customers take the product into areas that you did not originally envision, thereby potentially opening up adjacent and ancillary markets that get you "further away from the flame" of a large platform vendor whose ecosystem you are in. It can also attract third-party solution providers such as Systems Integrators and consultants to your side who see they can make money tailoring your product for customers. Another example of this is the scenario where other ISVs or vendors want to embed your technology within theirs.
Net net, I think this post is about risk avoidance. It is hard to envision the future, but I recommend you go into a new venture within the infrastructure software market not blinded to the possibility that a platform vendor will want to come out with functionality that addresses what your solution does. Don't necessarily let that dissuade you from going out there and building that "must have" solution which folks may consider to be a feature to say Cisco, but you may want to consider building something that has the flexibility to work with other platforms and allows others to extend your solution in innovative ways for you that causes an ecosystem around your solution to develop. So to me one of the key DNA elements for success in the infrastructure software market is that successful vendors don't just release a feature or a product on top of an underlying platform, but in fact build something that morphs into a mini-platform unto itself that spans across multiple underlying platforms and leverages a power of a community to take it into new spaces and markets. Plus, it will probably throw the VC for a loop if he asks you if your solution is either (a) a feature or (b) a product, and you actually answer it is (c) a mini-platform.
In my next post I will discuss key DNA element #4 for success within the infrastructure software market — making sure your solution is part of a large and fast-growing market.
Tom Kemp is CEO of Centrify. You can follow him on his Centrify blog.