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
