For your enterprise AI projects, what you want now is resilience. I’m using that term from a paper called “AI as a Normal Technology." There, resilience means " taking actions now to improve our ability to deal with unexpected developments in the future.” There’s a lot of great thinking in that paper, but I want to narrow it down to what management at companies should be doing with AI-driven projects and strategies.
What these executives should do now is put in places systems, policies, and tools to explore, learn, and then apply AI. The system they use should have less to do with building AI capabilities and platforms, and much more to do with coming up with uses for AI. They should experiment with ideas and apps, not build infrastructure and platforms.
This is because we don’t really know what AI is useful for in most organizations - we don’t know what “normal AI” looks like.
We do know some AI uses that are good: code generation, chat-based text, text manipulation, and “better search.” There’s of course all sorts of little, situational uses across industries. We’re in an unknown state, and that’s why we need this “resilience.”
In IT, “resilience” means something more technical: the ability to recover with minimal loss of time or damage. (And, sure, it also means gardening the sociotechnical system that allows for that, “culture,” etc.)
That’s not exactly what “resilience” means in here. You could pull from past enterprise-speak and say it means “learning organizations.” For the purposes of AI projects, thinking in terms of product/market fit and “lean startup” are helpful phrases too.
We last applied these concepts to enterprises in the digital transformation era of the late 2010’s. And it worked out well! Have you seen how good software from governments and banks are now compared to 2013? The urgency to build new apps during COVID proved that enterprises can do good, at least capable software very quickly.
This process uses constraints and boxes to experiment and move forward. The main tool is developing applications or standing up new services, writing software. For each “project,” you come up with a theory of what the customer or end-user needs. You then come up with a theory of how to solve it with software; for example what features to put in an app. You write the code, deploy it, and then observe how the person uses the software, comparing it to the outcomes you thought would happen. Then, you feed that back into the next cycle. You try to do this in one or two week cycles, maybe a month at most.
What’s important here is that you’re learning along the way. Whatever process they follow, few people would say they’re not learning, of course. But most projects are delivered once and done. You write out what you want the app to do, you code it, you deploy it, people use it. You only modify it if there’s bugs.
In the learning approach, you’re not settling on anything for sure early on, and you’re trying different things. You might even use “progressive delivery” to try different features with different clusters of customers.
You want to do this with AI now because we don’t know all of the uses inside organizations.
We also don’t know all of the “day two” concerns - what it’s like to operate, run, and maintain those new AI-driven apps over three, five, even ten years. These “day two” things are where the unaccounted for costs and risks of most IT projects are.
The mechanics of all of this are well know, and tested in that era of digital transformation. I wrote about this mindset in three booklets during that time (most of them are free now). Everyone was writing about this approach to software.
What executives trying to figure out AI need to do is return to that mindset and method. They need to shift their organization over to that way of thinking.
I argue that we’ve lost focus on that attention to resilience, learning organization, product/market fit.
Enterprises don’t focus on “apps” as much as they used to. Instead, it’s often all about optimizing by lower costs, building new platforms and stacks, moving to cloud and then back to on-premises…
This isn’t “moving chairs around on the deck of the Titanic” - business has been going well in recent years. The metaphor for how IT’s been operating is more like annual house redecorating. You change things around - sometimes dramatically - but end up with the same rooms and house and activities you do at home. That is, you have the same activities and “business outcomes.”
For example, there’s a good chance your organization is doing the opposite cloud strategy you were doing 3 to 5 years ago. If you were going to public cloud, now you’re considering what to keep and bring back to on-premises. If you’ve been on-premises the whole time, you’re launching a plan to migrate to cloud. Did you just finish building out your Kubernetes stacks so that you can hand out clusters and namespaces to developers on-demand? Now you’re looking to make your Kubernetes fleets more developer friendly with a platform, probably by hiding Kubernetes from them. You want something more like Cloud Foundry or Kratix. Do you have a platform that developers love using and that is “boring”? Now you’ve got a mandate to move to the industry standard of Kubernetes.
This redecorating the data center has to stop if you’re going to take advantage of AI. You need to lock-down whatever your stack is instead of moving it around. You’ve got to make sure your stack supports following a resilience-driven strategy.
The primary thing you want your platform to do is help you enforce some simple principles: self-service access for developers, built in security and control of data access, brokering access to AI services instead of directly accessing them, monitoring performance and usage, and so forth. These are basic things and, again, well understood.
There’s so much more to say - check out those books! - but here’s a short-cut. When you’re discussing what to do with AI, if someone suggests building a system or a platform, ask them why you can’t just use what you already have. Challenge them to outline what doesn’t work with the numerous platforms and stacks you’re already using and paying for. We have so many platforms and stacks in place already. You probably have two or three that will work just fine - maybe they need to be updated to the latest version or configured slightly differently.
Instead of talking about building infrastructure, shift the conversation to what infrastructure needs to do to support this resilience, learning mindset. Always bring it back to “how is this going to help us learn how to use AI to run our business better?”
Related: why not TryTanzu.ai?