Make your applications future-ready

Functional Decomposition

A popular strategy to overcome challenges of monolithic architecture is by functional decomposition of the legacy application into a set of loosely-coupled, collaborating services.

Functional Decomposition 1

Functional decomposition enables you to adopt modern design paradigms such as user-centricity, domain-driven design, and platform thinking to decompose the application into functional services:

  • by business capabilities
  • by application’s business sub-domains
  • by use cases

It is ideal to define a service in such a way that it has a clearly defined functionality, with its own database, and which can be developed by a small 2-pizza team.

Constraints of monolithic code and tightly coupled architecture

Functional Decomposition 2

Legacy software applications often have a monolithic code base with tightly-coupled architecture which are relatively easy to develop, test, and deploy. But, as they become large and complex, numerous drawbacks of monolithic applications become amply evident, such as:

Difficulty in maintaining code base: As the application becomes complex with a large monolithic code base, it becomes very difficult to understand, maintain and modify, especially for newer team members. This results in a natural downward spiral in terms of code quality. With a monolithic code base, it also becomes very difficult to scale the development organization.

Obstacles to incremental changes and frequent deployment: In the absence of modularity, even small changes will need a complete redeployment of the application. This obviously increases the risks associated with redeployment, discourages frequent updates, and either accumulates technology debt or delays important changes to the application. Most importantly, this prevents continuous deployment, which is one of the core application needs in the current business context.

Inability to scale: For applications with a monolithic architecture, scaling is possible only through running multiple instances of the application, which is a very inefficient way to handle transaction and data volumes. The tightly coupled architecture of legacy applications, doesn’t allow for separation of resource requirements (such as CPU, memory etc.), making it impossible to scale components independently.

Barriers to adoption of newer technology: One of the biggest constraints of applications with monolithic architecture, is that they are very often locked-into specific technology choices for a long time. Lack of modularity makes it even more difficult to adopt newer technologies (programming languages and frameworks), resulting in increasing obsolescence of these applications.

Customers

Redefining customer success

Functional Decomposition 23
Functional Decomposition 24
Functional Decomposition 25
Functional Decomposition 26
Functional Decomposition 27
Functional Decomposition 28
Functional Decomposition 29
Functional Decomposition 30
Functional Decomposition 31
Functional Decomposition 32
Functional Decomposition 33
Functional Decomposition 34
Functional Decomposition 35
Functional Decomposition 36
Functional Decomposition 37
Functional Decomposition 38
Functional Decomposition 39
Functional Decomposition 40
Functional Decomposition 41
Functional Decomposition 42
Functional Decomposition 43

Get in touch

Font
  • A  A  A