4 years, 5 months ago

Beyond Bimodal

Ten years ago (March 2006) I attended the SPARK workshop in Las Vegas, hosted by Microsoft. One of the issues we debated extensively was the apparent dichotomy between highly innovative, agile IT on the one hand, and robust industrial-strength IT on the other hand. This dichotomy is often referred to as bimodal IT.

In those days, much of the debate was focused on technologies that supposedly supported one or other mode. For example SOA and SOAP (associated with the industrial-strength end) versus Web 2.0 and REST (associated with the agile end).

But the interesting question was how to bring the two modes back together. Here’s one of the diagrams I drew at the workshop.

Business Stack

As the diagram shows, the dichotomy involves a number of different dimensions which sometimes (but not always) coincide.

  • Scale
  • Innovation versus Core Process
  • Different rates of change (shearing layers or pace layering)
  • Top-down ontology versus bottom up ontology (“folksonomy”)
  • Systems of engagement versus systems of record
  • Demand-side (customer-facing) versus supply side
  • Different levels of trust and security

Even in 2006, the idea that only industrial-strength IT can handle high volumes at high performance was already being seriously challenged. There were some guys from MySpace at the workshop, handling volumes which were pretty impressive at that time. As @Carnage4Life put it, My website is bigger than your enterprise.

Bimodal IT is now back in fashion, thanks to heavy promotion from Gartner. But as many people are pointing out, the flaws in bimodalism have been known for a long time.

One possible solution to the dichotomy of bimodalism is an intermediate mode, resulting in trimodal IT. Simon Wardley has characterized the three modes using the metaphor of Pioneers, Settlers, and Town Planners. A similar metaphor (Commandos, Infantry and Police) surfaced in the work of Robert X Cringely sometime in the 1990s. Simon reckons it was 1993.

Asked “Isn’t bimodal new?” … god no. It’s a bad rehash of ideas from a decade or more ago. Even “tri” modal dates back to 1993.

— swardley (@swardley) April 27, 2016

Trimodal doesn’t necessarily mean three-speed. Some people might interpret the town planners as representing ‘slow,’ traditional IT. But as Jason Bloomberg argues, Simon’s model should be interpreted in a different way, with town planners associated with commodity, utility services. In other words, the town planners create a robust and agile platform on which the pioneers and settlers can build even more quickly. This is consistent with my 2013 piece on hacking and platforms. Simon argues that all three (Pioneers, Settlers, and Town Planners) must be brilliant.

absolutely @mjbrender @richardveryard @TheEbizWizard : all three must be brilliant … https://t.co/DHMtkmrgzs

— swardley (@swardley) May 4, 2016

Characterizing a mode as “slow” or “fast” may be misleading, because (despite Rob England’s contrarian arguments) people usually assume that “fast” is good and “slow” is bad. However, it is worth recognizing that each mode has a different characteristic tempo, and differences in tempo raise some important structural and economic issues. See my post on Enterprise Tempo (Oct 2010).

Updated – corrected and expanded the description of Simon’s model.  Apologies for Simon for any misunderstanding on my part in the original version of this post.


Jason Bloomberg, Bimodal IT: Gartner’s Recipe For Disaster (Forbes, 26 Sept 2015)

Jason Bloomberg, Trimodal IT Doesn’t Fix Bimodal IT – Instead, Let’s Fix Slow (Cortex Newsletter, 19 Jan 2016)

Jason Bloomberg, Bimodal Backlash Brewing (Forbes, 26 June 2016)

Rob England, Slow IT (28 February 2013)

Bernard Golden, What Gartner’s Bimodal IT Model Means to Enterprise CIOs (CIO Magazine, 27 January 2015)

John Hagel, SOA Versus Web 2.0? (Edge Perspectives, 25 April 2006)

Dion Hinchcliffe, How IT leaders are grappling with tech change: Bi-modal and beyond (ZDNet, 14 January 2015)

Dion Hinchcliffe, IT leaders inundated with bimodal IT meme (ZDNet, 1 May 2016)

Dare Obasanjo, My website is bigger than your enterprise (March 2006)

Richard Veryard, Notes from the SPARK workshop (March 2006), Enterprise Tempo (October 2010), A Twin-Track Approach to Government IT (March 2011),

Richard Veryard, Why hacking and platforms are the future of NHS IT (The Register, 16 April 2013)

Richard Veryard and Philip Boxer, Metropolis and SOA Governance (Microsoft Architecture Journal, July 2005)

Simon Wardley, Bimodal IT – the new old hotness (13 November 2014)

Simon Wardley, On Pioneers, Settlers, Town Planners and Theft (13 March 2015)

Lawrence Wilkes and Richard Veryard, Extending SOA with Web 2.0 (CBDI Forum for IBM, 2007)

updated 27 June 2016

5 years, 5 months ago

Agile and Wilful Blindness

@ruthmalan challenges @swardley on #Agile

Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015

@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015

@swardley in theory 🙂 What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015

@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015


Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stuart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.

Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.

But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.

And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.

One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).


Wikipedia: Shearing Layers

5 years, 5 months ago

Agile and Wilful Blindness

@ruthmalan challenges @swardley on #Agile

Asked what is agile? It’s a method of reducing the cost of change when developing an uncertain act.
— swardley (@swardley) April 21, 2015

@swardley have you seen John Seddon’s quip: “Waterfall: doing the wrong thing righter. Agile: doing the wrong thing faster.”?
— ruth malan (@ruthmalan) April 21, 2015

@swardley in theory 🙂 What we’re paying attention to shapes what we perceive and pay attention to. etc.
— ruth malan (@ruthmalan) April 21, 2015

@swardley I was making a sophisticated/nuanced point. We canalize — we think we’re open to finding misdirection but it’s hard
— ruth malan (@ruthmalan) April 21, 2015


Some things are easier to change than others. The architect Frank Duffy proposed a theory of Shearing Layers, which was further developed and popularized by Stuart Brand. In this theory, the site and structure of a building are the most difficult to change, while skin and services are easier.

Let’s suppose Agile developers know how to optimize some of the aspects of a system, perhaps including skin and services. So it doesn’t matter if they get the skin and services wrong, because these can be changed later. This is the basic for @swardley’s point that you don’t need to know beforehand exactly what you are building.

But if they get the fundamentals wrong, such as site and structure, these are more difficult to change later. This is the basis for John Seddon’s point that Agile may simply build the wrong things faster.

And this is where @ruthmalan takes the argument to the next level. Because Agile developers are paying attention to the things they know how to change (skin, services), they may fail to pay attention to the things they don’t know how to change (site, structure). So they can throw themselves into refining and improving a system until it looks satisfactory (in their eyes), without ever seeing that it’s the wrong system in the wrong place.

One important function of architecture is to pay attention to the things that other people (such as developers) may miss – perhaps as a result of different scope or perspective or time horizon. In particular, architecture needs to pay attention to the things that are going to be most difficult or expensive to change, or that may affect the lifetime cost of some system. In other words, strategic risk. See my earlier post A Cautionary Tale (October 2012).


Wikipedia: Shearing Layers

8 years, 8 months ago

Location, Location, Location

#pacelayering In Stuart Brand’s theory, originally titled Shearing Layers and subsequently relabelled as Pace Layering, the slowest moving element of physical architecture was location, or what he (for the sake of alliteration) called Site.

An intere…

8 years, 8 months ago

Location, Location, Location

#pacelayering In Stuart Brand’s theory, originally titled Shearing Layers and subsequently relabelled as Pace Layering, the slowest moving element of physical architecture was location, or what he (for the sake of alliteration) called Site.

An intere…