Chapter 2.

Architectures for System Integration

Topic Outcomes
1. Differentiate between monolithic, modular, SOA, and microservices
architectures.
2. Evaluate the suitability of different architectural paradigms for specific
system integration challenges.
3. Understand how APIs enable integration and communication in modern
architectures.
4. Apply architectural principles to design systems that meet scalability,
flexibility, and maintainability goals.

Architectures for System Integration

System integration architectures are frameworks and design principles that enable

multiple software systems, applications, or components to communicate,

collaborate, and function as a unified whole. In today’s interconnected world,

organizations rely on various systems to handle diverse operations such as

customer management, inventory control, and financial processing. These systems

often need to share data and processes to deliver seamless functionality, requiring

integration. Integration architectures provide the blueprint to connect these

systems, ensuring interoperability, scalability, and efficient data exchange. They

address challenges such as differing technologies, platforms, and protocols by

offering structured approaches like monolithic, modular, service-oriented, and

microservices architectures.

The evolution of system integration architectures reflects the growing complexity

of business needs and technological advancements. Early approaches like

monolithic systems focused on simplicity and uniformity, while modular designs

allowed better scalability and adaptability. The emergence of Service-Oriented

Architecture (SOA) marked a shift toward reusable, loosely coupled services,

enabling large enterprises to integrate heterogeneous systems effectively. More

recently, microservices and APIs have gained prominence, offering a lightweight,

decentralized approach to integration tailored for modern, dynamic, and cloud-

based applications. These architectures empower organizations to build systems

that are robust, flexible, and capable of adapting to changing demands.

Developing a new application is all about risk, and selecting the right architecture

is an important step toward success. There are multiple options to consider such

as monolithic, service-oriented, and Microservices architecture, this article helps

you to understand monolithic architecture.

Monolithic vs. Modular Systems

What is monolithic software architecture?
Monolithic software architecture is an approach that builds a software system as a

single, indivisible, and self-contained unit. All the components and functionalities of

the system are tightly coupled and integrated into one executable or library.

Monolithic software architecture simplifies the development, deployment, and

execution of the software, as there is no need to manage multiple modules or

dependencies. However, it also makes the software more rigid, complex, and

difficult to modify, scale, and maintain. In software engineering, this describes a

single-tiered software application. Here, the user interface and the data access

code are combined into a single program from a single platform. A monolithic
application is self-contained and independent from other computing applications. It

is deployed as a single monolithic application.

Monolith is an ancient word that refers to a huge single block of stone. In software

engineering, a monolithic architecture refers to a single unit. The different

components of a monolithic application are combined into a single-tier software

application. Usually, a monolithic application consists of a database, server-side,

and client-side application. All the application’s parts are unified and all its

functions are managed in one place.

Components of monolithic applications are interconnected and tightly coupled,

which helps the software to be self-contained. All features and components are

developed in a single code base. This is a traditional solution for developing

software applications, but some developers find it outdated. However, we found

that a monolithic architecture is an ideal solution in some circumstances.

Pros of a monolithic architecture

Simpler development and deployment

All features are developed in a single codebase, which makes it easier for

deployment. With a monolithic architecture, developers don’t need to deploy

changes or updates separately, as they can do it at once.

Cross-cutting concerns
Most applications require fewer cross-cutting concerns, such as logging, rate-

limiting, authentication, authorization, etc. Monolithic applications incorporate

these concerns much easier due to their single code base. It’s easier to hook up

components to these concerns when everything runs in the same application.

Better performance
An app with a microservices architecture might need to make 50 API calls to 50

different microservices to load each screen, for example, which obviously results in

slower performance. Monolithic applications allow fast communication between

software components due to a single code base.

Cons of a monolithic architecture

Large Codebase
In course of time, more features are developed and their structure becomes

blurred. The codebase gets cumbersome over time and becomes difficult to

understand and modify.

Technology Constraint
If there’s a need to add some new technology to your applications, developers may

face barriers to adoption. Adding new technology may require reconstructing the

whole application, which is costly and time-consuming.

Limited Agility
Every change requires full redeployment of the whole application. Thus, all

development teams have to wait until it’s done. Agility can be reduced greatly

when several teams are working on the same project.

Example:
A traditional e-commerce website built as a monolithic application might have:
 A single codebase that includes modules for user authentication, product
catalog, shopping cart, order processing, and payment.
 All parts of the application are interdependent and run as one large process.
Characteristics:
 If you want to update the payment system, you have to rebuild and redeploy
the entire application.
 A bug in one part (e.g., the shopping cart) could bring down the entire
application.
  Scaling is done as a whole—if traffic spikes, you have to scale the entire app,
not just the parts that need it.
The monolithic architecture isn’t outdated, and it is still an ideal solution in some

cases. Some giant companies still stay monolithic despite today’s popularity of

microservices. Monolithic architecture can be beneficial if you are at the founding

stage, you’re building an unproven product, and you have no experience with

microservices. This solution is perfect for startups that need to get a product up

and running as soon as possible. However, certain issues mentioned above come

with the monolithic approach.

What is modular software architecture?

Modular software architecture is an approach that divides a software system into

smaller, independent, and reusable units called modules. Each module has a well-

defined interface and functionality, and communicates with other modules through

standardized protocols or APIs. Modular software architecture allows developers to

build, test, deploy, and update each module separately, without affecting the rest

of the system. This enhances the modularity, flexibility, and extensibility of the

software, and makes it easier to adapt to changing requirements and technologies.

A similar benefit is maintainability. If you have a monolithic application like this,

where you have all these layouts on the left figure, and when you reach to dozens
and hundreds of layouts, it's going to be very hard to look at it and understand

what's going on. Instead, if you group those layouts based on what feature they're

in (based on the right image), now it will be so much easier. When you're looking

for something, you will find it there. It will never be a long list of weird names. And

that has a new added benefit, which is faster incremental compilation.

How to compare modular and monolithic software architecture?

To compare modular and monolithic software architecture, we can use four criteria:

performance, scalability, maintainability, and complexity. Generally, monolithic

software architecture has higher performance and lower complexity than modular

software architecture. However, modular software architecture is more scalable

and maintainable. Performance-wise, monolithic software architecture has less

overhead and latency in executing and communicating within a single unit.

Meanwhile, modular software architecture can optimize the design and

implementation of each module and the communication protocols to achieve high

performance. Scalability-wise, modular software architecture is more flexible as it

can easily add, remove, or replace modules to cope with changing workloads and

demands. Monolithic software architecture requires more resources and effort to

scale up or out the entire system, and may face limitations in terms of hardware or

software compatibility. In terms of maintainability, modular software architecture

allows developers to isolate, debug, and fix errors in each module without affecting

the rest of the system. It also enables faster and more frequent updates and

releases, as well as better code reuse and quality. Monolithic software architecture

makes it harder to identify, locate, and resolve issues in a large codebase. Finally,

modular software architecture has higher complexity than monolithic software

architecture as it involves more design decisions, coordination, and integration

among multiple modules and teams. It also requires more skills and tools to

manage the dependencies, configuration, and deployment of the modules.

Example:
The same e-commerce system built as a microservices architecture might have:
 A user service to handle authentication and profiles.
 A product service to manage the product catalog.
 A cart service to handle shopping carts.
 An order service to process and track orders.
 A payment service to process payments.
Each of these services can be built, deployed, and scaled independently.
Characteristics:
 If you want to update the payment system, you only redeploy the payment
service, not the whole system.
 If the cart service crashes, the rest of the system can still function.
 Scaling is more efficient—you can scale just the product service if that’s
where the traffic is highest.
Comparison Table
Feature Monolithic Architecture Modular Architecture
(Microservices)
Structure Single codebase and deployment Multiple smaller, independent
services
Scalability Scale the entire system Scale individual services as
needed
Maintena Difficult to isolate and fix issues Easier to maintain and
nce troubleshoot
Flexibility Hard to adopt new technologies or Easy to use different tech for
features each service
Risk One failure can bring down the Failures are isolated to
whole system individual services

Summary:
Monolithic Architecture: Everything is in one block, easier to start but harder to
scale and maintain.
Modular Architecture: Divides the system into independent parts, harder to build
initially but more flexible and robust in the long run.
How to choose between modular and monolithic software architecture?
The choice between monolithic and modular software architecture depends on the

context, goals, and constraints of each project. Generally speaking, if the system is

small, simple, and stable, monolithic architecture may be more efficient; whereas if

the system is complex and dynamic, modular architecture may be more suitable.

The team size and culture can also impact the choice: a small, cohesive team may

prefer monolithic architecture, while a large, diverse team may opt for modular.

Additionally, if the technology and environment are homogeneous and stable,

monolithic architecture may be more compatible; however, if the technology and

environment are heterogeneous and evolving, modular architecture may be more

adaptable.

Service-oriented architecture?
Service-oriented architecture (SOA) is a method of software development that

uses software components called services to create business applications. Each

service provides a business capability, and services can also communicate with

each other across platforms and languages. Developers use SOA to reuse services

in different systems or combine several independent services to perform complex

tasks.

For example, multiple business processes in an organization require the user

authentication functionality. Instead of rewriting the authentication code for all

business processes, you can create a single authentication service and reuse it for

all applications. Similarly, almost all systems across a healthcare organization,

such as patient management systems and electronic health record (EHR) systems,

need to register patients. These systems can call a single, common service to

perform the patient registration task.

Service-Oriented Architecture (SOA) is a style of software design where services

are provided to the other components by application components, through a

communication protocol over a network. Its principles are independent of vendors

and other technologies. In service-oriented architecture, a number of services

communicate with each other, in one of two ways: through passing data or through

two or more services coordinating an activity.

Service-Oriented Architecture Patterns

There are three roles in each of the Service-Oriented Architecture building blocks:

service provider; service broker, service registry, service repository; and

service requester/consumer.

The service provider works in conjunction with the service registry, debating the

whys and how’s of the services being offered, such as security, availability, what to

charge, and more. This role also determines the service category and if there need

to be any trading agreements.

The service broker makes information regarding the service available to those

requesting it. The scope of the broker is determined by whoever implements it.
The service requester locates entries in the broker registry and then binds them to

the service provider. They may or may not be able to access multiple services; that

depends on the capability of the service requester.

Implementing Service-Oriented Architecture

When it comes to implementing service-oriented architecture (SOA), there is a

wide range of technologies that can be used, depending on what your end goal is

and what you’re trying to accomplish.

Typically, Service-Oriented Architecture is implemented with web services, which

makes the “functional building blocks accessible over standard internet protocols.”

An example of a web service standard is SOAP, which stands for Simple Object

Access Protocol. In a nutshell, SOAP “is a messaging protocol specification for

exchanging structured information in the implementation of web services in

computer networks. Although SOAP wasn’t well-received at first, since 2003 it has

gained more popularity and is becoming more widely used and accepted. Other

options for implementing Service-Oriented Architecture include Jini, COBRA, or

REST.
It’s important to note that architectures can “operate independently of specific

technologies,” which means they can be implemented in a variety of ways,

including messaging, such as ActiveMQ; Apache Thrift; and SORCER.

Microservices and APIs

Microservices and APIs are two approaches to modular software design. Modular

programming aims to design smaller software components that interact with each

other to perform complex functions. This is more efficient than designing software

as one large codebase for all functions. Microservices are an architectural

approach that composes software into small, independent, highly specialized

services. Each microservice solves a single problem or performs a specific task.

In contrast, an API is a contract of communication between two software

components. APIs specify the data that the software component needs to perform

a function, as well as the expected response. Microservices communicate with

each other using APIs. However, developers also use third-party APIs to integrate

preexisting functionality into their code.

A microservice contains all the code required for a particular application function.

An API is a communication mechanism to access that function. Microservices

expose functionality via APIs so other microservices can use them when required.

How microservices work

Microservice architecture is the evolution of the service-oriented architecture

(SOA). Developers decompose an entire application into individual functions that

run as small, standalone programs. The microservices interact with each other to

perform more complex tasks.

For example, a ridesharing app could have multiple loosely coupled services, such

as ones that retrieve geolocational data, process payments, or send alerts. When a
user hails a ride on the app, all the microservices would work together to help the

user find a driver and make the payment.

How APIs work

APIs are an interface that allow any two software components to exchange

information. An API specifies the communication contract. Developers use the

contract to access specific functionality or data from third-party code.

For example, a ridesharing app could use a payment API by passing customer

credit card details to the API. The code behind the API could securely deduct the

payment from the card and return a success or failure response to the ridesharing

app.

APIs are interfaces for exposing the functionality inside of software components

and applications, whereas microservices is really an architectural approach to

software development.

APIs are actually an essential part of a microservice architecture. Each

microservice in the architecture will have its own API. The API sits in front of the

microservice and allows communication between the different components of the

microservice architecture.
A microservice architecture likely contains many APIs, though APIs can also be

used for other purposes without being a part of a microservice architecture. This is

likely where the confusion comes from when comparing the two.