Enterprise integration is everywhere, yet most people only notice it when something stops working. Applications need to communicate, APIs need to exchange information, ERP systems need to connect with business processes, and data needs to move reliably across organizational boundaries. For decades, integration has largely followed a deterministic model: when this happens, do that. Developers and architects define triggers, conditions, transformations, retries, exceptions, and destinations in advance. But what happens when AI becomes part of that integration layer? In this episode of M365 FM, Mirko Peters talks with Sonny Gillissen [MVP], an Azure Integration Services specialist with a particular focus on Azure Logic Apps, about a concept he calls “Organism as a Service.” The idea is that enterprise integration can evolve from static workflows into systems capable of interpreting context, responding to unexpected situations, choosing appropriate actions, and potentially recovering from failures more intelligently. The conversation covers Azure Logic Apps, Azure Integration Services, API Management, Azure Functions, Azure Service Bus, Event Grid, managed connectors, managed identities, Azure Key Vault, Infrastructure as Code, Bicep, Terraform, CI/CD, observability, Log Analytics, security, least privilege, network isolation, AI agent loops, self-healing integrations, and the future of intelligent enterprise integration.

WHY ENTERPRISE INTEGRATION MATTERS
Integration has effectively become infrastructure. Employees open an application and expect the information they need to appear. Customers place orders and expect them to reach the correct systems. Financial transactions move through ERP platforms. APIs exchange information. Events trigger downstream processes. From the user’s perspective, this often feels automatic. Sonny compares it to turning on a water tap: people expect water to flow without thinking about everything happening behind the wall. Enterprise integration works similarly. The complexity becomes invisible until something fails. Behind seemingly simple processes can be dozens of applications, APIs, business rules, security controls, identities, transformations, queues, monitoring systems, and organizational responsibilities. Integration therefore isn’t simply about connecting application A with application B. It is about keeping business processes operating across systems that were often never originally designed to work together.

WHY ENTERPRISE INTEGRATION BECOMES SO COMPLEX
The technology itself is not always the primary source of complexity. Enterprise business processes are complicated. ERP environments such as SAP and Microsoft Dynamics contain extensive transactional processes because financial and operational activities need control, consistency, and auditing. Multiple departments participate. Business knowledge remains distributed among employees. Organizations accumulate years of architectural decisions. Eventually, integration architecture begins reflecting all of that organizational complexity. Sonny argues that a good integration consultant therefore needs to look beyond the technical request. Instead of simply asking “How do we connect these systems?”, the more important question is: “What is the organization actually trying to accomplish?” Simplifying integration starts by understanding the business process behind it.

WHAT MAKES A GOOD INTEGRATION ARCHITECTURE?
An integration that works today is not necessarily a good integration. Sonny highlights reusability and security as particularly important characteristics. Modern integration architectures should become increasingly composable. Instead of rebuilding the same functionality repeatedly, organizations should be able to reuse components in different processes. Security is equally fundamental. Integration services frequently connect highly privileged business systems. Poorly designed access can turn an integration platform into an extremely attractive attack path. A successful request is therefore only one measure of integration quality. The architecture also needs to remain reusable, supportable, secure, observable, and adaptable as business requirements change.

WHAT ARE AZURE INTEGRATION SERVICES?
Azure Integration Services is not one product. It is a collection of Microsoft Azure capabilities that can be combined to build enterprise integration architectures. During the conversation, Sonny and Mirko discuss five major technologies: Azure Logic Apps provides workflow orchestration and low-code integration. Azure API Management provides an API gateway and management layer. Azure Functions provides serverless code for scenarios where pro-code functionality is appropriate. Azure Service Bus supports messaging and helps decouple systems. Azure Event Grid provides event-driven integration capabilities. Different services solve different pieces of the integration problem, and real enterprise architectures frequently combine several of them.

AZURE LOGIC APPS VS AZURE FUNCTIONS
One recurring architectural question is whether a particular integration should use Azure Logic Apps or Azure Functions. There is no universal answer. Organizations with strong low-code expertise may find Logic Apps particularly effective because developers and integration specialists can visually construct workflows. Organizations with experienced .NET development teams may prefer Azure Functions for scenarios where custom code provides greater flexibility. The important point is that this does not need to become an ideological choice between low code and pro code. An enterprise integration architecture can use both. Logic Apps can orchestrate processes while Functions provide specialized code where required.

WHY AZURE SERVICE BUS MATTERS
Azure Service Bus plays an important role in decoupling enterprise systems. Without a messaging layer, application A may directly depend on application B being available. That creates tight coupling. Introducing Service Bus can separate those systems. Application A can send information to Service Bus, while application B processes it according to the architecture. This can make backend integrations more resilient and provide opportunities for reprocessing. Sonny notes that Service Bus is not automatically appropriate for every synchronous scenario because adding asynchronous messaging can affect response time and user experience. But for backend processing and decoupled architectures, he considers it an important component. 

WHY SONNY SPECIALIZES IN AZURE LOGIC APPS
One reason Sonny focuses heavily on Azure Logic Apps is visibility. Traditional code requires developers to deliberately implement logging and monitoring. A Logic App provides a visual workflow and run history. After executing a workflow, developers can inspect what happened, which actions executed, what results were produced, and where failures occurred. This allows integration specialists to spend more time thinking about the business process and less time building basic troubleshooting infrastructure. For people who naturally think visually about processes rather than primarily through code, this can make Logic Apps particularly effective.

THE DEVELOPER MISUNDERSTANDING ABOUT LOGIC APPS
Developers sometimes assume that writing custom code will always be faster or more powerful than using a visual integration platform. For some scenarios, that may be true. But the calculation needs to include more than the time required to write the core functionality. Monitoring matters. Logging matters. Deployment matters. Error handling matters. Operations matter. Maintenance matters. Logic Apps provides significant platform functionality around the workflow itself. Sonny also discusses codeful workflows as an attempt to bridge the gap between visual Logic Apps development and traditional pro-code development approaches.

LOGIC APPS SHOULD BE TREATED AS CODE
Low code does not mean organizations should abandon software engineering practices. Sonny recommends treating Logic Apps as code and deploying them through CI/CD. An organization could manually create something in development, export it, and reproduce it in another environment. But manual deployment creates an obvious risk: Eventually, somebody forgets something. Development and production begin to differ. Those differences become operational problems. Automated deployment provides repeatability and helps organizations maintain consistent environments.

INFRASTRUCTURE AS CODE WITH LOGIC APPS
Azure Logic Apps can be deployed as part of an Infrastructure as Code strategy. The episode discusses ARM templates, Bicep, and Terraform. Infrastructure as Code describes the desired Azure environment deterministically. The configuration can define resources, SKUs, locations, resource groups, and other infrastructure properties. Bicep provides a more concise Azure-focused authoring experience while ultimately relating closely to ARM deployment. Terraform provides another approach for defining and deploying infrastructure. The important architectural principle is repeatability. Integration infrastructure should not depend entirely on somebody remembering which buttons they clicked in the Azure portal.

Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365–6704921/support.