Introduction 

It was over a decade ago when my professional journey into enterprise integration began, not with a simple project, but with the challenging task of building a robust Enterprise Service Bus (ESB). Our tool of choice was IBM WebSphere Message Broker (in combination with WebSphere MQ), a powerful platform that served as the backbone for connecting a complex network of applications. That foundational experience with WMB taught me the core principles of application integration, Service-Oriented Architecture (SOA), and key integration design patterns like messaging and Event-Driven Architecture (EDA). 

Having since followed the product’s evolution through IBM Integration Bus and now to its modern form as IBM App Connect Enterprise, I’ve had a front-row seat to its transformation. This review is a reflection on that journey, offering a long-term perspective on how the platform has adapted—from a traditional on-premises ESB to a flexible, cloud-native integration solution—and how its enduring strengths have been shaped to meet the demands of today’s digital landscape. 

Developer environment 

The developer tool is Eclipse based and is used to build integration flows using either predefined nodes or nodes containing custom code containing ESQL, java, graphical mapper logic,… Over time the toolkit has evolved gaining new features like new connector types, shared libraries, built-in Unit Testing, containerization,… For management there is also the ACE Web Ui which gives a visual representation of what is running on the integration runtime. 

Core architecture 

Where we initially focused on brokers and execution groups to centralize all integration logic into powerful, monolithic runtimes, today’s Hybrid Cloud Focus marks a fundamental shift. The “old ways” provided a robust governance and stability, but was often  difficult to scale independently and contained many complex dependencies. A change to one part of the broker could potentially impact all the integrations running within it. 

The move to IBM App Connect Enterprise completely re-architected this approach. The concept of an independent integration server is the key, allowing us to deploy and manage integrations as lightweight, isolated microservices. This enables us to run our integrations anywhere—on-premise, in a private cloud, or in a public cloud like IBM Cloud, AWS or Azure for dynamic workloads. Even better, it enables a combination of all three, with a consistent runtime and development experience. This flexibility means we can manage each integration as a distinct component that can be containerized, scaled, and updated independently, without the overhead of a large, centralized broker. 

Evolution to Microservices 

In the WebSphere Message Broker and IIB days, development was often tied to heavy, centralized runtimes. A full “broker” with multiple “execution groups” had to be managed, and a single deployment could affect many different integration flows. The result often was very complex deployments with high risks. 

With ACE, we have moved to independent integration servers. This allows developers to design the integration servers to handle specific business functions. By decoupling business functions into separate integration servers, we can take away the risk of impacting other integration runtimes. By removing this risk, it is possible to have faster deployment cycles and in combination with a Kubernetes platform like Red Hat OpenShift we can deploy integration servers in seconds instead of in minutes. 

Kafka integrations 

In my latest project I’ve built lots of integrations with Kafka topics. IBM ACE v12 provided the core nodes to integrate with Kafka (KafkaConsumer, KafkaProducer and KafkaRead). These nodes allowed us to create basic pub-sub and data streaming integrations with Kafka. However, the lack of the Avro schema support and support for the schema registry forced us to do custom development for a real Kafka integration experience.  

ACE v13 takes the Kafka integration to the next level with the upgrade of the Kafka nodes now supporting Avro schemas. By using the newly added schema registry policy, Kafka nodes can now be configured to create a connection to the schema registry so the nodes can automatically connect to the schema registry and apply the correct schema for a given topic. 

Conclusion 

Reflecting on my experience with the Integration platform from IBM and its evolution, I can say that the latest evolution to IBM ACE is not just an evolution of new features. But it was really about reinventing how IBM looks at integration. While to core capabilities (Universal Connectivity, Transformation, Enrichment Intelligent Routing and Filtering) remain, the product reinvented itself by making the shift from monolithic centralized brokers to lightweight and containerized integration micro services. This evolution has not only improved the development experience, but also improved the delivery process by drastically reducing the risk and providing faster deployment cycles. 

While I’ve focused on the Kafka integration, there are many capabilities worth discussing. 

For organizations seeking a highly reliable and performant integration platform that is equally comfortable with legacy systems and the cutting edge of containerized microservices, IBM App Connect Enterprise is not just a viable option—it’s the definitive choice for a future-proof integration strategy.