Some More Thoughts on Software Architectures

Some month ago I wrote a blog post about some of my thoughts on software architecture and why I think the metaphor of a cathedral is no longer very useful for todays software development. I don't mean that you don't need an architecture when you do agile software development. A good software architecture is absolutely necessary to survive. It is an essential part of each system.

Nevertheless agile software development is based on the idea of embracing change. "Inspect and Adapt" is the secret of success in agile development. The structure of your software emerges over time when you constantly refactor your code. But is this also true for the architecture of the system? Does this architecture emerge over time as well? Or is it adaptable when life changes?

I discussed this a lot over the past years with various people. We typically found two basic contrasting (for this posting simplified) opinions:

• Opinion 1: The architecture includes the most important technical decisions. It is hard to change those things later on. Therefore the architecture should be defined at the beginning of a project and should experience only minor changes. Major changes in the architecture are considered a bad thing and should be avoided.
• Opinion 2: The architecture of a system is an artifact that emerges over time. It reacts to change by embracing it. Changing the architecture of a system is considered a good thing and part may be part of your daily live.

While I was always an opinion-2-guy, I always had to admit that some parts of the architecture of a system are hard to change. So changing a large rich-client app to a web-based app might be expensive. The same might be true for changing the implementation language or refactoring a classical three-tier app into a Quasar-like structure.

Then I recorded SE-Radio podcast episode 166 with John Wiegand and listened to him talking about what he calls "Living Architectures":

• SE-Radio Episode 166: Living Architectures with John Wiegand

During the episode he explains the basic architectural decisions behind the Eclipse platform and the Jazz project at IBM. Both architectures are surprisingly simple. They define the general idea of how parts of the system are built and interact. And both don't contain a single word about those things I mentioned above. Even the language is an implementation detail.

The Jazz system is, for example, built around the idea of the web. RESTful services define the heart of the structure. It doesn't matter how those services are implemented, which frameworks they use or how they are internally structured. The whole system might consists out of various languages, various runtime platforms, various infrastructure settings. Even object-orientation becomes an implementation detail of individual services. All things I often thought of being part of the general architecture. But now I know that I was terribly wrong about this.

Of course there are things that are expensive to change. Reimplementing a huge system with a different language might cost you a lot. But the question is: Why do you need to reimplement everything if you switch to another implementation language? The RESTful style, for example, doesn't require such a tight language binding. Its just an example, but it made me think. And it convinced me that "the definition of architecture as the set of things that are hard or expensive to change" leads into the wrong direction.

Architectures are living things. Don't treat them as dead artifacts. And don't be afraid of change. Its a good thing. It reflects your learning. It helps you build better systems.

Some month ago I wrote a blog post about some of my thoughts on software architecture and why I think the metaphor of a cathedral is no longer very useful for todays software development. I don't mean that you don't need an architecture when you do agile software development. A good software architecture is absolutely necessary to survive. It is an essential part of each system.

Nevertheless agile software development is based on the idea of embracing change. "Inspect and Adapt" is the secret of success in agile development. The structure of your software emerges over time when you constantly refactor your code. But is this also true for the architecture of the system? Does this architecture emerge over time as well? Or is it adaptable when life changes?

I discussed this a lot over the past years with various people. We typically found two basic contrasting (for this posting simplified) opinions:

• Opinion 1: The architecture includes the most important technical decisions. It is hard to change those things later on. Therefore the architecture should be defined at the beginning of a project and should experience only minor changes. Major changes in the architecture are considered a bad thing and should be avoided.
• Opinion 2: The architecture of a system is an artifact that emerges over time. It reacts to change by embracing it. Changing the architecture of a system is considered a good thing and part may be part of your daily live.

While I was always an opinion-2-guy, I always had to admit that some parts of the architecture of a system are hard to change. So changing a large rich-client app to a web-based app might be expensive. The same might be true for changing the implementation language or refactoring a classical three-tier app into a Quasar-like structure.

Then I recorded SE-Radio podcast episode 166 with John Wiegand and listened to him talking about what he calls "Living Architectures":

• SE-Radio Episode 166: Living Architectures with John Wiegand

During the episode he explains the basic architectural decisions behind the Eclipse platform and the Jazz project at IBM. Both architectures are surprisingly simple. They define the general idea of how parts of the system are built and interact. And both don't contain a single word about those things I mentioned above. Even the language is an implementation detail.

The Jazz system is, for example, built around the idea of the web. RESTful services define the heart of the structure. It doesn't matter how those services are implemented, which frameworks they use or how they are internally structured. The whole system might consists out of various languages, various runtime platforms, various infrastructure settings. Even object-orientation becomes an implementation detail of individual services. All things I often thought of being part of the general architecture. But now I know that I was terribly wrong about this.

Of course there are things that are expensive to change. Reimplementing a huge system with a different language might cost you a lot. But the question is: Why do you need to reimplement everything if you switch to another implementation language? The RESTful style, for example, doesn't require such a tight language binding. Its just an example, but it made me think. And it convinced me that "the definition of architecture as the set of things that are hard or expensive to change" leads into the wrong direction.

Architectures are living things. Don't treat them as dead artifacts. And don't be afraid of change. Its a good thing. It reflects your learning. It helps you build better systems.

Some More Thoughts on Software Architectures

Some Thoughts on Cathedrals and Software Architectures

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

Slides from Meet-The-Experts on Architecture

Last friday I was invited to give a talk at the Meet-the-Experts event in Solingen. I talked about my view on architectures in an agile world and how module systems drive those architectures for a flexible future. Here are the slides:

• How Module Systems Drive Architectures (pdf)

Enjoy!

Last friday I was invited to give a talk at the Meet-the-Experts event in Solingen. I talked about my view on architectures in an agile world and how module systems drive those architectures for a flexible future. Here are the slides:

• How Module Systems Drive Architectures (pdf)

Enjoy!

Slides from Meet-The-Experts on Architecture