Thoughts on Software Architecture
Software architecture has been there since 1960s when someone in a NATO software engineering conference compared civil architecture to a relevant design in computer science. However, the term was not popular until 1990s.

In 1960s Ernest Dijkstra -who all computer students know him for his graph algorithms- from a mathematical point of view emphasized that getting the structure of the system is critical.
As someone who has been going through policies, standards and compliance rules, I looked up the original definition for software architecture and found IEEE 1471 from 1995. In 2011, IEEE 42010 revised previous definition and then, computer scientists agreed on this this definition:
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
However, as a data architect, I should mention that there is no word like “architecting” in formal activities defined for software architecture. Back to the standard, there are various activities that are in general called as above. Here is the list of those activities:
The process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle (i.e., “designing”)
However, as a note to myself, this process starts from conceiving and definitions. These are dependant on the requirements and therefore, the process cycle requires somewhat clear input in each round. I can imagine if the requirements changes throughout the cycle, we should let the cycle continue and work on the changes in the upcoming cycles.
The other note is about the cycle that could go under revisions and various rounds. Architecting is a cycle, likewise other software SDLC known methods.
