Effectively planning and setting realistic expectations before you start your CM project can mean the difference between actual and perceived success and failure. Here are some great tips to help you sell the success of your project and avoid costly pitfalls.
“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: