Thanks for the clarification on data modeling. I have worked with database experts, but do not consider myself one. From your description, I think that “conceptual” and “logical” modeling from the data modeling field overlap with what the architecture folks might call “domain” and “type specification” modeling. Unfortunately everyone who writes a book uses a slightly different term. It’s not surprising, though, that people with different specialities converged on the same basic ideas.

Personally, I think it’s better to think of architecture as a sub-field of design, rather than an independent and completely different beast. There is a big distinction between talking about the world without your system — conceptual modeling or domain modeling — versus the world with your system. The truth in conceptual/domain modeling should be enduring, like “doors can be opened” or “cars have wheels”, and will not change whether or not your system exists. It is useful to talk about architecture, because they are the largest-scale design decisions you make and there are techniques that work there that do not work in detailed design, but architecture is still just a part of design.

From that perspective, the question of whether or not (physical) data modeling is architectural is somewhat academic, because it is a design activity, and you can call that activity architecture, design, data modeling, or Henry. (It may be relevant to process definers, because they will want to say that Person X will do Activity Y during Phase Z). Perhaps the blog posting could have been more clear: We model architecture because it helps us deal with complexity and scale, so we necessarily reach for models that help us condense details rather than models that ask us to make detailed representation decisions.