Sometimes speakers make me frustrating when they talk about software architecture and forget about application lifecycle. It happened yesterday at the meet-up.

Gennady was talking about possible duplication of security functions, his topic was the development of secure software, and he provided the picture like:

Telling the story about avoiding duplication of security functions between 2 levels — application server and RDBMS, he called the decision of adopting app server logic to DB level security an achievement of professional database development team, which made it possible. In Gennady‘s case, security logic at RDBMS level was reused.

I’m very sceptical about a long-term success of ideas like that. I wasn’t earlier, but the similar case I had at my last job. There was legacy client-server system + big webshop for customers, connected to the same database. And there were problems with scaling out database (even connection to replica didn’t make life easier, once I will explain why) because tons of business logic was performed inside of it. Tons of. Because of years of development by professional database development team.

Here is the case how architecture flaw can be introduced and stay undiscovered until new workload.

What facts I see in Gennady’s picture:

  1. The new type of workload was introduced. Probably much more user connections.
  2. They made the life of previous application architecture longer.

Relevant question is — how can they be sure, that old architecture is adequate to the new type of workload?

Very probably, at the moment of research targeted to avoid security functions duplication, decision makers were focused on this and other limitations of architecture were undiscovered.

Doing so, staying at previous architecture with the new type of workload, in most cases, you end up with a monster application with super-long lifetime, with a super-high cost of replacement in future. Why do this, having complex research with security integration?

In my opinion, when it comes to adding web customers to a legacy system, best choices are:

  1. Build autonomous system for customers, exchanging with legacy.
  2. Build new system, replacing legacy, ready for the new type of workload.

And choice #1, currently, is my favourite in most situations.

Complex adaptation of old architecture to a new type of workload is not an option, because, strategically, you have to cut the life of old architecture (with all its restrictions, it always have it) sooner or later. Avoid monsters!