To clarify, someone with a PHD and architect title came up with a system that had 8 layers server side. The actual programmers coded up two of them on top of each other as simple 1:1 mappings using objects with different prefixes, and a third layer on top of that which was usually 1:1, but occasionally not. They did plenty of other odd stuff like stored all values as a string rather than using any database data types on the off chance they would port or a different database.

Anyway, I worked for the same company and very occasionally helped some friends on the team, but was not really directly involved day to day or even most months.

A PHD does not make you an "architect." There's no formal design theory around "layers" "patterns" or "software architecture" so a person with a PHD does not have a definitive answer to good design or bad design. It is unlikely that anything he studied in school is relevant because such a science or theory doesn't even exist. His answer could be just as good or just as terrible as an engineer. Every architecture or pattern you here about is NOT theory OR Science, it is opinion and opinion only.

I don't have context on what those programmers did, nor do I know whether the 8 layer server side design was good. But I do know that how good a design is, is not influenced by a PHD or a software architect title.

That being said, an 8 layer design points to 8 things that want to be re-used. Typically you just need 3 layers (letters represent types, arrows represent a conversion process from one type to another.):

   IO input -> A
   A -> B
   B -> IO output

I have rarely seen a business case that necessitated 8 layers:

   IO input -> A
   A -> B
   B -> C
   C -> D
   D -> E
   E -> F
   F -> G
   G -> IO output

From my experience those 8 layers are probably garbage and unnecessary. You just need A -> G. You might break A -> G into several components but 8 is overkill.

Likely the architect and the software engineers both don't know what they are doing.

I'll go further to say that no architect will ever reason about "layers" the way I just did because my break down of the design layers above isn't some science. I made it all up, it's basically my opinion and most architects you meet will have either canned opinions from some book or have their own made up reasoning on how it all goes together. An engineer can easily come up with his own opinions and read an "architecture" book as well (which is again basically reading someones opinion). The "architect" title is a BS title that implies an "architect's" "opinions" are better than an engineers. It's not and from what I've seen in the industry an architect rarely has better design chops then an engineer. It's all relatively equal.

That being said there is some formal theory on network topology and graph theory that can say something definitive like this graph has faster output than another graph but rarely is it used or applicable in most web apps.

I was specifically using this guy as an example of someone with a job title that said “Architect” going through the motions that was terrible at his job.