Thoughts on Architecture (I)
Architecture:
...the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them... [Wikipedia]
...the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution... [IEEE 1471]
Bull.
Software architecture is about communication.
Architecture is a tool by which the developer communicates with another developer at another point in time and space. It may be a partner in a shared design session, a maintenance developer six months later, or the same developer a year down the road returning to look over his or her project. It is a language for communicating intent - no more, no less.
What an exceptionally well-chosen term for it! Consider a few choice phrases from the web regarding the term "architect":
"...an architect is a person who translates the user's needs and wants into a physical, well built structure...[such that] he or she is not apt to omit any necessary requirements, or produce improper, conflicting, ambiguous, or confusing requirements." [Wikipedia]
"...Architects see the big picture when it comes to your project. They help you explore what appeals to you aesthetically and what you require functionally." [American Institute of Architects]
Architects in the physical world are responsible for many things. They made sure the building is functional. They make sure that it meets the necessary requirements. They're responsible for eliminating ambiguity, and they are particularly important in the aesthetic realm. Why shouldn't all of these be true in the software world as well? We too easily consider an architecture only by its characteristics: "scalable", "flexible", "performant". But the most important aspect of any software architecture is how it conveys its purpose to the viewer.
Consider this as well. Since architecture is a language to communicate design decisions, shouldn't precise terminology be important? Of course - using the right words is critical. A developer who claims to be an architect but whom cannot be bothered to remember the right terms for his or her design patterns is no more than a dilettante. Consider: if two surgeons consult with each other, how important is terminology? Surely we can agree that a multimillion dollar piece of software deserves a similar attention to detail.
On a lighter note, software architects must consider their audience. Most technical personnel in America pepper their speech with pop-culture references (particularly movie quotes). Metaphor is a powerful communications tool and is often used in both design documentation and code. It is imperative therefore that software architects be familiar with common movie and music references. Professional development has never seemed so easy!
At the end of the day, architecture is a means by which the developer communicates the intent and functioning of the software to another developer. Like all software disciplines - like all software itself - architecture is about people. If the code were never to be read by another developer, what would be the purpose of the architecture? It would be meaningless. This is why we prefer object-oriented design, which allows us to personify architectural elements and use active voices when speaking about their activity. This is why we have so many different attempts to "standardize" the language (e.g. UML) - and, unsurprisingly, like any living language, architecture refuses to be locked into a single dialect. And, of course, like any language, nothing is provably "true" or "false" - which makes our arguments inevitable.
...the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them... [Wikipedia]
...the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution... [IEEE 1471]
Bull.
Software architecture is about communication.
Architecture is a tool by which the developer communicates with another developer at another point in time and space. It may be a partner in a shared design session, a maintenance developer six months later, or the same developer a year down the road returning to look over his or her project. It is a language for communicating intent - no more, no less.
What an exceptionally well-chosen term for it! Consider a few choice phrases from the web regarding the term "architect":
"...an architect is a person who translates the user's needs and wants into a physical, well built structure...[such that] he or she is not apt to omit any necessary requirements, or produce improper, conflicting, ambiguous, or confusing requirements." [Wikipedia]
"...Architects see the big picture when it comes to your project. They help you explore what appeals to you aesthetically and what you require functionally." [American Institute of Architects]
Architects in the physical world are responsible for many things. They made sure the building is functional. They make sure that it meets the necessary requirements. They're responsible for eliminating ambiguity, and they are particularly important in the aesthetic realm. Why shouldn't all of these be true in the software world as well? We too easily consider an architecture only by its characteristics: "scalable", "flexible", "performant". But the most important aspect of any software architecture is how it conveys its purpose to the viewer.
Consider this as well. Since architecture is a language to communicate design decisions, shouldn't precise terminology be important? Of course - using the right words is critical. A developer who claims to be an architect but whom cannot be bothered to remember the right terms for his or her design patterns is no more than a dilettante. Consider: if two surgeons consult with each other, how important is terminology? Surely we can agree that a multimillion dollar piece of software deserves a similar attention to detail.
On a lighter note, software architects must consider their audience. Most technical personnel in America pepper their speech with pop-culture references (particularly movie quotes). Metaphor is a powerful communications tool and is often used in both design documentation and code. It is imperative therefore that software architects be familiar with common movie and music references. Professional development has never seemed so easy!
At the end of the day, architecture is a means by which the developer communicates the intent and functioning of the software to another developer. Like all software disciplines - like all software itself - architecture is about people. If the code were never to be read by another developer, what would be the purpose of the architecture? It would be meaningless. This is why we prefer object-oriented design, which allows us to personify architectural elements and use active voices when speaking about their activity. This is why we have so many different attempts to "standardize" the language (e.g. UML) - and, unsurprisingly, like any living language, architecture refuses to be locked into a single dialect. And, of course, like any language, nothing is provably "true" or "false" - which makes our arguments inevitable.