The Unbridgeable Gap Between Visible and Invisible Architecture

Software architecture usually means the overall internal structure of a system. But there’s also the architecture of its user interface, the external structure. Software development should probably be driven through the user interface to a far greater extent than is the case today, but there is an unbridgeable gap between the internal/invisible architecture and the external/visible.

Peter Bøgh Andersen, A Theory of Computer Semiotics

In A Theory of Computer Semiotics, Peter Bøgh Andersen advocates an approach in which the user interface is central. He sees the interface as consisting of signs, or semiotic “objects,” which the user interacts with either directly or indirectly. He distinguishes between semiology and meta-semiology in the definition of these signs. The semiology defines the features of the signs that either contrasts signs from each other, or contrasts different states of individual signs, as well as the “handling features” of interactive signs. The meta-semiology, on the other hand, defines the manifestation of the signs. Where the semiology would say that a sign differs in shape or color from another sign, the meta-semiology would say that that shape is circular or green. Andersen writes:

[Sign-oriented programming] recommends a particular program architecture. All things being equal, the system should be structured as a collection of computer-based signs, and the specification of each sign should contain at least two main parts: a semiology that describes those parts of the sign that are pertinent to the interpretation of the system processes, and a meta-semiology that describes how the semiology is in fact implemented.

The source code, however, isn’t all about visible things. Peter Bøgh Andersen acknowledges this, but says that “although a component of a system may not be visible to the user and therefore not directly be a sign, its ultimate justification is that it contributes to sign formation.” He uses as example a database search process, which would appear not as a visible sign, but “as a relation between visible signs,” namely the ones representing query and answer. Andersen continues:

[T]his does not mean that the sign concept must dominate in all activities of programming. An analogy to a meta-semiology of natural language, phonology, will be helpful. Phonology is concerned with the physical substance (sound) and production of speech (manner of articulation), in much the same way as programming is concerned with physical states and state changes of the computer system, and it needs concepts like voiced and aspirated that can describe that substance. In the same way, programming needs concepts like list, number, character, record, object, loop, condition, etc. that are good for describing the particular substance of computer systems.

Still higher level concepts than those Andersen mentions are needed as well, to help “describing the expression substance.” But they are always, in his approach, secondary to the signs.

Photograph by João Estêvão A. de Freitas

I have a feeling that this is not entirely unproblematic. A system can be divided into a primary and secondary part, where the primary part contains the signs, and secondary the invisible objects, which would include the mentioned database search process. What about software where the secondary part is significantly more complex than the primary part, where the user interface is very simple, and the internals very complex? What about when there’s a disconnect between the user interface and the internals, when there’s complexity that would make no sense at all to the user? Is it still meaningful to let the signs dictate the architecture?

Photograph by James Hernandez

As I began this post, my intention was to write about the relation between architecture (“real” and software) and process, but after having written about the internal architecture, I felt I had to mention the visible architecture as well. Then I got lost and couldn’t find my way back. But I do, however, feel that the gap has relevance for the fact that software architecture is more about process than about structure. Not that it caused it, but it’s something that has to be considered.

(Photo credits: James Hernandez for the gas pump, and João Estêvão A. de Freitas for the clock, both from stock.xchng. I hope I haven’t offended them by cropping their pictures.)

The above was posted to my personal weblog on March 23, 2004. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)