Metropolis and the Big Ball of Mud

Last month I had the good fortune to be at Microsoft’s main campus in Redmond, and saw Pat Helland, from Microsoft’s .NET Enterprise Architecture Team, gave an excellent talk, entitled “Metropolis : Envisioning the Service-Oriented Enterprise”.  He had some very neat ideas about comparing software architecture, and the way it has evolved, with that of urban infrastructure – the Metropolis. He examined the impact of railroads, factories and increased travel during the 19th century on production, consumer goods and society, and likens it with what has been happening in the IT world. Very illuminating, especially when you consider that urban infrastructure is ahead of software in terms of its evolutions, so the parallels he draws are not only about what has happened, but historically what will happen in the future.

 

A version of this talk is available as a streaming media session on MSDN’s Architecture Strategy Series. The session is described as “Cities emerge one building at a time, but with the right planning codes the result can be more graceful and functional than anything one architect could conceive alone. Are services the Jerusalem stone of information technology, the facade that unites old and new to the benefit of all? What will an organizational technology portfolio look like in ten years time? How will advances in technology transform business and business processes? What are the key architectural patterns? What are the new limits? What do you set in motion today to anticipate the architecture of tomorrow? ” The link on the page to the session seems to be broken, so try this one instead.

Pat mentioned in passing a paper that caught my eye – Big Ball of Mud. Its worth reading this paper – its around 40 pages long, and very readable. It discusses why architectures tend to get in the mess they do, why good architecture is so important, and what can be done about the whole situation. I’m a big fan of this idea. On more than one occasion I come across applications that, whilst they may have started of their life well designed, have moved well beyond that, to the point where adding new subsystems or technologies (such as security modules, directory service integration, web services support, etc) becomes extremely difficult to do, whilst still ensuring the integrity of the system as a whole. Facades, abstractions and indirections are key to creating a loosely coupled architecture, and building in flexibility and growth to a system. If you think you are immune to this problem, could you really make the changes I mention above to your systems today???