Agile Architecture: Real World Problems, Abstractions and Generalizations
When designing architecture you have to be aware of the temptation to go into direction what I call generalizations.
As a real world problem we want to solve with an architecture is a not trivial one, we use abstractions (in form of the models) to describe it. Having this abstract problem modeled, we develop a solution, which is an abstract solution as it solves an abstract problem. After that we apply this abstract solution to the real world to get a real world solution to the real world problem we encounter at the start. This way of architectural work has been defined by Mary Shaw and depicted by George Fairbanks in his book as follows:
This way of thinking has some kinks but (nevertheless) it works quite well. However many architects tend to extend this model using generalizations. From an abstract problem they model a generic problem first, which allows the creation of a generic solution. They reason that this generic solution allows to find abstract solutions to the various abstract problems, not just that one they specified at the beginning. And as a result they apply these abstract solutions to get real world solutions to various real world problems, not just that one they encounter at the start. We can depict this model as follows:
It sounds great. Based on just one real world problem, we can get multiple real world solutions to the various real world problems. But if you analyze this approach deeper you will find that it sounds strange and simply doesn't work. Why? On the way to the real world solutions we loose many details that causes these solutions not to be able to fulfill their goals. The generalization steps deliver solutions that are mostly of low quality due to the lack of individual characteristics, thus inappropriate to solve real world problems.
Did you ever build a generic framework for a software project that should be re-used in your next one? Did you re-use it really? Or maybe you found that the framework you built was actually good just for the initial project, but still "imperfect" for the new one, so you decided to build another one with the same promise of generalization and re-usability? Does it sound familiar to you? That was exactly generalization that killed this cool idea with a framework. I repeat. It doesn't work.
So just remember this statement and forget generalizations. Forget proprietary, means built just for your purposes, frameworks. Allow thinking about abstract problems and abstract solutions only.
This blog post was created based on my upcoming book "architecture4me: Agile Architecture from the Trenches".
As a real world problem we want to solve with an architecture is a not trivial one, we use abstractions (in form of the models) to describe it. Having this abstract problem modeled, we develop a solution, which is an abstract solution as it solves an abstract problem. After that we apply this abstract solution to the real world to get a real world solution to the real world problem we encounter at the start. This way of architectural work has been defined by Mary Shaw and depicted by George Fairbanks in his book as follows:
This way of thinking has some kinks but (nevertheless) it works quite well. However many architects tend to extend this model using generalizations. From an abstract problem they model a generic problem first, which allows the creation of a generic solution. They reason that this generic solution allows to find abstract solutions to the various abstract problems, not just that one they specified at the beginning. And as a result they apply these abstract solutions to get real world solutions to various real world problems, not just that one they encounter at the start. We can depict this model as follows:
It sounds great. Based on just one real world problem, we can get multiple real world solutions to the various real world problems. But if you analyze this approach deeper you will find that it sounds strange and simply doesn't work. Why? On the way to the real world solutions we loose many details that causes these solutions not to be able to fulfill their goals. The generalization steps deliver solutions that are mostly of low quality due to the lack of individual characteristics, thus inappropriate to solve real world problems.
Did you ever build a generic framework for a software project that should be re-used in your next one? Did you re-use it really? Or maybe you found that the framework you built was actually good just for the initial project, but still "imperfect" for the new one, so you decided to build another one with the same promise of generalization and re-usability? Does it sound familiar to you? That was exactly generalization that killed this cool idea with a framework. I repeat. It doesn't work.
So just remember this statement and forget generalizations. Forget proprietary, means built just for your purposes, frameworks. Allow thinking about abstract problems and abstract solutions only.
This blog post was created based on my upcoming book "architecture4me: Agile Architecture from the Trenches".
Comments
Post a Comment