The Role of EiPaaS in Enterprise Architecture - Part 1
By Asanka Abeysinghe
- 19 May, 2021
Enterprise architecture is evolving daily, with organizations continually focusing on digital transformation initiatives and new technologies such as cloud and microservices. Integration is therefore becoming an increasingly vital part of enterprise architecture.
In this two-part article series, we will look at how an enterprise integration platform as a service (EiPaaS) can help organizations build a future-proof enterprise architecture. In this article, we will discuss the business, information, application and technology domains as well as the four evolutionary stages of a sample enterprise architecture. Let’s dive in.
When discussing enterprise architecture, a diagram of the IT landscape comes to mind because that is the standard approach to defining an architecture. However, during our work with a number of enterprise architecture teams worldwide, we discovered that enterprise architecture has a larger strategic scope than what typical IT diagrams capture.
Fundamentally, enterprise architecture converts business strategy into a value generation outcome by creating a foundation to execute various IT initiatives and processes. It is about gaining a long-term view for the organization, including the integration and standardization of various elements involved in the business.
There are four architecture domains involved in enterprise architecture: business, information, application and technology.
The role of enterprise architecture is shifting from a centralized governing framework to a value stream generator – where it connects business and IT. This transition does not happen overnight – organizations take different paths to achieve it, but we have generalized this into four stages. We will examine this evolution in the next section.
‘Evolution happens in jumps, very rapidly’ - Marilyn Ferguson
The following diagram represents the evolution of a sample enterprise architecture as a topology in which an organization has four functional units or lines of businesses (F1..F4). Each functional unit uses many systems and subsystems and subscribes to cloud services (i.e., software as a service [SaaS]) required for their day-to-day operations.
At the initial stages, an enterprise architecture will define the systems and subsystems required for each organization's function. It starts with purchasing core systems, such as human resource management (HRM), customer relationship management (CRM) and/or enterprise resource planning (ERP) based on the business domain of the organization. In addition, subsystems will be built around the core systems by in-house or outsourced development teams. Systems and subsystems that belong to each function operate independently with limited or no information exchange. Any information exchange will happen manually or outside the system boundaries. Spreadsheets are an excellent example of this method of data exchange. Hence, we refer to this stage as siloed.
The second stage (i.e., connected) is about standardizing technology usage and connecting the systems and subsystems across functions. Organizations move to this stage due to demand from individual functions and top management. However, the connections established are point-to-point at this stage. File-based and database synchronization techniques, such as extract, transform, load (ETL) and master data management (MDM) are popular methods used in point-to-point integration. However, the standardization focuses locally between lines of business (LoBs); therefore, cross-function access and security is a challenge with this approach, leading to minimal connectivity between functions.
The next stage of an enterprise architecture moves to a center of excellence (COE) operation model. The third stage predominantly focuses on optimizing the core. This approach predominantly focuses on overcoming challenges created during the connected stage and increases cross-functional integration (which is why we call this the centralized stage). Integrations are achieved using an integration hub or an enterprise service bus (ESB). Characteristics include a centralized integration team building and managing the integration logic for the organization. In addition, centralized security, governance, portals and dashboards are produced by leveraging the improved connectivity. The reuse of business functions internally and externally using APIs, which have been introduced with the advancement of integration, becomes the focus area of an enterprise architecture at this level.
The fourth stage of the enterprise architecture emerged as a result of internal organizational changes and the external market outlook—mainly decentralized architecture styles (microservices and cloud native) and agile processes. Each function or LoB is looking for autonomy by recruiting their own technical teams and owning the entire lifecycle (plan, build, test, run, manage) of the systems and subsystems they make or buy. The enterprise architecture utilizes platforms running on internal and external cloud infrastructures to facilitate this. Multitenancy and segmentation are some of the techniques used to provide platform capabilities to each LoB. As a result, the integration logic and the implementation responsibility also move to each LoB.
However, the platform approach of this fourth stage incorporates centralized governance, security, monitoring and standardization of technology and patterns. It is important to use platforms in such an environment; otherwise, LoBs will start building shadow IT applications private to the function and the IT team will lose control of those applications. Decentralization and autonomy allow each LoB to expose APIs, which cover extended business capabilities. As a result, the organization starts providing more value by facilitating the efforts of internal and external application developers to build applications and provide a digital experience for the end-users.
Whether organizations design one or simply observe what they have in place, an enterprise architecture typically follows these stages of evolution.
In parallel with the enterprise architecture's four-step evolution, there is a change in the type of applications used within each LoB, the number of applications used, and the platforms that support integration and other development needs.
The trend is moving to the cloud by subscribing to software as a service (SaaS) and platform as a service (PaaS) product offerings. Usually, this happens as a three-step process: on-premises, hybrid, and cloud.
Collectively, three trends—the rapid rise in cloud services adoption, the increasingly agile and decentralized nature of corporate cultures, and the growing complexity of business problems—are driving demand for cloud-based solutions and integration within the enterprise architecture.
In the next article, we will look at an enterprise iPaaS reference architecture and highlight some 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 an EiPaaS.
Try out Choreo for integration - A developer-friendly platform to build, deploy, and manage integrations quickly and easily. Create scheduled tasks, reusable APIs, or event-driven integrations. Build, deploy, run, and observe seamlessly in serverless, multi-cloud, and multi-environment setups.
This article was first published on The New Stack.