top of page

From SCCM to Superintelligence: What 20 Years as a Microsoft Architect Taught Me That AI Can't Replace

  • 7 days ago
  • 8 min read

I'll be honest with you. When I first read that Microsoft was bundling Copilot, AI agents, Entra, and Intune into a single $99/month SKU called M365 E7, my first thought wasn't excitement. It wasn't fear either. It was something more like the feeling you get when you're standing at a railway platform in Mangalore and you hear the Rajdhani approaching — you know it's coming, you know it's fast, and you know you'd better decide which side of the tracks you're on.

Two weeks ago, Satya Nadella quietly restructured Microsoft's entire AI organization. Mustafa Suleyman — the guy who was supposed to be the face of Copilot — got redirected to chase superintelligence. A former Snapchat executive is now running the show. And a senior Microsoft executive said something that, if you're in enterprise IT, should make your chai go cold mid-sip: "In the future, probably most knowledge work will be done by AI agents. A knowledge worker's main responsibility will be the management and upkeep."

I've been a Microsoft enterprise architect for over 15 years. I've spent more nights than I care to count staring at SMSTS.log files and ADFS error codes. I've built careers — mine and helped others' — on technologies that no longer exist in their original form.

So when people ask me, "Kiran, should I be worried?" — I don't give them the LinkedIn-optimized answer. I give them the real one.


Every Tool I Loved Eventually Died. I Didn't.

My career reads like a Microsoft product lifecycle document. Let me take you through it — not the polished resume version, but the version I'd tell you over a filter coffee.

The early 2000s — I cut my teeth on SMS 2003 and ghost imaging. You'd build a "golden image" on a reference machine, capture it, and push it across the network via PXE boot. Sounds simple, right? It never was. The Task Sequence would fail at step 47 of 82, and the error log would give you something wonderfully unhelpful like "0x80004005 — Unspecified Error." You'd sit there, cross-referencing timestamps in SMSTS.log like you were deciphering an ancient manuscript. I got very good at this. I was proud of being good at this.

Then SMS became SCCM. And everything I'd learned had to be relearned — but not from scratch. The muscle memory carried over. The debugging instinct. The patience.

The ConfigMgr years were my kingdom. OSD Task Sequences, compliance baselines, patch management, MBAM for BitLocker — I could build a deployment pipeline that handled driver injection across 15 hardware models, three continents, and 10+ languages, all triggered by a single collection membership change. When it worked, it felt like conducting an orchestra. When it didn't, it felt like defusing a bomb with a Nokia 3310 for a manual.

Then the cloud happened. Intune went from being "that MDM thing nobody took seriously" to a genuine co-management partner. Autopilot promised zero-touch provisioning. Azure AD Connect bridged two worlds that were never designed to talk to each other. I remember the first time I configured co-management workload sliders — moving compliance policies from ConfigMgr to Intune — and thinking, "This is either the future or the most elaborate way Microsoft has ever broken production."

It was both, honestly.

And now, here we are. Copilot is everywhere. 200,000 organizations are building their own AI agents in Copilot Studio. Microsoft is calling this "the era of Copilot execution." The tools I mastered? They're still running in data centers around the world. But the conversation has moved on.

Here's the thing nobody tells you about technology career grief: you don't mourn the tool. You mourn the version of yourself that was the expert. The person people called at 2 AM because nobody else could figure it out. That identity is hard to let go of.

But here's what I've realized, and it took me a while — the thinking survives every platform death. ConfigMgr Task Sequences taught me orchestration logic. Kerberos debugging taught me how trust actually works in distributed systems. Group Policy taught me layered inheritance models. Active Directory taught me that the topology is the architecture.

None of that dies when a product gets deprecated. It compounds.


The Night That Taught Me What AI Still Can't Do

I want to tell you about a specific night, because I think it matters.

It was 2 AM during a tenant-to-tenant migration. Cross-border acquisition — a European manufacturing company merging with a North American tech firm. We were in the middle of a cutover weekend. 8,000 mailboxes. Tight window. No room for error.

And then the hybrid Exchange connector threw authentication errors that didn't match anything in Microsoft's documentation. Not approximately didn't match. Literally not in the docs.

The runbook said: escalate to Microsoft support. Microsoft support said: 4–6 hours for a callback. The business said: 12,000 people need working email on Monday morning.

My hands were shaking a little. Not because I didn't know what to do — but because I knew the answer wasn't going to come from a knowledge base. It was going to come from pattern recognition.

Two years earlier, on a completely different engagement, I'd spent a miserable night debugging a Kerberos authentication failure. The root cause turned out to be a clock skew between an on-premises AD FS server and Azure AD. The token lifetime was off by just enough to cause intermittent failures that looked like something else entirely.

Standing in that war room at 2 AM, staring at the Exchange error, something clicked. The error signature felt similar. Not identical — different product, different context, different symptoms. But the shape of the failure was the same.

I checked the clock sync. Found a 7-minute drift on the AD FS server. Fixed it. The connector came back up within minutes.

Here's my point: Copilot is brilliant at analyzing logs against known patterns. It can scan documentation faster than any human. It can suggest next steps based on established knowledge. But it cannot reach across two years of unrelated experience and say, "Wait — I've felt this error before." That cross-domain intuition, that gut recognition that comes from years of living inside interconnected systems — that's not in any training dataset.

And then there's the other thing Copilot definitely can't do: read the CIO's face on the bridge call. That night, there was a moment when I could see him quietly calculating whether to pull the plug on the entire migration. Not because of a technical failure — because of a loss of confidence. The fix wasn't just technical. It was saying the right thing, at the right time, in the right tone, to keep a $200 million integration on track.

That's the judgment layer. And no, I don't think AI is close to replacing it.


Let's Talk About the Elephant in the Architecture Review Board

I need to say something that might be uncomfortable, but I think the AI era is about to make it painfully obvious.

In every large enterprise I've worked in, there are two kinds of architects.

The first kind has calluses. They've seized FSMO roles during a domain controller failure at 4 AM while someone from facilities kept asking them to keep the noise down. They've debugged ADFS certificate rollovers that broke SSO for an entire region. They've sat on 14-hour bridge calls during ransomware incidents, manually validating backup integrity one server at a time, sustained by nothing but cold Maggi and stubbornness.

The second kind lives in PowerPoint. Beautiful diagrams. Perfect TOGAF references. They attend architecture review boards and ask questions like, "Have we considered the enterprise-wide implications?" They haven't logged into a production environment since the Obama administration. Their authority comes from their title, not from the memory of having fixed something that was actually broken.

I'm not saying the second kind is useless. Strategic thinking has value. But here's what's about to happen: Copilot can now generate architecture diagrams, write TOGAF-aligned documentation, and produce reference architectures in minutes. The PowerPoint architect's primary deliverable just got commoditized overnight.

For the first kind — the ones who earned their architecture perspective through years of operational depth — AI becomes something entirely different. It becomes a force multiplier. You already have the judgment. Now you have a tool that handles the scaffolding, the boilerplate, the first draft, and the documentation. You're freed up to focus on what actually requires a human: the decisions that demand deep contextual understanding.

The AI era doesn't eliminate architects. It exposes who was actually doing architecture and who was doing presentation design.


"Cognitive Architect" Is Just a Fancy Name for What We've Been Doing All Along

Analysts are now predicting that IT professionals will become "cognitive architects" — people who orchestrate AI agents, design decision boundaries, and build governance frameworks for multi-agent systems.

With respect to the analysts — I've heard this movie's soundtrack before.

When SMS became SCCM, nobody called it a "paradigm shift in endpoint orchestration." We just learned the new console, figured out the new Task Sequence engine, and kept going.

When ConfigMgr met Intune, nobody said we were becoming "hybrid cognitive managers." We just opened a second portal and started moving workload sliders while muttering under our breath.

When Azure AD Connect arrived, identity architects didn't need a new job title. They needed a new understanding of how claims-based authentication works across hybrid boundaries.

Every time the platform shifts, the title changes, the conferences rebrand, and LinkedIn fills up with posts about "the future of work." But the underlying skill hasn't changed in 20 years: understanding complex systems and making them work together under constraints.

The constraints used to be hardware limitations, bandwidth, and network topology. Now they're governance policies, agent permissions, and data boundaries. But the thinking is the same.

If you've spent two decades learning how to orchestrate complex Microsoft systems, you're not starting over for the AI era. You're starting ahead.


What I'm Actually Doing About It

I'm not going to end this with five bullet points of career advice that sound good on LinkedIn but mean nothing in practice. Instead, I'll tell you what I'm actually doing — with all the uncertainty that comes with it.

I'm going deeper on identity. Not wider on tools — deeper on identity. In an AI-native enterprise, every agent needs an identity. Every action needs authorization. Every data access needs governance. Entra ID, Conditional Access, identity governance — this is the layer everything else sits on. AI agents don't run on hope. They run on tokens. And tokens are my language.

I'm learning to think in agents, not endpoints. Copilot Studio, Power Platform, the Model Context Protocol (MCP), Agent-to-Agent standards — this is the new infrastructure. It's being called the most significant convergence on an open standard in 30 years. I don't fully understand all of it yet. I'm being honest about that. But I understand orchestration, and that's the transferable skill.

I'm writing more. You're reading the evidence. For years, I kept my architecture thinking inside my head and inside client deliverables. That was a mistake. In an era where AI can generate the "what" in seconds, the "why" becomes your differentiator. Why did I choose this migration approach? Why did I split the identity boundary here instead of there? Why did I push back on the vendor's recommendation? That reasoning — that's intellectual property that no model has been trained on.

I'm making peace with not knowing. This is the hardest one. For 20 years, my value was in knowing — knowing the right cmdlet, the right registry key, the right workaround. In the AI era, the value shifts to judgment under uncertainty. Knowing when to trust the AI's recommendation and when to override it. Knowing when to automate and when to keep a human in the loop. That's a different kind of expertise, and I'm still building it.


The Real Question

Everyone's asking, "Will AI replace architects?" I think that's the wrong question.

The right question is: What will you build with the time AI gives you back?

When I look at the last 20 years, I see a pattern that repeats with every platform shift. The tools change. The titles change. The conferences change. But the people who thrive — are the ones who understood that every new layer is built on the foundations of everything before it.

The architect who debugged Kerberos at 2 AM is the same architect who will govern AI agent trust chains. The person who built ConfigMgr Task Sequences that worked across 15 hardware models is the same person who will orchestrate multi-agent workflows that span business domains. The skills compound. They don't expire.

Your 20 years aren't baggage. They're bedrock.

And if the platform shifts again in five years — which it will — I'll do what I've always done. Learn it. Break it. Understand why it broke. Fix it. And then help everyone else make the transition.

That's what architects do. That's what AI can't replace.

 
 
 

Comments


bottom of page