Original post can be found on the Cloud Native blog.

For enterprises who aim at transitioning away from a monolithic application structure that supports their daily operation into a more cloud-native designed landscape the task at hand can be overwhelming at first. While the initial and technology-centric ideation often primarily focuses on the end-state a large complexity becomes apparent when trying to map out the route from the as-is state towards the to-be state.

Initial high-level ideation

Stepping away from the more technical side and focusing on the high-level ideation architecture the general idea is captured in the below diagram. The focus of this type of high-level ideation is to identify a set of business functionalities that can be perceived as a group and translate them into a business domain that will hold a number of distinct services offered by this business domain.

Even though the general idea of moving towards a model where business domains contain individual services who offer a service to the domain they belong to as well as other domains is a very valid goal to achieve when trying to transition into a cloud-native enterprise architecture it is a highly ambitious goal to achieve in a single step.

Rather than trying to achieve the end-state in a single step, it is highly recommendable to think about a logical evolution that will support the transition from the current state into a cloud-native state. To make the logical evolution transition more achievable and realistic a number of intermediate steps are advisable. The below sections of this post will go, on a high and conceptual level into possible intermediate steps to provide support in the start of building the initial ideation on an evolution transition.

Business functionality domains

An intermediate step in the logical evolutional transition is to define the business domains that are present within your as-is monolith application. Decomposing the monolith application into business domains is primarily focusing on the functional services per business domain and stepping away from the technical implementation of it for a moment.

As a secondary exercise one will need to define how the technical implementation of the identified business domain is done and see to what extent this can be untangled from the larger monolith application. Depending on the type of the application and the way it is technically designed this could be a relatively simple exercise or it could entail an almost full overhaul of the code-base.

To ensure continued momentum in the project and to ensure lowering the risks associated with doing everything in a single project flow it commonly makes sense to start with extracting the most easily extractable business domain. 

Extracting the most easily extractable business domain first to start the decomposition of the monolith application into a business domain-based deployment will result in an intermediate state of a mixed monolith as shown in the diagram above.

The aim of the mixed monolith is to ensure the decomposition of the monolith can be achieved in a phased manner and at a realistic pace while steering away from the need for a big-bang approach. Using the mixed monolith as an intermediate step to a full business functionality domain architecture provides a higher level of control, lowering of project risks, and is better suited in an agile environment.

While achieving the state of a full business functionality domain architecture is a milestone in the evolution it is not the aimed for end-state. The aimed for end-state is a business service domains-centric architecture which will be described in the below section.

The added benefit of the mixed monolith approach is that one can already start, for a specific business functionality domain, to transition into a business service domain-centric architecture while at the same time some of the functionality is still not fully decomposed and is still part of the monolith. When using multiple agile teams who all take the responsibility of a specific domain they can work with their own team-specific velocity and will not be hindered by the velocity of other teams.

Business service domains

As the next stage of the logical evolutional transition is moving out of the business functionality domains and start decomposing the still relatively big and relatively monolith-based functional domains into smaller services.

The services will be grouped together and form a business service domain, all individual services provided in the small business functionality domain monolith will become individual services.

Each and every individual service in a business service domain will ideally be a microservice-based service and can have the form of a container-based microservice or it can make use of a serverless function such as OCI Functions.

By slowly decomposing the small business functionality domain monolith into a full microservice / serverless business service domain you can grow from a single central monolith-based enterprise solution into a full cloud-native model where services are grouped into business service domains.

In conclusion

For enterprises who aim at transitioning away from a monolithic application structure that supports their daily operation into a more cloud-native designed landscape the task at hand can be overwhelming at first.

Applying a logical evolution transition model and ensuring a domain driven design thinking during the transition will take away a large part of the project-related risks and will support a more agile way of decomposing a large monolith-based enterprise application into a cloud-native architecture.

Stepping away from a big-bang approach will ensure fewer risks and a better quality in the end-state while being able to steer and guide the direction of the project without the need for large and complex rework.

From this viewpoint using a logical evolution transition model and ensuring domain-driven design is advisable to consider when undertaking the next step into the direction of a cloud-native enterprise.