It has been seven months since I started at ServiceNow and I think I’m just beginning to understand the advantage of delivering enterprise applications on a mature platform.
The advantages of building on a consumer platform are well understood and primarily about access to potential customers. If you are building an application, you naturally want to build it on the platform that provides access to the most customers. This is one of the reasons that the Macintosh has become more prominently used by consumers and enterprises over the last 15 years: As the computing platform slowly shifted from Windows apps to web apps, there simply wasn’t as much need to run Windows. This allowed the Macintosh’s superior user experience and reliability to drive buying behavior. (Of course, without Microsoft writing Office for the Mac, none of that would have happened but I digress.)
In contrast, enterprise applications built on an enterprise platform get you speed and robustness. Speed and robustness are critical for emerging enterprise products in a competitive market and they are often interrelated. Let’s get into why.
While working at several startups in product development, I realized that balancing building features to support the reason a venture capitalist wrote you a check and building features that ensure a successful deployment are often completely unrelated. This is because the foundational capabilities enterprises depend on to run a new piece of critical technology are the same capabilities they depend on to run everything else. Scalability, APIs, security, reporting, customization, and certifications are all expected attributes of any piece of software used by Global 2000 organizations. But while developing such capabilities is not novel, it is very time consuming.
So inevitably, you try to balance. This often means focusing as much as you can on the innovation the company was funded to create, while trying to ensure you meet a minimum bar in the requirements common to all enterprise software. Early adopters are often willing to sacrifice some of these foundations but the majority of the market is not. As you transition from these early customers to more established ones, the technology you built has likely morphed considerably to the point that better addressing some of these enterprise capabilities becomes a costly retrofit, robbing an organization of feature velocity often right at the time when your core business is under attack from new competition.
Planning for this eventuality from an architectural standpoint while maintaining growth-fueling innovation is arguably the most important skill an engineering leader needs outside of recruiting top talent. Approaching startup development from the opposite direction (building the foundation requirements first) is even worse as innovation stalls and you exhaust your initial funding before you are able to prove the business.
Which brings us to the point of this essay. Building your new enterprise application on an established platform cheats this Catch-22. Someone else builds the platform before you show up, and you come along and benefit from all their hard work.
A big part of why our new Security Operations capability at ServiceNow is successful in its early days is we have zero resources devoted to enterprise foundations. Those foundations are built by an entirely different and well funded team elsewhere in the company. Also, their output benefits many products, not just mine. Sure we talk to them and pass along requirements from time to time but almost everything we need is already there. Scalability, security, APIs, customization, reporting and so on are free features for us. Our entire business unit is focused on innovation in the security response space which is exactly where our board and investors wants it. This is an essential element of why the expansion of ServiceNow’s core technology into new markets is so exciting. By hiring talent in a new domain area and allowing them to innovate quickly on top of a mature platform, we can build robust new solutions to key business problems that most startups can only dream of.
The counterargument against an enterprise platform is that by building your own enterprise foundations you can build them exactly they way you want. And for certain technology problems, that makes sense; you need to start from scratch. For example, Apple could never have built iOS by starting with a requirement that the phone ran OS X applications. Buyer beware though. The problem I highlighted earlier still stands: while “built from the ground up” is a great tag-line on a data sheet, it often means spending the minimum amount of time possible on those foundations because early customers buy differentiation not robustness.
As enterprises increasingly go cloud and embrace technology the advantages of building on a mature enterprise platform will only grow. As mentioned earlier, when robustness comes almost for free it unlocks amazing feature velocity in your core area of focus. As for me, I’m excited to see how this plays out in my technology area and am curious to hear other’s experiences in building on a platform, or deciding to go it alone.