Hi there,
You may find that as you build your workflow it can become huge and unwieldy before you know it.
However, I would like to borrow some ideas from other fields and rethink the size, scope, and units of workflow.
Monolithic systems and microservices
Does the term “monolithic system” bring anything to mind for you?
Those who or whom the answer is “yes” are probably those who are familiar with the infrastructure of systems over the internet.
The services on the internet that we all access on a daily basis are connected to a large answering system called a server.
This system is very well structured, allowing an OS (Linux), HTTP middleware (Apache, Nginx, etc.), databases (MySQL, PostgreSQL, etc.), and server-side languages (PHP, JAVA, etc.) to reside together on a single server.
In addition, it was standard for the functions necessary to provide web services to be stored on a single server. Until about 10 years ago, even a large scale EC site could be operated on two servers, the main server and a spare server.
Well, times have changed and now we are in 2022.
Unlike a decade ago, cloud services have become more common.
For example, the accounting software Freee.
It can be linked to many domestic banks, reducing the amount of time spent on transaction information management. In addition, since Freee itself opens its API to the public, you can use it in communication with your own familiar system.
From the above, it can be said that the era of cloud services, in which services are used only via the internet in addition to operating services within the company’s own servers, is becoming the mainstream today.
The idea of microservices is a bit similar to the use of cloud services described above, in that instead of providing all functions within a single server, separate services are installed for each function and communicate with each other to form an overall service.
As you can see in the diagram above, this has been a monolithic operation.
Each program lives together in a single server to implement business logic.
Microservices, on the other hand, have separate servers for each function (for the sake of convenience we use this terminology, but they can also be called serverless). Each function is provided by its own server, and these servers communicate with each other.
Microservices – Wikipedia
Now, the advantages and disadvantages of microservices are (roughly) said to be the following:
Advantages
- Independence: Team A can modify function A, team B can add function B, etc.
- Maintainability: Clear boundaries with other services limit the scope of impact when adding functions, etc.
- Scalability: Easy to expand machine resources when you want to increase the processing capacity of Function C itself.
- Availability: Problematic services can be disconnected and other functions can continue being run
- Reusability: Only the parts applicable to a particular function can be changed to similar services.
Disadvantages
- Communication: Care must be taken with transaction processing, etc., to communicate with external parties
- As pointed out in Conway’s Law, it is necessary for the organization’s way of thinking to be independent
- Structure: Function A uses this development language, Function B uses a different language from that used in A, etc., so the development tools and interfaces associated with these may be disparate.
Now you have a better understanding of what microservices are.
Let’s start thinking about microservices in workflow.
Concept 1: Create Separate Apps For Each Function
Consider the workflow and business process on the left side in the figure above as a workflow diagram for fulfillment services.
Fulfillment services can be thought of as one large operation, from order receipt to shipping and accounting within the company.
However, it is possible to create smaller apps instead of a single app by following the microservices approach described above and creating separate apps for each function (apps as a state in which the workflow is assembled on the system).
It will be easier to renovate and maintain.
Now, the above figure shows a situation in which an error occurred in part of the actual operation of a large application. In this case, the process that should proceed in conjunction with other functions and departments may stop unexpectedly. On the other hand, if the apps are separated by their functions and operated in accordance with their communication, only the app that is causing the error should be considered a problem. Even if some apps are stopped, other apps can be considered to be operational, so the scope of impact when an error or failure occurs is likely to be small.
2. Integration With External Systems and Services
In the diagram above, we have tried to apply the services provided by each company for each function.
For example, the order interface is implemented by Shopify, etc. The Questetra App is launched when an order is received, and the data is imported and processed on the Questetra App up to the next external service.
In addition, if each functional application is linked with external parties, such as payment settlement and BPO assignments, it is possible to introduce functions that are difficult to produce in-house in a relatively quick manner.
Items to Create a Small Apps in Questetra
In the previous chapters, we introduced one conceptual example of how workflow and business processes (Apps) can be divided based on the microservices concept.
Many of you who have read this far may be thinking “well, I understand the idea”, but in reality it may be quite difficult.
However,
Questetra actually provides many items to realize such a microservice workflow.
Click here for a list of items (parts)
R2010: List of Modeling Elements
Start event group (group of parts provided as standard)
- Message Start Event (HTTP / Webhook / Email / Form)
- Other Start Events (e.g. when receiving Gmail / Google Calendar appointments / adding data to a Kintone record, etc.)
Intermediate Event Group
- Parts that start another existing workflow in the middle of a workflow (number and name may vary depending on each company’s environment)
OAuth2 authentication with external parties
…and so on.
If you have touched APIs in general development, you can make full use of existing parts and APIs of external services to link small applications inexhaustibly (although I don’t think you will link that many).
Great use of business templates
Questetra has prepared a number of workflow App templates that follow the business systems that would generally be created.
These templates can be used free of charge, and in line with the microservices concept described above, existing templates can be divided into a number of Apps and used as a group of Apps with a granularity that is easy to operate in-house.
Questetra Support Site：Workflow App (Business Template)
Workflow Apps (Business Templates)
How was it?
I have tried to write this article by borrowing the good points of microservices in creating a workflow App, but I cannot say that the microservices way of thinking is suitable for everything in the actual work environment.
The appropriate size of the workflow to allow the people on site to perform their tasks without error or stress is determined on a case-by-case basis.
However, when building a microservices workflow you can actually leave the difficult parts to the development team and create the parts that are easy to create within your department, so considering this concept can help improve your business.
I’ll leave it there for now.
If you want to try building a microservices workflow App for free click the button below ↓
See you soon!
