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, 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.