Enterprise CM refers to implementing Configuration Management across an entire organization. I have had this responsibility in large global organizations and I can tell you that it can be quite a challenge to implement anything across at an enterprise level. There are many reasons why this is true and you may find that you are confronted with very challenging obstables when implementing CM on an Enterprise level including establishing corporate standards, a global support function and just gaining acceptance among teams that may have their own culture and group dynamics. Working in a large corporation is often like working across many smaller organizations – especially when they have had a history of being kept separate. You may find yourself working in an environment where the divisions were separate and were simply combined as part of a corporate merger or acquisition. Read on if you would like to meet the challenges ahead and be effective at implementing CM on an enterprise level.

Is Enterprise CM different than CM in small groups?
In some ways, enterprise CM is the same as implementing CM in a number of smaller organizations. I have personally seen that large organizations have a global organizational culture and then often a more local division specific culture. There may be historical reasons for this and the team if often keenly aware of whether or not they are accepted as part of the larger organization. I recall one division of a large financial services firm that was involved with rather risky mortgage financial transactions. The parent organization did not want their name associated with the division despite the fact that team was operating within all proper legal requirements and was quite profitable. The image of this division was not popular (something about taking grandma’s house if she didn’t pay her mortgage on time) so this division was often left to fend for themselves. They adopted with own tools and processes to handle configuration management, application testing and other application lifecycle requirements. When a senior manager dispatched me to conduct an assessment of their CM practices, I found the team to self sufficient, cohesive and suspicious of the “city slicker” from New York City. Around the third round of beers things started to thaw out a bit.

My Corporate Standard
I have always insisted on three basic requirements for CM. The first is that you must be able to tell me exactly what version of your code is running in Production (or QA). The second requirement is that you must be able to tell me the exact version of the code used to build the release in Production (or QA) and you must be able to create a sandbox in order to make a small change to the code (e.g. create a patch) without any chance of the code regressing because of the wrong version of a header file (or other compile or runtime dependency). If you can do these three things then I don’t mind implementing CM a little differently for  your team - if that fits the way that you want to be able to work. This means that I establish a simply corporate standard, but I am also comfortable having some differences between teams. So Enterprise for me is actually very similar to setting up CM for a bunch of smaller teams with a few caveats.

Some things need to be centralized
Licensing, administration, servers, training and support should always be centralized. For example, implementing a complex and feature-rich source code management tool may require some specialized expertise – especially for administration, support and training. So there may be some good economic reasons to handle CM at an enterprise level. On the other hand, I have often found that it is more effective to train local administrators and plan for backups on a division level. So I look for a pragmatic balance between centralized administration and decentralization.

IT Controls and Compliance
When an organization has a requirement for establishing IT Controls and Compliance then you will often find that you need to work at a consistent “enterprise-wide” level. You may find the Office of the Currency (OCC) visited one division of your bank and ascertained that there was a lack of proper controls established between development and production. In this case. you will suddenly need to meet compliance requirements throughout the entire firm (and usually in an extreme hurray).

Asset Management
Some firms adopt asset management on a firmwide basis and suddenly Configuration Management becomes an asset management function. The itSMF ITIL v3 framework discusses how to do this with a considerable amount of detail.  Similarly, your organization may decide that you want to establish integration between your ITIL help desk and your source code management system. Similarly, Configuration Management Systems (CMS), Configuration Management Databases (CMDBs) and Definitive Media Libraries (DMLs) may be implemented on an enterprise level.

Don’t forget Agile/Lean and Self-Directed Teams
I don’t want to start a religious debate here, but research going back 25+ years has pointed to the fact that Self-Directed and autonomous teams are more effective for a number of excellent reasons. Whenever possible, I recommend that you allow a team to have their own autonomy as long as they maintain some basic corporate standard. This is certainly consistent with today’s increasingly popular Agile practices.

Conclusion
Enterprise CM can be a lot like implementing CM in a pool of decentralized smaller teams. You should establish corporate standards when necessary and pragmatic. You should be comfortable with realizing that one size does not always fit all and your Enterprise will be more profitable and effective if you can show flexibility!

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment