Build vs. Buy: Unveiling the Real Costs of Intelligence Solutions for IT Leaders

Digital.ai forecasts that you have a better than 50% chance of failing with your DIY implementation of analytics and AI/ML at an operational scale. A CIO.com article detailed reasons why many AI and analytics projects fail. Our own experience at Digital.ai is that many of our customers had one or more similar failures prior to adopting our Digital.ai Intelligence product. Let us look at some of the top reasons why you would buy instead of build when seeking the following Goal.

Goal:

An extensible , operational, scalable, and sustainable analytics BI, AI/ML solution spanning all stages of the software delivery lifecycle from planning through operations. The Goal acts as a co-pilot to leadership and tactical teams, allowing them to observe what is going on in their environment, with predictions and prescriptions on how to speed up their digital delivery process with higher quality.

Let me share the common challenges that we see our customers going through when building themselves.

Challenge 1: Time to Value

I was talking to a company that had built an initial set of dashboards from scratch and a single data source, and their lead implementer was saying how three years ago the need arose, but they only just have it in beta-usage now with a lot more work to go on the AI front. Most of that delay was waiting to hire the right skills, expertise, and knowledge. IBM touched on this in 2022 when they said lack of AI skills was the top barrier to AI adoption. For this company, that barrier translated to a three-plus year wait for the solution they desired…they are still waiting.

Failures can delay the value you seek. Thinking of the failure rates mentioned at the outset, we experienced a few over the years as we built out our stable SDLC-focused intelligence offerings. Our team has the software domain and data science knowledge, and experience. Over eight years, they have evolved Intelligence offerings through internal innovation and customer-driven extension. Failures in DIY can force big delays across the many activities required to build the Goal. Avoid failure-based delays, and buy an existing stable solution.

As you might expect, our customers share similar observability challenges across their SDLC; likely similar to yours. Yet they have proven to us that there is no single correct solution that applies. For example, we have had a number of customers who sought to measure and improve the productivity of their scaled agile teams, and our work with each has led to novel solutions that satisfy their leadership. When you subscribe to our robust offering, your needs might be met out of the box, or we can craft a bespoke solution based on your ideas and our experience and insight of having solved the problem before. You will be 95% there the day you subscribe. If you build your own, it could take a year or three to get to a similar place.

Challenge 2: Opportunity Cost

When you subscribe to our Intelligence products, we assign you an Intelligence Architect. They bring the experience to design the solution you need, if it does not already exist, and will liaise with our dedicated team to realize your solution. Getting value from our solution requires some time from one person on your team who can act as the Product Owner for your desired solution. Our skilled and experienced team, working with your Product Owner and the Intelligence Architect, builds out your solution, typically in four to eight weeks. Were you to build your own from scratch, it would take twenty people across thirteen different skill areas over a year to, perhaps (remember the failure rate), get to the same point.

What should start to be clear is the opportunity cost of building the Goal vs. buying the Goal is significant – and that assumes that you are successful when building. With the high failure rate, it is more likely that your building effort will result in sunk costs.

Digital.ai has spent over eight years and $100M to build a software delivery intelligence capability that stands ready to ingest your data and light up dashboards. It runs on a purpose-built AWS infrastructure with its technical components identified in the figure below.

Most of the technical components in Figure 1 accommodate the flow of data from your tools into the visualized insights the Goal requires. The remainder of the components operationalize the capability’s ongoing running, maintenance, and upgrades.

Common extensions of capability come in step three, in Table 1 below, because you may configure a tool differently than its defaults; and step 9, because you want to see the results in a particular way.

Less common extensions to the list here would be step 8 in some products to train the model, or steps 5-7 to surface the ability to visualize new metrics. Remember, any of the changes discussed here are specified by you for our team to accomplish swiftly.

Digital.ai designed our Intelligence Products to be adapted to your needs. When you wish to specialize or extend our Products, you have access to an experienced team. Think of building your own capabilities; how much staff will you need to retain to support the evolving needs of your organization? Couldn’t they be doing something to help you put more value in front of your customer? The time spent on DIY alone, with the given failure rate, would be better spent putting value in front of your customers while you subscribe to the desired capability.

Challenge 3: No Content

The technical components in Digital.AI’s Intelligence products go far beyond the code required to build each component; they include a Data Lakehouse and customer-tested content out of the box. We infused our content with years of DevSecOps knowledge and industry best practices from our partnering with Scrum.org, Scaled Agile framework, and others, from their guides, websites, and books. This content includes thousands of OOB metrics, configurable connectors for popular DevSecOps tools, a Unified Data Model that encompasses all stages of software delivery into operations, and hundreds of dashboards containing actionable insights. The combination of the infrastructure and technical components would be appropriate for any BI or AI project in the business, but our content instantiates them for the software delivery domain. If you were to build the technical components and the domain content, where would you start? How long would it take? What would you source?

Challenge 4: Actual Costs

“We will do it on our own; it will be free.” We have actually heard prospects say that before. Do you see how this could be a true statement? We cannot. We use our Intelligence products internally and pay the data costs and labor to keep it running. A smart employee with Microsoft Power BI does not achieve the Goal in an enterprise, nor will it be free. What are the costs?

• Build Staffing Cost – Can be several million, even with off-shore staffing
• Run Staffing Cost – Likely to be over 500K if the solution is actively growing and evolving
• Tooling Costs – Likely to be in the 30-80K range
• Data Warehouse Cost – At an enterprise-scale (1k-40k developers) and depending on the number of data sources and their growth, even cloud storage can become non-trivial
• Cloud Compute Infrastructure Cost – When you build your own, the full scale of this is often unknown at budgeting time

You will find Digital.ai’s Intelligence Products will cost a fraction of those outlined above. And you have control over how much you want to spend to extend the solution to your needs if required.

But wait, some tool vendors will give us this for free. Timeo Danaos et dona ferentes¹. No, seriously, that is great. So, you are getting thousands of metrics across the software delivery cycle, ingestion of the DevSecOps tools you use, a data model built from years of DevSecOps experience, useful visualizations, access to domain-experienced data scientists, domain experts, data architects, and data storage all for free? Figure out what it will cost you and if it will bring you the value you need today and tomorrow before you commit. Caveat emptor.

Conclusion

Just considering the historical failure rate of even well-funded analytics projects and the fact that IT is often too busy with paid work to attend to their own analytic needs, doesn’t subscribing to this needed capability make more sense?

 

To learn more about how to identify risks and trends to deliver reliable digital products on time, check out our Intelligence product webpage.

1. Virgil. The Aeneid of Virgil., 29-19 BC, “I fear the Greeks even when they bring gifts.”