While preparing a talk on module systems and architectures I remembered some old talks I listened to talking about architectures and arguing why an explicit software architect is necessary within professional projects. Many of them used the analogy of building a dog-house versus building a cathedral. For a small dog house, you don't need an architecture. But for the cathedral you do. Hm, agree, but where is the point?
I think the world has changed. Today for most software systems the analogy of building something like a cathedral is no longer a good choice. And I hope that people no longer have a cathedral in mind when designing software. We have learned that building software is a learning process, that requirements change all the time, that we need a short time-to-market, and most of all that we need feedback all the time - and react to this feedback quickly. Agile methods reflect this and allows us to move forward to modern ways of software development.
But our view on architectures need to reflect this. Modern software architectures need to be build for flexibility, for changing requirements all the time, for changing even fundamental layers of our software in a flexible way without causing tremendous costs. Having a cathedral in mind don't help you here. But if you still like the analogy of building real buildings (even though I think this is not always a good analogy to building software at all), you should take a look at some modern office buildings. Maybe they are not as beautiful as some of the old cathedrals, but they are built for flexibility.
But building flexible architectures is not an easy task. We need to build a flexible architecture and at the same time just what we need without designing all possible stuff upfront. Sounds like contradictory goals, eh? Hm, in some way, they are. I think modularity can help you to solve this conflict. Modularity (and I mean modularity on a higher level than individual classes or packages, but more something like Bundles in OSGi) helps you to think about dependencies, coupling, cohesion, and many of these nice design principles. And I think we all agree on having a good, decoupled design makes life easier when things change - and they will change.
While preparing a talk on module systems and architectures I remembered some old talks I listened to talking about architectures and arguing why an explicit software architect is necessary within professional projects. Many of them used the analogy of building a dog-house versus building a cathedral. For a small dog house, you don't need an architecture. But for the cathedral you do. Hm, agree, but where is the point?
I think the world has changed. Today for most software systems the analogy of building something like a cathedral is no longer a good choice. And I hope that people no longer have a cathedral in mind when designing software. We have learned that building software is a learning process, that requirements change all the time, that we need a short time-to-market, and most of all that we need feedback all the time - and react to this feedback quickly. Agile methods reflect this and allows us to move forward to modern ways of software development.
But our view on architectures need to reflect this. Modern software architectures need to be build for flexibility, for changing requirements all the time, for changing even fundamental layers of our software in a flexible way without causing tremendous costs. Having a cathedral in mind don't help you here. But if you still like the analogy of building real buildings (even though I think this is not always a good analogy to building software at all), you should take a look at some modern office buildings. Maybe they are not as beautiful as some of the old cathedrals, but they are built for flexibility.
But building flexible architectures is not an easy task. We need to build a flexible architecture and at the same time just what we need without designing all possible stuff upfront. Sounds like contradictory goals, eh? Hm, in some way, they are. I think modularity can help you to solve this conflict. Modularity (and I mean modularity on a higher level than individual classes or packages, but more something like Bundles in OSGi) helps you to think about dependencies, coupling, cohesion, and many of these nice design principles. And I think we all agree on having a good, decoupled design makes life easier when things change - and they will change.
Some Thoughts on Cathedrals and Software Architectures
4 comments:
If you mention the cathedral, where is the bazaar?
The Cathedral and the Bazaar
Good post, Martin. At the Software Engineering Institute, we have begun a project to look at the role of architecting in agile development. The members of the project team have made several posts on this topic at the SATURN Network blog. See http://saturnnetwork.wordpress.com/category/architecture-and-agile/
Regards,
Bill Pollak
Hi Sebastian!
There is indeed some kind of relationship between my posting and the book and papers you mention. The idea of moving away from the cathedral style of building applications is based on the same ideas, I think. The reason why I don't talk about the bazaar part of that story (although I like that a lot) is that I am not focussing on that kind of development where you have distributed teams, open-source software with various committers and so on. So my point is even if you are working with a closed-shop team within a large heavyweight organisation, developing a corporate inhouse app, moving away from the cathedral style of software architecture is the way to go, IMHO - even if you don't want or cannot shift towards a bazaar style.
Cheers,
-Martin
Hey Bill,
thanks for the link and the pointer to the work at the software engineering institute. I will have a closer look at the postings soon, I think. Looks definitely interesting!!!
Cheers,
-Martin
Post a Comment