Internal Developer Platform: Insights from Conversations with Over 100 Experts - Looks comprehensive!

Spring AI: An AI framework for Java developers - No python? No problem.

Spring AI: An AI framework for Java developers - No python? No problem.

Reflections on Palantir - There’s a lot going on here, from small tactical points (much of the work in enterprise software is just meetings and “politics” to get access to enterprise data and systems) to complete world views (always questing for the most optimized, quickest, and profitable solution that actually works, no matter the cost). Counter arguments: how would one live like this with three kids, even one kid? // There’s also the mystery of why the thought leaders and executives of this world are so weird.

Are Kids Screenable? - New screen time app. It sounds like it actually integrates with iOS stuff, which I didn’t even know was possible.

Tanzu Postgres for Tanzu Platform for Cloud Foundry adds new features - Faster, incremental backups using pgBackRest, AI/ML support with Pgvector, and streamlined restore options with adbr

The Evolution and Expansion of IT FinOps - Overview of current needs and possibilities in enterprise-y FinOps, I assume.

Most of the generative AI applications we'll see in the coming years will be just new features added to existing applications. Even more pragmatically, simply improving how existing applications work will drive a lot of the AI benefits. When it comes to applications, this means we should manage AI like we would any other service, both in process and how we run it. That's my prediction at least. I'm as enamored with AI as anyone else, trying out plenty of experiments and ravenously hungry for any real world case studies that are more complex that chatbots, sophisticated search, and (re)writing.

The reality of AI roll-out in the enterprise is creeping in. That reality is: it’ll be slower than we were promised. For example, Battery Venture's recent enterprise tech spending survey says: 

The AI wave is still building, but the future has been slower than anticipated. Today only 5.5% of identified AI use cases are in production, a sobering reality check on respondents’ Q1’24 projection that 52% of identified use cases would be in production over the next 24 months. 

As Benedict Evans put it "the future can take a long time."

My point is not to dampen the enthusiasm, but to make the timeline more realistic and, thus, the chances of success much higher.

In enterprise software, sanity is valuable because it introduces stability and reliablity. I'm not sure I want my bank working at break-neck speed, applying new ideas this way and that before figuring out what works and, even, what's valuable for me. As with any highly regulated business, I want to trust my bank, and that trust comes from knowing they're operating in a consistent, proven way. I want my bank to be a lot more sane than whatever services I use to share pictures of my sandwiches or listen to Yacht Rock.

There's years of AI-driven benefits in our future, especially in large organizations and businesses. AI stuff could, indeed, be a silver bullet: something that didn't previously exist that lets us solve problems faster and cheaper, and even better than what we previously had.

But, how you achieve those goals is likely immune to silver bullet dreams. This is especially true when it comes to applications. The practice of creating, evolving, and maintaining good applications will remain the same as they were in the pre-AI era. If we mess around with and ignore those practices, just as we found out when Kubernetes up-ended all the progress we made with PaaS, we'll have to start all over again, losing time, progress, expertise, and trust.

In the enterprise, just like the rest of the world, great ideas are a dime a dozen, in a good way: there's lots of options for improvement. In a large organization, three hurdles stand in the way of transforming good ideas into code and ultimately into production: (1) neglecting product/problem fix, (2) "politics" due to silo-defending cultures, and, (3) fear of releasing due to lack of trust in resilience, reliability, and sometimes cost.

When enterprises try to spin up AI projects, these three barriers will come into effect just like they would any new IT services. Let's look at each.

Most IT projects fail because of neglected product/problem fit 

I'm sure you've used many applications and thought "do the people who build this software actually use it?" That's the first layer of the problem: the app is poorly designed and doesn't actually help the people using it do their job better. The second is that the application is just solving the wrong problem. "Wrong sounds" judge-y. What I mean there is that there were better problems to solve first. Of more vexingly, better ways to solve the problem. 

AI projects will have to solve this product/problem fit. Worse, that product management labyrinth is even more dangerous when it comes to hot new technologies because we get so torqued up that we lose sight of basics. We assume that these new silver bullets will remove the need for all that tedious process stuff we’re currently putting up with. 

I like how Jürgen Geuter put it recently: 

[W]ith every new technology we spend a lot of money to get a lot of bloody noses for way too little outcome. Because we keep not looking at actual, real problems in front of us - that the people affected by them probably can tell you at least a significant part of the solution to. No, we want a magic tool to make the problem disappear. Which is a significantly different thing than solving it. Because actually solving a problem includes first fully understanding the reasons for the existence of the problem, reasons that often come back to an organizations’ structure, their – sometimes inconsistent – goals and their social structure in addition to actual technical issues.

The antidote for this is consistently applying product management. Well, applying it at all for most enterprises.

Product management brings a cool-headed approach to all that "magic." The good news is that product management is one of the more understood, more developed and real-world tested software practices out there. And, if you follow the frequent weekly or fortnightly release cycles that people who follow the Tanzu Labs model do, you introduce a data-driven method of planning and improving your apps. I've seen this done at numerous large enterprises. You can read more about it in my book Monolithic Transformation and the Tanzu Labs Product Manager Playbook.

Culture

To me, "politics" is whatever noise, sandbagging, and (selfish) behavior people in an organization do that prevents you from doing "the right thing." No one likes "politics": it's always bad. Otherwise we'd just call it "work." It's grit in the system, often put there by other people in your organization who want to protect what they have, hoard budget and the rewards that come with success.

For the most part, it's not so much the grit-throwers fault, but management's fault for setting up and sustaining the system to work that way. People are rational, they figure out "the game" and play it.

When it comes to initiatives like the magic of AI, politics shows up in maximum force. People either want to hoard the benefits and attention, or they want to defend themselves. Is it taking a long time to get access to the infrastructure you need to run AI models? That's probably politics. Are you trying to find time for yet another meeting to get access to the manufacturing quality data you need? I bet it's "politics."

The fear that AI will eliminate jobs will compound this problem even more: people will be reluctant to give you access to their data to automate analysis because "then, what will I do?" After all, employees rarely get the benefits of “productivity,” speeding up work by 20% doesn’t mean workers now get Fridays off.

There's absolutely nothing about the magic of AI that will solve these culture problems. To adapt what one of my team-mates once said: "AI will not fix your broken culture."

Solving culture problems is difficult, but, again, we have decades of experience learning what works and doesn't work. There's a lot of "it depends'ing" to it, yes. But, as with product management, that's why you start with a system and rigorously apply it.

Lack of trust in process and platforms

I mentioned that I want my bank to be sane. This is because, you know, they have all my money. If that money just disappeared overnight, my life would get very difficult. It'd be a major bummer!

The financial sector hasn't exactly behaved rationally during my years as an adult, and there's a whole generation of people who were born into bad financial times. That is, banks have earned that need for trust. 

Similarly, IT has earned a need for trust. Just as with banking, in aggregate, things are fine. I still have all my money after all these years! And, IT keeps running businesses. But, when big problems happen - delays, growing budgets, ineffective apps, and security breaches - all of IT gets blamed. People forget how valuable most all IT is. In short, IT needs to constantly win and maintain the business’ trust.

When it comes to software, this lack of trust feeds delays by adding in endless governance and process. But it also injects fear into the people doing the work. If things go poorly, if we're not 100% correct and successful, we will be punished. For applications, this means you have a bias towards taking fewer risks. For organization, this means you're afraid of releasing your apps. 

It all comes together in a cultural malaise - a fog of timidity and lethargy that stifles innovation, slows down decision-making, and encourages risk-averse behavior. Here again, the people are acting rationally within the system that management has built and continues to maintain, if only through neglect.

In applications, the first step to solving this malaise is to get a reliable, proven platform in place, changing how operations works to be the product managers of that platform. The second step is to change how developers write applications to take advantage of that platform.

This is where platforms and platform engineering come in. I'm, you know, reticent to hand over the torch from DevOps to platform engineering - the PE crew has done a good enough job just swiping it - but platform engineering has a lot going for it when it comes to building trust. Of course, you need a platform too - culture without technology is just delightful conversations.

What I'm talking about here is a baseline of trust in application development and platforms, nothing to do with AI. But, AI will need that same amount of trust. And that trust will come from being "just another service" in a reliable platform. You're not going to want AI to exist on its own as a weird service held together by newly typed up python, you'll want it supported by platforms relying on the same old, boring but “enterprise grade” components that run the world day in and day out.

This means putting in place the SRE-smells in platform engineering, the product management in platform engineering to make sure the AI services are useful and used by developers, and then the actual platform stack itself, hopefully one that you didn't just paste-pot together out of parts.

People probably trust AI now because it seems like magic, because they haven't used it day-to-day to know how finicky it is, and because not many AI apps have been put into production yet. But, as with any new software, the more it’s used, the more you'll notice the failures and start to build up mis-trust.

We know how to run, program with, govern, and secure any old type of "service," and I don't think there'll be much different with AI services if we treat them as such. You need an AI platform strategy.

How to eat silver bullets

Does this seem to slow? Unrealistic in the face of boards and CEOs hungry for those AI silver bullets? It can, and we see this over and over. You can achieve those stupendous results, but your biggest problem is going to be figuring out what exactly to do and how to organize your teams to do it.

If you have those parts right, you've got a good chance of getting that AI magic. You'll certainly have a better chance than people who follow the fire-aim-ready approach to strategy. Seemingly contradictory, the most important thing is to start right now: assess your software capabilities. Do you have product managers? Are you able to release software every week or two to actual users? Can you gather feedback about what works and doesn't work so you can refine your app? Maybe you can, but most organizations don't have the basics of that loop in place.

Adding product-thinking and frequent releases to your organization and culture takes a long time, but it will take even longer if you don't start. Put that in place, and then you'll be on your way. Set realistic expectations and then you'll benefit from another theory of applying IT magic to your business: "Most people overestimate what they can do in one year and underestimate what they can do in ten years."

I’ll be in two talks on these topics next month at Explore in Barcelona, November 4th to 7th.

I’m really interested in a panel I’m moderating with a platform engineer from Mercedes-Benz, Benni Miano, and what I’m going to call our chief AI architect (in Tanzu-land), Adib Saikali. I’ve been really bored with enterprise AI for awhile, and talking to those two has gotten me interested in again. Adib had some interesting thoughts on roles and responsibilities in the enterprise AI stack.

There’s another one on platform contracts that I’m helping out with. It’s based on some work that we’ve done with NatWest to get developers to shift to cloud native applications - that whole point above of changing how your developers work to take advantage of your platforms.

And, of course, there’ll be all sorts of talk about how we think about adding AI to your platforms. Plus, Barcelona in November - what’s not to like! Check out the two talks, and tell me if you’re coming.

Logoff

I’ll save up the links and weird finds for next time. If you’re into my experiments using generative AI to play solo Dungeons & Dragons, here’s a new technique I’m working on and recommend.

The Deep Dive crew [adds commentary to hitting the snooze button a lot](https://newsletter.cote.io/p/the-curious-case-of-the-strategic).

Here’s the text I gave it, a narration of waking up in the morning, rather, not waking up:

Well, I woke up at the time you woke up about 6 AM, and I thought I shouldn't get up now so I played a game a little bit. And then I went back to sleep. And then my alarm went off, which is about seven, and I hit snooze and went back to sleep. And then my alarm woke me up again, and I thought, “well I'm gonna get up now,” so instead of pressing snooze, I pressed stop. And then I went back to sleep. Then you came upstairs and you woke me up and I got up.

“This whole snooze button saga…it’s…it’s a JOURNEY.”

The recording of one of my talks has 8,400 views. That’s a lot more than other talk recordings. How does YouTube work, I sure don’t know!

Confusing it more is that the same talk given at a different conference has 85 views. At least I wore a different shirt each time.

Oh, and while I’m promoting myself, here’s my lighting talk (5 minutes) from DevOpsDays Antwerp pondering if DevOps is successful.

Internship

My nephew, Caleb Marques, is looking for an internship in IT and would love to join a great team. He's studied all the thrilling IT stuff at Texas A&M: Unix sysadmin'ing, cybersecurity, networking, python, Business, and all that kind of stuff. He graduates in August 2025 and needs an internship to finish up his business and cybersecurity degrees. He'll move where ever, so location is not a problem. Tell me if you're interested, or know someone who's got an IT, especially security internship. He's fun too! :)

Relative to your interests

• Developer Relations Foundation Aims to Clarify Role - Hopefully it’s good for enterprises too, big organizations that need internal-facing devrel.

• California Becomes the First State to Ban Sell-By Dates on Food Labels - I think we all knew these were bullshit. // “Sell-by dates are a slightly ironic, and unnecessary, cause of food waste, because they’re not intended to ever be used by consumers. Instead, these dates are meant to indicate to store employees when stock needs to be rotated, and are not accurate representations of freshness or consumability.”

• Viktor Farcic: There is no such thing as a DevOps engineer - Platforms bundle services developers use to make it easier and faster for them. // Viktor’s platform engineering definition: “In practice, certain experts are codifying their experience into services. Hence, if you’re a database administrator, you’re an expert. Instead of waiting for somebody to ask you to create a database for them or to configure it, you can codify that knowledge, transform it into a service and plug it into that platform so that everybody else can do it themselves instead of asking you to do things for them. Click a button, fill in some fields, and create some YAML; whatever the system is, should be the mechanism for others to create and manage that database without you. And you should focus on managing those services instead of managing requests from people to do something.”

• Continuous Authorization to Operate (cATO) needs a DevSecOps platform - This is written in US Federal government speak, but the same benefits apply to commercial enterprises. If you use a centralized PaaS for your apps instead of customized infrastructure per each app, you can certify the layers below the application as compliant to use. Then when you put new all code on it, you only need to certify a thin layer of new code. The more traditional alternative (a customized infrastructure stack per app) means you have to certify the whole stack for each new app version. That takes a lot more time than the wafer thin layer of app.

• Departure Mono - This font from Tobias Fried, Departure Mono, is amazing. Well, amazing if you remember dot-matrix printers and the screens in the Aliens movie. What’s even more amazing is the website: be sure to scroll and keep scrolling.

• Parents' Earnings and the Returns to Universal Pre-Kindergarten - “parents work more hours, and their earnings increase by 21.7%. Parents' earnings gains persist for at least six years after the end of pre-kindergarten. Excluding impacts on children, each dollar of net government expenditure yields $5.51 in after-tax benefits for families”

• Cave Oak - Wow! This is fun.

• Writing Examples - Good for itself, and probably good for instructing The AI.

• Desperately seeking AI ROI as IT budgets tighten - ”As we show above in red, at least 44% of the respondents indicate that gen AI is funded by stealing from other budgets. We’ve seen that number hover around 40% to 42% in previous surveys, and it pops up to at least 55% in the Global 2000.” // Also, one tactics for general IT cost savings is vendor consolidation.

• Sorry, GenAI is NOT going to 10x computer programming - People have been using generative AI to help with coding for a couple years now. Is it making 10x developers? This guy tries to make the excitement more realistic by pulling together research on the topic.

• How to Choose the Architecture for Your GenAI Application - I should read this!

Wastebook

• “Today I am the man in seat 61 on the Eurostar from Paris to London.” Here.

• “It’s clear they’re not used to halflings wandering into their midst, offering strange pockets of extradimensional comfort.” ChatGPT in D&D mode.

• “Not sure when I started eating like a country hermit.” Here.

• “salt libertarians” Here.

Conferences

Talks I’m giving, places I’ll be, and other plans.

If you’re going to explore, be sure to pre-register for my two sessions. It helps! Check out all the poop at cote.pizza.

VMware Explore Barcelona, speaking, Nov 4th to 7th. GoTech World, speaking, Bucharest, Nov 12th and 13th. SREday Amsterdam, speaking, Nov 21st, 2024.

Discounts! SREDay Amsterdam: 20% off with the code SRE20DAY.

Logoff

I’ve been at CF Day in Karlsruhe, Germany. It was great seeing the CF people. There were some great talks, especially on the topic of Cloud Foundry and Kubernetes co-existing in a useful way. They’ll be up on their YouTube channel sometime soon. Also, there was a live recording of Cloud Foundry Weekly, available now.

No travel until Explore, which I guess is actually soon-ish. Hopefully that means I’ll get some content out.

Here’s some good advice on how to eat Dutch food:

(I actually like stamppot a lot, and, now that I think of it, I’m not really sold on hot pot yet. But, you know: ha hah. Good one.)