The Tools, Processes, and Infrastructure of ALM

When I think of enterprise CM, three things come to mind: tools (and processes) that expand CM from a software team to a product team capability; processes (and standards) that help keep CM consistent across the enterprise; and 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 case for transforming the separate team functions into a single team function.

A number of commercial tool vendors have tried 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 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 (and tools) in place for a project.  It's quite another thing to do so across the enterprise.  The move from CMMI maturity level 2 to 3 deals primarily with establishing a common CM process across the organization.  How does one do this?

One of the big problems is that organizations often dictate a tool to be used across the enterprise.  If they pick the right tool, that’s great.  The vast majority of the time, though, the wrong tool is mandated and results in budget crunches, resource crunches and capability shortfalls.

Establishing an enterprise-wide tool requires understanding the CM/ALM process across the enterprise, and then selecting tools that can be used to support an overall process and framework.  This requires expertise and experience, as one project is not the same as another.  An agile project that delivers a constant stream of releases to stay ahead of the competition is much different than an infrastructure project that occasionally upgrades repository technology.  A development team of 3 or 4 is much different that one of 300 to 400, yet these variations exist in any large corporation.

Initial CM standards of trying to cope with the various project attributes were very generic in nature, adding insufficient process guidance for any project.  However, with time and experience, these CM standards are improving.

The process needs to be complete, but architected in such a way that the project variations can be supported within an overall framework.  Supporting agile and traditional development models really isn't that different.  If you think so, take a look at the artifacts that are needed and that have to be produced.  It's the packaging of the project management that makes the difference.  Unfortunately, a lot of the key players make the mistake that says a release process that occurs every two years doesn't have to be as efficient as one that occurs every month.  In other words, the goals aren't as lofty. 

Continuous integration works quite well in a traditional model, as does frequent customer evaluation and involvement.  Yes, design is different, as analysis gives way to production prototyping, but there is a mix of both in either model.  The CM process must cater to supporting the same elements in both models.  The tools must reinforce this support.  It's the use of the process and tools that can be adjusted to fit the model, as long as the process and tools have been defined in such a way as to support both.

The process has to be carefully architected with non-negotiable elements, but with the capability of weaving together these elements to support each project's unique requirements.  Perhaps a number of pre-canned variations can be established as part of the process architecture to help minimize the amount of weaving required.

Just as important though is the selection of tools.  Open source tools can’t be imposed on Ares V development, at least not with the state of current open source tools.  The same goes for most commercial tools, as well, with only a few exceptions in my opinion.  Tools must be process-centric, but also should be easily customized.  It must be possible to extend the tools to support the particular functions of each project, but customization and extension are not sufficient if they require too much effort.  Further, it must be possible to evolve process and tool customization over long periods of time, because needs will change constantly.

Enterprise process and tools across the organization will give a great benefit if users can move from project to project without having to undergo significant training in these tools and processes.

Beyond SCM
Assuming you can get the tools and processes in place, there's still another aspect to enterprise CM, which involves moving from traditional CM to organizational-wide CM practices.  What do I mean by this?

Let's start out by looking at hardware versus software development.  One uses PDM/PLM tools, while the other uses CM/ALM tools.  Don't try to impose one set of tools on the other's discipline, as it simply won't work.  This is because the tools, though this is changing, have been designed to meet the needs of a particular discipline.  If you haven't found one yet, it won't be long before you see CM tools that can address both Software and Hardware, turning two teams into one.  The requirement here is that tool vendors understand both Hardware and Software processes and their corresponding requirements.  This is not too difficult, but if the tools weren't built with this level of support flexibilty in mind, they'll not be easy to change.  Because software is such an important part of hardware today, this is going to happen, but may take a bit of time.

Let's move a bit further from SCM.  What about the other CM, also known as asset management? Again, the CM technology base is the same: tracking configurations, baselines, changes.  The end-user interface is, though, quite different.  Again, it comes down to understanding requirements and having tools flexible enough to adapt to the requirements and to support the processes.  There are different processes involved, different problems to be dealt with, and niche pieces of technology that can help.  For example, hardware and software that can report on its configuration is a big help to Asset Management.  It helps to identify changes made to a configuration from the configuration itself, sort of like identifying changes to a workspace that were made completely apart from the SCM tool.  RFID technology will help here. Change authorization procedures and technology will also help.  Add a few of these technologies into a CM tool, change the user interface focus and/or role functions, and you have an asset management tool that will also support development CM.

So far we've stayed more or less within the realm of recognized CM of one sort or another.  How are our financial spreadsheets evolving?  Who's tracking changes to processes and procedures?  How are we tracking human resources: requirements, offers, hiring, etc?  What does all of this have to do with CM?  Well, mature Enterprise CM contains a lot of intelligence that can be applied to other parts of the organization.  Think of the organization as the product - how is it changing?  Think of finances as measurement of a corporation's success.  How do we put business cases and requirements in place to ensure this success?  How do we track adherence to these requirements?  What about the legal department?  Not only are there a lot of similarities to software version control, but requirements, information access, and traceability are basic needs shared here as well as with traditional CM.

In fact, in the past year or so, the Institute of Configuration Management has expanded its domain from development to the full set of business processes.  There are dozens of business processes that can benefit from the disciplines of CM.  And all of these have components such as document management, problems/ issues/requests, project management and so forth.

This gives Enterprise CM an entirely new scope! Maybe we're not ready to move there yet, but remember that if you have a successful, flexible CM backbone, you're already molding business processes.  As users identify the benefits of a fully integrated data and process environment with effective role-based user interfaces, they're likely to identify other parts of the organization that could benefit.  If the tools and processes can be adapted to these areas, there will be a lot less re-inventing and a lot more team synergy.

Summing Up
Enterprise CM starts with tools and processes but requires, more than anything, experience and ambitious goals.  Expand your CM into full ALM and beyond.  Apply it across the organization by first understanding the needs of all projects.  Then move your successful backbone technology to conquer the rest of the business processes.   At that point you have established full enterprise CM.