This is part 2 of a pair of articles about clearing bottlenecks in enterprise software development and management using AI. Check out part 1 to learn how AI can help you address bottlenecks in the software delivery lifecycle.
For the last decade, the rule was simple: Don’t build what you can buy. Over the past six months, I’ve seen AI invert this enterprise software strategy. When the cost of writing code plummets, it’s time to reevaluate that approach. Why pay subscription fees for a generic tool when you can use AI to generate a bespoke application that fits your exact workflow for much less? As tech leaders begin to shift their way of thinking about their build-versus-buy strategies, we’re going to get a torrent of new enterprise applications.
Most of these will be small apps. These are “line of business” (LoB) apps, like sales dashboards, inventory trackers, and factory ops monitors. If you’ve worked in sales, you’ve encountered a lot of these LoB apps. Few people can get their official CRM to work the way they want. The dolphin-spawned dream of CRMs got lost in customization and data quicksand at some point. The UIs are often comforting for web nostalgists. Instead of using these, people create custom dashboards and analytics that make it easier to see your current sales pipeline, activities with customers, and forecasts.
There are other LoB apps,including ones that manage inventory at warehouses, minor operations at factories, or that help decide where to open a new bank branch. My two of favorite ones from the height of the digital transformation days were running the paint desk and tool rental desk at Home Depot.
Jason Hoffman and it’s a good example of these types of apps. He estimated that AI reduced the cost by 99.8%. As they say, your mileage may vary, but even halving that number—maybe even thirding it!—is worth taking seriously. That kind of change in costs eliminates the “ROI bottleneck” for apps.
The ROI bottleneck
That these types of apps exist shows a need and value for more of these apps. Intuitively, we can imagine that for every sales dashboard and paint desk app, there are 10, even 20 more that would be productive. Creating these LoB apps is often bogged down by the bottleneck of people’s time and ability to show ROI.
“ROI” is a catch-all phrase for a few things in business-think: Is this going to be worth the time and money? Is there something that we should do instead? Are we paying too much for this? These questions matter when the price tag is high.
As Hoffman estimated, to do his app—and, I assume, to “do it right” by the standards of an industry veteran like him—it’d cost $750,000 to $1,500,000 and a year at least. Something like a paint desk app probably needs that kind of attention, a sales dashboard less. But if you can make apps so cheaply and quickly on the high end of “doing it right,” making smaller apps should be equally cheap and fast.
Reducing the time it takes and, thus, the cost to create these little apps eliminates the LoB app ROI bottleneck. It means you can start making all of those little apps that will help you run the business better.
The new ROI bottleneck: Operations
The tools to do this code generation are here and, from what I’ve been seeing, good enough to start with. It’s possible to remove the bottleneck for coding and start showing ROI. Once you remove one bottleneck in a complex process, though, we know that you encounter the next one. In this case, that next bottleneck is how you secure and run all those little AI-made applications.
A new sprawl
If building an app is this cheap, everyone is going to do it, and we’ll get into a shadow AI mess. In the past, shadow IT was a rogue Excel sheet or a credit card swipe for a SaaS tool. Now, it’s a marketing manager asking an LLM to write a Python app that processes customer data, then running it on an unsecured cloud instance because IT was moving too slow. Without something to catch these apps, you aren’t just looking at both shadow AI and AI sprawl. This is a compliance nightmare where your corporate data is leaking through thousands of unmanaged, custom-coded sieves. It also makes just “keeping the lights” even worse for the IT department.
Day 2 operations
The next bottleneck is about everything that happens after the application is developed. This includes getting access to data in your organization, releasing the software, configuring and deploying the application, monitoring and managing it in production, and most importantly making it “enterprise grade” with plenty of security and regulatory controls. In the industry, we’ve long called this “Day 2 operations,” or just “Day 2” for short. Day 2 activities are a huge part of what consumes and slows down the enterprise application cycle—and makes it expensive.
Thankfully, we’ve solved these problems many times before. These problems are solved by first putting an internal developer platform (IDP) in place and, second, by consolidating your applications to use that platform. The first is a technical move, the second is a management challenge.
The platform fix
Let’s look at the goals of a platform. It’s to remove and automate as many activities that are not part of the application design and development process as possible. Instead of working on how the application runs and connects to a database, the platform has services and conventions, and the programmer uses those. Instead of requiring the developer to spend time configuring and packaging the application, the platform has services and conventions to that—and so forth. Platforms standardize how all of those non-app-related activities are done and seek to automate them as much as possible.
Applying security patches is a good example. Without a platform, when a security issue (a “CVE”) comes out, developers are responsible for analyzing if and how it manifests in their app and for applying the patch to their apps. The organization has chosen to put this work on the developers because there is no platform in place. Dealing with things like this and “keeping the lights on” is why you see so many people complaining that they spend too much time on maintenance—50%, even 80% of their time.
Platforms address that by taking over many of those non-app-development tasks from programmers. In the case of security as done in Tanzu Platform, developers are not responsible for configuring and packaging their applications. Rather, they’re not responsible for specifying how that’s done and doing it. The platform has standardized how apps are built, configured, and deployed (for example, developers use buildpacks instead of containers as the way of deploying applications).
AI coding will encounter these same problems if you don’t have a platform in place. And it’ll be worse. If we’re looking at a 10x multiple in the number of apps you have, if each of those apps follows its own ways of managing apps, you’ll have a spaghetti nightmare. Imagine 500 unmanaged LoB apps all connecting to your customer database without a security patch strategy. Your operations and security people will freak out, and rightfully so. If you want to benefit from AI coding, you have to standardize on a platform. Just as with humans, you want the AI writing application code, not determining how that code is run, managed, and secured.
The new bottleneck: Platform sprawl
The reason why this Day 2 stuff is such a mess is because most organizations do not standardize on platforms. These organizations suffer from platform sprawl: instead of a handful of platforms, they have dozens or more platforms in various states of “enterprise readiness.” They likely have ongoing initiatives to build new platforms (often building on top of Kubernetes).
Sometimes there are understandable reasons for this platform sprawl. Large banks are a primary example. Most large banks have acquired and merged with so many other banks that they’ve inherited portfolios full of different platforms and Day 2 operations practices. These banks never had a choice. Most of them are working very hard to consolidate those platforms.
Other organizations just lacked the discipline to limit the number of platforms in use. They’ve allowed developers and industry fashion to drive platform sprawl. Worse, they’ve allowed developers and others to drive complete replatforms of perfectly good platforms. The industry desire to move to public cloud and Kubernetes has seen years of organizations consumed with the work it takes to build platforms from scratch. They often go over budget and fail to deliver on ROI.
To get the productivity benefits from these AI-generated LoB apps, though, there’s no time for that. That constant rebuilding of the platform will kill your ROI and productivity. Of all things, your platform shouldn’t be a bottleneck; it should be the opposite.
Here’s a test to see if you’ve solved the platform problem or not. Ask your developers if they like using the platform. Ask the developers if the platform makes it easy to deploy apps. If they say yes, your platform is working well. Ask them if they spend a lot of time applying updates, security patches, making sure their apps satisfy regulatory needs. If they say no, you’ve got a good platform in place.
These same issues will come up with AI-generated apps, but they’ll be multiplied by a huge amount. Having a platform in place that takes Day 2 problems off the table makes it possible to use those AI-generated apps and get over the last ROI bottleneck: the platform. Rather, the lack thereof.
Platform sprawl is a solvable problem
If you’re working at a larger organization, here’s some good news. You probably have a good platform in place already. Tanzu Platform is proven to address these two problems and speed up human developers. Many large organizations have Tanzu Platform in place. We’ve seen proof in several organizations in the past year that the platform works well with putting AI in the loop. For example, our own IT department (Broadcom GTO) is using the Tanzu Platform in the development process to use AI in secure and well-governed environments.
I mentioned data above, and that’s the other part that makes the Tanzu Platform a great landing zone for AI-generated apps, namely, the data services and approach in Tanzu Data Intelligence. To top it all off, like most large organizations that want and need to run this all in their private cloud, Tanzu Platform layers on top of VMware Cloud Foundation (VCF) and gives you an integrated, enterprise-hardened private cloud.
For decades, “build vs. buy” was the defining question for enterprise applications. Buying usually won because building was too slow, expensive, and risky. AI is changing that for LoB applications. But to successfully build at this scale, you need the right foundation. The bottleneck has shifted from creation to operation. It’s tempting to think you could build this platform too. But the industry has spent many years trying that, and the result is usually a mess. The new strategy is simple: stop buying generic applications that dictate how you work, and buy the platform that lets you build exactly what you need. Stop building platforms, and start building apps.
