February 1, 2004
Singapore is one of my favourite cities in the world. I like it for its people, for its various kinds of delicious food and for its advanced software companies. Singapore is also the cleanest city in the world.
I have just finished a week of intense work, meeting customers in rather small but competent groups. Basically all customers have expressed that the week was very important and they are now looking into how to move forward. Thus I feel happy with my work. I will soon take a flight to Seoul in South Korea, but before doing so I will reflect on one of my concerns with RUP.
In my earlier email I said that I often get the following question? “Is there nothing in RUP you don’t like?” I responded:
“Of course, there are many things I don’t like. However, they are in comparison with what I like rather small.” I said that one of them is “The way RUP describes architecture is unnecessarily complex and confusing.” In this postcard I will elaborate on this concern.
The single most important determinant of the quality of a software system is its architecture. A good architecture is an understandable architecture, it allows a system to grow gracefully for years to come, and it forms a system that is built out of reusable assets or that has harvested such assets.
Develop architecture first
Developing the architecture should therefore be done as early as possible. Even in theory it is very difficult to change a poor architecture into a good one with incremental techniques such as refactoring. In practice it is close to impossible. The costs are too high for any business-oriented manager to accept and he/she will typically opt for quick fixes instead. A good architecture needs to be created when the cost of creating it is small or even non-existent. Prioritization of architectural work has a very good return on investment. It will reduce the need for redesign and minimize throw-away work during the remainder of the project.
Architecture is captured by a skinny executable system
However, architecture is not just a paper product. The architecture must be verified and validated. We do that by first building what I call the “skinny system”, a system that includes a backbone with enough muscles to be able to exercise it. It is a system in its own right. It has everything a system has, but only things that are significant. Thus, it has all significant paths through the use cases (or scenarios); it has all significant subsystems, components, classes, nodes. Usually this skinny system only includes 5-15% of the final code, but enough to demonstrate that the significant elements work. And most important, we know that this skinny system can grow to become the complete system. This is so because we have scrutinized all features and use cases and selected to implement (part of) those that carry the largest risk, have the highest priority, or are unique in some other way. The remaining parts of the system can then be added incrementally without disruption. This skinny system is accompanied by a paper product called the architecture description. But now, this paper product is verified and validated. The architecture is actually working.
The architecture descriptions are views of the models.
The models are the models that we have in RUP. Thus it is the use case model, the analysis model, the design model, the implementation model and the deployment model. Well nowadays we have more models. We have a user experience model, we have a domain model and when we work with asset based systems (software reuse) we have even more models.
So far there is no major difference in what RUP describes as an architecture description and how I think it should be presented. The problem comes now when we start to look at these views of models. In RUP each view has been given a name. They are the use case view, the logical view, the process view, the implementation view, and they don’t map exactly to the models. It means that the developers have to deal both with names of views and with names of models. It is just confusing. I have yet to meet one developer or one tech rep at Rational that understands both this view structure and the model structure. Even some top experts at Rational could never really explain how these structures were related to one another. Most people either understood the view structure or the model structure.
And it could have been made so simple.
Since the final product is described by its set of models, and architecture is about an extract of these models, there is no reason for having separate names for views. Instead just call them simply the architectural view of the use case model, the architectural view of the analysis model, the architectural view of the design model, etc. Most people I talked to agreed that this was a simplification, but I could not convince the key people…and I didn’t get a reason for their hesitation. The only reason, I was told, for keeping view names separate from model names was that for architecture we needed a process view and there was no process model. That is an argument that I don’t accept. If we need an architectural view, we most certainly need a model as well, since the models are the complete description of the system.
Thus the most natural way to deal with architecture is to describe it as an extract of the model structure and call this extract for the architectural views of the models.
This is the right approach for other reasons as well:
There are more models than the original 4+1. The more we get the harder it becomes to give names for views that are different from the names of the models.
- With asset based development we get many more models; it becomes almost ridiculous to name its architectural views different than the models.
- The user experience model is as important as other models from an architectural viewpoint, something the advocators of separate names originally didn’t agree with. Would we give the architectural view of that model a separate name? No!
- Finally, test is nowadays not a separate model, but instead each of the other models has a view for testing (verification and validation). Thus we have test views of basically every model…are we going to give these separate names as well? No!
Thus, this is my proposal for you RUP developers. It is my hope that you take the chance to simplify the presentation of one of the most important artefacts in the software industry. Make the architecture description what it ought to be – an extract of the complete set of system models and remove it from being a creature living side by side with the system. The most important reason is to make RUP easier to understand. RUP is complex enough without making it unnecessarily complex.