I disagree. That is one interpretation of an application architecture. However is not the only one. I wrote my Master Thesis on exploring the concept of software achitechture and among the conclusions is that, by necessity, the scope of "the architecture" is not always tangible or strict. It can (but more often is not) be defined for one single functionality, for the database, for the logging, or for every and any part of the application.
The tangible documentation of the architecture is usually referenced on older literature, but modern software solutions have extrapolated multiple layers of complexity and tend to be higher level, thus defining the architecture on a separate set of documents, ideas or mandates is less and less practical (where do we stop if we have an N number of references, do we specify those as well? do we use partial documentation of "obvious" dependencies? what if we need to take over one of those dependencies? where do we stop the abstractions? when is it more pragmatic to make an actual implementation that is self documenting?).
Often architecture is interpreted as "how to organize the project" and for many authors that means the way the project is literally organized on a file system is an implicit declaration of it's architecture. Under that construct, it is completely valid to say that this article defines the application's architecture in it's own realization.
The purpose of my thesis was to explicitly demystify and make the concept of architecture less esoteric, since is supposed to be a tool for a more concrete plan of realization of an application. Another conclusion is that things like a simple diagram could define an architecture and that any author can express it as detailed and using as many tools as the intention (which is express the organization for a purpose) require or was practically desired. Under those circumstances, declaring that this cannot be called architecture is up actually up to the author and whoever receives this information, if it helps clarify how the application works, then definitely serves as the architecture. The recipient of the information cancan request a more concrete definition of any of the parts (but I can hardly find a more concrete way than the code explained). Architecture in software serves the purpose of communication. The tools could be the discussion, articles or diagrams, but that on their own do not exclusively define the architecture.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I disagree. That is one interpretation of an application architecture. However is not the only one. I wrote my Master Thesis on exploring the concept of software achitechture and among the conclusions is that, by necessity, the scope of "the architecture" is not always tangible or strict. It can (but more often is not) be defined for one single functionality, for the database, for the logging, or for every and any part of the application.
The tangible documentation of the architecture is usually referenced on older literature, but modern software solutions have extrapolated multiple layers of complexity and tend to be higher level, thus defining the architecture on a separate set of documents, ideas or mandates is less and less practical (where do we stop if we have an N number of references, do we specify those as well? do we use partial documentation of "obvious" dependencies? what if we need to take over one of those dependencies? where do we stop the abstractions? when is it more pragmatic to make an actual implementation that is self documenting?).
Often architecture is interpreted as "how to organize the project" and for many authors that means the way the project is literally organized on a file system is an implicit declaration of it's architecture. Under that construct, it is completely valid to say that this article defines the application's architecture in it's own realization.
The purpose of my thesis was to explicitly demystify and make the concept of architecture less esoteric, since is supposed to be a tool for a more concrete plan of realization of an application. Another conclusion is that things like a simple diagram could define an architecture and that any author can express it as detailed and using as many tools as the intention (which is express the organization for a purpose) require or was practically desired. Under those circumstances, declaring that this cannot be called architecture is up actually up to the author and whoever receives this information, if it helps clarify how the application works, then definitely serves as the architecture. The recipient of the information cancan request a more concrete definition of any of the parts (but I can hardly find a more concrete way than the code explained). Architecture in software serves the purpose of communication. The tools could be the discussion, articles or diagrams, but that on their own do not exclusively define the architecture.