When I think of enterprise CM, three things come to mind: 1. Tools (and processes) that expand CM from a software team to a product team capability, 2. Processes (and standards) that help keep CM consistent across the enterprise, and 3. Infrastructure (and management) that pushes CM technology into the rest of the organization. Enterprise CM is not a simple feature, process, or edict. It is the establishment of tools, processes, and infrastructure so that management can confidently reap the benefits of CM and ALM across the enterprise. Think beyond ALM, think beyond software, think beyond development, and think beyond products.
Enterprise CM Tools
You can have some very good tools with fantastic merge capabilities, automated builds, great workspace management, and dozens of other features, but if the tools cater specifically, or even primarily, to programmers, developers, and configuration managers, they'll remain very special purpose tools.
Enterprise tools need to go past CM to ALM and beyond. A product doesn't start or end in the development team. It starts with a concept, contract, or business case. The product moves through establishing a set of requirements that can be evaluated sufficiently to reach a contractual agreement to deliver a series of product releases. Product development involves project management, architectural design, test suites, documentation, verification tracking, customer delivery, deployment, customer feedback and support, change requests, change management, configuration management, build and release management, organization charts, maintenance, retirement and disposal, and more.
Enterprise CM must support the entire team and the customers as well. If the CM tools are specific to a few roles, the group doesn't really doesn't have much of a chance to gel into a team. If a developer can't understand the urgency of a customer, or if project management tasks don't line up with requirements, you end up with separate projects within a project: customer support, project management, requirements definition, build management, programmers. When the tool easily melds these functions into a consistent end-to-end capability; with point-and-click navigation across functions and through traceability links; with easy to use interfaces, dashboards, and guidance; it makes a big case for transforming the separate team functions into a single team function.
A number of commercial tool vendors have endeavored to provide comprehensive end-to-end tools. Some have had more success than others. Some have created multiple departments for administration, customization, glue management, and multiple-site operation. Others vendors have succeeded in giving us end-to-end tools with few, if any, of these additional groups. It's not an easy problem to solve. Multiple attempts have been made over time to create "backplanes" or portable tool environments to pull things together. Perhaps Eclipse has has the most success here, but there have been plenty of failures along the way, each contributing to the overall body of knowledge.
Open source tools tend to be good. There are great merge tools, editors, documentation tools, graphics tools, and so forth. But I think, at least for now, the concept of enterprise CM tools is beyond the scope of open source. One of the key reasons here is that a successful enterprise CM tool suite must be built on a common database, with a common process engine, and a consistent user interface. Things like multiple-site operation, administration, and customization must be shared, they can't be different for each function. Open source enterprise CM will come when a commercial vendor turns over its tools to the community. Not just any vendor; not just any tool. I think we have a ways to go before this happens.
Enterprise CM Processes and Standards
It's one thing to get a good CM/ALM process