Before we continue on our integration journey, we need to first understand how it is possible to attain a level of communication between different systems.
At first, there was a straightforward method of bundling all code together; the monolithic infrastructure.
Monolithic infrastructure refers to a type of software architecture where an entire application is built as a single, self-contained unit. This means that all the different components of the application are tightly integrated and interdependent, and any changes or updates to the application require the entire application to be rebuilt and redeployed.
A monolithic application might be a software system that handles all aspects of the Christmas tree farm’s business, from managing inventory and orders to processing payments and shipping trees. All of these different functions would be tightly integrated and dependent on each other within the same software system.
While monolithic infrastructure can be a simple and straightforward way to build an application, it can also be inflexible and difficult to scale as the application grows. Taking a process down would result in the whole infrastructure to halt. Any changes to the application require the entire system to be rebuilt and redeployed, which can be time-consuming and disruptive.
Whereas the monolithic infrastructure was once a major part of the IT world, it is not that dominant anymore. In recent years, many businesses have moved away from monolithic infrastructure in favor of more modular and scalable architectures, such as microservices or containerization. These architectures allow businesses to break down their applications into smaller, more flexible components that can be updated and deployed independently of each other.
With the need to keep things working around the clock, there has been a more convenient choice in the infrastructure world: Service-oriented architecture.
Imagine you are building a big Lego castle. You have many different Lego pieces, like bricks, windows, and doors. To build the castle, you need to put all these pieces together in the right way.
Service-oriented architecture is kind of like building a big Lego castle. But instead of Lego pieces, you have different computer programs that you want to use to build a bigger program. Just like with Lego pieces, you need to put these programs together in the right way to make a bigger program.
In Service-oriented architecture (SOA), each program is like a little worker that performs a specific job called a ‘service.’ Each service can communicate with other services and collaborate to achieve goals. It’s like all the little Lego workers building the castle together by passing the bricks and tools they need to each other.
SOA is a way of building large programs by assembling smaller programs that work together and communicate with each other, just like Lego workers building a castle.
By breaking down the code into smaller building blocks, Service-oriented architecture aims to create a robust, interconnected structure that also serves as a foundation for creating new processes.
To revisit the Christmas tree farm example, an SOA approach might involve breaking down the farm’s software system into smaller, independent services, with each service handling a specific aspect of the business. For instance, there could be a service for managing inventory, another service for processing orders, a service for managing payments, and a service for shipping trees.
These services would all communicate with each other through standardized interfaces, which would allow them to work together seamlessly even if they were developed using different programming languages or technologies. We can bundle these reusable business services into more advanced processes. For example, the Christmas tree farm might want to allow only non-mobile users to cancel orders, whereas mobile users don’t get this functionality. We can create both advanced processes by using the same reusable services.
Using an SOA approach can have several benefits. It allows for greater flexibility and scalability as the application grows since each service can be developed and deployed independently. It also allows businesses to reuse existing services across different applications, which can save time and resources in the long run.
In the process of selling a tree, we want the underlying reusable business processes of the warehouse storage and the finance department to perform an action as well:
- Remove one of the trees from our warehouse database
- Add the sale to our balance sheet
Most of the time, this is done through the use of a middleman: application programming interfaces, or APIs for short.
