Software Architecture and the Disruptive Nature of the Virtual
Software architecture is an odd aspect of software engineering. Given that my family on both sides has been involved in both architecture and engineering longer than most people were aware of the meaning of the words (with a couple of other families they founded the first engineering and architectural company in 1783), and that I have 27 years’ experience as a software engineer, much of it with architecture at least partially involved, it seems reasonable for me to compare architecture as an aspect of software engineering with architecture as an aspect of more conventional civil engineering.
Architects, or as often architectural/engineering firms, which somewhat correspond to software consulting firms, are generally hired for a project based on their history of finished projects: including the overall effect, customers it attracts, etc. While different structural means are used for different building types, they are also used to create different effects and buildings that are attractive to different groups of potential customers within a more general type of building.
To keep things on the mundane level, rather than the more esoteric ‘special buildings’ such as skyscrapers or arenas, I’m going to stay with common loft/townhouse combination condominium developments. Within that area, there are the more modern, open designs where glass is often the most noticeable physical aspect; the more traditional, homey designs where the overt aspects tend to be brick and mortar; and the in between, and somewhat out of favour ‘modern but not too modern’, i.e. still displaying a substantial feel, designs where concrete, glass and various other materials are the most obvious outward aspects.
That the latter is largely out of favour, at least in North America, can probably be traced to its association with various large ‘projects’ from the 1960’s and 1970’s, aimed originally at providing decent low cost housing, but failing to take into account the social idiocy of putting everyone with every type of lack of privilege together in one location, have become notoriously horrid, dangerous places to be unfortunate enough to have to live in.
Within the other two types, while the outward aspects, or eidos, of each is very different, the architectural and engineering techniques uses may be radically different within two developments that outwardly are similar, and quite similar between two developments that outwardly couldn’t be more different.
Since cost is a key factor, techniques often are based more around resource availability in a given area, rather than the eventual effect to be achieved. No matter what the outward eidos is, for instance, in Canada, with the exception of very high-priced developments much of the structural materials are likely to be wood based, due to its flexibility in terms of uses, easy availability, and relatively low cost. In the area of the UK where I originally grew up, by contrast, clay brick is likely to lie at the heart of most such developments, since the soil is virtually all clay, and forestry is a distant collective memory. The skill of a given architectural/engineering firm, then, is often based on being able to achieve a specific desired effect no matter what materials can be used with reasonable cost.
Brick, for instance, in Canada is usually a ‘strong façade’. While not a ‘mere’ façade as it often is in areas of the southwest U.S. where I lived for a number of years, due to the harsher climate in Canada it is not the main structural material in such developments as it is in northwest England. The amount of wood used structurally in Canada, similarly, is higher than in the southwest U.S., where it is used either as part of the eidos primarily, and structurally only where substitutes such as inexpensive plastics and metals would be insufficiently strong and/or flexible.
Correlating this to software engineering, ‘materials’ include languages, frameworks, libraries; cost factors include availability of developers, productivity of chosen materials, etc. However, the virtuality of software rears its disruptive head firstly in the difficulty of judging such things when core materials are treated the same way as final eidos’, since both are, after all, just software; secondly in the fact that the cost factors are as dependent on popularity and fashion as the choice of core materials.
Some years ago, I was asked to analyze tens of thousands of projects stored in a project repository to determine “why so many projects fail?”. In contrast to the common studies analyzed by Claude Ciborra, where the way the question is posed makes it impossible to determine an answer via the study, in this case posing the question in that manner makes the answer ridiculously simple. The main reason it isn’t known by everyone is that the answer is precisely the people generally posing the question — management.
However, why that’s the case can only be understood in architectural and engineering terms by reformulating the question. The answer is management simply because projects are rarely allowed to actually fail. Instead, at a certain point, depending on how crucial the project is, they are either cancelled or ‘rebooted’. Since that point and the choice of action are management decisions, there is no other possible answer when the question is posed that way. It fails though to explicate what triggers the decision point itself either as averages or in any particular case.
As it happens, the answer largely doesn’t change when the question is reformulated to something like “What factors trigger the decision point to cancel/restart a project, and what architectural and/or engineering decisions lead to those factors becoming significant?”
As in civil engineering, architectural decisions and initial engineering projections can only make the actual building of the structure easier or more difficult. In the latter case, more difficult means at the least more expensive, and at most impossible, which lead to the factors management considers when deciding to cancel/reboot the project.
The reason the answer remains largely the same is that those decisions and projections, unlike civil engineering, are largely made by management in the first place. Architects, engineers and programmers are hired after the decisions are made and are chosen simply by their familiarity with the chosen materials. Since those hired are most familiar with the proposed materials they are unlikely to question them, and even if they do, concerns are unlikely to be welcomed by either the rest of the team or by management. Since management, however, lacks the technical acumen to determine the best available materials, materials are chosen largely on the basis of fashion and popularity.
Although availability and relative cost of developers is often given as a reason for choosing fashionable, popular technologies, it’s a red herring. Since architects, engineers and programmers have to earn a living, they have to become familiar with whatever is considered fashionable and popular, rather than learning what their developing judgement tells them is the better technology of a given set. As a result, responsibility falls back almost completely on management.
