There is no level 0 in the Capability Maturity Model (CMM), but there ought to be. Actually, there is no CMM either, at least in theory. It was replaced by the CMMI - Capability Maturity Model Integration - several years ago. However, the CMM has been so successful that it survived its own official demise.

The CMM describes a scale of effectiveness for software development processes. The scale begins with level 1, which is termed “initial,” and goes up to level 5, which is “optimizing.” Organizations at level 1 do not really have any software development processes. Things are done in an ad hoc fashion but can get done, albeit often exceeding budgets and delivery dates. To be successful at level 1 usually requires the participation of what are termed “heroes” - very intelligent people who work hard for long hours. Such an approach is not scalable and is often not sustainable in the long run. However, the peculiar things that happen at level 1 are perhaps the most interesting aspect of the CMM. Those who have experienced this level might be tempted to ask if there is anything worse. There may be.

Life at Level 1

My first experience of level 1 occurred when I was working on a large development project and noticed that a group of external consultants tended to work most weekends. In reality, they were fixing problems that they themselves were continually making, which were being found by the testing team. Did this earn them the opprobrium of project management? Certainly not. The more weekends they worked, the greater management held them in awe, and the more they were lavished with praise for keeping the project on track. Meanwhile, individuals who got their work done during regular hours and created no problems went largely unnoticed by management.

Down to Level 0

No matter how development ends up at level 1, the spirit of the CMM is that the heroes are definitely oriented to getting a successful product out the door. However, working in the data field has given me the chance to encounter a different type of “hero” who is not oriented to developing a product but exists to keep siloed applications running. This hero exists in a situation worse than what is envisaged at level 1. Admittedly, it may not fall within the domain of the CMM because it represents maintenance rather than development, but for the purposes of argument let us call it level 0.

The chief characteristic of level 0 is that the heroes are not distinct from an application - they are actually part of it. The hero must continuously intervene to keep the application running. It must be remembered that we are talking about maintenance, not development, of these applications. It is understandable how these kinds of situations arise - the heroes seek job security by becoming indispensable. They often have strong personal or political ties to the silo boss. Such ties are typically formed when the hero worked in the development of the application and stayed on afterward to support it. The level 0 hero, however, is a significant obstacle to enterprise-wide sharing of data.

Gaining understanding of the data in a silo for consumption in a warehouse is not often done well. Warehouse teams are more often oriented to technologies and methodologies than data to begin with. Even with a commitment to source data analysis, there is usually no way to avoid dealing with level 0 heroes. Documentation is always incomplete and unreliable, silos are almost never part of a metadata strategy that describes their data, business users are rarely available for interviews, reverse-engineering is challenging and analyst-driven data profiling is patchy and probabilistic.

Deliver us from Heroes

A level 0 hero has little to gain by sharing his or her knowledge of the data in the silo. They have made a Faustian bargain in which they have traded a lot of professional development and quality time for job security. That security would be challenged if knowledge of how the silo works were freely available.

My observation is that the heroes know how to get information about the data in a silo, rather than having this information available and at hand. Even if a hero is prepared to cooperate with a project that requires understanding of a silo’s data assets, it may take quite an effort to assemble the necessary information. At least, this is in the spirit of level 1, but at level 0, the heroes are more typically concerned with staying indispensable and thus are not inclined to share knowledge.

If warehouse projects were truly oriented to physical data management as much as they are to the tools and architecture involved in building warehouses, this problem would have been better highlighted years ago. “Hero” might even be a recognized data governance category along with “data owner” and “data steward.” This has not happened. However, the ever-increasing demand to share data across enterprises is building up pressures that will eventually be irresistible. One potential consequence of this may well be to disintermediate the level 0 heroes in terms of knowledge of siloed data. In fact, a class of tools that can do this has appeared. These tools automatically map the data landscape, both from a metadata and physical data perspective. They build knowledge of the data landscape without human analysis and thus bypass the need to involve heroes who carefully guard this knowledge. Perhaps the days of the hero are numbered after all.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access