When to Build vs Buy an API Analytics Solution
When to Build vs Buy an API Analytics Solution
In this article, see when to build vs buy an API analytics solution.
Join the DZone community and get the full member experience.Join For Free
Purchasing a new enterprise analytics solution can be a great experience if you’ve never purchased software before, yet it can be a daunting task. There can be a variety of analytics vendors with overlapping features for a use case yet each has its strengths and weaknesses. As an alternative to purchasing ready-made SaaS, you can also build your own in-house API analytics infrastructure on top of open-source software like Spark, Druid, and Elasticsearch. This article digs into when it makes sense to build vs buy ready-made analytics solution and provide a point-based framework for evaluating API analytics solutions and perform the proper diligence.
The first decision a company should make is whether they want to build the infrastructure or purchase a ready-made solution. There are benefits and risks to both. In general, purchasing shortens the delivery of a well-polished analytics solution with lower cost in time and money compared to homegrown, but a homegrown gives you greater control over what is tracked and presented.
Answer the following questions starting with a point scale of 0.
Add 1 point if you answer yes to any of the following:
Buying a ready-made analytics solution is almost always cheaper than building and maintaining a homegrown solution yourself. Vendors can amortize the R&D cost to build high-performance infrastructure that scales to billions of API calls across many customers. In addition, ready-made SaaS solutions have almost zero maintenance overhead whereas homegrown solutions accrue technical debt over time due to engineer turn-over, product neglect, and evolving business demands.
According to SAP, 78% of homegrown enterprise apps are abandoned after first use. Feature and bug fixes (even critical security fixes) remain unresolved after the initial delivery due to engineering resource reallocation. If you don’t have a data infrastructure team dedicated to maintaining your homegrown solution, it almost always makes sense to purchase.
Due to feature creep and unexpected onion peeling, building a usable analytics solution can drag on for months or years even for the fast-moving teams. Fully-managed SaaS solutions take less than a day to get up and running. Every day your team is building analytics infrastructure is time not spent on building customer-requested features that drive your bottom-line growth. Buying allows you to invest your efforts into your core competencies rather than reporting infrastructure. If it takes six months to deliver the first iteration of your analytics solution, then that’s a six-month delay in data collection and having access to proper data causing sub-optimal planning and execution.
Do you care if new data shows up the next day or are you looking for real-time monitoring and anomaly detection capabilities? Vendors can invest larges amounts of resources to make their solution high performance and real-time which are necessary if you want real-time alerts on API and account level health. To shorten the schedule, homegrown systems are usually built on existing technologies like SQL and Hadoop, whereas a vendor can invest much more resources into custom-built data stores and infrastructure.
Company-wide tools require strong access controls, audit logs, data management, along with an easy-to-use interface to make data accessible by non-technical users that a ready-made solution already has built-in. A homegrown API analytics solution is usually designed by engineers for engineers, forcing non-technical users to rely on making requests to an already overloaded data team. This slows down time-to-insight drastically.
In addition, homegrown solutions usually don’t have any security features in place due to aggressive schedules to build quickly. The majority of security incidents are due to insiders rather than third parties, sometimes inadvertently due to employees sharing passwords, employees unaware of proper IT-security policies, and no automatic threat detection of homegrown systems. Just because it’s behind the corporate firewall doesn’t mean it’s immune.
With regulations like GDPR, CCPA, and the upcoming ePrivacy Regulation being introduced, enterprises are now having to navigate more regulation than ever. Homegrown analytics systems rarely have frameworks and features in place to deal with things like GDPR’s right to erasure and methods to stop the collection of a specific user or company. Ready-made API analytics solutions from a third party vendor usually have additional features and frameworks already in place to make this much easier for their customers. After all, their main business is selling compliant API analytics software.
Will your API analytics solution be used by engineering only, or do you expect other teams like product, marketing, and customer success to also leverage your organization’s API data? If so, each team may have their own workflows and tools of choice. For example, engineering might be using PagerDuty and Jira, product using Amplitude and Segment, customer success using Zendesk and Salesforce, and finally finance using Tableau and Slack bots. Will you be building integrations with each of these products? Otherwise, you may have data silos which decrease the usefulness of API analytics and slow down your organization’s productivity. A ready-made solution usually has an ecosystem of plugins and integrations.
Because of their experience helping many companies leverage API analytics, vendors usually have deep expertise that they can share with their customers on best practices and ways to leverage API analytics at your organization. They’re able to provide a framework to build a better platform and can point you to tutorials and other know-hows that can assist your organization. Homegrown systems are usually built without any input from experts in growing API platforms and what to measure. A partner with deep expertise in API analytics can help you get started tracking core metrics like TTFHW (Time to First Hello World) and walk you through best practices for API cohort retention analysis while understanding what custom metrics are important for your business.
Subtract 1 point if you answer yes to any of the following:
Certain highly-regulated industries like healthcare and banking have very specific requirements on where data is held and the type of data that can be collected such as with HIPAA compliance. In these cases, it makes sense to build your own system to have complete control over data and not rely on a third-party vendor. While most third-party vendors already follow general best practices for SOC 2 and ISO compliance and have hardened infrastructure, but may not have industry-specific compliance like HIPAA. If they do, it may require a special plan Regardless, it’s imperative that your homegrown system is also compliant. Don’t fall into the trap of assuming internal systems are immune to compliance.
Building an analytics solution gives you complete control over how information is presented to end-users. While many ready-made solutions do provide ways to customize dashboards and white-label for customer-facing portals, if you have very specific requirements, you will need to build that in house.
Does your organization have a well-defined road map of what analytics features are important now and in the future? Do you believe the vendor cannot keep up adding more advanced features? Does your team have certain trade secret metrics that no other company is tracking? If you’re unsure what’s the best way to measure, a read-made solution will come with a well-defined framework so you don’t have to think about which analytics features are important, but this can limit you in measuring very specific things.
Do you have a dedicated data engineering teams and data science teams to build and maintain this? Have they already built and supported analytics infrastructure before at your organization? A dedicated team is not constantly context switching between feature development and building analytics infrastructure. This gives them more time to spend on maintenance and improvements.
If you’re building and selling a payments API and your main competitive advantage is that payments can be made in every global currency and can occur even offline without internet service, it would make sense to build your payments infrastructure in-house. On the other hand, unless you’re in the business of selling analytics solutions, it makes sense to partner with a vendor that already has deep expertise in analytics that can supplement your own engineering expertise rather than reinvent the wheel. The vendor can bring not only their infrastructure but also know-how on what are the best metrics to be tracking and how to track them better.
An overlooked benefit of building your own analytics infrastructure is you can also open-source it. If your company has a friendly policy for open sourcing internal tools, it can be a great way to boost recruiting efforts especially if you’re trying to recruit more data engineers. Since you have full control over the analytics platform, you can do as you please. If you do plan on open-sourcing, make sure you make that decision early. Open source projects have a higher bar to code cleanliness and also need to be able to run as a single container without require many dependent services to be stood up. If your analytics infrastructure depends on many components like a SQL database, Hadoop, Spark, and Kafka, it may be harder to open-source.
If you have a very specific use case and don’t intend to grow from there, building sometimes makes sense because you can over-optimize on compute and disc space. This is one of the hardest ones to decide on since it’s hard to plan for unknowns. If you want to track one single metric, and know that’s all you need, then buying a solution may not make sense. However, be careful of the fallacy that today’s use case seems specific since as more teams start using your homegrown solution you’ll discover new ways to leverage API data at your organization.
Building vs buying an API analytics solution can be an overwhelming process, but the best companies get the most ROI when a methodology is applied like above. Sometimes it’s recommended you try both. After all, building a solution may take 6 or 12 months but a purchased solution may take only a few hours to set up. In this case, it makes sense to purchase first, even if shorter contract to have something up and running while your company looks into what it takes to build.
The awesome thing about today’s SaaS-based solutions is you don’t need to commit multiple years using a product. Purchase a solution, learn how the product works, and then go build it after seeing what features your team uses the most and what they don’t use.
Published at DZone with permission of Derric Gilling . See the original article here.
Opinions expressed by DZone contributors are their own.