A Tale of Two Architects: Computer Science vs. Civil Engineering

The difference (in software engineering) between architecture and design has recently been topical for me, and in looking at this I’ve come to realise that peoples thinking on this is heavily influenced by another comparison involving architecture: Computer Science vs. Civil Engineering.

This raises a number of questions and interesting points that I want to explore here, apart from the obvious “how do they compare”, including:

• Did we (computer nerds) “steal” the term architect?
• Is it fair to compare the two kinds of architect / architecture?
• What are the less obvious similarities?
• What are the less obvious differences?
• To what extent has legacy thinking distorted our view?

Hopefully at the end of this we’ll all be better informed of how the two architects relate, and we’ll be able to use comparison more effectively in our own thinking and how we explain what we do to those less informed than ourselves.

A Microsoft outsider, the new chief software architect was handpicked by Bill Gates to retool the Windows giant for the 21at century. Gates calls Ray Ozzie "one of the top five programmers in the universe."
Photo: Wired / Lionel Deluy.

"Skin-House" (2005) by Japanese architect Yasuhiro Yamashita

As a starting point, let’s begin with the predictable opening gambit of some textbook definitions:

Architect / Architecture:

From Princeton’s WordNet:

• Architect - someone who creates plans to be used in making something.
• The discipline dealing with the principles of design and construction and ornamentation of fine buildings.
• In computer science, Architecture is the structure and organization of a computer's hardware or system software.

From Wikipedia:

• An architect is trained and licensed in the planning and designing of buildings, and participates in supervising the construction of a building.
• The art and science of designing buildings and other physical structures.

The 5th edition of the Penguin Dictionary of Architecture and Landscape Architecture concurs, in its definition it describes architecture as:

“…encompassing the totality of the designed environment, including buildings, urban spaces and landscape.”

Clearly (for me at least) the main points are that architecture encompasses:

• Both the related processes and products (architecture can exist “on paper”; the architectural “product” is not necessarily the final implementation).
• The disciplines and principles that support those processes and products.
• Architecture goes beyond what we might call the underlying “structure” of something (in itself); it includes the totality of the environment in all aspects – to some degree.

The final point that forms the foundation is that of the architectural role: as soon as you start to consciously think about architecture (or begin engaging in the related processes) you are in effect wearing the “architects hat”, you’re fulfilling that role, and that might be just a small a part of what you perceive your overall job to be, or, you might just one of many people all dedicated to the same task.

As far as exclusions are concerned I’m not going to discuss or include formal definitions of “architect” that pertain to professional jurisdictions; such matters are technical details which are only really relevant within those fields, we can discuss the topic at hand sufficiently without them.

Did we “steal” the term architect?

“… real architects - y'know, the ones we stole the name from.”

- Jason Gorman, http://parlezuml.com/blog/?postid=559

Jason’s comment has negative connotations which I don’t think are warranted; firstly he supposes that software architects are not real architects, and secondly that our use of the term is illegitimate.

“We” refers, of course, to the builders of websites, applications and ERP systems, and not those of churches, factories and skyscrapers.

The short answer is no.  Exhibit “A” in my case is the origin of the term “architect” itself:

Etymologically, architect derives from “architectus” (Latin), itself derived from “arkhitekton” (Greek), in which (arkhi is chief or leader, and tekton is builder or carpenter), i.e. chief builder.

This directly implies that the origin of the term architect is “chief or leader”, if we consider what our “leaders and chiefs” do we find that it’s usually not low-level tasks and dealing with detail, but rather the higher-level ones; the ones that will be harder to undo.  So in a leadership sense, the use of architect in the domain of computer science is valid.

Assuming the leadership aspect of an architect is no longer in dispute, we now come to the aspect of domain – architecture originated in the civil engineering space (the design and construction of homes, factories and so on, and ignoring the arguably older engineering discipline of military engineering).

If you actually consider the architectural similarities in both civil engineering and computer science: the relative types of inputs and constraints, processes and “on paper” results, it’s hard to argue that the role of the architect is any different between the two.  As an exercise, I’ve walked through the general process of architecting, side-by-side, a bank: both its physical structure and its banking software.  Try walking through the “Bank Building” example (see the appendix below).

As is well known, buildings originated before the advent of computer science (if we use the digital computer as the starting point).  Had it been the other way around would we effectively have the same issue?  Computer geeks laying siege to the use of architect in civil engineering circles?  Can we really see ancient Greeks in such a position?  Obviously not, although it does make you wonder – the advantages of being first, perhaps.

It’s worth noting that computer science isn’t the only entity guilty of using (or “stealing”) the term architect:

• In his book “The Great Terror” Robert Conquest refers to Stalin as the “architect of terror”.  
• Former U.S Defence Secretary Robert McNamara has the reputation of being the primary architect of U.S. involvement in the war in Vietnam.
• George W. Bush publicly thanked Karl Rove calling him "the architect" in his victory speech, after defeating John Kerry in the 2004 presidential election.
• Many Christian theologians and apologists view their God as the Grand [Great or Supreme) Architect of the Universe.
• Darl McBride is known as the architect and public face of The SCO Group's misguided campaign and litigation against Linux.

The term architect is therefore widely used outside of the civil engineering domain.  (I’m not aware of anyone objecting to the use of the term architect in any of the contexts listed above – but that’s hardly a surprise; I’m probably only aware of resistance to use of the term in the software domain as that’s the one I work in).

This aligns with the fact that cultures often reuse terms across different fields of endeavour - giving them new meaning, such as: pipe, table, column, fork and farm.

But such arguments are merely a warm-up for the main event.  The single biggest, most plainly visible distinction is the obvious difference between a building and a computer system.  Let’s face it – there’s very very few people I can think of that can’t see the difference.  I suggest that this obvious difference is in fact irrelevant, and improperly distorts our view.  Because it’s so visible it blinds us to the differences and similarities that actually matter.

It’s true that a building is more physical than an application – it’s not like we’re likely to take two skyscrapers from different parts of the earth and vertically integrate them – as we might integrate core line of business applications in the event of a merger.  That’s a distinction that is valid, and presents software architects with a specific type of challenge that their colleagues in the civil engineering space are unlikely to face.

Artists work in many different media: paint and sculpture, for example.  One might paint in oils, watercolour or acrylic – or draw in pencil, graphite, charcoal or pastel; a sculptor might work in bronze, plaster, stone or wood.  To suggest that one is any less as artist than another based on material is clearly absurd.  The fact that many photographers and graphic artists use digital media doesn’t make them any less of an artist, does it?

Certainly in times gone by, simply the style one painted in could deem them an outcast in the art world – now they are seen as among the greats; what would Da Vinci or Michelangelo have made of Picasso or Matisse?

To claim one is not an architect simply based on the material they work in is surely not a valid argument.

Buildings and applications (and their architectures) have much in common once you strip away the physical dimension.

• You can live in a house, you can live in software (how many hours do you spend on Facebook or in a game)?  
• Both are used as a place of work.
• Structural architecture and choices affect aesthetic options and execution.
• The local (national, global) environment will naturally add a variety of constraints on both.
• Both have cross-cutting concerns or specialist areas: plumbing, electrics, ventilation; logging, authentication, encryption and validation.
• They equally have (and need to meet) various execution and evolution qualities (often referred to as the “illities” is software circles), although a building doesn’t “execute” as a program does it is still used:
• Transaction volumes: how many people use the space?  Peak traffic periods - such as those of a major subway station or transport hub; Search engines, EDRMS systems, online banking websites. 
• Resilience: ability to withstand certain levels of water on the roof (extra weight), structural integrity; component failover.
• Security: defence against terrorist threats, bombs; DDOS, Intrusion attempts, user authentication.
• Protecting Inhabitant / user privacy.
• Availability: can the bridge be used in high-wind conditions?  When can the system be taken down for maintenance?  The number of lifts; the number of load-balanced components.
• Usability: sufficient floor space, ceiling height, materials; application flow, information structure, appropriate UI technology selection.
• Accessibility for people with disabilities: wheelchairs, the blind.
• Maintainability: both civil structures and software systems need regular maintenance: such as Bridge repainting, building refurbishment; purging system logs, OSX maintenance. 
• Modifiability: adding extensions, changing facades, repurposing for commercial or residential use; changing database technologies, queuing platforms, adding new pages, refreshing the look-and-feel.

One wonders how far you can take the comparison before you end up in troubled waters.  I would be very surprised if there are any software development practitioners out there who haven’t at one time or another been party to a discussion where the system they were working on was compared to a bridge (the classic example often cited here is that you don’t see agile being used by bridge builders).

The place of architecture and its processes are effectively identical across the two domains, although the context of the final implementation is obviously different.  The issue is that people (lay-people in particular) often fail to identify the point at which the shared process diverges into domain specifics.

If you look at an old stone archway or bridge (specifically those with a visible keystone) you see an architectural that serves in both a structural and aesthetic sense.  Advancements in knowledge, materials and technologies have expanded the range of reference architectures for bridge building; it has allowed the “separation of concerns” – the structural integrity can be hidden under a façade that aims to deal with aesthetic qualities.  The advantage of this sort of separation has been well understood in software development for some time, although that doesn’t stop people from failing to do so. 

It exposes the fact that well architected (and implemented) buildings contribute to us forming a view of the future that is tied, perhaps unnecessarily), to the past.  Computer science is prone to the same issues – but has the current “advantage” of having less history.  Using civil engineering metaphors with computer science is fine – as long as the correct examples are used.

A final comparison, something that both kinds of architecture seem to unfortunately share, is a (hopefully small) faction of society that “hate” architecture; Marre and Perre seem to hate buildings and their creators, and there seems to be no shortage of those who feel the same way about software.

There certainly seems to be an understandable aversion to the lofty ivory tower mentality that some architects appear to exude, but I don’t think it’s fair to paint all architects with the same brush, nor are architects the only people on earth who can appear so self important.

On a final note; last night my wife was talking about a mutual acquaintance and how he’s “a real architect” (sigh).  I guess that despite the fact that the term architect can be used in other domains, the majority of us still primarily associate the word “architect” with buildings – as originated by the ancient Greeks.

Appendix – Bank Building

Let’s “architect” a bank (a building) and some banking software, side-by-side (and please bear in mind that whilst I have familiarity in the latter I don’t really know how to do the former – from experience).

In both cases we need to identify and appropriately engage with the relevant stakeholders.  We need to know how success is defined for the project, what our main risks are, relevant priorities, and so on.

As far as some of the detail goes: both require an essential structure or presence: the bank needs a basic structure (such as floors, walls and roofs) to protect its inhabitants from the elements; our software will need a similar base structure (a web-based front-end, a place to put logic and somewhere to store data).

They both need to function: the building will need doors for egress, windows for light, and a vault to secure towering piles of gold; our software will need an interface that gives staff egress to the data and functionality, and some protection for sensitive data.

Come to think of it – both will need to pay specific attention to security: protection against theft by staff and outsiders, ways to monitor access and use, verification of identify.  We’ll architect our building so that the vault is deep underground (can’t be easily accessed by digging, drilling, etc) and we’ll only provide one way to access it so that we can more easily control access; for our software we’ll place sensitive data and functionality deep under a layer of authentication and access control (well use a firewall for some basic external protection and we’ll build authentication into the software itself using some security libraries.

Our client is keen to exude a certain brand and aesthetic, we need to convey a sense of security and time-enduring without being overly ‘offensive’.  We’ll base the aesthetics of the bank on the work of Greek architects (yes, a bit staid, I know), but with a modern twist – vast expanses of glass; for the software we’ll stick to clean and functional.

So I guess we’ll be working in concrete and glass with a steel frame; for the software; we’ll use an off-the-shelf Microsoft based system (okay – I’ve never architected a banking system!).

Hmmm, think I’ll leave the interior to a specialist designer; same for the website.
The designer can use whatever they like as long as it fits in with the style I have in mind (see [virtual] attached spec), probably a mix of poured concrete and polished wooden floorboards; and a mixture of WCAG compliant Web-based forms and Sliverlight.

How big is this thing?  Expected number of account holders, their estimated usage patterns (times of day, etc) and staff numbers to match mean we need the bank to be X in size; same for the software, X concurrent users, Y numbers of transactions, Z in terms of data growth.

What if there’s a disaster?  We’ll architect the building in such and such a way to be resistant to magnitude 5 earthquakes and use fire retardant materials where possible.  We’ll include a water based fire suppression system, hooked up to the water mains nearby; for the software we’ll use a fail-over cluster for the primary components (specifically the database), with near real-time replication to an off-site copy.

Both need to adhere to Non-functional Requirements (NFR’s) and in some cases you could even argue they go under the same name, and in both cases we need to perform analysis on them and the possible options we have to meet them.  The whole time we do this we also need to consider other needs, the wider environment (city planning states our building can’t exceed 37 metres in height; and our software needs to meet national banking regulations), it needs to look good and someone needs to actually be able to build the thing.

At this point some would argue that the architects work is done – but those of us with any sense know otherwise, invariably issues will arise that the architect needs to resolve or consult on; having established the architecture the architect must ensure its interpretation is consistent with his vision – which ultimately reflects that of the projects owner and stakeholders.