Accelerate to Mule 4:
Considerations for Migration
Table of Contents
2. Why do you need to migrate to Mule 4? 4
2.1 Exception handling 5
4.2 Choosing the right migration options 8
2
1. Introduction
,
,
industry.
,
Glossary
Abbreviation
CoE Center for Excellence
2. Why Do You Need to Migrate to Mule 4?
,
Mule 4 has improved on the following fronts, compared to Mule 3:
Frictionless upgrades
Exception handling
New connectors
streaming
Seamless access Enhanced enrichers
to data
4
2.1 Exception Handling
In points:
and
Mule 4 Event Mule 3 Event
Message Message
Payload
Payload
(Includes Attachments)
Inbound
Attributes Properties
Outbound
(immutable) Properties
Variables Attributes
Exception Message Attachments
Attributes
Event Models
5
Self-Tuning Capabilities
meaning
Is there an Is the existing Are there better Does it align
Can my cores
upgraded version version going out features which with my future
get optimized?
for the product? of support? are useful? road map?
Does the version help in doing things better
Monitoring | Governance | Maintenance
AS-IS What are
the options
Re-Architecture
Long term vision Address the short Reengineer Leverage the capabilities
comes with larger comings of current security & of latest version fully, get on
implementation optimize core with best practices
Want to manage risks with
Short term Quick turn
versions going out
vision around time
of support
Decision Process
:
migration process:
Rationalization of Existing Mule 3 Implementation
existing integrations in order to support a smooth migration. Integration rationalization can help
The process for rationalization is shown below:
Governance
• Group based on functionality • Finalize scope
Group
• Future state • Identify requirements
• Device strategy • Establish governance parameters
Integration
Rationalization
Process
• Finalize inventory
• Bring in scoring methodology Score Business • Categorize the inventory
• Review interface scoring Inventory Value • Isolate end points
Cost
• Confirm cost and distribution • Review value & Technical Fit
• Compare Value against cost • Identify dependencies
• Suggest new ways to bring cost distribution • Identify duplication and versions
Rationalization Process
,
the long term.
Migration Bubble
Cost
Time
Migration Bubble
4.2 Choosing the Right Migration Options
.
,
8
t
As-Is
As-Is
Op ons As-Is Re-Architecture
Cost Low High
Time Low High
Version Compliance Yes No
Pla orm Bene ts No Yes
Core Op miza on No Yes
Long-term bene ts No Yes
Short-term plan Yes No
Production
Build
UAT
SIT/Functional
e
c tur TestingA
hite
Arc
Re
Design
As Is ion
Requirement Product
Analysis
sting
Build Level 0 te
Current
State Objectives
9
aligning to the product roadmap.
Standardization
Pattern implementation
Monitoring
Best practices Migration
Message model Considerations
Error Handling
API
Refactoring Led
P1 P2 P3 P4 P5 P6
• Patterns P1, P2 align to the API Led Approach
Proxies • Pattern P3 is proxy an external API
Exp APIs - Connecting using native protocols in P3 is an anti pattern
UX
• Pattern P4 is valid unless process needs tight security
Process APIs
• Pattern P5 is not recommended unless
- Exception is obtained from Governance team
System APIs • Pattern P6 is valid for internal consumption
unless systems need a tight security
System
API Patterns
Security is crucial in any type of implementation. When an organization decides to migrate to a new
0 1 2 3
Private APIs for Internal Collaboration for APIs APIs are products
API Access to Identi ed Partners
Internal Integration COE & Governance External Developer Access
Where does Security kick in?
Security Thought
0 1 2 3
Internal Collaboration for APIs APIs as products
Private APIs for Internal Integration API Access to Identi ed Partners
COE & Governance External Developer Access
• Internal users Internal teams External partners Public access
• n
•
Security Understanding
Authentication & Data Monitoring Infrastructure
Authorization
11
details how is extremely important.
Re-Architecture
Category Descrip on
Pla orm Is the API hosted on-premise or on cloud? Can it be hosted on cloud? If not, why?
API-led Is the API/integra on designed as per API-led thought process? Can they be relooked
again, as some mes organiza ons would have over-engineered the implementa on
and now could relook and op mize?
RAML Is there a refactoring of RAML required? Do we increase readability, implements types?
Custom Are there custom Java implementa ons for le handling, parsing, reading messages
from queues, backend applica ons, etc.? Are there Groovy Scripts? Are there any
customer components used?
Naming Are there naming standards and are the implementa ons following them? Did they
Conven ons evolve over me and need standardiza on?
Logging & Are the standards and formats followed as per guidelines? Is it API kit default and do
Excep on handing you want to relook?
End Connectors Are there any system-speci c connectors? Are there any object stores used?
Reusability Is there any scope for reusability? Are there any common processes across LOBs?
Pa erns Have you iden ed the pa erns applicable for your organiza on? Are the
implementa ons following those pa erns?
Auto Discovery Is auto-discovery implemented?
General General condi ons, hard coding, cer cates, removal of custom implementa ons with
Op miza ons latest pla orm capabili es, op mize variable usage, conversion op miza on
Compliance Does the implementa on need to be compliant with PCI etc.?
Security Is the security implemented across layers as per standards? Can someone hack, if they
pass through the DMZ?
Foundation
Productionized
12
• Reference Architecture Development
•
• practices
• Code scan
• Components t
• Show case LTIMindtree
• Accelerators
• Architectural suggestions
Phase 2 is multi phased based on use case and
migration plan
Independent use cases
Use case 1 Use case 4
As-Is Migration
As-Is
follows:
• Migrate Patterns • Migrate Connectors
Module
• Migration Core Components
<parent>
•
•
• Update annotations and Params Classes
•
•
• DataWeave Header Content
• Standardize RAML Template
and
organization roadmap.
, ,
14
6. Conclusion
on the sidelines is no longer an option. Organizations need to ensure that the continuity of the services is
essential, costs are lower, and the need for migration is considered as an opportunity towards ensuring
long-term benefits. Based on the options available, we have created a model that can provide
For more details, contact us.
7. Reference
•
•
•
•
8. About the Authors
Srinivas Kanduri has about 19+ years’ experience working as Program Architect at LTIMindtree Digital
practice, specializing on enterprise application integration. Experience in major integration technologies like
,
Enterprise Digital Transformation consulting, Architecture Consulting, Solution architecture, technology
consulting, and leadership for technology groups within organization and IT strategy for client organizations.
Vijay Chakka possesses close to 17+ years of IT industry experience, primarily in the integration space, and
,
the Enterprise Application Integration service line under LTIMindtree Digital. He has been part of the growth
path for multiple organizations across industries such as banking, entertainment, energy, manufacturing etc.
Surendra Thekkatte is a CoE head within Enterprise Application Integration service line under LTIMindtree
Digital practice with over 22+ years of experience specializing in Integration and Architecture consulting
from LTIMindtree, helping customers API Strategy, setting up of API CoE, and implementation
roadmap for customers transitioning from SOA centric middleware products to Microservices based
architecture involving API management platforms.
LTIMindtree is a global technology consulting and digital solutions company that enables enterprises across industries to reimagine business models, accelerate
innovation, and maximize growth by harnessing digital technologies. As a digital transformation partner to more than 700 clients, LTIMindtree brings extensive
domain and technology expertise to help drive superior competitive differentiation, customer experiences, and business outcomes in a converging world. Powered
by 84,000+ talented and entrepreneurial professionals across more than 30 countries, LTIMindtree — a Larsen & Toubro Group company — combines the
industry-acclaimed strengths of erstwhile Larsen and Toubro Infotech and Mindtree in solving the most complex business challenges and delivering
transformation at scale. For more information, please visit https://www.ltimindtree.com/
