Eric Raymond coined the phrase The Cathedral and the Bazaar in his 1997 book of the same name, referring to the differences between the traditional, top-down approach to building software and the bottom-up approach at the center of open source projects, respectively. Today, throngs of developers live and breathe the Bazaar approach, including the OpenStack team I discussed in my previous blog post. It occurred to me, however, that Cathedral-centric thinking still crops up, even in the most Bazaar places (I know, groan!).
Let’s step back a minute to clarify the core concepts. Raymond was essentially describing a set of organizational patterns for how to set up, run, and participate in software development teams. However, it doesn’t take much of a leap to consider the Cathedral and the Bazaar as architectural patterns as well, especially in the context of Enterprise Architecture, where organizational patterns are an essential tool in the tool belt of the Enterprise Architect.
The Cathedral vs. Bazaar architectural patterns crop up whenever there is a choice between doing something one way because it’s your job to figure out a given problem, vs. letting many people propose or contribute possible solutions to a problem and then choosing the right one for your needs. For example, if you’re building a RESTful API, you should provide hyperlinks to all the appropriate media types for a given interaction, and if a standard Internet media type doesn’t meet the requirements, then access a marketplace for custom media types, instead of simply creating one of your own.
Another example, from the world of Cloud Computing: if an existing machine image doesn’t meet your needs for provisioning your Cloud instances, you may find yourself creating your own custom machine images. But this approach takes you down the same Cathedral rat hole: how to deal with continual updates to your custom machine image, and how to get everybody else on the same page. Instead, access a marketplace for machine images. It’s no mistake that Raymond used the Bazaar metaphor, since a bazaar is nothing more than a decentralized marketplace.
Following the Cathedral pattern gives you a bespoke solution that meets a short-term need, but doesn’t deal well with change or with diverse needs. On the contrary, the Bazaar pattern frees you from having to do all the work yourself, and allows you to automate the interactions with the marketplace. And perhaps most importantly, the Bazaar supports change better than the Cathedral, because participants are encouraged to update their contributions, and consumers can always decide whether or not to select the new version.
It’s no surprise, of course, that the nascent Cloud Service Broker market is focusing on automating a marketplace. How Bazaar is that?
