Part 1 – InApps Technology 2022

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.

Enterprise Architecture: An Architect’s View

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.

• Business architecture is the first step in converting strategy into executable units that we call ‘projects.’ Previously, business analysts drove this exercise; however, with time, business architects have come to own this. The business architecture looks at the internal organizational objectives, consumer demand, partners and ecosystem behavior while building the business blueprint. The business blueprint consists of strategies, outcomes, initiatives, objectives and key results (OKRs) and value stream generation. Most importantly, a business architecture provides the “why” factor for the technical teams to make decisions.
• Information architecture defines the exchange, storage and processing of information in an organization. Some architects refer to this as a data architecture, but a data architecture is a subset of an information architecture. Data architecture defines new data sets or identifies the data sources to fetch data from systems of record (SOR) layers and fulfill the business services’ data needs. Once the essential characteristics are fulfilled, an information architecture can extend to various advanced data science techniques, such as machine learning (ML) and artificial intelligence (AI).
• Application architecture transitions the business capabilities to end-users (internal and external) using various channels, such as desktop, web and mobile applications and internet of things (IoT) compatible access points. The application architecture will include applications (whether built, purchased or rented by the organization), application program interfaces (APIs), services (macro/mini/micro) and software development kits (SDKs). Various policies and business logic defined by the organization govern the behavior of the applications as well as usage.
• Technology architecture defines the hardware, system software, and middleware needed to facilitate the business, information, and application architecture demands. Technology architecture looks at modernizing the existing IT landscape by adopting service-oriented (SOA), event-driven (EDA), and microservice architecture (MSA) patterns. It also looks at crosscutting concerns such as security, automation, and observability. In addition to enterprise architects, various technical and non-technical teams define technology architecture; they include infrastructure engineering, database administration (DBA), middleware engineering, and procurement.

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.

The Four Stages of an Enterprise Architecture

“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.

Key Takeaways

• Enterprise architecture converts business strategy into a value stream generation outcome by creating the foundation to execute various IT initiatives and processes.
• Integration (and APIs) are a key feature in enterprise architecture that evolved in parallel with operational change and advances in technology (where cloud systems and cloud applications are seeing increased adoption).

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.

Featured image via Pixabay.