Archaeology as a metaphor for understanding systems.

A number of people have been using the archaeological metaphor as a frame within which to discuss the process by which we understand software systems. I've been discussing this with a colleague of mine on and off for a few weeks and we've come to the conclusion that while this metaphor helps, it isn't the whole picture.

Let's start off by defining software archaeology, and we'll use a dictionary definition to do this[1].

soft·ware ar·chae·ol·o·gy Pronunciation Key (sôftwâr ärk-l-j)
The systematic study of past software systems by the recovery and examination of remaining material evidence, such as code, tests and design documentation.

Using archaeology as a metaphor allows us to reason about how we recover and examine material evidence relating to software projects. As useful as this is, it is by no means the entire story. Many times there exist individuals to interview, and primary and secondary evidence to investigate. These types of activities owe more to historical practice then they do to archaeology. One of the reasons for this is that existing communities in organisations ensure that the investigation of systems is as much about people, existing practice and precedent as it is about tools and artefacts 'dug out of the ground'. As an illustration, consider the UK constitution. The UK constitution defines the form, structure, activities, character, and fundamental principles by which UK society, law making institutions and government institutions operate. Famously though, it is not written down. Instead it consists of a number of bodies, namely the monarchy, the executive, parliament and the civil service, supported by both precedent and law. A student of the UK constitution is rather like someone trying to understand a software system. The student has to talk to experts, study paperwork, identify 'urban myths', analyse past behaviours and cope with the fact that, whilst they investigate it, the constitution is changing. The I find this process, the process of historical study, to be a more compelling analogy than archaeology when considering practical techniques for studying software systems.

---

[1] Even the archaeological community hotly debate the definition of archaeology so this is a working definition, but it is not the only valid definition.

Modeling multiple business perspectives

I've been involved in a conceptual modeling exercise that, whilst moving forward, would occasionally suffer from 'modelers' block. I've been using the following standard approach to help with this.

Problem

You need to build a conceptual model of the key business entities but are finding it hard to bottom out the meaning of these entities due to conflicting viers on the entities semantics.

By modeling the business you are modeling multiple concents, e.g. scheduling, settlement and trading. Each aspect of the business views the entities from different perspectives. You need to obtain agreement on the semantics of the entities and their relationships but this is tough with everyone viewing the model from different positions.

Solution

Model the business from each useful perspective and then reconcile the models.

During the modeling workshop explicitly communicate which perspective people are to view the model from. Work through the model from that specific perspective (an no others). Narrate the place of the key entities in the business process as you go. e.g. Trader under name of a legal Entity does a deal with a counterparty at a given time for an agreed price. This keeps things practical. Once you have got as far as you can from one perspective then switch perspectives. Start with a clean sheet, as building from one model (adding perspectives as you go) forces you to reconcile models 'on the fly' - which is very hard and prone to failure. Once you have models for each perspective ready, merge them together. Where they don't match, reconcile the perspectives through a workshop.

Resulting Context

By making the perspective you are modeling from explicit you have partitioned the modeling activity into a few easier modeling problems. When you recombined the different perspectives you forced the business to reconcile the different perspectives in a controlled way. The result being a conceptual model for the business that all aspects of the organisation can buy into. In addition, the different pre-reconciliation models tell a story of how the design was developed - and are useful when explaining the model to the unitiated.

Incorrect Application

Using too many perspectives.

Switching perspectives continually in a modeling session.

Known Uses

Syntropy uses different model perspectives (rather than business perspectives) to ensure modelers know what aspect of the modeling activtiy they are address.

Large global organisation is currently building a conceptual model of the business and has been using this approach with a good success rate.

Jackson describes using problem frames to control and frame thinking processes.

Arts & Crafts movement alive and well in software?

I went to the International Arts & Crafts exhibition at the weekend. The items on display and outline of the Arts & Crafts movements sparked of a number of thoughts, two of which I'm going to expand on here.

A perspective

The Arts & Crafts movement (I am talking specifically about the UK movement here) feels to me very much like a 'middle class' activity. I hypothesise that the rise of an affluent urban class was a pre-requisite for the Arts & Crafts movement to have succeeded as it did. As industrialisation progressed a well off urban class started to form, a class that romanticised rural life[1]. This class's intellectuals, from an urban perspective, started to question the impact of industrialisation. Out of this Arts & Crafts was born. Urban craftsmen moved out into rural areas and learnt from country people. They applied those skills, mixed with the Arts & Crafts philosophy, to produce elegant works. The output was then imported back into the cities by the rich urbanites. These 'country designs' continued the romanticisation of the countryside by providing some of the raw material that allowed affluent city dwellers to construct a hyperreal version rural life. More cynically, they could sit in their solid practical Arts & Crafts arm chair and comfort themselves as industrialisation increased their isolation from the environment.

I could be well off the mark here since I have very little knowledge of that part of history.

Alive and well in software?

The V&A descibe the movement thus: "It was a movement born of ideals. It grew out of a concern for the effects of industrialisation: on design, on traditional skills and on the lives of ordinary people. In response, it established a new set of principles for living and working. It advocated the reform of art at every level and across a broad social spectrum, and it turned the home into a work of art."

and

"In Britain, the Arts and Crafts Movement flourished from about 1880. At its heart lay a concern for the role of the craftsman. Inspired by the ideas of John Ruskin and William Morris, it advocated a revival of traditional handicrafts, a return to a simpler way of life and an improvement in the design of ordinary domestic objects."

Doesn't this feel a little like some parts of software at the moment? There are workshops on beauty in software, rallying cries against Taylorism and Fordism. Everyone needs to get back in touch with the craft of software, just write code, do the simplest thing, test first. Are we at the start of softwares Arts & Crafts movement? Will we stand at the shore commanding the tide of industrialisation retreat? Will some of us spend more time crafting our products and taking more pleasure in the act of creation?

Did the Arts & Crafts movement make a lasting impact on people as a whole? We can certainly buy expensive William Morris wallpaper and import Mouseman blanket boxes from the North, maybe that is it. All we are left with are these vestigial organs. Maybe we are on a hide into nothing?

This is a bit tongue in cheek (I'm a big proponent of agile methods), but it is a mildly interesting parallel. Perhaps.

-----
[1] As industrialisation proceeded the English started to romanticise rural life. This has continued to this day.