Benko Blog

I've been thinking a lot lately about AI and what it means for the future of software development. There are people who use AI, and there are people who build AI. But there's another group that I think is going to be much larger, and potentially more interesting. These are the people who use AI to build software systems.

For years we've relied on specialized software engineers to translate business requirements into working applications. We gather requirements, design the solution, write code, test, deploy, and maintain it. Along the way we've developed entire professions around making sure these systems are secure, reliable, scalable, and able to work with the other systems in our enterprise.

Now AI is changing who can build those applications.

A business analyst, accountant, or operations manager can describe what they need to an AI tool and have it generate something that looks and behaves like an application. They may not understand C#, SQL, JavaScript, or how to build an API, but they understand the business problem they're trying to solve. And in many cases that's enough to get started.

Is this something fundamentally new? Or have we seen this kind of transformation before?

I think we have. And to understand where we're going, it's worth looking back at how we got here.

Remember When We Needed a DBA?

Back in the 1990s, relational databases were becoming the backbone of enterprise applications. SQL Server, Oracle, DB2, and other database engines gave us powerful ways to store, organize, and retrieve information. But working with those systems required specialized knowledge. We needed people who understood indexes, transactions, stored procedures, backups, security, and how to keep the database running.

Enter the Database Administrator, or DBA.

As enterprises grew, I would argue that the responsibilities quickly evolved into two important branches, one that focused on the database engine performance and the other on the application data. Where does customer information live? Which system owns it? What relationships exist between orders, customers, invoices, and products? How do we ensure data integrity when multiple applications need the same information?

This second group became increasingly concerned with data architecture, business meaning, and establishing a trusted source of truth. Both roles were important, but they were solving different problems. One made sure the database worked, the other made sure the information could be trusted.

Then Developers Started Taking Control

But working with DBA's acted as a brake as well, slowing down things and asking for additional review and approval before carving out the data structures much like a sculptor chisels stone. Does the data already exist? Who else uses it? Who owns it and ensure that a change in one place is reflected in all the others? The governance of the data was owned and managed by the people who owned the engine that stored it.

But as our tools and frameworks evolved, developers became more capable of working directly with databases the value of that central governance comes into question. Do we really need this? As the developer tools and languages evolved it became easier to work with data, with things like object-relational mapping, code-first development, and frameworks that could generate database schemas from application models.

Instead of sitting down with a database designer to define every table, column, and relationship, we could define our classes in code and let the framework handle much of the storage implementation. That was a pretty big deal!

With NoSQL, document databases, and cloud-native architectures we started questioning whether every application really needed to share the same relational database. Microservices took that idea further. Rather than having one enormous SQL Server containing data for every application, we could design smaller services that own their own data. Each service could choose the storage technology that made sense for its workload.

An order service might use SQL. A product catalog might use a document database. An event-processing service might use a distributed key-value store.

We were no longer limited by the size of a single database engine. We could scale services independently, distribute workloads, and let development teams make decisions closer to the problems they were solving. Of course, code-first, NoSQL, and microservices weren't all part of one coordinated evolution. They solved different problems and often worked together. But they contributed to a common shift.

Developers were gaining more control over how their applications stored and managed data.

And that created some interesting challenges.

Just Because You Can Doesn't Mean You Should

Think about what happened as applications started owning their own data. The customer service has a customer record. The billing service has information about that same customer. The shipping service needs an address, and the support system maintains information about customer interactions. Each service might be perfectly designed for the job it performs.

But what happens when the customer changes their address? Which system knows first? Which one is authoritative? How do the others find out? Or what happens when Finance and Sales have different definitions of an active customer?

Now we have a problem that isn't about SQL Server performance, indexing, or even which database technology we selected. It's about how our systems work together. We didn't eliminate the need for data architecture by making it easier for developers to create databases.

If anything, we made the architectural questions more important. We moved the responsibility for storing data closer to the application, but the enterprise still needed to understand what that data meant and how it related to everything else.

I think we're about to experience a very similar transformation with AI.

AI Is Doing for Applications What Code-First Did for Data

Consider a business user who needs an application to manage a departmental workflow. Historically, they might create a spreadsheet, build an Access database, use a low-code platform, or submit a request to IT. If the requirements were complex enough, a developer would get involved to build the application.

Today, that same business user can sit down with an AI development tool and describe what they want. "I need an application to track customer requests, assign them to team members, notify people when something is overdue, and provide a dashboard showing what's happening." AI can help create the user interface, define the data structures, write the business logic, and connect the pieces together.

With the right tools and deployment environment, that user may be able to produce something useful without writing much code at all. That's exciting! Think of all the ideas that never got built because there wasn't enough time, budget, or development capacity. We're lowering the barrier to creating software.

But here's where my database analogy comes back.

Just because someone can create an application doesn't mean they understand how that application fits into the enterprise.

Does it need its own customer database? Should it use information from the CRM system? Where do the business rules come from? Who is responsible for keeping the information accurate? And what happens when someone in another department asks AI to build something that does almost the same thing?

Are We About to Repeat an Old Mistake?

I've worked with organizations where different departments had their own databases, applications, spreadsheets, and reporting systems. Each solved a real business problem. Each had a reason for existing. But over time, the organization struggled to understand which information was correct, which system owned a particular business process, and how changes in one application affected everything else. 

We spent enormous amounts of time integrating systems that were never designed to work together. Microservices and cloud-native architectures gave us better ways to distribute those systems, but they didn't automatically solve the enterprise architecture problem. 

Now imagine what happens when creating applications becomes dramatically easier. Instead of needing a team of developers to create a departmental system, a business user can ask AI to build one.

And another.

And another.

We could end up with hundreds or thousands of independently created applications that work perfectly well on their own but have very little understanding of each other. The technology may be new, but the problem sounds awfully familiar.

So Where Does That Leave the Software Engineer?

I don't believe AI means we no longer need software engineers. I think it means we need to reconsider what we're asking them to do. The database evolution didn't eliminate the need for specialized expertise. It changed where that expertise was most valuable. As developers took on more responsibility for creating and managing application data, we still needed people who understood performance, integrity, ownership, and the relationships between systems.

Now AI is giving more people the ability to create software.

But creating an application and engineering a system that belongs in an enterprise are not necessarily the same thing. Maybe the biggest change ahead isn't how we write code. Maybe it's how we ensure that all the independently created applications and services actually work together.

And that raises some interesting questions.

• When anyone can create an application, who decides whether we need another system?

• Who owns the data, the business rules, and the relationships between systems?

• If AI builds an application, who is responsible for maintaining it when the business changes?

• And if writing code is no longer the defining skill of a software engineer, what is?

I think the answers will have a lot to do with the next evolution of enterprise software architecture.

In the next post, we'll look at what happens when everyone becomes a software builder, and why making it easier to create applications might make enterprise architecture more important than ever.

What do you think? Are we heading toward another generation of disconnected departmental applications, or will AI give us a better way to build systems that work together?

I'd love to hear what you're seeing in your own organizations.

- Mike

Imagine you’re handed a pile of bricks, lumber, and nails—no blueprint, no plan, no guidance—and told, “Build me a fortress that will stand for centuries.” You start stacking bricks, hammering boards. You hope your walls are straight, your gates secure, your ramparts high enough to repel invaders. You pray you remember every measurement, every joist placement, every bolt torque.

That… is how most organizations still build their cloud environments today. We hammer in security rules by hand. We patch servers one by one. We scramble to recover from failures without a guide. And when disaster strikes, the walls collapse like a house of cards.

Now, picture a different scene: You stand at your keyboard, you click run—and lines of code that you defined every server, every network, every firewall rule start running. You press Deploy, and in minutes your fortress rises, identical in every test environment, every region, every time. No guesswork. No finger-crossing.

• Consistency in Every wall is laid true to the requirements and design.

• Secured Every gate is reinforced with best practices and security guidlines in mind

• Every tower has a lifeline (backups and DR).

Your environment is no longer a fragile assembly of one-off changes. It is a living artifact, defined in Code, versioned in Git, peer-reviewed, tested like your application code.

Why You Can’t Afford to Wait

• Human Error becomes a myth: No more fat-fingered deletions or midnight firefights.

• Configuration Drift is dead: What you tested in staging is exactly what runs in production.

• Recovery is an automated heartbeat: Spin up the exact replica of your world in another region in minutes.

• Compliance & Audit happen by default: Every change is a pull request you can trace, review, and rollback.

• Cost Control is built-in: Tear down ephemeral environments the moment you’re done with them—no more orphaned servers quietly burning your budget.

This isn’t a “nice to have.” It’s the difference between surviving the next storm or watching your walls crumble.

The Forge: Tools of the Trade

• ARM Templates & Bicep: Native Azure blueprints with first-class support and modularity.

• Terraform: Multi-cloud sorcery that speaks the language of AWS, GCP, and Azure alike.

• Pulumi: Write your infrastructure in C#, TypeScript, or Python—turn your Dev skills directly into cloud metal.

Each of these is your blacksmith’s hammer, your crucible for shaping resilient infrastructure.

Call to Action — Five Minutes to Build Your First Wall
I’m asking for five minutes—a small investment for a giant leap in reliability. In five minutes, I’ll show you how to:

1. Define a simple network, a VM, and a load balancer in code.

2. Deploy it repeatedly, in any region, with zero manual steps.

3. Tear it down when you’re done, so you only pay for what you use.

By the end of that demo, you’ll see how IaC transforms your cloud from a labyrinth of one-off scripts into a codified, battle-tested fortress.

The choice is yours

You can keep building with mortar and guesswork. You can cross your fingers and hope nothing breaks. Or… you can forge your infrastructure in code, version it, test it, and trust it to stand against any siege.

Which would you rather have—sandcastles or stone fortresses?

Five minutes is all it takes. Let me show you the blacksmith’s forge. Let’s build something that lasts.

I recommended a video by Julie Ng, who has a blog and a video thing on YouTube you can subscribe to that provides some great information about containerization, kubernetes and Azure. The video is CI/CD Review - How DevOps in Real Life & Mature Organizations works | Julie Ng

Here's some tools and links from Julie's talk

• Automatic Versioning https://npmjs.com/package/standard-version 
  • Conventional Commits
  • googleapis/release-please: generate release PRs based on the conventionalcommits.org spec (github.com)
• Git Branching strategies 
  • https://nvie.com/posts/a-successful-git-branching-model/
  • https://guides.github.com/introduction/flow 
  • https://docs.gitlab.com/ee/topics/gitlab_flow.html 

I was watching the movie "The Right Stuff" over the holiday week and was impressed by how far we've come in terms of technology and using it to help us accomplish amazing things. From the story of Chuck Yeager chasing the demon in the sky limit of Mach 1 in the Bell-X1 to how they developed the Mercury project to launch space exploration, I loved seeing how the people and technology were used to make it possible. Of course there were mistakes, but without trying how do you learn? 

Doing things right is a mindset that is a requirement if you want to get in the game anymore. It's no longer good enough to think we can just show up and get paid, we have to provide value. The value of being willing and able to make decisions and try the impossible, by reaching for the sky we don't come up with a handful of mud. But is doing enough?

Doing Things Right

In the movie Apollo 13 we see Tom Hanks play Jim Lovell as the commander of the crew that experiences what can go wrong, and we see how the team responds to see if they have what it takes to bring them home. The challenge comes when one of the oxygen tanks malfunctions and damanges the return ship on their way to the moon. The drama plays out, but ultimately by thinking outside the box the team on earth comes up with ways to repair enough of the damage to bring them home.

Doing things right means having the right people in the right places there when you need them. Knowledge of what's possible, how to do things, what tools work for which jobs, all of these are important. Knowing how and when to combine the ingredients are what separates the star baker of the week from the one who gets voted off the island. It might mean finding someone who's done it before and knows the things to avoid. Doing things right is a whole lot easier than doing it poorly and doing it again and again.

For example, in the work that I do we're talking about containers and infrastructure and cloud. It is important to understand Docker and Kubernetes, as well as DevOps and Infrastructure as Code options like Terraform or Bicep. Doing things right means combining these tools to develop and deliver solutions where we follow sound project management practices. Whenever I come across a new project there's good questions to ask so you can get an idea of where things are at.

But Because you Can Doesn't Mean You Should

With that said, does the use of these tools and technologies mean success? Should we use containers and DotNet Core with WebAPI's? Should we use Agile and 2 week sprints with daily scrum meetings? We are putting together a team and it's going to go in and solve the challenge and keep the world safe for technology!

Sometimes we immediately prescribe an answer, using our best practices and ensuring we're using the right stuff to deliver value, but we fail to hear the requirements and understand the lay of the land. We kick off the project and by hook or by crook we drive the daily scrums and manage the sprints and work like crazy. We dedicate ourselves to the task at hand and make sure everyone participates. We deliver our solution, then realize it solves the wrong problem.

Do the Right Things

We fail to ask the right questions, so we end up doing the wrong things. Who is our team, and what is their experience? How much learning do we need to do to bring people up to speed? What is the timeline and who is the audience? The consultant's answer is it depends. Who do you ask? What is the vision and how is it related to the mission we're working on? Based on this are we ready to move on to new tools and technologies? Are we ready to make smart decisions that fit the reality we are in? 

As 2023 starts out it's apparent to me that we need to make time to reflect and give some space to think before we act. Doing is good, but sometimes not doing or doing something else is better.

This week in Las Vegas at the Agile DevOps West conference I'm presenting the session Permit to Cloud - Land with Confidence in Azure!

We'll talk about a lot fo things, but the goal is to provide an introduction to how to get started with Azure in a way that will help ensure continued success in taking advantage of the promises the cloud offers. For the code and demos I've published them to https://github.com/benkotips/askdad - Check it out!

Guess What? In person events are a thing again,  and I'm back on the road. It's great to be back to St. Louis, this week I'm delivering sessions at DevUp on how to work with Azure and Infrastructure as Code topics. 

• Permit to Cloud : Land with Confidence in Azure
• Cosmos DB Performance Tuning
• Infrastructure as Code Bake-off : Comparing ARM, Bicep, Terraform and Pulumi

The link to the code is on GitHub at https://github.com/mbenko/du22-ptc - Check it out!

Thinking about going to Cloud? I've been consulting around Azure for the last 8 years since I left Microsoft where I helped launch it in 2009. I want to offer my support, so I'm starting a thing called Azure Office Hours on Fridays, where anyone can block out 15 minutes to chat about anything Azure.

1. Find a time that works - https://bit.ly/BnkAzHrs 
2. Let me know what you want to talk about
3. Let's chat! 

I speak at conferences and have LinkedIn learning courses on Azure and DevOps including templating, compute, storage, messaging, networking and governance topics.

My calendar is open. Let's connect!