40 Years of IT, Change, Complexity… and Why It’s Time to Turn the Page
I’m a Jimmy Buffett fan, and one of my favorite songs has always been A Pirate Looks at Forty. It’s a song about looking at where you’ve been, how the world around you has changed, and maybe wondering a little about what’s coming next.
Well, I’m not much of a pirate, but after 40 years working in the IT industry, I thought it might be time for a chorus of, A Flook Looks at 40.
When you’ve spent four decades in tech, you learn a few things. The first is pretty obvious: Technology changes. Constantly. Usually, right after you’ve just figured out how the last “game-changer” was supposed to fix everything.
When “Connected” Meant Something Entirely Different
My first job was with Lee Data Corporation out of Minnesota. We installed what were called controllers, which allowed our terminals to communicate with IBM, DEC VAX and HP mainframe systems. The key word there is allowed, because you could only connect to one system at a time. Moving information between systems wasn’t exactly seamless either.
I remember people logging into one system, running a report, printing that report, logging into another system and then manually typing the information from the printed report into the second computer. Think about that for a second. That was data integration. Human middleware.
Then networking began changing everything.
I also remember working in General Motors factories where we installed 50-meter sections of Thicknet Ethernet cable. And when I say thick, I mean thick. There were no RJ45 patch cords running from every device back to a switch. To connect a device, we physically tapped into the shared Ethernet cable using something with one of the greatest names in networking history: a vampire tap.
Devices shared the same physical Ethernet segment and relied on CSMA/CD—Carrier Sense Multiple Access with Collision Detection. In simple terms: listen before transmitting, transmit if the wire is clear, detect a collision, back off and try again. It sounds primitive today, but it worked.
Then we turned the page.
In 1994, I installed my first Ethernet switch, an ODS switch. Coming from shared Ethernet, switching was a big deal. Over time, Thicknet gave way to Thinnet, twisted pair, hubs and switches. Routers connected networks. Switching, VLANs and faster Ethernet transformed the LAN. Wi-Fi changed how we connected users and devices. Then came virtualization, cloud, SaaS, SD-WAN, Zero Trust, and now AI.
Turn the page. Turn the page.
I’ve been in this industry long enough that some of the technologies I once installed are now museum pieces. That’s what this industry does.
Token Ring, FDDI, ATM, Frame Relay, ISDN, AppleTalk, IPX/SPX, Thicknet, Thinnet and WEP all had their day. At one point, each solved a real problem. They had engineers who knew them inside and out, training programs, certifications and sometimes entire careers built around them.
And eventually, we turned the page.
That’s one of the most important lessons 40 years in this industry has taught me: Don’t fall in love with the technology. Fall in love with the problem you’re trying to solve. Technology changes. The problem usually doesn’t.
A Few Things I’ve Learned Along the Way
Not all the lessons over the 40 years have been technical. If I could sit down with the younger version of myself, I’d tell him to put family first. There will always be another meeting, project, customer and quarter. There won’t always be another Saturday with your kids.
I’d tell him not to unnecessarily make enemies. The IT industry is a lot smaller than you think, and the person sitting across the table today may be your customer, partner, coworker—or boss—ten years from now.
I’d also tell him to get comfortable being uncomfortable. Change is coming whether you like it or not.
Most importantly, I’d tell him to learn when to turn the page. I’ve watched some very smart people spend enormous amounts of energy defending technologies and architectures that the industry had already begun leaving behind. The biggest career mistake isn’t failing to know every new technology. It may be spending your career defending the old one.
Which brings me to something I’ve been thinking about lately. After watching IT turn page after page for 40 years, is there one really important page we still haven’t turned?
The Enterprise Network: The Page We Haven’t Yet Turned
Think about what’s happened around the network during the last four decades. Mainframes gave way to client/server computing. Physical servers became virtual machines. Virtualization moved to the cloud. Applications became SaaS. Traditional telecom gave way to VoIP, unified communications and collaboration. Storage transformed. The WAN transformed. Security transformed. Now AI is beginning to rewrite the rules all over again.
We’ve modernized almost everything that uses the network. But what about the enterprise LAN itself?
Look at how many enterprise networks are still built and operated: switches, VLANs, Spanning Tree, ACLs, 802.1X, NAC, firmware, controllers, configuration files, compatibility matrices, software upgrades, EOL/EOS cycles and trouble tickets.
Wait a minute. I was doing some of this 30 years ago.
Certainly, we’ve made networks dramatically faster and more capable. We’ve added automation, improved management tools and layered increasingly sophisticated security technologies around them. But fundamentally, much of the operating model remains surprisingly familiar: buy the boxes, install the boxes, configure the boxes, manage the software, maintain compatibility, upgrade everything and eventually replace it when the manufacturer tells you it’s reached end of life.
When something breaks, one of the first questions from technical support is inevitably some variation of, “Tell me about your network.” After decades of individually designing, configuring and integrating these systems, nearly every enterprise network has become its own unique snowflake.
Maybe the next big networking innovation isn’t another faster box. Maybe it’s changing the operating model itself.
Connect First. Secure Second. Wrong.
Security has also changed dramatically during my career. In the early days, network security could literally mean controlling who had physical access to a network port. As connectivity expanded, we added firewalls, encryption, WEP, WPA, 802.1X, NAC, ACLs, segmentation, microsegmentation and eventually Zero Trust.
All of these represented important advancements, but for much of networking history we’ve followed roughly the same sequence:
Connect → Configure → Secure
First connect the device, then determine what it is, configure the network to determine what it should access, and add the controls necessary to secure it. Every new requirement often meant another configuration, another policy, another product, another integration or another dependency.
Over decades, that adds up: more devices + more software + more configurations + more integrations = more operational complexity and a larger attack surface.
So what if we reversed the thinking? What if security wasn’t something we added to the connectivity layer? What if security was an inherent property of the network itself?
Maybe It’s Time for a New Book
For 40 years, I’ve watched us turn page after page in the book of networking: faster Ethernet, faster Wi-Fi, new switches, new controllers, new security products, new management platforms, new software versions, new configurations and certainly plenty of new acronyms.
Maybe it’s time we stopped turning pages in the same book and picked up a new book.
That’s one of the reasons I find what we’re doing today at Nile so interesting. Nile wasn’t created simply to build another Ethernet switch or wireless access point. It starts with asking a different question: Why should customers have to build and operate enterprise networks this way at all?
Why should networking require so much specialized labor? Why should the customer own all the operational complexity? Why should security be something we add to the network after the fact? Why should software and hardware upgrades introduce risk? Why are EOL/EOS events the customer’s problem? Why does every enterprise network need to become a snowflake?
And perhaps the biggest question: Why can’t enterprise networking operate more like the cloud and SaaS services we’ve adopted everywhere else in IT?
There’s a quote I like: “Those who know how will always work for those who know why.”
For much of my career, I lived in the how. How do I configure the protocol? How do I build the VLAN? How do I troubleshoot Spanning Tree? How do I configure the WLAN? How do I integrate NAC? How do I upgrade this environment without breaking something?
Knowing the how mattered then and it still matters today. But increasingly, I think we need to spend more time asking why.
Customers don’t really want switches; they want connectivity. They don’t want NAC appliances; they want access security. They don’t want dashboards filled with alarms; they want assurance that the network is working. They don’t want to manage upgrades; they want availability. They don’t want complexity; they want outcomes.
That’s a very different way of thinking about enterprise networking.
The traditional model has often looked something like:
Connect → Configure → Secure → Monitor → Troubleshoot.
Network-as-a-Service gives us an opportunity to rethink that model:
Secure → Connect → Automate → Assure. Or even more simply:
Secure First. Communicate by Policy.
Rather than adding security after the network is built, security is built into the network from the start. Rather than customers buying boxes and accepting responsibility for integrating, configuring, upgrading and operating them, the network can be consumed as-a-service. And rather than measuring success by whether individual components are “up,” we can focus on whether the network is actually delivering the business outcome it was intended to deliver.
When I think about this next chapter, I keep coming back to five things: Secure, Simple, Service, SLA and Scale. And if you picture those five S’s surrounding one central idea, that idea is Outcomes.
Because ultimately, that’s what customers are paying us to deliver.
A Flook Looks Forward
After 40 years in technology, I’ve also learned to be skeptical whenever someone says, “This changes everything.” I’ve heard that one a few times. A new architecture is only interesting if it actually works in the real world.
That’s what makes this chapter particularly interesting to me. The Network-as-a-Service model isn’t just an idea on a whiteboard anymore. It’s being deployed in real production enterprise environments across industries and geographies. Like every technology transition I’ve watched during my career, eventually the conversation progresses from “That’s interesting” to “Does it work?” and ultimately to “Why aren’t we doing it this way?”
So what do I see when I look back at 40 years in IT?
A lot of change, a lot of acronyms and a few technologies I’d probably rather forget. I apparently also have enough obsolete networking knowledge in my head to make me dangerous at a technology museum.
But mostly, I see an industry that has never stopped reinventing itself.
I’ve watched technologies we thought would last forever disappear and entirely new industries emerge. I’ve watched computing move from the data center to the desktop, back to the data center, into the cloud and now increasingly toward AI.
And I’ve learned not to get too attached to how we do things today, because change doesn’t particularly care whether we’re ready for it.
After 40 years, I’m still excited about what’s next. And I think enterprise networking may be approaching one of those moments again.
We can keep adding pages to the networking book we’ve been writing for decades—another box, another feature, another configuration, another management platform, another security product, another upgrade and another acronym.
Or maybe it’s time for a new song book.
Forty years in IT has taught me a lot of things, but perhaps the most important lesson is also the simplest:
Know when it’s time to turn the page. And sometimes, know when it’s time to put down the old book and pick up a new one.
I have a feeling the next bestseller in networking is already here. It’s called Nile.
Learn More
