This chapter is from the book
This chapter is from the book
This chapter is from the book
Models as Assets
Some years ago, one of us was working with a large telecommunications company that was implementing a level-four protocol stack not once, but three times. There were three groups, each in a different part of the U.S., each building essentially the same system. As it turned out, each team was working a slightly different subset on top of different technologies (operating systems, languages, and the like) for different markets. We were able to bring these groups together somewhat, but the reuse we achieved was limited to concepts as expressed informally through the models. Geographical distribution, divergent goals, and just plain politics resulted in three almost completely separate projects.
The cost of building systems this way is enormous. The same system, or a simple subset of it, was implemented with three teams, which tripled the costs. Three times as much code was produced as was required—and that code was then added to the pile o' code the company needed to maintain over time.
In short, software is an expense. And, as we discussed in the previous section, reuse on the application level is often prohibitively difficult. Contrast this situation with the vision promulgated by MDA:
-
Take a model of the protocol stack off the shelf.
-
Subset the model as necessary.
-
Take models of the implementation technologies off the shelf.
-
Describe how the models are to be linked.
-
Generate the system.
When it comes time to change the application, we make the changes in the application model and leave the models of the implementation technologies alone. When we need to retarget an application to a different implementation environment, we select the models for the new environment and regenerate. There's no need to modify the application models. Costs are lower; productivity is higher, based on increased reuse of models; maintenance is cheaper—and each new model that gets built is an asset that can be subsequently reused.
The cost of building and maintaining systems this way is significantly lower. The incremental cost resides primarily in selecting the appropriate models and linking them together. The models themselves need to be constructed, of course, but once they're complete, they have greater longevity than code because they evolve independently of other models. In other words, they become corporate assets.
This is not just a vision: Systems are being built this way today. But not many systems, unfortunately—most folk are stuck pushing bits in Java or something else. The issue now is to increase the rate of adoption, which we hope will happen as people gain a rich understanding of MDA, starting with Chapter 2.