Mike — Thinking Out Loud...
Welcome to Mikeland, a small corner of Prescher.com where experience meets unfiltered perspective. After years of advising leaders on complex strategic and operational network and cybersec challenges, Mike uses this space to unpack what’s really happening behind the buzzwords — what works, what doesn’t, and what actually moves the needle. Whether you’re a founder, owner, operator, or curious observer, here you’ll find practical insights, sharp opinions you can put to work in the real world.
Does Ai Belong in Critical Infrastucture?
Within my teams I'm well known to prefer to stand on the shoulders of giants, and there are plenty of technology and standards giants out there to help us do our work. NERC CIP SITES groups are one we like to follow, closely as they tend to lead critical infrastructure environment thinking on secure communications. I had a chance to read the latest draft of NERC's AI/ML paper and it's about what I expected — a careful patient approach to introducing Ai/ML in to the North American grid systems. This is as it should be. The take-a-ways from this good work, in my own words (not theirs) are: Key Takeaways: — Establishes an AI/ML maturity model for electric utilities spanning experimentation, operational decision support, and bounded autonomy. — Reinforces that organizational accountability never transfers to AI. Utilities remain responsible for all outcomes. — Strongly prioritizes reliability, cybersecurity, data quality, governance, and workforce readiness above automation ambitions. — Promotes decision support and human-in-the-loop architectures as the near-term practical path for grid operations. — Identifies autonomous and agentic grid operations as possible future states, but only with extensive validation, regulatory acceptance, and cyber controls. For potential EPC Impact (Design, Build, Secure, Optimize): — Design: Increased demand for AI-ready OT architectures, data pipelines, observability, time synchronization, deterministic communications, and edge computing platforms. — Build: More projects will require integration of AI capabilities into EMS, ADMS, DERMS, cybersecurity, asset-management, and operational analytics environments — Secure: AI systems become new critical assets requiring segmentation, monitoring, validation, supply-chain scrutiny, and protection against model manipulation and data corruption. — Optimize: Creates opportunities for predictive maintenance, anomaly detection, operational decision support, outage response, and workforce productivity improvements. — Consulting/Governance: Likely drives demand for AI maturity assessments, cybersecurity assessments, OT . architecture reviews, AI governance frameworks, and compliance advisory services
Knowledge Sharing — Learning to Drive
The only way modern critical infrastructure can be sustained is if their teams (the Human Factor) keep pace with the rapidly changing technology which drives it. This is even more true if you've read another opinion on this page regarding NERC CIP's vision on Ai/ML's rapidly evolving impact. Humans are essential to the resilience and reliability equation. A “Front Seat, Side‑by‑Side, then Back Seat” approach lets an OT network consultant guide a customer through new communications technology in a way that builds both confidence and capability. In the front seat, the consultant leads design, deployment, testing, and turn‑up, so the solution is architected correctly and aligned with safety, reliability, and compliance needs from day one. Moving side‑by‑side, they co‑execute changes with the customer’s team, explaining decisions, documenting processes, and transferring practical skills while real work gets done. In the final steps, in the back seat, the consultant steps into a support and review role, allowing the customer to operate and evolve the network independently, but with expert backup when needed. This progression reduces risk, accelerates adoption, and leaves the customer with a resilient OT communications environment they truly understand and can sustain.
Why Boltzmann's Formula for Gas Entropy in a Vacuum Matters in OT Networks
I never really knew, (or understood) Boltzmann’s gas entropy in a vacuum formula, until I had been in the large-scale data communication network business for about a decade. Then a light bulb above my headed started to flicker on when I truly appreciate that complex systems...they break. It's not a question of if, just when. That's not good for critical infrastructure. The concept of Entropy offers a powerful mental (and actual) model for why some complex OT critical infrastructure networks may be destined to fail. Boltzmann’s determined that a gas in a vacuum naturally spreads out into all available space, moving from an ordered state to a highly disordered one because there are simply more ways for the system to be disordered than ordered. The same thing happens in large OT data communications networks - as we add more devices, protocols, data paths, routes, and privatizations and filtering, combine with normal OA&M moves, adds, changes...the “state space” of the network expands. There are far more ways for configurations, interactions, and failures to combine into chaos, or at least mal-functions states, than there are for everything to line up in a clean, predictable way. Over time, without strong constraints and oversight, operation standards and work QA, the network drifts toward higher “entropy”, more complexity, more hidden dependencies, and ultimately more fragile behavior. For critical infrastructure, that inevitable drift toward disorder is not just inconvenient — it’s dangerous. Increasing complex OT networks are harder to understand, harder to secure, and harder to recover when something breaks. That’s why we have to actively fight this natural tendency by simplifying and at the same time further hardening our designs and doing better knowledge sharing with our customer's operations staff. That means reducing unnecessary variation, standardizing architectures, limiting the number of allowed paths and behaviors, and designing with clear boundaries and deterministic behavior wherever possible, while keeping tight to published system requirements. And when something does break, fix it, correctly...don't patch it. By intentionally lowering the entropy factors of our OT communications—through simpler topology logic, well‑defined roles, and robust, testable patterns — we trade a little flexibility, and yes some points of 9's availability, because 20 paths provide more availability potential than 2, but at what cost? Because what we want is overall life-cycle practical reliability - not theoretical reliability. This is what makes for improvements in safety, and resilience in the systems that keep the lights on and the industrial world running.
Follow The Spec. And Your Data Communications Networks Won't be a Wreck!
The advent of Ai tools for and against data security are changing the network design landscape. Even so, most of the architectural and functional design for a given communications project has in fact already been done for us through a myriad of applicable standards, (e.g. IETF, IEEE, ISA/IEC, CISA, NIST, INL CIE/CCE, HIPAA, PCI, CMMI/C, C2/M2, NERC, ISACA, ISC2, SANS, COBIT, ITIL, PMI PMBOK, and ISO). I often hear from customers that there are in fact too many standards and frameworks out there for them to reference - and first they need help in selecting the right one(s). Certainly it is true that this over-abundance of guidance advising us, secure critical infrastructure data network design/build projects and their successful operation have the potential to self-define, if we let them. To elevate the prospect of creating a sustainable data communications system from a desired outcome to a certainty, remember… "Follow the spec. so your data communications systems won't be a wreck."
Schweitzer Engineering Labratories OT SDN — Fewer Knobs. Fewer Data Disruptions. Fewer Network Engineers!
I have recently had the opportunity to work with SEL's relatively new data network solution on a real-world grid project. This work was to replace a very complex legacy Multi-protocol Label Switching (MPLS) virtualized network where after many years of reliable service, entropy had invaded. The choice was to have rare and expensive MPLS senior network engineers refresh the existing infrastructure - or do something simpler. That something was SEL OT SDN. Here are my own classic data communications network challenges this solution helped address... Deterministic performance: It's funny, coming from years of Cisco Systems switch/route design engagements and way of thinking, as opposed to "More data paths equals more reliability". I quickly learned this is NOT the mantra nor philosophy for OT data network design. Rather, more paths equal more configuration knobs equals more complexity and feature code exposure (bugs) equals more fragility in the overall network. SEL OT SDN takes a more homogeneous (to OT owners/operations) approach. It enforces simple core data network principles including predictable latency and bandwidth, which is critical for protection, control, and real‑time monitoring in power and industrial systems. Stronger security model: Centralized control lets you strictly define which devices can talk, on which paths, and for what purposes, reducing attack surface and lateral movement. Simplified, centralized management: Instead of configuring dozens of switches one by one, policies and paths are managed from a single controller, making complex OT networks easier to operate. In my project, with a focus on knowledge transfer, we were able to hand-off OA&M for the solution to a group of EE grid engineers, NOT to a group of highly skilled data network engineers. This was perhaps the most impressive result (and lesson we learned) on this project. First time that's ever happened on one of my critical infrastructure projects. Built for critical‑infrastructure reliability: SEL designs for harsh environments, fail-over, and redundancy. They are the solution of choice for more than 50% of U.S. grid customers for protective relays. So the SDN fabric can maintain communications even during faults or cyber events. Ready for future grid and OT demands: As more IEDs, sensors, and analytics tools come online, SDN’s flexible, software‑defined paths make it easier to scale and adapt without constant hardware re‑engineering.
Next Up — Analog Resilience?
Read a good article from the BBC recently on a small trend of Analog Resilience and Security by Antiquity. Cute. The article wasn't focused on critical infrastructure but anybody in this space sees the parallels. U.S.critical infrastructure has dealt with this for years as it dealt with the transition to Smart Everything. The article made me revisit something common in many utilities today, avoiding expensive compliance regimes through data communications architecture manipulation. Couple this with the advent of Ai powered machine speed attack construction and...more soon.