Showing posts with label ChristopherAlexander. Show all posts
Showing posts with label ChristopherAlexander. Show all posts

Saturday, March 19, 2022

Christopher Alexander 1936-2022

The architectural theorist Christopher Alexander, who has died at the age of 85, had a major influence on software architecture as well as buildings.

His first book Notes on the Synthesis of Form (1964) was referenced by the structured methods gurus of the 1970s (Ed Yourdon, Tom deMarco). This was followed by A Pattern Language (1977), which was adopted as a core text by the Object Oriented school of software engineering.

In 1987, Alexander and a few colleagues published an account of a design experiment under the title A New Theory of Urban Design, showing how order can be created without top-down planning, by a governance process that imposes some simple structural principles on all design activity. I believe I was one of the first to apply this approach within the software world, and he remains a major influence on my thinking on SOA and enterprise architecture. See for example the following posts

I also drew on Alexander in my books Component-Based Business (Springer 2001) and Next Practice Enterprise Architecture (LeanPub 2013). 

In 2004, Pat Helland, who was then a senior architect at Microsoft, wrote an article entitled Metropolis, in which he suggested computer system architects could learn something from city planning. Philip Boxer and I wrote a reply, mentioning Christopher Alexander. Microsoft subsequently flew me over to the USA for a closed workshop (SPARK), sending all attendees copies of The Timeless Way of Building in advance. However, although Microsoft had recognized Alexander's importance, I'm not sure all the other attendees at the workshop did, and I don't recall much discussion of his work. I think we spent more time discussing Stewart Brand's notion of shearing layers / pace layering.

My observation was that it had taken around 15 years for the ideas in Notes on the Synthesis of Form to be taken up in the software world in the late 1970s, and another 15 years from the publication of A Pattern Language to the popularity of pattern thinking for software in the early 1990s. So in the early 2000s, I was publishing ideas taken from A New Theory of Urban Design, in the hope that the software world would now be ready for them. Unfortunately it wasn't. For many people in the software world, Alexander continued and continues to be seen as the man who invented Design Patterns. Alexander's material from this period is also credited as having been an inspiration for The Sims game.

Perhaps the same is true of people in the architecture world. A book was published last year called Relational Theories of Urban Form, in which Alexander was represented by an extract from A Pattern Language, plus a few papes of Timeless Way.

Alexander initially expressed some ambivalence and suspicion about the use of his work by software engineers. Later he was persuaded to make occasional keynote speeches at software conferences and to write prefaces for software books. It is possible that some software practitioners understood his work better than most architects. However, I believe he remained concerned that software practitioners mostly only picked up fragments of his work, and ignored the holistic aspects of his thinking that he regarded as crucial.

I was once privileged to observe Christopher Alexander teaching first year students at the Prince of Wales Institute of Architecture in London. An amazing experience. Click here for the full story >> Christopher Alexander as Teacher.

 

Most of the tributes on Twitter mention Notes on the Synthesis of Form and A Pattern Language. Some mention The Timeless Way of Building. But the culmination of his work was the four-volume Nature of Order. I'm not sure how much I understood when it first came out, but I'm now re-reading. More than 15 years have passed since its publication, so maybe its time has come?



Good sources of material on Christopher Alexander include Architecture's New Scientific Foundations (Architexturez) and New Science, New Urbanism, New Architecture (Katarxis 3, September 2004)

David Brussat, Christopher Alexander RIP (Architecture Here and There, 20 March 2022)

Howard Davis, Christopher Alexander Obituary (The Guardian, 29 March 2022)

Pat Helland, Metropolis (Microsoft Architecture Journal, April 2004)

Daniel Kiss and Simon Kretz (eds) Relational Theories of Urban Form (Birkhäuser, March 2021) Review by John Hill (9 July 2021)

Mae-Wan Ho, The Architect of Life (Science and Society, 4/11/2003)

Bin Jiang and Nikos Salingaros (eds), New Applications and Development of Christopher Alexander’s The Nature of Order (Urban Science Special Issue, 3/1, 2019)

Ben Sledge, Home comforts: how The Sims let millennials live out a distant dream (The Guardian, 5 February 2020)

Richard Veryard and Philip Boxer, Metropolis and SOA Governance (Microsoft Architecture Journal,. July 2005). See also Philip Boxer and Richard Veryard, Taking Governance to the Edge (Microsoft Architecture Journal, August 2006)

updated 29 March 2022

Friday, February 25, 2011

Modernism and Enterprise Architecture

Underlying conventional enterprise architecture theory and practice are some implicit assumptions that could be loosely characterized as modernist. Several people are offering more or less radical departures from conventional enterprise architecture, which could be loosely characterized as post-modern.

Aspects of Modernism
  • Fordism- Simple decomposition of responsibility, authority, expertise and work (RAEW)
  • Functionalism - Form follows function
  • Linear Explanation - Simple association between cause and effect – e.g. process improvement
  • Cartesian Theatre - Unified representation of what is going on (WIGO)
  • Central Planning - Unified decision-making
  • Unified Value System - Complete and consistent set of shared goals and objectives on behalf of The Enterprise
  • Ultimate Solution - Converging towards an ideal set of systems, perfectly aligned to The Business

Limitations of Modernism

  • Difficulties handling complexity, emergence and self-organization.
  • Lack of agility, flexibility, evolution.
  • Constrains organizational learning.
  • No explicit treatment of holistic architectural properties such as balance and harmony.
  • No room for pluralism and human values.

Towards Postmodernism

Obviously the labels "classical" and "modernist" can mean different things, but I associate the classical approach to architecture with Vitruvius - Firmness, Commodity and Delight - and I see the essential characteristics of the classical aesthetic as an emphasis on balance, harmony and order.

This emphasis on balance is completely absent from the modernist functionalist aesthetic, which seems to assume that if you take care of the parts and connect them together properly, the whole will look after itself.

The IT modernists (such as James Martin) told us to concentrate on Commodity (roughly translated as functional requirements), because Firmness (reliability and other non-functional) could be handled by technical design and innovation, and Delight could be handled by user design specialists (ha!). For his part, Zachman has said nothing to indicate that he doesn't fully share this mindset, and his interpretation of the "classical" is conceptually and metaphysically flawed. We may note that most of the notations favoured by enterprise architects (IDEF, UML, ArchiMate) concentrate on the functional.

In our time, it is of course Alexander and Salingaros who represent the return to balance and order, as the title of Alexander's masterwork indicates, although I suspect they would not take kindly to being labelled as neo-classical.

Meanwhile, an emphasis on self-organization and heroic agility can be seen as echoing some of the romantic aesthetic. After all, the post-modern aesthetic often combines elements of the neo-classical with elements of the neo-romantic.

Exploration of New Ideas


In response to the perceived limitations of the modernist approach to enterprise architecture, various thinkers are looking into other disciplines for ideas that can be imported into enterprise architecture.

Systems Thinking Holism and Emergence
Viable Systems Model (VSM)
Wicked problems
Dissipative Structures (Prigonine via @empiricator)
Design Thinking
and Urbanism
Creativity
Organic planning
Metadesign 
Pace layering
Post-modernism
Organization Theory Loosely coupled systems
Self-organizing systems
Ecological Thinking Panarchy
Evolutionary change
Complexity Theory Anticipative Systems
Complex Adaptive Systems
Dynamics of Strategy (I-Space, Cynefin)

have I missed anything?

The challenge here is two-fold. Firstly, how can a heterogeneous selection of ideas from different sources be combined into a coherent approach? Secondly, what kind of practical hands-on research (reflective practice) is needed to turn interesting speculation into grounded and credible knowledge?

Some Post-Modern and Other Approaches to EA

I don't know how many of the following approaches can be properly described as postmodern, but they all represent various attempts to break free from the limitations of modernism.

Philip Boxer et al, Asymmetric Leadership

Dave Duggal and William Malyk, Putting Work in Context for Enterprise Agility (December 2010)

Nicholas Gall (Gartner), Panarchitecture: Architecting a Network of Resilient Renewal (January 2011)

Nigel Green, A new context for EA: The Enterprise: An ecosystem of values and value (Sept 2010)

Dion Hinchcliffe, Post-Modern Enterprise Architecture: Service-Oriented, Agile, Decentralized (April 2005). Pragmatic new models for enterprise architecture take shape (August 2009)

Anders Jensen-Ward, Pondering a new model of architecture and postmodern complexity: Deleuze’s rhizome as the substitute for architectural layers and control. (June/July 2010) via Tom Graves. On management and systems (Aug 2009) On architecture and strategy (Aug 2009) Architectural control as a management paradox (Jan 2011), Rhizome: On Dilemmas in Enterprise Architecture Planning (April 2011)

@rlimbanda To understand human systems based on postmodern natural architecture and the transformation of 21st century social enterprise. // And to understand and share the things that make us human #thoozd (December 2009) via Tom Graves

Further reading

Max Boisot and Bill McKelvey, Complexity Science-A Bridge Between Modernist and Postmodernist Perspectives (2008)

Hubert Maturana, Metadesign (1997)

Neil McBride, Rachel Lander and Steve McRobb, Postmodernist Business Information Management 1997 (HTML, PDF)

See my previous post on Adaptation and Adaptability

See Linked-In discussion "Is Enterprise Architecture (and IT in general) trapped in the psychological prison of Modernity?" from January 2011 onwards



Updated October 21, 2012
Some links corrected 19 February 2020. Some remaining broken links under investigation - please help.

Saturday, November 28, 2009

Is Enterprise Architecture a Science? Part 2

@RSessions was in London this week, so I sat down with him to continue our previous discussion Is Enterprise Architecture a Science?

The first question to address is - which enterprise architecture are we talking about? I think we both agree that there are some activities within the EA world that look more like religion or mediaeval scholastic philosophy than empirically verifiable science.

For example, in his post What's Right with the Zachman Framework, Grant Czerepak states that "the architectural metaphor conceals what the six perspectives are actually about: Entities, Relationships, Attributes, Constraints, Definitions and Manipulations". And referring to the Kipling-Zachman lens, Grant claims that "the interrogatives have a foundation that goes back over three thousand years across every human culture". In a separate post, he says It's not Aristotle's fault, it's your fault. See my post Arguing with Mendeleev (March 2013).

Lots of EA frameworks are essentially abstract classification schemes that start from an abstract ontological argument ("obviously all businesses are made of objects" or "obviously all processes are made up of nouns and verbs") and make assertions that are not amenable to empirical verification.

Roger's SIP methodology is at least based on an empirically testable (and quantified) hypothesis. That a system of systems with such-and-such measurable structural qualities (in terms of Roger's definition of complexity) will have such-and-such predictable costs. So this provides the basis for a scientifically-grounded engineering practice. I think SIP methodology has a reasonable claim to be scientifically grounded: it can be evaluated not just on whether its prescriptions are practical, cost-effective and useful, but also whether its predictions are true. (Incidentally, I think it would be interesting to compare SIP with Christopher Alexander's early book Notes on the Synthesis of Form. This contains detailed and mathematically grounded work on architectural complexity: although the software gurus who developed structured methods in the 1970s were aware of Alexander's book, they left out most of the difficult detail.)


I think there is a further step before EA could ever dream of becoming a fully empirical science, and this would involve large-scale collection and analysis of empirical data, so that there would be a closed loop between theory and practice, connecting structure and value. In order to achieve this, we should need the active participation of some of the more powerful players in the EA game - the large consultancies and above all the key government agencies that govern IT expenditure. (You know who you are.) At the moment, there is little sign that these organizations are seriously interested in any game-changing innovation. (Roger and I should be delighted to talk to representatives of these organizations, please contact us.)

Thursday, July 09, 2009

Is Enterprise Architecture a Science?

asks @RSessions (Roger Sessions)

I have long argued that the answer is no. What passes for knowledge in enterprise architecture is largely a combination of anecdote and received opinion. Intellectual effort is devoted to hierarchical forms and elaborate classification schemas, based on abstract reason rather than empirical measurement; this kind of work looks more like mediaeval scholastic philosophy than modern science.

In comparison, the followers of Christopher Alexander seem like nineteenth century gentleman scientists, carefully collecting specimens from which they try to infer useful principles and patterns. Alexander's four-volume masterpiece on the Nature of Order is a brilliant and fascinating work, which I think every enterprise architect should read (in their spare time), but it's not exactly suitable as an everyday handbook.

In order for enterprise architecture to qualify as a science, it has to follow scientific method. Now I am pretty broadminded about what counts as scientific method, but it's more than mere predictability. (Card games are predictable, but that doesn't make cribbage a science. Roger says if card games were predictable, he'd be a rich man. But if card games were not predictable, the casinos would go broke.)

Anyway, you can get predictability from art. I saw Dave Crosby on a documentary once, criticizing the fact that the Eagles' concerts were note-for-note predictable, CSNY preferring a slightly looser style in response to each audience. So what if EA's an art, asks @HotFusionMan (Al Chou).

Peirce understood the limitation of scientific method, holding
"that slow and stumbling ratiocination can be dangerously inferior to instinct, sentiment, and tradition in practical matters" (Wikipedia).

So does it matter if (as I believe) Enterprise Architecture is not a science? The key question that raises is - what is the source and status of EA knowledge, and how can we ever resolve matters of opinion, except by obscure mediaeval argument?



Follow-up post Is Enterprise Architecture a Science (2)?

Sunday, January 25, 2009

SOA and Holism

Wikipedia's definition of holism traces back to Jan Smuts
Holism ... is the idea that all the properties of a given system (biological, chemical, social, economic, mental, linguistic, etc.) cannot be determined or explained by its component parts alone. Instead, the system as a whole determines in an important way how the parts behave.
To what extent does this concept apply to SOA? My own view is that SOA needs to be understood from the Systems-of-Systems Engineering paradigm rather than from the Systems Engineering or Software Engineering paradigm. This helps us to deal with a range of system level phenomena including Feature Interaction.

In my writings I've drawn on the recent work of Christopher Alexander, from A New Theory of Urban Design to The Nature of Order, where Alexander talks about something he calls structure-preserving transformations.

According to the New Theory (or at least my interpretation of it, which I call Organic Planning) each act of transformation should be a step within a larger and open-ended evolutionary development, and should have three aspects.

  1. Produce something at some level
  2. Complete something (larger) that was already part-developed - typically by linking smaller (lower-level) things and peer (same-level) things that already existed, or were created in previous steps.
  3. Create new opportunities - Alexander calls this hinting-at.
For example, an information service called Product Catalogue might (1) establish a single point for accessing product information, (2) linking together data from multiple legacy data stores and third-party feeds, while (3) hinting towards a new business process (yet to be fully specified) in which the product catalogue becomes a dynamic object, using some kind of real-time business intelligence.

I published a very simplified version of this in the CBDI Journal in 2004, suggesting that the service designer needed to look in four directions (upwards, downwards, sideways, inwards). I understand that this was picked up and referenced by the ArchiMate people, for example in a 2005 book called Enterprise Architecture at Work, and it has been implemented in the Telelogic tool. My colleague Tony Bidgood has recently published an article on ArchiMate, with some further examples.

Here's how I intended the four directions to map to the New Theory of Organic Planning

1. Inwards: Functional correctness
2a. Downwards: Integrating and composing smaller stuff
2b. Sideways: Interoperability
3. Upwards: Larger whole

Organic Planning is described in my 2001 book on the Component-Based Business, and there is a short version on my website, but I didn't make this explicit in my 2004 article.

My expectation has always been that a series of transformations (whether structure-preserving or otherwise) would be expressed as a series of model pairs, in which the nth TO-BE becomes the (n+1)th AS-IS. But some alternative modelling notations (such as Michael Bell's SOMF) allow both AS-IS and TO-BE to be expressed in a single model, so it would be very interesting to see how a series of transformations could be expressed and analyzed.



 
 See also SOA and Holism 2 (February 2009)

Monday, March 13, 2006

Timeless Way

Just been reading Dion Hinchcliffe's post A Timeless Way of Building Software, in which he rewrites the opening of Christopher Alexander's book A Timeless Way of Building into a kind of Web 2.0 manifesto. See my earlier post on Christopher Alexander.

Dion seems to want to present Web 2.0 as something new, and yet grounded in ancient software engineering wisdom. His own examples are all very recent, but his version of Alexander's principles would seem to apply to every piece of software ever produced by Microsoft, especially Windows and Word. As I said in my recent comment Hype and Hyperbola on the impending encounter between Dion and Dare Obasanjo, "technology is full of statements that lack precise empirical support". Especially in the "blogosphere" (stupid word, yes Dare I agree.)

The Google interface is a particularly interesting test case. Much praised for its simplicity, it provides access to some extremely sophisticated computer science - certainly not something you could produce by mashing together a few software design patterns. Nothing timeless about this, unless you count the timeless quality of hard work. And all credit to Joshua (creator of del.icio.us) and the Flickr people for putting in a lot of creative hard work, and getting bought out by Yahoo. You certainly can't attribute their success just to deep study of the Gang of Four book. (Or to Gang of Four song lyrics.)

Coincidentally, the cityofsound blog today provides a couple of extracts from an Observer article on Divine Inspiration, which shows how painter Will Alsop and composer Steve Reich both rely on hard work - doing something that we could call a Focal Practice (as this term is used by the American philosopher of technology Albert Borgman).

Christopher Alexander's original book was called the Timeless Way of Building. The title ends with a verb - a focal practice. Dion Hinchcliffe has stuck a noun on the end, which changes the emphasis completely. And in any case, I think it's the wrong noun.

If there is a timeless way that is illustrated by Dion's examples (and I'm not convinced about this), then it is not about software. It's about business service. As the software increasingly becomes a reconfigurable commodity, then it becomes possible for people to produce new business services - the timeless (but often forgotten) principles and structural patterns here are not about software but about the service economy - supply and demand.

Yet another new blog crossed my path this weekend. In his post Business Patterns, Allan Kelly mentions Christopher Alexander and myself, and points out that I haven't updated my patterns material recently. True - and furthermore I still haven't followed up my post from December 2004 on Patterns and Strategies. I think Allan's line of enquiry may be significantly more productive than Dion's, and I really will try and follow it up this time ...

Tuesday, March 07, 2006

Christopher Alexander

I've just received a preparation pack for the SPARK workshop, including a new copy of Christopher Alexander's book Timeless Way of Building, first published in 1979. I wonder how many of the SPARK participants have looked at Alexander's later material, including his New Theory of Urban Design (1987), and his magnificent new 4-volume work The Nature of Order.

A few years ago I wrote

Christopher Alexander's work is frequently cited in the software world, usually after a delay of about 15 years. Thus Notes was used by Ed Yourdon and Tom De Marco in the 1970s, to support a view of top-down design. Patterns made a serious entry into the software world the early 1990s. His book on Urban Design has not yet achieved such popularity, although I think it is extremely relevant to business and IT planning. In the past, Alexander has expressed some ambivalence and suspicion about the use of his work by software engineers. More recently, he has been persuaded to make occasional keynote speeches at software conferences and to write prefaces for software books. It may even be true that some software practitioners understand his work better than most architects. However, he is clearly troubled by the fact that software practitioners mostly only pick up fragments of his work, and ignore the holistic aspects of his thinking that he regards as crucial.
 

Here are some of the themes of Alexander's thinking that I see as particularly relevant to SOA.

1. Under the right conditions, complex order emerges from a series of simple steps. A given structure at a given moment is in a partially evolved state.

2. Each step is generally structure-preserving - it builds upon the differentiation and coherence (strength) of the existing structure.

3. Each step brings greater differentiation and greater coherence (strength). Alexander calls this the Fundamental Differentiating Process. (See Nature of Order, Book 2, page 216).

4. Alexander defines structure in terms of a network of centres. Alexander's notions of structure-preservation, differentiation and coherence are explained in terms of this notion of structure. (See "Centers: The Architecture of Services and the Phenomenon of Life," FTPOnline, Richard C. Murphy, March 2004)

5. A key role of governance is then to establish and maintain the conditions under which this fundamental differentiating process can work. (See my articles in the Architecture Journal: Metropolis and SOA Governance and Taking Governance to the Edge).

 

See also Christopher Alexander as Teacher (May 2004), Christopher Alexander 1936-2022 (March 2022)

Thursday, March 24, 2005

Service Fabric (SOA)

Phil Wainewright (Loosely Coupled) has been drumming up interest in the SOA: bus or fabric? debate. He identifies a number of vendors on the fabric side: Actional, Blue Titan, SOA Software (formerly Digital Evolution). 

I have always described the service economy as a continuous fabric of services. Service-oriented projects are then understood in terms of developing and maintaining this fabric: weaving new fabric; and repairing and patching holes in the existing fabric. 

This fits with my interpretation of Christopher Alexander's Nature of Order. Complex systems of systems are formed as a continous network of what Alexander calls "centres", and emerge from a series of design acts under an appropriate mode of governance. (Alexander previously used the word "fabric" but now seems to prefer the mathematical word "field".)

My notion of fabric is general and abstract. In particular, I think of the fabric metaphor as applying to the whole of SOA and not just the messaging layer. I like the metaphor because it suggests extension in two or more dimensions, rather than a simple linear bus. We can also talk about the quality of the fabric, in terms of its completeness, connectedness, density, flexibility, and so on. (Obviously these terms need more precise definition before they can be used as part of a formal design method, but they already have some intuitive force.) 

But the term "SOA fabric" is now being used to describe a class of software products supporting SOA, rather than the whole of SOA. (This is a figure of speech known as synecdoche.) 

Thus for example: "An SOA Fabric is the unifying software structure for security, provisioning and management of Web services applications. It provides a unified control layer for software architects to integrate, share, scale and reuse applications, define and enforce consistent operational and security polices across an enterprise’s distributed architecture, and quickly implement required changes to evolving business processes." (Anexinet white paper, pdf). 

Meanwhile, there is an entirely different use of the fabric label within the SOA world: WebMethods Fabric, which is sold as a business integration product suite. Business processes are woven (in other words: composed, orchestrated) from so-called Smart Services. But at the centre of the WebMethods graphical representation of the SOA fabric is a service bus. So what's going on here? Is it just too difficult to produce a simple graphic of a fabric without reducing it to a bus, or are the concepts really not that different? 

So can we sustain the notion of SOA fabric as a distinct concept? I hope we can, but we shall need to find some better graphics.

Friday, May 28, 2004

Urban Design and SOA

There are some strong analogies between town planning and service-oriented architecture, which make it reasonable to translate Christopher Alexander's ideas into the SOA domain. 

1. The distribution of design. Detailed design decisions are taken within different organizations, each following its own agenda (e.g. commercial or political goals). 

2. The constancy of change. Elements of the whole are constantly being redesigned and reconfigured, and new elements are constantly being added. Structures must evolve in robust ways. 

3. The need for progressive improvement. Each design increment should not only make local improvements, but should have a positive effect on the whole. 

4. The recursive nature of the architecture. Similar design tasks must be carried out at different scales (levels of granularity).

Read more on metropolis on my website ... 

Richard C. Murphy: Christopher Alexander's theory of centers helps explain the essential properties of service-oriented architectures. (FTP Online, March 2004)

Monday, May 10, 2004

Metropolis

In a piece called Metropolis, published in the Microsoft Architecture Journal, Microsoft guru Pat Helland has written about the relationship between service-oriented networks and cities

Helland's article makes the following argument.

  1. Progress requires standardization. (According to Helland, people didn't even wash properly until they had standard clothing.)
  2. Standardization is associated with commoditization.
  3. Standardization requires concentration of power (and if this involves pathological distortions of socioeconomic relations, such as WalMart or dare we say it Microsoft, so be it).
  4. Infrastructure requires central investment. (Since we may regard infrastructure as an act of local standardization, it follows that it must involve concentration of power.)
  5. Central investment preserves the "sacred".

I was however surprised that he does not mention the work of Christopher Alexander - especially his 1987 book A New Theory of Urban Design. Given the influence that Alexander's earlier books on structure and patterns have had on the software engineering community, it is amazing how few people in this community have read his later work.

The analogy between computer networks and cities has also been explored by the mathematician Nikos A. Salingaros. See especially his piece on the Information Architecture of Cities. Further comments by Phil Jones.

For more commentary on Helland's piece see the Newswire on Service-Based Design by my colleague David Sprott (CBDI Forum) no longer available.

See also Peter Lindberg's blog.



Update: Following this post, Philip Boxer and I wrote two articles for the Microsoft Architecture Journal.

Metropolis and SOA Governance: Towards the Agile Metropolis (Architecture Journal 5, July 2005)

Taking Governance to the Edge (Architecture Journal 6, August 2006)

Related post: SOA and Holism (January 2009), Christopher Alexander 1936-2022 (March 2022)