On Separation Anxiety...

You gotta keep 'em separated. Or so says conventional wisdom (and the song). One of the homework items for this week's UML Roadmap working group meeting was to propose a solution to the 'separation of concerns' problem in UML. I would argue that this, like many other problems with UML, is actually a symptom of more fundamental issues with the way specifications are defined/developed at the OMG, and that we ought to address these issues before it’s too late (if it isn’t already).

The bottom line is that the status quo will no longer suffice. Design by committee and vendor politics won't get us anywhere. Neither will closedness and opaqueness. In his webinar on ecosystem development the week before last, Mike suggested that ecosystems could be evaluated on the basis of five key concepts (see below). In order for the ecosystem of specifications (languages) that exists at the OMG to survive, I'd say its health in these areas needs to be measured and improved.

Co-evolved innovation. There's certainly a lot of innovation happening at the OMG, and by a lot of players. But sometimes I wonder how relevant the innovation is (in the absence of reference implementations) and how coordinated the activities are (sometimes chairing a task force seems a lot more like cat-herding than coordinated evolution).

Alignment of Vision. The OMG has a vision - MDA (Model Driven Architecture). But how aligned are the various OMG specifications with this vision? How long will the industry wait for it to be realized?

Degree of openness. The OMG is an open organization, in the sense that its reason for being is to produce open specifications. But its processes are less open than other organizations like Eclipse, and that has garnered it some negative press. To borrow from Bjorn's analogy, I think the OMG would benefit from being an openness bear that's "just right".

Degree of modularity. I think this is at the heart of the 'separation of concerns' problem. Languages like UML and its relatives are in fact designed to be modular - they're structured as sets of packages, or "capabilities" and then merged into various compliance levels... but something went wrong along the way, because subsets of these languages aren't as reusable as they were originally intended to be.

A network of niches. A set of vertices without edges is not a graph - it's just a set of vertices. I think many of the niches (UML, BPMN, IMM) are falling into place at the OMG; now, we just need to connect the dots.

Mike also talked about the importance of an open, extensible platform as the basis for a successful ecosystem. I think that's what's missing in the OMG ecosystem. Yes, it has MOF, but that's not a platform on its own; MOF is to the OMG as OSGi is to Eclipse. The OMG needs a platform (a working version of what the InfrastructureLibrary in UML was intended to be) upon which MOF-based languages can be built.

So, here's what I think should be done to solve the 'separation of concerns' problem in UML. Direct the renewed interest and energy in "fixing" UML toward defining a platform of shared concepts upon which UML (and other specifications like BPMN and IMM) can be based. Implement (yes, implement!) a proof a concept that demonstrates the benefits of refactoring UML based on this platform using mechanisms from the emerging Diagram Definition and Semantic MOF specifications, and extrapolate to infer how the same benefits could be reaped by other specifications like BPMN and IMM. Then, and only then, submit responses to the RFPs for Diagram Definition, Semantic MOF (MOF 3.0?), and UML 3.0.

Some say that making changes like this will only serve to disrupt the industry, to scare away the vendors and users once and for all ("they waited forever for UML 2.0; if we propose UML 3.0, we'll lose them for good!"). That's just FUD, if you ask me and, well, desparate times call for desparate measures. The way to avoid this disruption is to make the changes in a more open and transparent way than before, for example, in a project at Eclipse. Of course, we'd try to maintain backward compatibility if at all possible or, at the very least, provide an explicit migration path for existing tools. But let the (proven) technology speak for itself. If we build it, they will come. The time is now.