Enterprise Software Architecture — Generation X and Generation Y ?

Are Enterprise architecture changes kind of aligned with the dominance era of Generation X and Generation Y software engineers?

Applications used to be single or two-tier and applications made calls directly into the database.

Then the N-tier architecture revolutionized the software engineering. Applications (Clients) were communicating over TCP/IP to a service layer. This allowed us to separate the clients applications from the service application physically and it allowed us to scale better. It also allowed us to protect the service layer (where business logic resided) and to allow only certain clients to talk to these services on certain ports.

However, over the years the Enterprise development community kept implementing the “Service” tier as one big giant and exposing different endpoints and claiming that it is a Service Oriented Architecture. This works, but your code-base becomes very tightly coupled. To make this even better there are some steps to take in the right direction.

Vertical-slicing the “Service” giant into small services is the way to go. I understand that this is easy to say when you are starting from scratch, but we know it is a not an easy task if you already have large applications. What does “vertical-slicing” really mean? It means that each service is 100% independent of each other and they can even be coded in different programming languages / development stacks.

The overall goal is always:

  • Keep It Simple
  • Lightweight architecture
  • As platform agnostic as possible

The buzz word out there is “microservices”. It is fine to take good things out of the microservices’ architecture, but if you follow it religiously you might be jeopardizing the simplicity. I am sure this is up to debate. All I am saying is: Identify problems that you need to solve and find a solution for them. If that solution ends up being 50% of microservices architecture or 70% or 100%, then that’s what it is. Just don’t start by picking architecture that solved somebody else’s problems without trying to find a solution yourself.

Below diagram will show you the following:

  • Your business logic broken down into smaller independent services (Right side)
  • Libraries/APIs that are treated as black-boxes and consumed by your code (Bottom of diagram)
  • Your Website code and the Low-level website layer that bridges your website with all the services (Left side)

In the future posts I will go into more details and show examples of how you can organize this using .NET (Visual Studio solutions) or using Python as an open-source example.

Almir Mustafic (https://www.almirsCorner.com)