Phison Electronics and the Future of AI-Native Infrastructure

What happens when an organization reports healthy infrastructure while weak data, hidden spreadsheets, and undocumented processes quietly increase its financial exposure? In this episode of IT Infrastructure as a Conversation, I speak with James Briers, Founder and CEO of Intelligent Delivery Solutions and creator of GovScape. James works where infrastructure, data, governance, and commercial reality meet. His argument is that governance has to move beyond policies, dashboards, and periodic audits if businesses want to understand their actual operating condition. James describes a recurring problem in professional services. Financial information passes through several systems, but inconsistent records leave finance teams invoicing too much or too little. Employees then spend additional time investigating discrepancies and manually reconciling the numbers. His proposed response begins with data integrity across those systems, followed by continuous monitoring that identifies issues before they affect billing. A person remains involved to validate the final result, but the repetitive reconciliation work becomes easier to manage. We discuss how continuous governance differs from a six-month or annual compliance exercise. James uses the idea of constant pruning. Rather than waiting for a large audit to expose a backlog of issues, teams can see smaller changes as they happen, assign responsibility, and correct them while the operational impact remains manageable. The goal is not another dashboard. It is an accurate view of the current state and a clear action for the person who owns the response. That information becomes far easier to discuss at board level when organizations translate governance gaps into commercial terms. James believes controls, risks, data quality, and unresolved issues should be connected with the potential cost to the business. This turns governance from a line on a transformation plan into a boardroom discussion about cash, risk exposure, and return on investment. Cloud migration is another area where good intentions can carry old problems forward. Moving unreliable data into a modern platform can produce a better-looking system with the same contradictions underneath. James recommends treating data quality as the starting point, repairing known problems before migration, and continuing to monitor the information once it reaches the new environment. We also discuss shadow systems and shadow AI. The spreadsheet on one employee's computer may sit outside the official service map while remaining central to a business process. AI agents can create similar dependencies at greater speed. James argues that organizations need visibility into which workflows use AI, what data those agents access, where that data moves, and whether the result creates a return or another source of cost. Can companies turn governance into a continuous business discipline before hidden data problems reach the customer or the board? Listen to the episode and share your thoughts with me.

What does it mean when an IT department meets every SLA, closes tickets quickly, and produces healthy reports, but employees across the business are still unhappy with the service they receive? In this episode of IT Infrastructure as a Conversation, I speak with Phil Christianson, Chief Product Officer at Xurrent, about why IT service management needs to move beyond ticket processing and focus more closely on the business outcomes technology teams support. Phil describes infrastructure support as a collaborative activity. When a website, application, or business system fails, restoring service often involves operations, networking, security, developers, application teams, and business owners. A blame-focused culture slows the response because teams begin defending their own areas instead of solving the problem together. He shares an example from a large ecommerce business where one team updated product prices while another sent outdated pricing information to Google for product listing ads. When the prices did not match the retailer’s website, Phil says Google removed the company’s ads for two days. The root cause was not a complex technical failure, but a lack of communication between internal teams. The story also raises questions about how companies measure IT performance. Ticket volumes, SLA breaches, resolution speed, and first-contact resolution provide useful operational data, but they do not fully explain whether employees trust IT or whether a service helps people do their jobs. Phil recalls a CIO joking that a service desk could report excellent KPIs while the whole company disliked working with IT. His point is that metrics need to be considered alongside customer satisfaction, employee experience, and business outcomes. He also questions whether many IT processes still reflect how organizations operate today. A workaround designed for one request a week can become a major burden when demand grows and the person holding the knowledge leaves. Xurrent encourages customers to review processes roughly every eighteen months and ask whether they would make the same decisions today. Reviews can expose outdated request templates, undocumented knowledge, repetitive manual work, and overloaded roles. AI adds another layer. Phil believes employees should receive a useful automated answer quickly, with a clear route to a person when needed. Large language models can locate knowledge, summarize requests, detect duplicates, improve routing, and identify missing information. The risk is that AI can confidently return outdated or incorrect information. IT teams therefore need to review responses and improve.

Does a modern banking platform need a large collection of microservices and separate engineering teams, or can a compact monolith offer greater reliability and speed? In this episode of IT Infrastructure as a Conversation, I speak with Tomas Navickas, co-founder and CTO of myTU, about the architecture behind a cloud based digital banking platform and the lessons he has carried from two decades of building transactional systems. Tomas begins by challenging a familiar assumption. Infrastructure often receives the blame when an application performs badly, even though the application may be making poor use of the resources already available. His earlier work involved systems that managed large numbers of payment terminals, security changes and transactions that could not simply stop for maintenance. That experience also exposed the operational burden of running server rooms, backup facilities, generators and specialist infrastructure teams. When Tomas began building the current myTU platform, he chose mature cloud services and kept the architecture deliberately simple. The engineering team did not need to maintain physical infrastructure, and the application could be designed around services with known reliability. He also rejected the idea that every modern banking platform should default to microservices. His reasoning is organizational as much as technical. Tomas argues that software architecture and company structure tend to mirror one another. A distributed collection of services often produces distributed teams, additional handoffs and slower decisions. myTU chose one core engineering team and a compact monolith because the company wanted to remain lean, make decisions quickly and upgrade the platform as one consistent system. That choice comes with tradeoffs. Owning much of the technology stack gives myTU control over priorities, language support and product changes. A small team can react within a day when something important appears. The burden is finding engineers who can hold a wider understanding of the system, accept broader responsibility and work comfortably without the narrow boundaries found in a larger company. We also discuss what AI native banking means in practice. At myTU, AI is used across internal processes rather than being confined to customer support. Agents can parse poorly structured information, extract knowledge, summarize cases, gather evidence and suggest decisions. A person can then review the material and move the case forward with a clearer record of why the decision was made. Business onboarding shows where that approach can remove friction. Tomas says the largest problem is often delay. If a customer receives the next precise question immediately, they are much more likely to complete the process. A delay of 15 minutes, an hour or a day can cause them to abandon it. An agent can inspect a document, identify what is missing and ask for the correct item while the customer is still present. The conversation closes with a warning about speed. Tomas believes teams can move quickly, but shortcuts create hidden liabilities. Missing evidence, incomplete recovery paths and temporary design decisions can resurface months or years later. If a shortcut is used to test whether an idea has merit, the system must then be rebuilt properly. Is the industry too quick to equate modern architecture with distributed services, and could a smaller, more coherent system offer a better foundation for regulated AI? Listen to the episode and share your thoughts with me.

What happens when an enterprise invests heavily in AI compute but cannot move data quickly enough to keep those expensive processors working? In this episode of Infrastructure as a Conversation, I speak with Jim Fowler, Chief Technology and Product Officer at Lumen, about why network performance is becoming one of the defining factors in enterprise AI ROI. Jim brings experience from both sides of the relationship. He previously led technology programs inside large enterprises and served on Lumen’s board before joining its management team. His description of Lumen as a logistics company for information provides a useful way to understand the network’s role. Models can process information, but the network must deliver the right data to the right location at the required speed. Our conversation begins with the $2,000 per hour GPU problem. Jim recalls speaking with a Fortune 100 CIO whose company was training its own model using data stored across multiple clouds and regions. The company had GPU availability, but moving petabytes of data to those processors had become its largest bottleneck. Expensive compute was waiting for information. We discuss why an AI workload can perform well inside a controlled development environment before slowing down when users, data sources, and cloud services become distributed. Jim says many inference workloads require response times between 10 and 20 milliseconds. Factory automation can require latency below 10 milliseconds, while natural voice conversations may need responses within five to 10 milliseconds. Poor data movement also affects employees. Jim describes spending time with data scientists who began their mornings by moving information from three global regions. The transfers took between two and two and a half hours, leaving skilled employees waiting, attending meetings, or drinking coffee before they could begin modeling. In his words, these were “idle humans” waiting on the network. The problem becomes harder as AI workloads span public clouds, private data centers, colocation facilities, and edge environments. Jim says bandwidth growth between clouds and data centers is rising far faster than traffic between premises and cloud environments. Enterprises are also managing multiple carriers, tools, and operating systems, making performance and predictability harder to control. We examine data gravity and the decision to move compute closer to data rather than transporting large data sets over long distances. Security, resilience, sovereignty, compliance, and cost must be considered according to the requirements of each workload. Jim also explains why networking is beginning to behave like a cloud service. Traditional capacity could take weeks or months to provision. A software controlled network can increase or reduce capacity as demand changes. Lumen describes this model as Cloud 2.0, with automation, APIs, and real time control replacing static capacity planning. Our discussion closes with ownership. Network, cloud, application, data, and AI teams may each measure success differently. Jim believes a business owner should oversee the complete path from data source to AI outcome because a bottleneck can appear anywhere along the way. Could the biggest constraint on your AI investment be the network connecting your data and compute? Listen to the episode and share your thoughts with me.

Could the TV towers we drive past every day provide part of the answer to rising wireless traffic and last-mile network congestion? In this episode of IT Infrastructure as a Conversation, I speak with Conrad Clemson, CEO of EdgeBeam Wireless, about using existing ATSC 3.0 broadcast infrastructure as a one-to-many wireless data delivery layer. Most modern networks are designed around individual connections. That works well when every user requests different information, but it becomes inefficient when thousands or millions of devices need the same software update, live video stream, positioning correction, public safety message, or digital signage content. Conrad explains why broadcast infrastructure offers different economics. A cellular network may deliver an identical file separately to every endpoint. EdgeBeam Wireless can use TV broadcast capacity to transmit the shared payload once across a wide area. The distinction becomes clear in connected vehicles. Conrad says some automobile manufacturers have found that cellular communication charges across the life of a lower-cost vehicle could approach the cost of the vehicle itself. Software, maps, and AI models all need regular updates, creating demand for a delivery method that does not multiply the same payload across every car. We discuss how ATSC 3.0 added data capabilities to next-generation television infrastructure. Broadcast towers already have fiber connections, transmission equipment, spectrum, and regional coverage. EdgeBeam is adding the software, control, signaling, billing, and delivery components needed to use that infrastructure for internet data. Conrad also explains why EdgeBeam is beginning with business markets such as digital signage, public safety, and positioning services, where receivers can be deployed relatively quickly. Connected vehicles, fixed wireless access, consumer video, and autonomous systems represent larger opportunities that will require broader receiver availability. Digital signage provides another useful example. A one-gigabyte content update sent individually to 1,000 screens produces one terabyte of network traffic. Broadcast distribution can send the content once, allowing screens to store a local portfolio and select the most relevant material when needed. We also consider edge computing, live sporting events, AI infrastructure, and the pressure created when identical data crosses the wireless last mile through separate connections. EdgeBeam’s approach complements cellular networks by moving suitable shared traffic elsewhere and preserving cellular capacity for interactive and personalized services. Which workloads inside your network are still being delivered through thousands of duplicate connections, and could one-to-many distribution offer a better answer? Listen to the conversation and share your thoughts with me.