“CM,” as I use it in this article, may involve security, hardware and operating systems management, production control and deployment, version management, change management and build management. My experience lies primarily with the distributed platforms that have exploded in the last decade in terms of growth and delivery for companies. These platforms have historically offered few means to achieve consistent CM across large organizations. There are now numerous robust tools available to manage file versioning, compilation and deployment while providing consistency in CM methodology, auditing and reporting across multiple application teams. Now you get the word, “Put our software development under effective CM so we can manage costs and tell what’s going on!” Hopefully, you also get the words “Management is 100% behind you,” and “Here is a nice budget, expert technical consultants and some fancy tools to help you deliver!”

A typical enterprise CM project, from the business perspective, involves dismantling siloed development environments in favor of a layered organizational structure where change and configuration management, testing and production control functions are pooled and offered back to application teams as services.  These siloed environments are often highly optimized for development, but are not as amenable to standardized planning, reporting and control mechanisms.  The enterprise CM project involves bringing some measure of operational consistency across the different application environments for at least some of these functions.

Project Planning and Gotchas
So, how can you embark on this ambitious plan with some hope of success?  How do you target dates without jeopardizing your career?   Rule number 1:  Don’t promise any dates. Seriously!  The dates are largely driven by the application teams and are impacted positively and negatively by every part of IT and the Business. Management should understand this right away, so be prepared and know your enterprise landscape. It’s very useful to identify “gotchas” as early as possible.

You can set target dates, but don’t stake your career on it. If your company is highly fragmented and you are aiming for centralized CM, you may be in for a rough ride. To have effective enterprise CM, you need some measure of centralization of many other IT functions. A recent project to standardize application code or move all UNIX applications to a common platform is good sign for any enterprise project.

One of the big things that is likely to give you a tough time is having a large variety of development tools in house. Each development tool typically has its own way of doing things as far as treating files as objects, compilation of source objects into runtime objects and deploying changes to runtime environments.  The distributed platforms (*NIX + Windows) are inherently file based.

Your development tools should be file based as well or you will be faced with providing unique services for each vendor’s proprietary system of managing business objects. There are many brilliant pioneers and visionaries trying to change this, but the fact is, for now, all the versioning, build and deployment functionality in all the major and minor CM tools are all file based. If you come across a tool that promises (and really does) drive down costs for coders by hiding and controlling all of the files, you are looking at expensive CM.  Hey, there is no such thing as a free lunch. Raise an issue with management and don’t touch it with a 10-foot pole.  C, COBOL and the newest old hand, Java, are usually safe bets. (Now if only, the developers don’t do something weird!)

In planning for the project, it is helpful to have an inventory of development tools with a simple chart that everyone can understand.  Here is an example:

WebCube deployment: some issues need to be worked out with J2EE deployments to multiple servers – must compile a separate EAR for each of 15 servers running the same app.

Marginify:  Puts everything in one giant file (too big for version control).  Must rebuild changes via a GUI on production machine (not controllable, can’t automate, and violates audit requirements).

Many of the “gotchas” will be unique to your organization – conflicts with or requesting process changes from other groups, etc.

Project Plans
Now that you’ve planned for your project you need a project plan, or project plans, as it will actually be. What you should be aiming for is developing a project plan template that you can apply individually to each application team.  What you put in the plan is up to you and according to your goals, but items like “source code validation” and “deployment design” are general enough for most applications, but is a specific enough milestone to identify progress and dependencies. You may develop a further, detailed task list that would contain specific items relevant only for the application at hand – “Identify compile flags for the Read1 compiler as used by developers.”

Pilot Selection
As you delve into your project plan templates, begin searching for pilot applications (pilots, not Guinea pigs I hope). You may be able to identify different categories of applications, such as a bunch of WebSphere applications with AIX production environments, and another set running Visual Basic and Visual C++ on Windows.  It is a good idea to pick a pilot from each category in order to be able to identify the entire scope for the enterprise project.

Also, do not pick your most complex applications for pilots – it is important to achieve some early measure of success to bring confidence to the participants and to aid in bringing operational support on line.  A large, complex application could take years to meet all of its milestones.  What makes an application large and complex?  Large numbers.  Large numbers of anything – people, configuration items, different development tools, different production environments, different geographic areas where development is taking place.  Sometimes “large” can mean just 2 or 3.

Progress Scorecard
Pick a few high-level milestones that you can track with a “scorecard.” With the large number of fairly technical tasks involved, this can be an effective way to communicate progress to management. The scorecard will have “These applications have achieved X,” and “These applications have achieved X and Y,” and “These applications have achieved X and Z, but not Y.”

Treasury:  Developers still have production passwords until 5 successful deployments have been made with the new system.

FireArms: Waiting for UNIX systems to standardize production environment.

Management may wish to set priorities for some milestones over others. Your project plan template should not be too detailed either as tasks required to meet certain milestones are likely to vary widely between application teams that have different development tools, release cycles, people...

Another word on dates – dates are still important and should be a part of your scorecard.  You will likely have to keep after applications you are working with, who because of their own priorities (CM is not number 1!) find it easy to constantly lower the priority of CM related tasks.  Having regular meetings and a visible presence will help a lot.

Results
Here are some real, anonymous, results from clients I’ve worked with that show how enterprise projects can proceed and be or not be successful depending on your goals.  A word of warning, the definition of “application” can vary from organization to organization.  The companies below generally applied more resources, had a positive corporate culture for change and had significant management commitment behind them than those that were less successful.  Thanks to all the people who helped with this article, but for whom we did not get prior approval to mention by name.

• 150+ small to very large apps in version, build and deployment control in 4 years in a Agile like SCM environment
• 10 large apps under version, build and deployment control in 1 year in a fragmented, conservative organization
• 450 mostly small applications including commercial desktop software under version and deployment control in a year and a half.  Agile-like SCM.
• 500 apps under centralized version control in one and a half years.

Sean Blanton is Director of Consulting for Catalyst Systems Corporation. Sean has been with Catalyst for 6 years as a distributed platforms change and configuration management consultant and as a developer, trainer and product contributor for Openmake. He has a Ph.D. in Physics from the University of Chicago and a B.S. from Columbia University.