Escape from Metropolis

I've expanded on an old blog entry in this article: Escape Metropolis: Bridging the Divide Between Developers and Architects.

Assertions on architecture and strategy

#1: A good balance is achieved between architecture and strategy when strategy is biased to the prophetic and architecture to the socractic.

#2: A prophetic architect is dangerous without constraint.

#3: An architectural organisation that is failing often undergoes a Constantinian shift. When it does, membership of the architecture community requires acceptance of certain dogma and new thinking and socratic behaviours are supressed. This is often associated with a rise in the unconstrained prophetic.

What is a software architect?

It seems to me that architecture is a somewhat arbitrary term in IT, there is just design, construction and validation[1]. Someon can design a class, a module, a package, a set of packages, an application or a set of applications. As they move up the stack the amount of abstraction they deal with increases (since unless they're very smart they cannot hope to understand it all). At some point up that stack people seem to draw the line and label people doing design at that level as 'architects'. I thinks that is pretty much all there is to it.

The question of 'what is a software architect' then becomes 'where do we draw the line in that stack'. Of course, there are many stacks, all interelating. For example, there's a data stack (tables, application schema, logical models, conceptual models) and an infrastructure stack (switch configs, physical network diagrams, ....). Because different people operate in different stacks and at different points, they tend to define architects in terms of their location in a particular stack, and there is normally much confusion as a result.

One thing that has occurred to me is that the point at which people draw the 'architecture' line oftens seems related to the loss of 'singularity of purpose'. Developers and module designers are normally focused on one goal, with normally one stakeholder to manage. At some point they become team leaders or design leads (often called application architects). At this point life becomes that much more complex, singularity of purpose is lost as the job becomes more about weaving a path between all stakeholders and their views.

----
[1] order, breadth, depth and persistence dependant on the chosen SDLC.

Are you living in metropolis

The IMDB plot summary for Metropolis (1927) is as follows:

[snip] humans are divided into two groups: the thinkers, who make plans (but don't know how anything works), and the workers, who achieve goals (but don't have the vision). Completely separate, neither group is complete, but together they make a whole. One man from the "thinkers" dares visit the underground where the workers toil, and is astonished by what he sees...


This seems to sum up the stereotypical divide between enterprise architects and delivery teams - as seen from both sides. That is, architects thinking developers lack vision and developers thinking architects have no idea how anything works.

Vendor Selection Patterns

I've been involved in a number of vendor selection activities over the past few years. Recently I produced a paper called Vendor Selection Patterns as input into EuroPLOP. Unfortunately I failed to make it to the conference, but you may get some value from some of the lessons contained in this paper. I'll be submitting this to EuroPLOP next year and I imagine the post-workshop revision will be significantly improved. One of the really tough things was finding good references, the set of good technical books on the RFP process seems a bit thin on the ground.

Standards cause design fragility when used unwisely?

Enterprise architecture is in someways like urban planning. You have systems (buildings) connected by infrastructure (road, rail, sewage etc) and developers and users have to live in that city being built. The city changes over time as new buildings are put up, old ones taken down or extended and the infrastructure evolves. Of course, a city isn't as plastic as software and software doesn't have to obey many physical laws. Anyway, despite these problems, let's assume the metaphor holds and see if we can learn something.

In Europe Le Corbusier had significant traction as an architect and wrote up his ideas on urban planning, which were fundamentally modernist in origin. His ideas centred around zoned standardised accommodation and infrastructure, one of his proposals for a section of Paris is below:



His ideas on urban planning resulted in utopian drawings of homogenous living units in homogenous cities, with urban zones and a grid based model. These ideas have been largely discredited and the results of applying his ideas in the UK, the tower block housing estate (e.g. at Roehampton), have failed with pretty disastrous social results. I believe one of the problems with this modernist approach, where a large area of a city is planned according to a single design approach/theory, is that they allow design failures to effect the entire planned area due to the homogenous nature of the approach. Of course, we could blame the modernist movement as a whole, but that seems harsh. In Chicago, Mies Van Der Rohe, whilst being a modernist, didn't get to build a Brasilia (which was based on Le Corbusier's ideas). He had his modernist intentions bounded. Go to the plaza area in Chicago he designed, and whether you like it or not, it is only one design amongst the many surrounding it. A failure in Van Der Rohe's design approach doesn't break an entire area as the urban plan has been far more eclectic in its choice of approach.

I am tempted, given my initial parallel of urban planning with enterprise architecture to draw a parallel between Le Corbusier's ideas and those of the breed of architect that want all of the enterprise architecture standardised on single choices. If we do this, and our chosen technology fails (e.g. a major vulnerability is found in the single chosen operating system or J2EE platform), then we have effected vast tracts of systems. Of course, standards provide many many benefits, but maybe the trick is to ensure there is enough heterogoneity in our city plans to protect against major design failures in our enterprise architectures.

Perhaps we have more to learn from todays urban planners than we may first realise.

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.