This article describes justified definitions for the terms ‘architecture’ and ‘engineering’ in software. They are well-founded in Civil Engineering / the Building industry – their original source. (750 words)
As enterprises – that is: large-scale organised activities – software engineering and civil engineering are similar. So some transfer of higher-level terminology, and concepts, is not only straightforward but probably useful. Software can gain from Building's maturity.
Software development has adopted the terms ‘architecture’, ‘engineering’, and ‘construction’ from the building industry, but it has been casual and confusing with their use. The original meaning of the words has been overlooked. However, the building industry's example can be followed quite closely in concept as well as word. This can help delineate and situate software engineering, and its related sub-disciplines, more properly and clearly.
Building industry work is separated into, as an idealisation: architecture, engineering, and construction. In practice, these may tend to be merged (for smaller projects) or subdivided (for larger projects). Each is a sub-discipline and sub-sequence and successively dependent on each other, but not sharply defined.
In software the term ‘architecture’ has lacked distinct meaning; it is usually merely a grandiloquence for high-level engineering design. But following building gives it real meaning: it is then the overall external appearance, usage, and function of the software system – it is the ‘what’ – the usage structure. (This was also Brooks' view in ‘The Mythical Man-Month’.) For id's Quake 3, for example, it is the desktop executable packaging, the first-person 3D interface, the game-play, the network multiplayability, the content modifiability, etc.
The term ‘engineering’, in software, is strengthened by having a proper ‘architecture’. Indeterminate matters like requirements and usability are distanced or removed. And it shrinks somewhat into a more well-defined logical realm – it is the ‘how’ – the technical structure. Then it treats only what kind of data is moved, where, and what processing is done to it. These are the truly essential concerns of engineering for software. For id's Quake 3, for example, it is the image rendering techniques, the content data-structures, the network protocols, etc.
This separation of architecture and engineering yields two improvements: It gives engineering clearer and more stabilised requirements, allowing it to work more determinately. And, it concentrates more attention on pure product design – something of pivotal value, yet without a sufficiently prominent identity. Now, the two major aspects of the work are clearly represented, and in a way that is supported by established engineering practice.
To be complete, the remaining third sub-discipline can be considered:
The term ‘Construction’ in software is problematic. In building it is the realisation of a descriptional model into material form. But in software both the model and the product are held in the same digital form. So there is no realisation, so no construction. It would be misleading to use the term in software. Maybe a vestigial form of construction could be seen in wiring-up networks, plugging-in and setting-up hardware. But it does not seem appropriate (or significant) enough to take the name.
On the other hand: from a process/management view, physical ‘construction’ and software ‘coding’ do match quite well. Coding is the detailed end of software engineering design, and building construction also does detailed design. Both bear the majority of time, labour, and risk. So adapting the ‘construction’ term to software could be useful. Furthermore, in building, the stricter separation of construction is a significant source of trouble and inefficiency, so a non-separate ‘construction’ may even be an improvement. But it must always be appreciated that this is an artifact of process and management. For software, there is an essential unity of engineering and construction.