Many organizations have traditional ESB and SDLC practices built on IBM App Connect Enterprise (ACE) and IBM MQ. Over time, sustaining these environments through incremental, continuous improvements provides limited value. Also, some places still use IBM Integration Bus (IIB) v10, which is out of support for their ESB. Though many readers may consider the traditional ESB hub-and-spoke model outdated, it remains the primary pattern for messaging and integration teams—supporting mission-critical systems that are not easy to replace.
One of the biggest challenges integration teams have is maintaining their core ESB and other established systems within scheduled delivery cycles (classic in nature) while simultaneously supporting next-generation integrations with faster, more fluid delivery cycles (DevOps in nature).
Reframing the ESB and its SDLC practices as a modern integration platform capability creates new opportunities to generate value—bridging the gap between stability and speed.
Pipeline Strategy for “Two Speed” Operations
One of the largest challenges integration teams face is the need to maintain their core ESB interactions with SAP or other established systems through scheduled delivery cycles (classic in nature), while simultaneously supporting a growing demand for next-generation integrations with faster, more fluid delivery cycles (DevOps in nature).
An organization’s ESB may effectively support on-premises hub-and-spoke integrations, but when container-based deployments are not possible, new business initiatives can be slowed or blocked. Leveraging containers can drastically increase the agility of next-generation pipelines. Containers enable integrations to be deployed reliably and migrated quickly between environments by packaging code, configuration settings, and dependencies into a single portable image.
A recommended approach is to construct and operate a pipeline that supports both needs using a “Two-Speed” strategy. Two-speed IT is the concept that strategic planning for technology should include a fast track—allowing some projects to be implemented quickly—while maintaining a classic track for mission-critical systems that require stability and governance. The strategy proposes that agile, innovative initiatives should be allowed to move forward rapidly without being constrained by the checks and balances necessary to safeguard core business operations.
Key points from the 2014 McKinsey article, “A Two-Speed IT Architecture for the Digital Enterprise,” reinforce this recommendation:
- Delivering enriched customer experiences requires new digital architectures running alongside legacy systems.
- A two-speed IT architecture helps companies develop customer-facing capabilities at high speed while decoupling legacy systems whose release cycles remain slower.
- Unlike digital-native enterprises, traditional companies must build modern architectures for the digital enterprise on top of their legacy foundations.
Traditional ESB Pipeline for Hub-and-Spoke
The Traditional ESB Pipeline introduces new functionality while maintaining the hub-and-spoke operations in place. For many integration teams, established CI/CD orchestrators such as Jenkins continue to play a valuable role in managing the controlled release cycles of core ACE and MQ components, where predictability and governance take precedence.
Though this Pipeline is for the current ESB supporting IIB v10, its approach is the same when upgrading to ACE v13 to continue the hub-and-spoke ESB with minimal changes to the Pipeline; this would be to maintain stability to transactional core systems such as SAP and not introduce containers.
As each new version of the Pipeline is iteratively released, additional functionality and automation is included as an accelerator for the current ESB.
The NextGen Pipeline
The Pipeline for NextGen Integrations that are container-based. As each new version of the Pipeline is released, additional functionality and automation is included as an accelerator for DevOps enablement using ACE and MQ.
While Jenkins remains a dependable backbone for classic deployment pipelines, organizations embracing containerized MQ and ACE workloads can gain speed and portability by adopting Kubernetes-native tools like Tekton and Argo CD, which align well with IBM Cloud Pak for Integration’s CI/CD framework.
The Need for a “Machine Shop” Team
DevOps (which includes CI/CD initiatives) has its best success when it’s a coordinated, multi-team effort. At its heart DevOps is about empowerment of developers and operations to work together, accelerating construction/testing/delivery of new business initiatives.
This should be considered a strategic endeavor requiring formation of new teams: The Automation Architecture Team and DevOps Engineering Team. Some organizations where such teams operate are collectively called a “Machine Shop” as that’s what they do: a workshop for making or repairing mechanical items.
The Automation Architecture Team
This team’s charter designs and develops strategies allowing an organization to automate its processes. They work with company leadership, departmental stakeholders, and IT departments to see the holes in an automation process before it starts.
Automation architects are problem solvers and creative thinkers who understand both the business and technological sides of an organization’s work environment. Basic recommendations for this team:
- Team size should be 3 members reporting to some director-level resource overseeing digital transformation. The director should already be someone with that role within your organization to give credibility and guidance to this team
- 2 to 1 ratio for internal vs external hires (this provides a composite of team members who have experience internally with the company’s business and technology side, and new team members (external hires) who bring their perspective and experience to automation)
- At least one of the team members should have a proven track record for automation and be recognized as a contributor through published articles, webinars, open-source contributions and work experience. Most likely, this will be your new hire and will be the Distinguished Engineer for Automation and leading/contributing to the DevOps Engineering team
- The team itself is an accelerator for a unified DevOps strategy for the organization. Its formation and charter may only need to exist for two to three years to design and develop strategies that will allow an organization to automate its processes. Team members can eventually move to the DevOps Engineering or application teams, depending on needs
This team’s charter is to 1) be the product owners and implementers of the tools and processes chosen by the Automation Architecture team and 2) advisors/consultants to application teams requiring their skills to collaborate on building out key pieces of a Pipeline.
This team’s efforts reduce DevOps complexity, closing the gap between actions needed to quickly change an application, and the tasks that maintain its reliability. Basic recommendations for this team:
- Keep team size around 3 (minimum) and 6 members (max), reporting to the Distinguished Engineer of Automation in the Automation Architecture Group
- 2 to 1 ratio for external vs internal hires (this provides a composite of team members who have experience internally and new team members (external hires) who bring their perspective and experience to automation)
- At least half of the team members should have relevant work experience for automation
- Team members must have skills that span both development and operations, including interpersonal skills to help bridge divides between siloed application teams
- This team should be considered permanent compared to the Automation Architecture Team, as this team will be the product owners of the Pipeline for future enhancements and rollout to additional application teams
Conclusion: Building the Machine Shop for Two-Speed Success
Two-speed CI/CD for IBM MQ and App Connect Enterprise is as much about people and process as it is about pipelines and tools. Balancing stability with speed requires more than adopting containers, Tekton pipelines, or Jenkins workflows demands intentional collaboration between architecture, operations, and development teams.
In conclusion, technology alone won’t deliver two-speed CI/CD success. Without a dedicated “Machine Shop” team to guide automation strategy and pipeline ownership, organizations risk fragmented efforts and inconsistent results. By investing in focused Automation Architecture and DevOps Engineering teams, enterprises can turn integration delivery into a repeatable craft, balancing the dependability of traditional ESB operations with the agility of modern, container-based pipelines. The outcome is a disciplined approach to speed, where progress is measured not just in how fast teams move, but in how consistently they succeed.
