What are the potential SCM problem Classes in the process?


When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified.
Potential SCM Problem Classes

  1. Multiple developer syndrome—When you have a project that requires more than one developer, there is the problem with multiple people working on one product base. This could be a test plan, requirements specification, or code. Effort is wasted when two or more people work on the same file and then save it. Without SCM control, the last person to save the file has those changes saved. All the other changes are lost. The simplistic method of locking a file while one person reads it prevents others from simultaneously working on the file.
  2. Multiple releases—Enhancements to the base product should result in additional releases of the product containing the latest changes. Once the second release is available, some users are on an earlier release. Having an SCM makes managing those releases possible. When bugs are reported, changes must be made across all impacted releases. As new features become available in the product, they must be made available to all current users, no matter what the release date.
  3. Product family—As products are built that offer the same capabilities across a heterogeneous set of hardware platforms, both the common and the platform-specific software bases must be managed. If a product operates on four versions of Windows, three versions of Unix, Red Hat Linux, and FreeBSD the user manual may be significantly the same. But there is a different installation process for all nine platforms. Without SCM, nine individual manuals must be written and maintained. With SCM, one documentation configuration item with nine versions will suffice, with the differences being only the installation procedure.
  4. Requirements change—The first law of systems engineering is that no matter where we are in the system life cycle, the system/software will change, and the desire to change it will persist throughout the life cycle. Dealing with this change represents a major management challenge. Having an SCM in place will ease the management of these changes to the requirements of the products that will occur. An SCM allows the easy identification of feature sets that group the requirements satisfied by a release or version of the product. These feature sets are tracked through development to delivery.
  5. Schedule change—As requirements change, so must the schedule. Mapping the feature sets for release to the schedule allows project managers to more accurately estimate the effort required for generating that next release. Having the SCM in place allows the project manager to look at historic effort levels in getting out releases. This is an enormous aid in estimating the “what if” scenarios that result from taking on new product users or providing customized solutions to other clients.
  6. Software changes—No product developer has the luxury to write code once and forget about it. Along with requirements and schedules, the software being developed changes in response to those other changes. Software is not static. That is its inherent power. It can be changed, so it will be changed. SCM systems track those changes so that, if the wrong change is made, a previous working version is available. This capability alone has saved enormous amounts of time as developers have tried out specific solutions that did not work in the product environment and were able to rapidly back up to a working version.
  7. Staff changes—In the best of organizations, people get promoted, take other jobs, and leave. When that happens in the midst of a development project, not just the technology knowledge goes out the door. The long-learned knowledge of how things are done is also gone. So when a replacement person is brought on board, they may know the technology, but without a documented SCM process, they will have no real idea how to do product development. SCM provides the framework and knowledge base of what has gone on before in the project. A new staff member has one place to go to understand the “how” of the organization’s development process and the “what” of the project to date.
  8. System/user documentation change—No product developer has the luxury to produce in a technology or tool vacuum. All product developers use hardware microcode, operating systems, tools, and documentation that are not under their control. When a major operating system change occurs (e.g., the next “best” release of Windows), an SCM will allow tracing all the CIs, components, and subcomponents that are impacted by that change. The change is isolated, and the amount of effort required to respond to the change can be estimated. This provides a responsible schedule for an upgrade based on situations beyond the organization’s control.

A template that may be used in the creation of a software configuration management plan (SCMP) appears in Appendix F, “Project Artifact Templates.” It includes management issues (organization, responsibility, etc.), SCM activities (configuration item identification, change control, status accounting, audit, and reviews), tools, techniques and methods, supplier control, and standards collection and retention.
SCM Staffing
On any given project, a few engineers or developers specialize in and become your SCM experts. While they are the gurus, everyone on your project will be a user of the product that they select, develop, and maintain. It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product.
We can group the characteristics and abilities needed by the four SCM functions: identification, control, auditing, and status accounting.


  1. Ability to see partitions
  2. Ability to see relationships
  3. Some technical ability
  4. System engineering orientation
  5. Programming


  1. Ability to evaluate benefits versus cost
  2. System viewpoint (balance of technical/managerial, user/buyer/seller)
  3. An appreciation of what is involved in engineering a software change


  1. Extreme attention to detail
  2. Ability to see congruence
  3. Ability to perceive what is missing
  4. Extensive experience with technical aspects of system engineering or software engineering

Status Accounting

  1. Ability to take notes and record data
  2. Ability to organize data
  3. Some technical familiarity
  4. System engineering orientation
  5. Programming

Once the staffing of the SCM function is complete and the overall organization’s SCM policy is established, the configuration control board (CCB) is identified. The CCB is the heart of the control function. It infuses sustained visibility into the process of change throughout the system life cycle and traceability into the process of change. The membership in the CCB is not limited to the developers or product line management. All stakeholders in the product must be represented. This includes the end-user usually represented by marketing, subcontractors used in the product development, product development funders, and the product developers. The CCB is the final decision maker as to what bug fixes, enhancements, and feature sets get included in the next product release.
The CCB has periodic meetings, with the results documented. These meetings can be done in a rapid fashion, and doing them online or via email is an adequate way to gain consensus and come to a decision. Important to status accounting is the documentation of CCB meeting minutes. The basic purpose of the minutes is to provide the CCB decision makers with the information needed to make intelligent, informed decisions. The amount of detail varies with the meeting frequency and technical content.

Tagged : / / / / / / / / / / / / / / / / / /

5 Keys to Automating Configuration Management for Application Infrastructure


5 Keys to Automating Configuration Management for Application Infrastructure

One of the trends being discussed in business, among vendors and in the analyst community is the importance of automating the functions performed by IT. Growing demands by the business, tight budgets and compliance pressures together accentuate the need for IT to be more agile, efficient and responsive to business stakeholders.

Naturally, vendors rush into this environment, each touting the unique benefits of its solution set and the urgency to move forward immediately.  A key area targeted for IT automation is the area of ‘configuration management.’  As it relates to automating day to day IT functions, configuration management can mean many different things: patch management, server and network management or others.

One of the newer targets for configuration management techniques is the application layer itself.  Think about that great stack of software that comprises a contemporary J2EE application—application server, web server, database, middleware and so on—typically from different vendors.  But they all adhere to industry standards, right?  So they all must plug and play together nicely, right? Not really.

In fact to make the entire stack work effectively, there are many individual configuration files, each one with a long list of their own parameters, which need to be edited, tuned and controlled.  And because the set of software is so complex, each element is managed by its own specialist in isolation without much knowledge of the other pieces of the puzzle.

The combination of many software assets, configured manually without much knowledge of dependencies leads to predictable results.  Someone makes a change in one area while stability and performance problems show up elsewhere.  Once the problem crops up, a team of IT specialists will take hours, maybe days to track down the problem and provide the solution.  Analyst firms like Enterprise Management Associates and Forrester Research agree problems in the configuration of the application infrastructure are now one of the leading causes of downtime.

Some vendors and businesses are now focused on a comprehensive approach to tackling this problem. The five building blocks required are easy enough to understand:

  1. Discovery and mapping—What application element and software assets do I have in my environment? How are they configured, item by item?
  1. Change monitoring—Inform management not only about the applications that have changed, but tell them how they have changed.


  1. Release Management—Sometimes called ‘provisioning,’ this relates to the ability to model configuration changes to the application infrastructure and then deploy those changes consistently across all phases of the application life-cycle.
  1. Auditing and Reporting—Show the business that IT supports corporate governance initiatives, not only at the server and network level, but also at the critically important application layer.


  1. Integration with the IT environment—Insure that the tools for configuration management of the application infrastructure work seamlessly with your problem management system or your configuration management database.

1.‘Discovery’ is usually where these solutions should start—as long as they do not end there!  In order to provide the IT team with a solution to managing the thousands of configuration settings in a J2EE application stack, you need to have a repository of the environment itself, a working model that reflects your application infrastructure.  With this repository of data in place, IT can then begin to comprehend how the various elements on the application layer are actually

2.‘Change Monitoring’ represents a critical component of a configuration management solution for application infrastructure.  With so many servers, instances and individual parameters, the number of configuration items quickly runs to the thousands per application.

Change monitoring must identify not only that a component changed, it must also identify exactly where the change was made and on which server(s).  Right now, IT specialists comb through text files trying to figure this out when there’s an application outage or when the application can’t make the transition out of the lab and into production. At mValent we call this “Hack and Hope”– they hack into text files, make a change and hope that it resolves the problem.  Automation tools instead can be used not only to find the change, but to find only relevant changes, ignoring unimportant differences.

Another key component of change monitoring to be addressed would be the notion of versioning and roll-back.  This is a well understood capability that exists in source code control systems and was applied by Documentum among others to the content management problem.  Now, we should focus on providing versioning and roll-back to the thousands of configuration settings which comprise a J2EE application stack.  Rather than have IT scramble to figure out what has changed when there’s an outage, let’s just re-instate a known working version of all of the configuration settings.  Then, IT can take the analysis and resolution off-line without the pressure to restore service immediately.

3. ‘Release Management’ is an important forward-looking area of a configuration management solution for application infrastructure. Right now, IT teams use a mixture of scripts and manual methods to deploy changes to application infrastructure settings. New solutions look to apply true automation to this process, insuring that configuration changes are modeled, evaluated and approved prior to deployment. Release management also validates that the process applies changes correctly. This also offers automatic deployment of changes to configuration settings and provides ‘out of the box’ templates for deploying new versions of an application server or a complete J2EE application stack.

These tasks currently take days to achieve and are error-prone.  Applying automation reduces cost and time while advancing quality.

4. ‘Audit and Reporting’ in a configuration management solution for application infrastructure refers to a capability report on the application infrastructure at a detailed level.  This would include reporting on change activity—which applications are driving the most change and causing IT execs the most headaches with SLAs.  Currently, this information exists at the server and network level, but less commonly for the applications themselves where change and upheaval is more likely.

Audit and Reporting also measures how your application infrastructure complies with recommendations, standards or your best practices for how the infrastructure should be configured.  Which assets are in compliance? Which are out of compliance?

Solutions should also measure change activity. Who made the change, Why, When, and so on.  And, it would be appropriate to measure whether changes were made according to your change process or were made outside that process.

5. ‘Integration with your IT environment’ in a configuration management solution for application infrastructure refers to the ability of the solution to fit with the other elements in the IT ecosystem, like your problem and incident management system, your Configuration Management Data Base (CMDB), a source code management system or your corporate LDAP directory.

Ideally the solution will integrate directly with these items and create a ‘closed loop’ environment for managing change to the application infrastructure.  As an example, when a ticket is opened requesting a change to the configuration setting for the web server, the solution should automate the actual change process, include the ticket number in the reason for change and report back to the incident system so that the ticket can be closed.

This eliminates yet another manual process and opportunity for error in IT management.

Benefits & Summary.  The major benefits of a configuration management solution for application infrastructure relate to reducing complexity and promoting compliance for IT.  By transforming today’s manual, error-prone tasks into a sequence of automated processes, your IT team will see benefits in:

·  Improving the productivity of your IT Infrastructure Team, by upwards of 50% and enabling them to spend more time on new initiatives rather than fire-fighting

·  Accelerating time-to-value for applications by 25%

·  Improving the quality and uptime of your applications by reducing the key elements that cause most of today’s outages

·  Providing comprehensive best practices and compliance reports to management and stakeholders.

With today’s IT struggling to meet increasing demands without headcount increases, a configuration management solution for application infrastructure offers important sources of value. configured.  More important, IT can begin to understand the dependencies between, say, how the data base is configured and its impact on the application server.  Thus, application configuration problems can be averted before they arise.

 Source: http://www.cmcrossroads.com

Tagged : / / / / / / / / / / / /

Command Line to find a Change list properties in perforce server


Command Line to find a Change list properties and associated path of the file in perforce server view:

Examples of the command you want:
p4 describe 1231928
p4 describe -s 1231928
p4 files @=1231928

Where 1231928 is the change list number.

Tagged : / / / / / / / / / / / / /