How all those who work with ServiceNow should think about buying a solution versus building their own
“Construction is the art of making a meaningful whole out of many parts.” — Peter Zumthor
Introduction
Buy versus build is a discussion perhaps as old as software itself. Certainly it has become more prevalent as software has evolved beyond canned (boxed) point solutions into development platforms. Modern platforms provide the ability to use existing components to develop new solutions and ServiceNow is no exception. In fact, ServiceNow was designed to do this from the ground up – it was the vision of the founder that ServiceNow was solely for quickly creating custom business solutions to replace paper, email, and spreadsheet processes. What has happened since the early days is both the market and ServiceNow itself has realized the flexibility of the platform allows for solving business problems across the enterprise and consolidating service management and data into a single platform. I’ve written about this history and using Service as a platform previously in these articles. I’ll use the rest of this article to discuss the decision points for determining whether to build or buy, specifically in the ServiceNow realm.
The ServiceNow Decision Conundrum
The “normal” reasons for buying instead of building are well documented, but I’ll summarize here:
- Cheaper in the long run – less maintenance costs
- Buying the expertise of an organization and not just a few developers
- Buying the “best practice” implementation based on knowledge of many organizations
- Access to future enhancements and bug fixes – and someone else is paying the developers to build them!
All of these are sensible and reasonable. And often tip the scales in the decision process to “buy” instead of “build”. But here’s the rub: ServiceNow is simply not like other platforms; it was designed to be built on! I won’t go over the ground covered in the previously cited articles, but in short, the entire vision for ServiceNow was as a platform on which to build process flows. Despite the company’s pivot in recent years to a product company, it doesn’t change the fact that the underlying platform can be developed on more easily than most other enterprise cloud platforms. There’s an annual event at Knowledge called “CreatorCon” for goodness’ sake!
So what are the reasons to develop on your own, rather than buying a product? Like the “buy list”, I’ll give a brief summary:
- The solution can be tailored exactly to your business needs, which encompasses the following:
- Quicker user and business adoption
- No need for costly OCM measures
- No waiting for updates or bug fixes
- Eliminate the concern of increasing license costs (often product sales strategies are “hook them at a good price then raise the cost”)
- No need to make the tough decision about how much to configure or customize a purchased product (which can put you at risk) – it’s your application, have at it!
- No upgrade concerns – ServiceNow release processes don’t care about your application.
These reasons are also compelling. So what’s the right answer? As almost always, the answer is “It depends”. Let’s walk through a real world scenario to help illuminate some of the decision points and how one might make the call.
Real World Example – Making the Call
Let’s take a specific scenario and think our way through it: An integration with another cloud-based platform (one that uses modern protocols). For the sake of this discussion, let’s say you need to integrate customer account records from Salesforce into ServiceNow, and as delivery processes in ServiceNow update account and account adjacent data, push these updates back to Salesforce. For example, as contracted support is delivered and tracked in ServiceNow, key metrics are passed to Salesforce so account managers are aware and can have informed discussions with their account contacts.
In general, these are the ways to accomplish this, and what each means:
- A ServiceNow provided integration, likely through Integration Hub. Usually this means licensing fees. It also means using the integration as designed, or face configuration or customization challenges, as well as upgrade and support concerns. In my experience, products rarely can be used as provided – individual business’s needs do not align perfectly with the product design.
- A 3rd party provided integration, embedded in ServiceNow. These usually have the same licensing, configuration, customization, and support concerns as a ServiceNow provided solution.
- A 3rd party provided integration through external cloud “middleware”. Again, this will have licensing costs and may or may not be configurable to your specific business needed.
- A custom built, API-based solution using out-of-box ServiceNow components such as REST messages and functions, security protocols, web service import sets, etc. This approach may or may not have licensing implications (in the past there were no licensing fees using these components, but this changes constantly and good luck guessing ServiceNow’s current model), and it requires enough in-house or contracted ServiceNow development prowess to know how to design and build the solution. However, the solution can be built exactly to your needs, it has no bearing on upgrades, and future changes are at your discretion.
An executive, without knowledge of the true nature of the ServiceNow platform, may read the last bullet and think, “I see the word custom, this is bad”. But here’s the rub: What I’ve found after dozens of these implementations is the last option is often the quickest, easiest and cheapest option. Why? Implementing a largely black box solution often means long development, testing and troubleshooting times for tweaking the solution to work with your business needs. In other words, if you can’t use the product exactly as designed, attempting to make the changes to make it work for your needs can take longer than building a solution “from scratch” using the tools the platform provides. (I put “from scratch” in quotes because it almost never happens that you’re building something that hasn’t been built and documented already.) I know from experience that troubleshooting a solution I’ve designed and implemented is orders of magnitude easier (shorter) than attempting to unwind a ServiceNow provided product to figure out a root cause.
Think of it this way: Consider buying versus building a home. It’s almost always faster and easier to buy an existing home and customize to your needs. But in the ServiceNow realm, you’re not building a home from the dirt up. Rather, the correct analogy is you’re building a modular home, where ServiceNow has provided the components and you are assembling them in a bespoke way that works best for you. In this scenario, it’s quicker and easier to assemble the parts in the way you want than it is to tear apart and reconfigure the house that’s already been built. And you now have knowledge of the assembly and how the parts connect together, rather than it being hidden behind paint and drywall.
There’s quite a large caveat to all this: You need resources that understand how to design and develop correctly on ServiceNow. If you are not staffed beyond basic administration and configuration, the balance of the decision scale may quickly tip towards “buy”.
Conclusion
We live in a world where notions and sayings often rise from urban legend to the level of conventional wisdom. It is imperative that decision-makers in the ServiceNow ecosystem do not accept these notions as conventional wisdom; after all, ServiceNow was designed to fly in the face of conventional wisdom – isn’t all disruptive innovation? Rather, they should use analysis, knowledge and intelligence when evaluating and deciding on the correct solutions for their business. And most importantly, understand that buy versus build for ServiceNow is not such a simple answer.
