Software Engineering (?) is a relatively new discipline that has contributed to the vocabulary its own inspired neologisms, starting with the word Software itself. But to give the art and science of building Software an intellectual shape that we can relate to, to situate it firmly within the familiar epistemological boundaries, we borrow terminologies from other disciplines and continue to reemphasize Software's familial connection to the body of human knowledge through such adoption : Engineering, Architecture, Complexity, Pattern, Design.
Some of these adoptions have been trenchantly effective, to the point of significantly enriching their ordinary usages with nuances and "signification" previously absent, for example Complexity.
Software Architecture is not one such example of effective adoption. One might be tempted to say that it is a singularly problematic example of ineffective adoption. In a rather frustratingly (or charmingly, if you are not in the business of calling yourself or others Software Architects and can simply appreciate the irony for what its worth) ironic twist a most rigorous and formal body of knowledge, Architecture, is used in a subjective open-ended manner where the disagreements tend to be strong regarding the very definition of Software Architecture. Which part of the Software development lifecycle is Architecture? The Component Diagrams? And/or the API Specifications? And/or the Object/Data Model? What about the Development Process? Or the Coding Guidelines? All of these? To what degree of specificity and determination? Can we describe the architecture of say a large Enterprise Software in words and diagrams and formulas in a manner that would remain a truthful description of the system throughout the course of its evolution? And if so can we precisely define the criteria for those words/diagrams/formula that can be applied to describe the architecture of all such Software?
Martin Fowler, in his book "Patterns of Enterprise Application Architecture" demonstrates this problem succinctly. To quote: "In the end architecture boils down to the important stuff -- whatever that is. "
But is that formlessness, the fluid boundary, the subjectivity of interpretation of its roles truly a problem? Or rather, it is truly an obstacle? Is this question "Which part of the Software development lifecycle is Architecture?" even a valid question?
Now that we are trespassing into the territory of ideas dominated by Wittgenstein's critique of language and philosophy, his theories of language-games and family resemblance ("Familienähnlichkeit" in the German original) are worth keeping in mind. Referring to the passages 48-83 in "Philosophical Investigations" we see that it is not a single unique, comprehensive set of fully enumerated criteria that characterizes the concept of "game" (or "language") but a pattern of resemblance and resemblance of patterns.
To quote: "we see a complicated network of similarities overlapping and criss-crossing: sometimes overall similarities, sometimes similarities of details". And immediately afterwards, "I can think of no better expression to characterize these similarities than 'family resemblances'...And I shall say, 'games' form a family."
Can Software Architectures too be best understood as such a family, with no precise set of criteria satisfied by all instances but best conceivable through a network of family-resemblance? If we answer yes then we not only obviate the need for answering a question -- namely, "Which part of the Software development lifecycle is Architecture?" -- that leads us nowhere in terms of either understanding technology or positively affecting the process of implementing great quality Software, but it also frees us to improve any given Software Architecture in ways unhindered by arbitrary restrictions and boundaries about what Software Architecture can and cannot be.
Equally importantly such a conceptualization can lead us to certain insights about the qualities that characterize great Software Architectures. No Software Architecture is great in-itself. It is fallacious to point to a poor Product and claim that the Product is poor -- and a Product is poor if its intended users find it to be so -- despite inheriting a great Software Architecture. Whenever such apparent disconnects between the quality of the "Architecture" and the "Product" are cited, the explanations almost always are either (a) that the nuances and sophistication in the architectural abstractions were not reflected in the implementation or (b) the requirements didn't represent the actual use cases. Each of these oft-cited rationalizations underlines this problem of conceiving Software Architecture as an intellectual exercise in itself with conceptual and temporal boundaries for its domain of influence. Those are imaginary boundaries.
The best Software Architectures are the ones that understand the problems of the target users accurately and generate designs that best facilitate the engineers who are supposed to implement the technology.
The oldest known author in the western canon on the subject of Architecture is the Roman architect Vitruvius who in "De Architectura" had identified these three qualities that characterize all good architectures:
Wittgenstein again, passage 71 from "Philosophical Investigations" : "But is a blurred concept a concept at all? Is an indistinct photograph a picture of a person at all? Is it even always an advantage to replace an indistinct picture by a sharp one? Isn't the indistinct one often exactly what we need?"
The venustas in Software Architecture can be its malleability, its flexibility, its mutability with time, with technology, with changing use cases and disruptive technological advancements. It is a departure from the tradition of monolithic component/stack designs where the impulsive monumentalism leads to over-specified, rigid, lugubrious edifices that for all their deceptive, almost mathematical, elegance often turn out to be brittle and unmanageable. Such Software Architectures lead to Products that require the dreaded "re-architecture" every time a significantly disruptive technology enters the fray or even higher orders of performance or scalability requirements are asked for.
In contrast to such monumentalism, an elegant Software Architecture would exhibit the qualities of functionalism, it would allow for organic growth of components and their interactions spanning across multiple releases by facilitating invention, innovation and engagements of the Engineering teams.
A tangible quality of such a "horizontal" functionalist Software Architecture would be the economy of specifications, a judicious usages of ellipsis and omissions, and almost an artistic restraint against presuming all the patterns that might become relevant in future. Not every facet of the component interactions or meta-models needs to be anticipated and solved. Not every single topology traversal algorithm or scaling strategies must be determined a priori .
Debussy is quoted to have said, "Music is the space between the notes.": an awareness that is built on a lucid understanding of the musical form.
The art of Software Architecture can benefit from such lucidity about the value of economy in expression. Not to over-specify or over-design. Not to assume all usage patterns can be easily extrapolated from the current set of use cases, but to infuse the design with the right degree of suggestions and openness such that future disruptions can be accommodated.
Such acts of lucid ellipsis is not antagonistic to rigor, but rather complements it. For to architect a great Software product, it is paramount that we do not architect it too much.
Some of these adoptions have been trenchantly effective, to the point of significantly enriching their ordinary usages with nuances and "signification" previously absent, for example Complexity.
Software Architecture is not one such example of effective adoption. One might be tempted to say that it is a singularly problematic example of ineffective adoption. In a rather frustratingly (or charmingly, if you are not in the business of calling yourself or others Software Architects and can simply appreciate the irony for what its worth) ironic twist a most rigorous and formal body of knowledge, Architecture, is used in a subjective open-ended manner where the disagreements tend to be strong regarding the very definition of Software Architecture. Which part of the Software development lifecycle is Architecture? The Component Diagrams? And/or the API Specifications? And/or the Object/Data Model? What about the Development Process? Or the Coding Guidelines? All of these? To what degree of specificity and determination? Can we describe the architecture of say a large Enterprise Software in words and diagrams and formulas in a manner that would remain a truthful description of the system throughout the course of its evolution? And if so can we precisely define the criteria for those words/diagrams/formula that can be applied to describe the architecture of all such Software?
Martin Fowler, in his book "Patterns of Enterprise Application Architecture" demonstrates this problem succinctly. To quote: "In the end architecture boils down to the important stuff -- whatever that is. "
But is that formlessness, the fluid boundary, the subjectivity of interpretation of its roles truly a problem? Or rather, it is truly an obstacle? Is this question "Which part of the Software development lifecycle is Architecture?" even a valid question?
Now that we are trespassing into the territory of ideas dominated by Wittgenstein's critique of language and philosophy, his theories of language-games and family resemblance ("Familienähnlichkeit" in the German original) are worth keeping in mind. Referring to the passages 48-83 in "Philosophical Investigations" we see that it is not a single unique, comprehensive set of fully enumerated criteria that characterizes the concept of "game" (or "language") but a pattern of resemblance and resemblance of patterns.
To quote: "we see a complicated network of similarities overlapping and criss-crossing: sometimes overall similarities, sometimes similarities of details". And immediately afterwards, "I can think of no better expression to characterize these similarities than 'family resemblances'...And I shall say, 'games' form a family."
Can Software Architectures too be best understood as such a family, with no precise set of criteria satisfied by all instances but best conceivable through a network of family-resemblance? If we answer yes then we not only obviate the need for answering a question -- namely, "Which part of the Software development lifecycle is Architecture?" -- that leads us nowhere in terms of either understanding technology or positively affecting the process of implementing great quality Software, but it also frees us to improve any given Software Architecture in ways unhindered by arbitrary restrictions and boundaries about what Software Architecture can and cannot be.
Equally importantly such a conceptualization can lead us to certain insights about the qualities that characterize great Software Architectures. No Software Architecture is great in-itself. It is fallacious to point to a poor Product and claim that the Product is poor -- and a Product is poor if its intended users find it to be so -- despite inheriting a great Software Architecture. Whenever such apparent disconnects between the quality of the "Architecture" and the "Product" are cited, the explanations almost always are either (a) that the nuances and sophistication in the architectural abstractions were not reflected in the implementation or (b) the requirements didn't represent the actual use cases. Each of these oft-cited rationalizations underlines this problem of conceiving Software Architecture as an intellectual exercise in itself with conceptual and temporal boundaries for its domain of influence. Those are imaginary boundaries.
The best Software Architectures are the ones that understand the problems of the target users accurately and generate designs that best facilitate the engineers who are supposed to implement the technology.
The oldest known author in the western canon on the subject of Architecture is the Roman architect Vitruvius who in "De Architectura" had identified these three qualities that characterize all good architectures:
- Firmitas : Robustness
- Utilitas: Utility
- Venustas: Beauty
Wittgenstein again, passage 71 from "Philosophical Investigations" : "But is a blurred concept a concept at all? Is an indistinct photograph a picture of a person at all? Is it even always an advantage to replace an indistinct picture by a sharp one? Isn't the indistinct one often exactly what we need?"
The venustas in Software Architecture can be its malleability, its flexibility, its mutability with time, with technology, with changing use cases and disruptive technological advancements. It is a departure from the tradition of monolithic component/stack designs where the impulsive monumentalism leads to over-specified, rigid, lugubrious edifices that for all their deceptive, almost mathematical, elegance often turn out to be brittle and unmanageable. Such Software Architectures lead to Products that require the dreaded "re-architecture" every time a significantly disruptive technology enters the fray or even higher orders of performance or scalability requirements are asked for.
In contrast to such monumentalism, an elegant Software Architecture would exhibit the qualities of functionalism, it would allow for organic growth of components and their interactions spanning across multiple releases by facilitating invention, innovation and engagements of the Engineering teams.
A tangible quality of such a "horizontal" functionalist Software Architecture would be the economy of specifications, a judicious usages of ellipsis and omissions, and almost an artistic restraint against presuming all the patterns that might become relevant in future. Not every facet of the component interactions or meta-models needs to be anticipated and solved. Not every single topology traversal algorithm or scaling strategies must be determined a priori .
Debussy is quoted to have said, "Music is the space between the notes.": an awareness that is built on a lucid understanding of the musical form.
The art of Software Architecture can benefit from such lucidity about the value of economy in expression. Not to over-specify or over-design. Not to assume all usage patterns can be easily extrapolated from the current set of use cases, but to infuse the design with the right degree of suggestions and openness such that future disruptions can be accommodated.
Such acts of lucid ellipsis is not antagonistic to rigor, but rather complements it. For to architect a great Software product, it is paramount that we do not architect it too much.
No comments:
Post a Comment