Sample business architecture

Our partners are also large companies with automated administration, with several programs running on several machines. We have no interest in their architecture and the technology they use, but we want to integrate their operations. We want to serve them in a way that doesn't require any human interaction for the administration to order goods on either of our sides. To do so, a web service interface is provided that can be utilized no matter what IT infrastructure they use.

On our side, as we imagine the example, we recently replaced our monolithic application with microservices architecture, and though there are still some SOAP-based solutions in the system, most of the backend modules communicate using HTTPS and REST protocols. Some of the modules still rely on asynchronous file transfers done on a daily basis using FTP started from a UNIX cron job. The General Ledger system was programmed in COBOL. Fortunately, we do not need to deal with these dinosaurs.

All this structure is an imagined setup but a realistic one. I made up and described these parts to give you a picture of how you may see mixed technologies in a large enterprise. What I described here is a very simple setup. There are companies that have more than a thousand software modules in their systems using different technologies and totally different interfaces, all interconnected with each other. This is not because they like the mess, but that is the way it becomes after 30 years of continuous IT development. New technologies come and old technologies fade out. The business changes and you cannot stick to the old technologies if you want to stay competitive. At the same time, you just cannot replace the entire infrastructure instantaneously. The result is that we see in an enterprise fairly old technologies still running and, many times, new technologies. Old technologies get rolled out by time. They do not stay forever, and still, we are surprised sometimes when a dinosaur comes in front of us.

What we have to deal with is the two frontend components that we will develop. These are as follows:

Product Information
Order Placement and Tracking

In the following image, you can see the architectural UML diagram of the structure that we look at. The parts we will have interaction with are only the frontend components, but it helps understand the working and their role if we have a bigger picture:

Product Information delivers information about a single product, but it can also deliver a list of products based on the query criteria. Order Placement and Tracking provides functions to place an order and also lets the client to query the state of past orders.

To provide product information, we need access to the Product Catalog module that holds the actual product details.

There can be a lot of other tasks that the Product Catalog does, and that is the reason it is a separate module. It can have, for example, a workflow and approval engine that lets product administrators to enter product data and managers to check and approve the data. Approval is usually a complex process, considering typos and legal questions (we do not want to trade unlicensed drugs, explosives, and so on), and checking the quality and approval state of the source of the goods. Many complex tasks are included that make it a backend module. In large enterprise applications, the frontend systems rarely do anything else other than the very basic functionality of serving the outside parties. But this is good for us; we can focus on the service that we have to deliver. And this is also good for the architecture. It is the same principle as in object-oriented programming: single responsibility.

The Product Information module also has to consult with the Access Control module to see if a certain product can be delivered to the actual customer, and with the inventory to see if there is any product left, so we do not offer a product that is out of stock.

The Order Placement and Tracking also needs access to Product Inventory and Access Control modules to check whether the order can be fulfilled. At the same time, it also needs services from the Pricing module, which can calculate the price for the order, and from the Logistics module, which triggers the collection of goods from the inventory locations and shipment to the customer. Logistics also has a connection to invoicing, which has a connection to the General Ledger, but these are on the picture only to show that the travel of information does not end there. There are many other modules that run the company, all of which are none of our interest at the moment.

Table of Contents for Sample business architecture

Create new playlist

Sign In

Sign Up

Table of Contents for
Sample business architecture