- Migrating from Another Middleware Platform
- Grouping Interfaces
- Detailed Work Breakdown
- General Implementation Tips
This document provides a high-level approach for migrating interfaces from an existing middleware platform to Dell Boomi AtomSphere. It discusses the unique opportunities and challenges when migrating platforms and offers guidance for dividing the effort into various project phases. However this document is not intended to serve as a detailed project plan.
Migrating from Another Middleware Platform
In many ways a migration project from an existing integration platform is similar to a net-new integration project, but there are differences. It is important to be aware of both the advantages and challenges of a migration project to seize improvement opportunities and avoid operational disruption.
- Familiarity with use cases - The team has familiarity with integration use cases, end applications, and known issues. Integration management procedures are typically in place and (hopefully!) some interface documentation exists.
- Known scope - Scope is generally well-defined, although there could be a large number of interfaces to move.
- Historical data exists - Historical information exists for sample data, volumes and performance as a basis for comparison. However be aware exact metrics may differ in comparison to AtomSphere depending on design.
- Management tooling - Supporting management tooling likely exists such as reporting dashboards, alerting channels, system monitoring hooks, documentation, change control procedures.
- Improvement opportunity - The migration project presents an opportunity to optimize integration designs such as streamlining “bolt-on” changes over the years, consolidating and parameterizing similar functionality, and deprecating outdated logic and interfaces.
- Learning curve - AtomSphere greatly reduces the learning curve and complexity of middleware platforms and integration development, but it is still a new tool for the team to adopt.
- New integration approaches - All middleware platforms aim to solve the same general integration problems, but each tool will approach the problem different--AtomSphere is no exception. Interface design will typically need to evolve from the legacy system to take advantage of the architecture and capabilities of AtomSphere. Because of fundamental differences in approach, rebuilding is generally required and usually more efficient vs. migrating legacy assets. The Dell Boomi professional services team can assist in helping translate legacy implementations into AtomSphere designs.
- Maintain production operations - The cutover must be carefully coordinated with existed interfaces to minimize disruption to production operations.
- Avoid impact to clients - Impact to existing clients should be avoided/minimized. Ideally the migration would be transparent to client applications but usually that is not entirely possible. Assess impact to client applications (especially those outside the organization) as early as possible. Common changes can include URL endpoints, authentication schemes and credentials, certificates, and whitelisted IPs/hosts. Data formats should be preserved to avoid more costly parsing logic changes for clients.
There are several common ways to organize the interfaces into logical groups for migration. The best grouping is the that makes the most sense for your project and should take into account the number of interfaces and endpoints, commonality across interfaces, project timelines, and external dependencies.
- Endpoint - Interfaces connecting to/from a given endpoint or set of endpoint applications.
- Business process - Interfaces enabling a given business process such as order-to-cash or customer-sync.
- Technical pattern/style - Interfaces using a given integration style such as batch vs. real time, or involve a specific processing requirements. See Technical Patterns below.
- Criticality - Interfaces supporting critical, frequently used, automated processes vs. less critical processes.
- Individual interface - Grouping by individual interfaces with no other discernible commonality.
Thinking in terms of technical patterns can be a great way to better understand the nature of the interfaces and break them down into individual solvable pieces.
A pattern-based approach to migrating interfaces to AtomSphere can help organize the work effort, ease the transition, and minimize risk. The big idea is to:
- Survey existing interfaces to identify common patterns and/or endpoints
- Group interfaces by pattern
- Create templates for each pattern
- Implement and cutover interfaces by pattern
Patterns can be generic or specific, simple or complex, functional or nonfunctional, but typically not end-to-end workflows. Some examples:
- Endpoint connectivity application/protocol (e.g. SAP, MQ, database, REST) and API interaction (e.g. specific queries/joins, upserts, etc.)
- Interoperability with existing integration infrastructure components such as ESB, monitoring channels, job tracking dashboards
- Authentication scheme (especially when publishing web services)
- Notable transformation or validation requirements (e.g. validate against custom database of allowable values)
- Integration “style” (scheduled vs. event-based, web services vs. messaging, synchronous, vs. asynchronous.)
The goals for cataloging and testing technical patterns are:
- Identifying external changes required (most notably for real time interfaces such as web services)
- Assessing level of effort and clarity of requirements for prioritization
- Discovering opportunities for reuse
- Gaining experience with the AtomSphere platform
Detailed Work Breakdown
Migration Phases Overview
The migration effort can be organized into several phases, each with a handful of parallel tracks. When migrating a large number of interfaces, it can make sense to divide the interface-related work (such as requirements gathering, development, and testing) into multiple waves. These waves can be tackled in parallel or sequentially, depending upon resource availability of the implementation team and inter-dependencies.
Keep in mind the first set of interfaces will be the most effort and longest duration because it will include all the one-time activities such as common framework development and runtime infrastructure build-out. However subsequent waves should be streamlined because those activities will have already been completed.
Below is an overview of suggested phases and tracks:
- Phase 1 - Discovery and Planning
- Track 1 - Survey, Proof of Concept, Project Planning
- Phase 2 - Templates, Framework, and Detailed Requirements
- Track 1 - Template and Framework Development (multiple waves)
- Track 2 - AtomSphere Account Administration
- Track 3 - Detailed Business Requirements (multiple waves)
- Phase 3 - Implementation
- Track 1 - Interface Development (multiple waves)
- Track 2 - Runtime Infrastructure Build-Out (if hosting integrations on-premises)
- Track 3 - Performance Testing
- Phase 4 - Testing, Production Readiness
- Track 1 - Functional Testing with End Users
- Track 2 - Production Readiness
- Phase 5 - Production Cutover
- Track 1 - Production Deployments (multiple waves)
Phase 1 - Discovery and Planning
|Track 1 - Survey, Proof of Concept, Project Planning|
Phase 2 - Templates, Framework, and Detailed Requirements
|Track 1 - Template and Framework Development (multiple waves)|
|Track 2 - AtomSphere Account Administration|
|Track 3 - Detailed Business Requirements (multiple waves)|
Phase 3 - Implementation
|Track 1 - Interface Development (multiple waves)|
|Track 2 - Runtime Infrastructure Build-Out (if hosting integrations on-premises)|
|Track 3 - Performance Testing|
Phase 4 - Testing, Production Readiness
|Track 1 - Functional Testing with End Users|
|Track 2 - Production Readiness|
Phase 5 - Production Cutover
|Track 1 - Production Deployments (multiple waves)|
General Implementation Tips
- Document patterns and framework components in a common place, such as an internal wiki.
- Establish and test connectivity to application endpoints as soon as possible to work through network access issues.
- If deploying locally, submit any internal hardware and networking provisioning requests as soon as possible.
- Incorporate modular design elements (e.g. using subprocesses and common components) to minimize effort to make template/pattern changes in the future.
- As the number of interfaces implementing a given pattern increases, spend more cycles refining the template. The additional upfront design and testing effort will greatly reduce the implementation effort and minimize rework.