As explained in the post on Postmodern ERP; a cloud-based ERP solution does often consists of many different IT applications that interact together towards a core ERP-system. Therefore, the architecture for the whole portfolio of software must be taken into account when an organization is deciding, designing, and implementing a new ERP-based business solution in the cloud.
These overall architecture decisions should be made as early as possible in the project phase, and preferably when starting the planning of the new ERP/IT solution.
Starting an implementation project without having clear architectural guidelines for the solution may lead to a project organization consisting of people with different visions, ideas, and interests to defend. This will again end up in a project with a large variety of more or less incoherent solutions and technologies that must be managed and often defended against questions and other suggestions from the management, project members, and other parties throughout the implementation period.
By deciding the architecture and anchor these decisions into the organization early on, you can ensure that the project members and the surrounding organization will work towards a common goal, that again will help you to ensure the success of the project.
This planning ahead will make it easier to utilize the available technology, competencies, and resources that already are available in your organization. A well-made solution architecture will also be easier to operate and develop the solutions after it is implemented, in comparison to a solution that has arisen more or less randomly throughout the project period.
Therefore, making some conscious choices about the overall architecture at an early stage will help the success of the business solution in all phases of its lifecycle.
The illustration below shows some basic architecture patterns that are commonly used when making a business solution in the cloud.
The image above shows four basic architecture patterns you can follow when making business applications in the cloud, these are:
- You can create a single software application that covers all requirements; or if possible, buy an off-the-shelf software for this. This choice relates to what is described as “Monolithic” in the figure above.
- You can develop the solution through a “Service-Oriented Architecture” (SOA) where you have several different services and -applications that interact via a service bus to fulfill the users’ requirements. Such an architecture will open for combining both off-the-shelf software as well as in-house developed components in the same solution, as the various parts can be coordinated via the service layer and share data through common databases.
- Microservices continues the service-oriented path by creating separate microservices with dedicated databases for each function in the solution. Through such an architecture you can be able to gradually expand the functionality as the requirements arise through adding more microservices to increase the number of functions. Using microservices can also help you to ensure a better uptime of the solution, by designing the solution so that if one microservice fails for one user, this will not affect other microservices and/or other users that are working with the solution. The use of micro-services does usually requires access to a skilled in-house development team since it is less possible to use off-the-shelf software to construct this architecture pattern.
- The last choice is to use serverless applications to create your solution. This is illustrated at the far right of the figure. Serverless applications are applications where the infrastructure and platform aspects are managed by the cloud. In this way, you do not have to consider the underlying technology in the same way as for other architectural choices and can therefore focus on creating the functionality of the business solution. Serverless applications can be “No-Code” or “Low-Code” applications where you only need to configure the application, without any need for programming any code to set up your business solution.
It is normal to combine several of these architectural patterns in a complex “Postmodern” solution design. Nevertheless, it is important to make clear choices when it comes to which architecture patterns to use wherein the solution, as there are different advantages and disadvantages for each of these. The table below summarises some of the advantages and disadvantages of the mentioned architectural patterns.
| What | Advantages | Disadvantages | Example: a case management solution |
|---|---|---|---|
| Monolith | – Relatively simple to develop and maintain – No need to integration and movement between the solutions parts – Easy to develop a solution with low latency and high performance | – Man be hard to change or add functions after the solution is put into use – Har to build-in or combine with other technologies that was not originally a part of the design – If one part of the solution fails, the whole solution do normally fail for all users | – You modifies the case management in your current ERP-system to fulfil the requirements your organisation has for this |
| SOA | – Make it possible to re-use functions and applications that have been part of old- or other solutions – Can be flexibe to maintain and further develop since the solution consist of several parts – Opens for combining off-the-shelves- and custom-developed applications in the same business solution | – Do often result in a complex solution architecture with several software packages and technologies the should act together – Can be more expensive to realise than e.g. (if possible) using an monololith software for solving the same functions – A good latency and performance can be harder to achieve compered to other architectural patterns | – You use separate several software applications for each type of case management in your organisation, and integrates these by using a middleware-software (e.g. Mulesoft or simlar) as a service bus |
| Microservices | – Possibility to use different teams for development, test and rollout of different functions at the same time – Allows for gradually increasing and changing the functionality of what for the user seems like one solution, with an almost limitless potential expanding the functionality – A potential of superior uptime of the solution. E.g. a fail in a microservice for one user will not necessary affect the other users at all | – Requires a high level of focus to be executed right, and do often end up in use of several development teams using different programming languages, different technologies, etc. – Hard to mix with off-the-shelves software packages – I may be hard to achieve high security (depending how the architecture is structured, and especially how the API gateway is executed) | – You develop several microservices for the case management using Java-programming language and deploy these on a Kubernetes server on the cloud-platform Amazon Web Services (AWS) |
| Serverless | – Easy to develop and roll-out in the organisation – Low development cost (“NoCode”/”LowCode”) – Easy performance scaling | – Can increase the “Lock-in” to the cloud plattform provider – May be difficult to calculate the actual could platform cost – Not suitable for all kind of functions. Currently most used for tasks with limited volume and intensity | You are using tools like Microsoft Logic Apps, Microsoft Power Platform, in combination with Microsoft 365 and Teams to create the caste management solution |
As mentioned, all of these architectural patterns can often be combined in a single solution. If we extend the example in the table above with a solution that should both handle accounting as well as case management in the cloud: You can then e.g. choose to use a Cloud ERP-system (“monolith”) for managing the accounting part, while making a solution for case-management using a custom made “Microservices” application, in combination with some “Serverless” functions. Simultaneously you can integrate the accounting functions (in the ERP-system) with the microservices and serverless for the case management through a service-bus in what reminds of an “SOA” architectural pattern.
Creating good business software architectures do often requires special competencies that are not easy to maintain in-house, so most organization is getting help from outside when laying out the architecture and solution strategy of their solutions.
Most IT-consultant firms can help you with that. Alternatively, you can always contact me by clicking on this text if you need help with the Cloud- or ERP-solution architecture in your organization.