WSO2 sponsored this post.
Understanding the neural system of modern digitally-driven organizations
In part 1 of this article, we introduced the four architecture domains as well as the evolution of a sample enterprise architecture. In part 2, we will look at an enterprise integration platform as a service (EiPaaS) reference architecture and highlight its key components.
We will also look at a hybrid enterprise iPaaS architecture, show why service mesh should be considered for future-proofing an implementation, and highlight the benefits of an enterprise architecture that utilizes EiPaaS.
Enterprise Integration Platform as a Service (Enterprise iPaaS)
A combination of cloud-centric integration technologies and API management capabilities provide a significant platform, i.e., enterprise iPaaS, to increase productivity by enabling agility, flexibility and scalability through automation and services. Technical leadership, including domain owners and integration-related stakeholders are increasingly adopting enterprise iPaaS as a complete platform as a service for a comprehensive single-shop solution for API integration scenarios. A wide range of protocol connectivity, application and data connectors, construction of integration workflows, routing/orchestration, policy enforcement, community management and built-in continuous-integration/continuous-delivery (CI/CD) pipelines are some of the key capabilities that come with an enterprise iPaaS.
|The industry follows many definitions for on-premises, private cloud and public cloud. This article refers to on-premises and private clouds managed by the organization and public cloud managed by the EiPaaS service provider.|
An enterprise iPaaS architecture consists of a control plane and a data plane.
- The control plane consists of several user portals, focusing on full API lifecycle management, code, no-code, low-code driven integrations, business intelligence reports, an API marketplace for community engagement, identity and access management (IAM), quality assurance, governance and observability. The control plane can be used to define policies, configurations and integration logic.
- The data plane is where policies, configurations, and integration logic are enforced using an API gateway, integration gateway, streaming gateway, workflow gateway, messaging gateway and proxies. Data plane components also capture metrics, logs and tracing data to observe the entire system’s behavior and generate all kinds of business insights reports, which are critical for business decision making.
Full API lifecycle management is a vital part of the digital transformation journey since APIs are a strategic investment for any organization — playing a significant role as both technical enablers and business drivers. API lifecycle management helps API creators to develop, document, scale and version APIs while also facilitating related tasks, such as publishing, monetizing and promoting APIs.
A related concept, the API marketplace2, is key to building an API ecosystem by allowing multiple parties to list and offer their APIs in a single place. Often, we call this model business to business to consumer (B2B2C). Well-defined API marketplace strategies help organizations to become more competitive and agile, allowing companies to get ahead as the API economy evolves.
Security is paramount when exposing business capabilities via APIs. The ability to define security policies, manage tokens and protect APIs by enforcing them in the data plane is essential in the API economy. API quality of service (QoS) and rate-limiting help to productize and monetize API products.
Obtaining meaningful business insights on how APIs are behaving is critical in every business. Built-in API observability tools and AI-powered decision-making engines play a significant role in providing vital business intelligence insights.
Low-code integration eliminates coding in most projects with a point-click-drag-and-drop interface. Simple, template-driven integrations cover a wider variety of integration use cases with ready-made connectors (e.g., Salesforce, NetSuite, Slack, Magento, Workday, Shopify, etc.). These take only minutes to get up and running. Most providers allow users to add code to make modifications to individual components or templates.
No-code integration provides out-of-the-box, cookie-cutter templates for application integration with drag-and-drop components. If the organization has standard integration patterns that match the provided temples, a no-code integration approach will speed time to market. However, unlike code and low-code platforms, they offer less advanced capabilities and flexibility. Both low-code and no-code offerings minimize the technical gap between many users and the skills required for integration — they also increase productivity, which, in turn, reduces time to market.
CI/CD is essential to speed innovation using customer feedback, making it possible to deliver an improved product or service on a daily or even hourly basis. A CI/CD pipeline is typically made up of one or more steps, where source code is turned into a build that is tested and deployed across one or more environments until it eventually reaches the end-user in production.
The majority of the enterprise iPaaS vendors provide comprehensive cloud-centric solutions, where both control plane and data plane components are running in the cloud. Organizations can increase their productivity when they choose to have all their applications and data reside with one enterprise iPaaS provider.
A Hybrid Enterprise iPaaS Architecture
As organizations attempt to stay relevant in a rapidly shifting digital economy, they can’t forget their legacy systems, which continue to play key roles. At the same time, regulations and data privacy rules often prohibit the movement of data out from organizational, county or regional boundaries. Compliance with these regulations, integration and policy enforcement within local boundaries may require implementing a hybrid enterprise iPaaS architecture as an interim solution to overcome restrictions.
In a hybrid enterprise iPaaS, data plane components can run off the public cloud (on-premises/private cloud) by decoupling tight cloud connections. Off-cloud data plane components can sync with configurations, integrations, certs and policies defined within the control plane and enforce them in the data plane. The data plane captures data periodically by syncing with the control plane to generate the necessary insights.
Private cloud data plane components can run on virtual machines or bare metal. However, for better automation and dynamic scalability, they need to run on top of container orchestration platforms, such as Kubernetes. Also, it is necessary that these data plane components are built to align with cloud native technologies if they are to get the maximum benefit out of these platforms.
An Enterprise iPaaS Service Mesh Architecture
Decomposing a complex problem into a set of smaller problems will make it easier to tackle and faster to develop, test, deploy and scale — not to mention, much easier to update. This set of smaller problems can be implemented as cloud-native applications. Each microservice can be created and deployed by a smaller team with the freedom to choose the appropriate technologies. All of these benefits often come with a fee.
When decomposing a monolith into microservices, it is necessary to address the fallacies of distributed computing as part of their application logic. However, this is not easy and can drain all the benefits we are looking for with the microservice architecture. A service mesh can address these problems by deploying a side-car proxy adjacent to each microservice. The side-car helps create a controlled network mesh for handling complex operational requirements such as discovery, load balancing, failure recovery, metrics, monitoring, A/B testing, rate limiting, access control and end-to-end authentication.
We observe that service mesh-driven enterprise architectures are emerging rapidly. We believe that service mesh will play a vital role in network resiliency and service-to-service management. While future applications PaaS are moving toward service mesh, enterprise iPaaS should also evolve to support it natively.
The following diagram shows how enterprise iPaaS works together with the service mesh architecture.
Service mesh mainly controls east-west traffic. By intercepting all traffic through side-car proxies, a service mesh can fulfill the complex operational requirements discussed above. The north-south traffic flows when we expose these services (mostly as APIs) to partners, consumers or businesses. This traffic should be managed via an API management system. A service mesh ingress gateway is the bridge that works in sync with the control plane to enforce all the necessary API management policies. If we want to manage application-to-application traffic, it is best to control traffic via an ingress gateway, even though it is east-west traffic. When integrating a service mesh with the enterprise iPaaS, it is necessary to have special ingress gateways. These gateways are capable of managing API gateway functions in addition to the generic ingress gateway functions.
The Benefits of an Enterprise Architecture that utilizes an EiPaaS
Enterprise iPaaS provides the full gamut of API management and integration capabilities to handle the connectivity and integration of applications on-premises and in the cloud. Once an enterprise architecture has reached the fourth stage of evolution, organizations can benefit from the extended autonomy, enhanced connectivity, enforcement policies and governance that this approach enables.
Furthermore, an enterprise architecture that utilizes an EiPaaS for internal and external integration can recognize several important benefits. From a technology standpoint, these include the ability to:
- Connect internal and external systems, subsystems and data: Harnessing the power of integration and APIs makes this efficient, effective and adaptable.
- Optimize the integration of cloud services: Running in the cloud removes the barriers to connect with the cloud ecosystem.
- Leverage cloud capabilities: Because an EiPasS is designed for the cloud, it brings built-in scalability, security, resiliency, observability and automation features that are automatically inherited by the integration flows built inside.
- Create a composable enterprise with an API-centric and decentralized architecture: Decentralization increases agility and fosters continuous development while APIs connect the individual components.
At the same time, adopting an EiPaaS supports an organization’s agility, innovation and collaboration by making it possible to:
- Facilitate agile and autonomous teams and increase their productivity by removing layers: Autonomy for various units is provided by using multi-tenancy or segmentation and enables each unit to own the entire lifecycle of the products they build.
- Seamlessly onboard new groups and projects: Provisioning and governing of environments is placed at the fingertips of the account administrators.
- Create a frictionless flow across the organization by reducing complexity: An EiPaaS encapsulates the complexity behind a traditional integration solution; development teams can focus on building solutions for business problems.
- Enable remote workforces: This is an added advantage for modern organizational needs. Cloud services are securely available to access from anywhere; therefore, remote workers can get the maximum benefit out of them.
Enterprise architecture has evolved in parallel with changes in how organizations operate and advances in technology — serving as the heart of the technology landscape, the connection between business and technology, and the driving force in generating value streams. However, to achieve those objectives, an enterprise architecture requires a future-proof integration platform and that’s where EiPaaS becomes the neural system of a digitally-driven organization.
Featured image via Pixabay.