I have many friends and acquaintances in the CM world that have lost jobs over the last year. In most cases, it has not been due to cutbacks in CM staffing as such, but rather due to the cancellation of major projects with which they were associated. In only a few cases was it due to across the board cutbacks, probably because CM is generally such a small percentage of the overall staff. What this has caused is CM'ers being split into components such as Build Engineers and Release Engineers. Change Management, at least the Version Control and Defect Tracking aspects, is being largely allowed to coast along with existing tools configured and running "as usual."

What does the continued economic situation hold for 2009? Here are a few predictions:

• The switch to new tools will be considered very carefully and require almost immediate payback. It is only to be competitive (i.e. allowing Development, QA, etc. to meet accelerated delivery dates with comparable or increased quality) that a switch will be justified. And any switch will need to occur very rapidly!
• A close look will be taken at license renewals. If there are "extra" licenses, these will be trimmed. If there is an annual fee to keep using a tool (versus just keeping a tool under maintenance), consideration will be given to replacing the tool.
• Tools that have a high administrative overhead, even if that overhead is to foster a desired customization, will be reviewed towards replacement - especially if FOSS tools could reasonably be used instead.
• Virtualization of Development and Test environments will require CM tools to operate in those environments and do so without additional cost. While discussed last year from an overall cost savings perspective, this year it will be driven more by the IT organization as they, too, try to cut costs. While failure to be able to migrate to a virtual environment may not be an immediate cause for tool replacement, it may well be a reason for scheduling its replacement within the next 18 months.
• The "quantum" used in deciding tool and role "costs" will be per person. Fractional allocation of personnel will be closely reviewed with the idea of "distributing" roles into non-CM related positions (primarily Development and Quality) used to allow reduction in head count. This will primarily impact organizations that have a CM team that provides overall support. In the case of project-specific CM teams, these will be reviewed in terms of each project's viability.
• One of two things will happen from a Process Improvement / Process Change perspective:
  • Projects will become more Agile in nature and CM will have to be able to rapidly address the mechanics associated with the process changes. If the existing CM'ers are not able to "roll with the punches" and make the needed changes in a timely fashion, they run the risk of being replaced by others who say they can (whether they in fact can or not).
  • Projects will cease process changes for the time being, thus not needing as much process change support from CM. Given the state of most CM tools these days, this means that fewer CM'ers will be needed to support each project.

What this means for tool vendors is that they need to ensure their product releases are very stable, do not include defects that were previously fixed and contain new features that will enable their users to become more productive with a minimum cost to implement. Of course, this is the same thing their customers are also trying to do in order to remain competitive.

Now that I have beaten the economic issue to death, let's take a look at last year's predictions and see how well they matched reality.

1. Things will continue on pretty much as they did in 2007.
   The focus on ALM/ALA tools did seem to continue to be the primary focus of tool vendors, though often this focus was more market-speak than reality. The predictions regarding build tools and java also seemed to be on target.
2. Dashboards will increasingly become part of IDE plug-ins, especially Eclipse.
   Last year, the details of this section accidentally got left on the cutting room floor. They were:
   
   Schiz: With today's sophisticated tools, there is just too much data and not enough information. With the use of dashboards tailored to each audience, each will be able to see at a glance what is important to them.
   Noid: The only problem I see is that each audience, whether it is Management, QA or whatever, will have to learn yet another tool in order to select what they want to see and how they want to see it.
   Para: Nonsense, that too will become part of a CMer's job. Just like setting up the CM tool reporting mechanisms and formats is today.
   Schiz: I think you will see more pre-defined dashboards initially than customizable.
   Phren: Or if they are customizable, they will be minimally so.
   
   I think both Schiz and Noid were right; there is too much data and not enough information coming out out of today's tools, but there is no great user community push for a better solution. While I think this will happen, I don't think it will happen in 2009 - especially given the poor economy and the need for other more critical features first.
3. Eclipse will continue to move towards a product model where it will become increasingly difficult to select an earlier release for download.
   This seems to be true and the anticipated problems also seem to be occurring. As tool vendors are bought up, merged or close down operations, the ability to use "old" plug-ins will increasingly become necessary. I am not sure how the Eclipse team will handle this, or even if they will address it in 2009.
4. Bridges will become more common as CM tool components.
   From all indications, this was true. The existing bridges were improved and new ones were implemented. Since the need for bridges continues, I think we will still see an increase in them for 2009.
5. The definition of what constitutes Configuration Management (CM) will broaden once again to include ALM, ALA and possibly other roles once assigned to other groups.
   There was a fairly decent start to a discussion on the merits of this trend and a desire for a future article based on it. I foresee the article appearing in 2009. I personally have mixed feelings as to whether CM should take on more process infrastructure.
6. More CM tools will advertise themselves as being "Agile Solutions," even if they really mean "CM Solutions for Agile Development."
   True for 2008 and I predict that it will continue to be so for 2009.
7. More "discussion" about ITIL and CM, especially whether ITIL is a subset of CM or not.
   This did happen and I think there will be more discussion during 2009, especially by the standards bodies. I think the consensus was that neither are subsets of the other, but rather they are complementary disciplines with a significant commonality up to, but not including, the tools level.
8. Component-level Dependency Management, especially of third-party components, will become more and more of an issue as Build Management (BM) advances to the next level. ALA will play into this as well.
   To some extent, this occurred during 2008, especially with the BM tools. There was more of an emphasis on adding post-build steps such as automated regression testing, deployment to staging areas, deployment to target systems and the use of electronic signatures for process-step approvals. I foresee the actual trend continuing for 2009, but the implementation of Component-level Dependency Management features will probably have to wait for a while before becoming something the existing user base will push for - especially since its implementation will necessitate increased tool and storage costs as well as requiring changes to existing methods.
9. On a more technical level, there will be a transition of CM tools to Virtualized Servers for both performance and reliability reasons.
   The trend towards virtualization did continue in 2008 and I see no sign of it slowing down in 2009. See the discussion above about the impact of the current economic situation.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment