Learn about the key aspects that need to be considered when selecting an integration platform for your business regardless of the business domain you are in.

1. How to Choose an Integration Platform Vendor
February, 2021

2. Hello!
Chanaka Fernando
Solutions Architect
chanakaf@wso2.com
Arunan Sugunakumar
Senior Software Engineer
arunan@wso2.com

3. Agenda

4. ● How to get started with Integration?
● Solution Architecture for Integration Platform
● Modern integration requirements (brown-field integration)
● Selecting a platform ready for cloud-native journey
● Non-functional requirements of an integration platform
● How to make the final decision
What you will learn from this webinar
4

5. How to get started with Integration?

6. Integration is the function of connecting
disparate systems to exchange data to
build a coherent system that produces
value to the users
- WSO2 Team -

7. ● Enterprises are adopting more and more applications as part of digitization or
digital transformation - Application Integration
● Users of the enterprise systems are generating more and more data in
disparate sources - Data Integration
● No business can survive without business partners - B2B Integration
● Taking the business to the next level requires careful exposure of business
services and data - API Management
Business need for an integration platform
7

8. ● Data transformation across formats/types
● Protocol translation
● Application connectors
● File processing
● Routing and orchestration
● Messaging & Event handling (Asynchronous, event-driven)
● B2B/EDI support
● Event stream processing (streaming ETL)
● API policy enforcement and management
Functional requirements of an integration platform
8

9. Integrating with an ESB
9

10. ● Not easy to scale
● Hard to manage (patching/upgrade)
● Resource underutilization
● Time to market is higher
● Hard to monitor/troubleshoot
● Hard to recover
Challenges with centralized ESB based integration
10

11. Solution Architecture for Integration

12. Layered architecture for Integration
12

13. ● Experience APIs - Innovation and digital products through user specific services
● Process APIs - Agility and Innovation with improved time to market
● System APIs - Decentralized access to core business systems
● Developer experience - Securely expose business services to 3rd parties
● Governance - Segregation of responsibilities with proper ownership
Layered architecture for integration
13

14. ● Segregation of responsibilities
● Modularized architecture
● Integrate through standard REST interfaces
● Ability to extend the functionality to 3rd parties
● Flexibility in selecting the best technology for each layer
● Improved monitoring and troubleshooting
● Better recovery (circuit breaking, retry)
Advantages of Layered architecture
14

15. Modern integration requirements

16. ● Enterprises are moving along with the technology trends
● Some teams adopt microservices architecture
● Core systems and cloud applications are still there
● Polyglot environments
● Continuous Integration / Continuous Delivery
● Agile development (improved time to market)
● Automation
● Resiliency
● Monitoring/Alerting
● Security
Brown field integration requirements
16

17. Brown field integration requirements
17

18. The rise of event stream processing
● Event-Driven-Architecture (EDA) is becoming a common pattern within
enterprises
● A continuous stream of messages need to be processed in real-time for
improved decision making
● Standard Extract-Transform-Load (ETL) workloads are replaced with streaming
ETL
● Streaming Integration can be a major capability to have in your integration
platform
18

19. Streaming Integration Architecture
19
Streaming Integration
Transform
Enrich
Cleanse
Correlate
Aggregate
Insights
Streaming Messaging
Systems
Software and
Sensors
Cloud
Databases
Files
Software
Cloud
Databases
Files
Input
Stream
Event
Tables Aggregation
Input
Stream
Result
Stream
Fetch Data On Demand
Via REST API
Standard
Integration
Trigger
Integrations

20. Selecting a platform with cloud-native
support

21. ● High availability across the globe
● Elasticity allows services to scale up/down based on need
● Scalability make it easy to expand services
● Cost savings - pay as you go
● Reduced overhead on managing infrastructure
Advantages of the cloud
21

22. ● To reap the benefits of the cloud (No, we are not suggesting to go with iPaaS)
● Flexibility to migrate to cloud
● No vendor-locking
● Microservices, container-friendly
● Future proof
Why selecting a platform with cloud-native capabilities?
22

23. Cloud native solution architecture
23

24. ● Messaging System — Accept large event streams that require asynchronous processing
● Event processing system — Process the events received by the messaging system in
real-time or in batch mode.
● System APIs (System Microservices) — Microservices style can be adopted at this layer
with the selected integration technology.
● Process APIs (Integration Microservices) — Micro integration services can be developed at
this layer.
● Experience APIs (Micro API Gateways) — The underlying services can be exposed as
experience APIs through micro gateways
● Developer portal — Interacting with 3rd party users and developers
● Analytics platform — Provide business intelligence and monitoring of the platform
● Identity and Access Management platform — Authentication, authorization, provisioning,
SSO, MFA capabilities
Supporting cloud-native, brown field integration
24

25. Non-functional requirements

26. ● Self-managed deployment(on-premise, IaaS) - User manages the deployment
which is done on a user owned or rented (IaaS) infrastructure. Vendor support
through JIRA/Ticketing portal
● Vendor managed deployment (SaaS, PaaS) - User get access to a shared
service which is fully managed by the vendor. Infrastructure management,
patching, upgrades taken care by the vendor.
● Hybrid deployment - Shared responsibility of managing the deployment across
vendor and the user. In most cases, vendor manages the “control
plane/management plane” while user manages the “data plane”.
Deployment options supported
26

27. ● Programmers - Engineers with programming background and willing to reuse
their existing knowledge on the integration platform
● Integration specialists - Engineers who comes with experience in integration
domain with one or more vendors. Prefer DSL based, XML based, config-driven
approaches
● Citizen integrators - People comes with a strong background with specific
industry domains such as financial, banking. Not necessarily familiar with
programming languages. Prefer low-code, no-code integration solution with IDE
support.
Developer productivity - types of users
27

28. ● Ability to reuse the work done by other people
● Service repository
● Management/Governance of SDLC
● Platform to engage with users
● Automation with CI/CD
● Docker kubernetes support (containerization)
Developer productivity - Reusability and Governance
28

29. ● Excellent Documentation
● Community support (GitHub, Slack, SO)
● Tech support (SLA, MTTR)
● Trainings/Certifications
● Managed services
Developer productivity - Support and engagement
29

30. CI/CD - Application Delivery Pipeline
30

31. ● Containers are everywhere
● Suitable for most of the architectures
● Adheres to 12 factor app methodology
● Container orchestration platform provides scalability
Containerization
31

32. ● Monitoring keeps a continuous watch on the system
● Observability enables users to understand what went wrong with
⦿ Logs
⦿ Metrics
⦿ Traces
● The growing trend of DevOps and automation creates the need for observability
● It enables data-driven innovative culture
● Delivers optimal customer experience
● Integration platform should have proper monitoring and observability
capabilities
● Ability to integrate over standard interfaces like opentracing
Monitoring and Observability
32

33. ● What is the cost of evaluating the product?
● The level of support available
● Ability to find engineering resources for development/maintenance
● How steep is the learning curve for newbies
● Total investment across 1,2,3 years
⦿ Licensing/Subscription
⦿ Development support
⦿ Resourcing
⦿ Infrastructure costs
● How long will it take to make returns?
● Tangible and intangible returns
Total cost of ownership (TCO) and Return on Investment (ROI)
33

34. 34
An Integration platform is typically used on multiple projects
Projects
ROI
(excluding
platform
cost)
Across multiple projects we get a ‘long tail curve’ of ROI
Some projects have an inherently large ROI
Other projects have a smaller ROI initially

35. 35
Not just saving TCO on existing projects: ROI expansion
Projects
ROI
(excluding
platform
cost)
Higher cost
Lower cost
Only these projects get funded with a
higher base infrastructure cost
With a lower infrastructure cost, these projects
become “positive ROI”, and get funded,
generating more value for the organisation
Area represents
total ROI under
Higher cost
vendor
Area represents
ROI under lower
cost vendor

36. 36
Enabling the “winners” of the future
Projects
ROI
(excluding
platform
cost)
Higher cost
Lower cost
● Often future “winners” start as small projects with low predicted ROI
● Over time they grow to give very high ROI
● These projects don’t get funded if the base cost is high

37. Making the final decision

38. ● Basic functional capabilities
● Support for modern IT requirements
● Developer productivity
● Reusability
● Deployment options
● Support for modern architectures
● Total Cost of Ownership (TCO) and Return On Investment (ROI)
● Quality of enterprise support and availability
Considerations for final decision
38

39. wso2.com
Thanks!