SPEM and the motivation for UML Profiles
As discussed in a previous post, one of the important move in the UML history was to change from Unified Method to Unified Language. Ed Seidewitz rightly suggests that the credit should probably be given to Rational (Jim Rumbaugh and Grady Booch) for this move. Remember that all this process was in the sequence of the work of the OOADTF group at OMG (Object-Oriented Analysis and Design Task Force) and that this group was organizing a confrontation and convergence between methodologies and methodologists. The idea of a methodology-agnostic language took thus some time to mature. If this idea seems obvious today, it was not always the same in 1995.
My observation point was the attendance to some OMG meetings from time to time. I had no information from inside Rational. I understand that the RUP (Rational Unified Process) was very important but I have no idea on the origin of the project inside Rational. I imagine that Philippe Kruchten was very influential on the process, but I don’t know the dates of these contributions and influences.
Coming back to this drawing of the previous post reproduced above, I should have mentioned that this is completely abstract and artificial. The dichotomy between product and process in software modeling is conceptually well presented above but there are two errors in the picture:
- The first one is that the name SPEM was found much later. If my memory is good, the work started with an unnamed goal, some sort of Unified Software Process Language.
- The second error in the picture was that there was never consensus on the use of a full fledged metamodel for SPEM. This is the story I want to record in this post.
The context was the continuing tension at OMG between so called lightweight and heavyweight modeling approaches, between UML strict orthodoxy and MOF deviants. The lessons of this tension could perhaps be examined today in a less passionate debate, but let us keep that for another discussion.
Of course nobody is naive and we all know the major influence of tool vendors on the definition of modeling standards and recommendations. At that time this was particularly important. After all, these companies were taking a major risk and it may seem normal to give them a major role in the definition of these standards. But it should be made clear that it was not industrial users or academics or any other categories of people that took the main decisions
The definition of SPEM was more or less made at the same period that the definition of UML profiles. The official motivation for profiles was to provide openness to the UML definition. But the real risk for providers of UML tools was to see the concurrent corporation of CAPE tools catching the market of software processes (CAPE = Computer Assisted/Aided Process Engineering). As a matter of fact, the description of the production of software (who is doing what, when, how and why?) is very similar to the process description of any other marketed goods.
In order to keep the SPEM market within the CASE scope (Computer Assisted Software Engineering, understand UML modelers), it was important that SPEM could be defined not only as a metamodel, but also as an UML profile.
This strategy worked quite well and has been more recently proposed again with BPMN. My opinion is that the profile mechanism has not been defined for conceptual reasons, but mainly for economical reasons, to protect the business of UML tool vendors and to allow them to make the heavy investments on building and maintaining their software tools.
There is now a significant literature on comparing the strict metamodeling approach and the UML profiling for defining Domain Specific Languages (DSLs). The debate is far from being closed. I just wished here to state that the rationale for initially introducing UML profiles was an economic and industrial strategy choice made by CASE tools vendors. The SPEM metamodel is much simpler than the UML metamodel and a pure SPEM tool would have been much easier to build. But the missed revenues would have weakened the UML tool market.
