Telelogic Synergy is not an SCM tool

In Januari I talked about Subversion being not an SCM tool. Now let's have a look at Telelogic Synergy, which has been acquired by IBM recently. Until recently, I did not have much practical experience with Synergy and most of it slipped away. Now, I am working with it quite intensively and I came to hate and love it.

So let me explain why I think Synergy is not an SCM tool either.

Promotion model
Since the introduction of the task-based, more or less as a replacement of the ancient object-based approach, Synergy has adopted the approach of change sets. Tasks are actually change sets.

In Synergy you can define almost any configuration regardless of how, where or when the objects are changed. There are a few predefined change models, e.g. Collaborative Development and Insulated Development. The difference is that with Collaborative Development all completed tasks come available to other developers, while with Insulated Development tasks are promoted manually by the build manager.

Using queries on the database you can define almost any configuration. Through (semi-)automatically updates of the configurations, objects are "promoted" to the configuration. So for this Synergy qualifies as an SCM tool.

Real baselines
With the introduction of Rapid Baselining, you can freeze a configuration of multiple components and subcomponents instantly. The resulting configuration are immutable.

So again, Synergy qualifies as an SCM tool.

No projects, teams and streams
Synergy structures a database into (what Synergy calls) projects. In fact these are not projects, but components that can be developed and released independently of eachother, of hierarchically if you wish. Calling them "projects" is misleading because they do not constitute an enterprise for an goal within an agreed timeframe, using a set of resources. Moreover, you cannot even assign people to a project (only to a database) or define a particular scope to a project.

Synergy does not know the concept of teams, or roles assigned to people in a project. It does define "roles" to assign tool privileges, but no roles in the sense of a project (e.g. project leader, librarian, developer, tester, release manager, etcetera).

It may sound strange, but Synergy does not know the concept of streams. You can create parallel configurations (called "parallel projects") and parallel versions, but the concept of "a flow of changes" (like a river meandering through woods and valleys) is missing. Configurations are more like cities (being somewhere, changing constantly but going nowhere) than like rivers (changing constantly and moving constantly). You can define concepts that look like branches or streams using the release value, purpose and platform, but they remain configurations not streams.
Even worse, Synergy is quite "parallel intolerant". There is no distinction between checking out the same version twice (with the same release/purpose/platform value) and checking out versions in completely different projects (with different release/purpose/platform value. Why would you be need to be warned that someone in another project is changing the same object as you are? I can understand why you need a warning if it happens within your own project team.

Change sets
As a wrote above, tasks (or change sets) are in the core of Synergy. It's more powerful and more comprehensively implemented than any other tool I know.

Components
At first sight, the so-called projects may be considered as components. However, since Synergy tries to be "smart" in selecting sub-project versions (or sub-component versions) there is a clash between using baselines of released components and using a development configuration of a sub-project/sub-component. Due to this smartness, Synergy sometimes selects the "wrong" configuration.

No roles
Yes, Synergy does define roles but only to distinquish between different tool privileges (e.g. developer, build_mgr, ccm_admin). Roles to separate responsibilities and authority, for supporting promotion models and release management are absent.
Although... you can define a change promotion model in Change Synergy that grants authority to promote requests. So in Change Synergy (control of requests) roles can be defined but in CM Synergy (control of configurations) you cannot.

Although some things can be customized, Synergy does not quality for SCM tool here.

Limited branching
Some branching can be implemented using release, purpose and platform, but it is rather a way to distinguish between different configuration than between different branches. Also, Synergy supports parallel versions but it is hardly sufficient to call it branching.

Conclusion
Taking all the pros and cons into account we can conclude that Synergy is a very powerful tool and it comes close to a SCM tool. Yet, it lacks several important concepts.