Organizations will implement a formal change control process to handle changes to a software product. This includes all aspects of a software system, such as requirements, source code, and documentation. There are many reasons a change might be proposed, including correcting a problem (a bug in the software), implementing a functional change (a change to a business rule), or adding new functionality to the software.
The goal of the process is to ensure that if changes are made, it is appropriate to do so, and to minimize the effort, difficulty, and disruption when implementing the change.
Some change control processes involve a change control board (CCB). This is a group of project stakeholders who are designated to analyze proposed changes and decide whether they should be implemented. As a software architect, you may be part of a formal or informal CCB. Your knowledge and experience might be leveraged by the board to help with:
- Evaluating a proposed change to decide whether the change is something that should be implemented in the project
- Prioritizing the proposed change based on its importance and severity (if it's a defect)
- Providing an estimate as to the effort involved to implement the change
There are several approaches to change management that an organization might use. A software architect should be familiar with their organization's process. As a software architect, you may offer input to change an existing process or you may need to help formulate the process for the first time.
One approach to change management, which is the most formal, requires that a CCB review all changes, regardless of how large or complex the change may be. It does have the advantage of allowing multiple people to consider the change. Having more people aware of the proposed change and giving them the opportunity to discuss it will increase the chances of making the right decision. Especially with large, complex systems, it can be very difficult or even impossible for a single person to be aware of all of the technical and functional ramifications of a particular change. Having multiple sets of eyes looking at it can certainly help. Unfortunately, this process is going to take more time. The CCB could easily become a bottleneck. Not only will more time be spent making decisions, sometimes, time will pass just setting up the meetings to get everyone together. For situations where many changes or decisions need to be made in a timely manner, having a CCB review all changes may not be practical.
The second approach to change management is the opposite of the first method. Rather than have a CCB review every change, in this approach to change control, there is no CCB. Individual developers make their own decisions for all changes. The advantage of this approach is that changes can move through the process much more quickly than either of the other two approaches. Also, empowering developers can give them a certain level of confidence and satisfaction. However, only one person is thinking about each change, and as mentioned earlier, this can have a detrimental effect. The quality achieved for a given change will solely depend on the developer making the change. Some developers may be new to the software or inexperienced in general, or they may simply not be very good. Whatever the reason, the change they decide to make could end up causing even more problems than what it is attempting to solve. As was mentioned earlier, even with an experienced and quality developer, it can be difficult with large systems to be aware of all of the ramifications of a particular change. For minor defects, this isn't much of an issue, but it can be for large changes.
The third approach to change management seeks a balance between the first and second. In this approach, a CCB only reviews some of the changes. Typically, this means reviewing the most important or most complex changes. While changes won't be completed as fast as the second approach, and the changes won't be under as much scrutiny as the first approach, at least the changes that could potentially cause the most problems are reviewed, and the CCB is not a bottleneck for the other changes. It simply may not be practical to have a CCB review everything, but you also don't want to sacrifice all reviews. For example, the CCB might review the majority of enhancements and high-priority/severity defects, but not the lower-priority/severity defects (although an analyst, developer, and tester will still have an opportunity to think about all fixes while they are working on a defect). It really depends more on how large and complex the change is, and how important the functionality is that will be affected, and not so much on whether it is a defect or an enhancement. Sometimes, a defect fix is more complicated than an enhancement, so those factors are always taken into consideration.
Perhaps the best approach to change management, and the most pragmatic, is to always use a CCB, but create multiple levels of it. The organization may designate different levels of authority, and changes with limited impact and scope can be approved at lower levels of authority, while changes that have a larger impact are escalated to higher levels of authority within a CCB. When there are multiple levels of a CCB, the project's stage (that is, how close the team is to releasing) is sometimes considered when determining what CCB level is appropriate. A shift typically occurs as a project gets closer to release, with the focus going from wanting flexibility to wanting more stability and control over the changes.