Section 6.1. A Brief History of CMMI

6.1. A Brief History of CMMI

The Capability Maturity Model, and its evolution into CMMI, began in the wake of the PC revolution in the early 1980s. During that time, data-processing departments across America underwent an abrupt and radical change. The once predictable landscape of centralized processing, batch loads, and dumb terminals gave way to a kaleidoscope world of personal computing. This change split the discipline of data processing two ways. First, it discarded the concept of "stability through limitation." Computer departments were now faced with a myriad of options, a constantly changing (to this day) sea of choices. New architectures, programming languages, database systems, spreadsheets, and communications avenues all promised to deliver a host of rich and robust capabilities that were faster and cheaper than ever before.

Second, and perhaps more important, the control of technology moved from the back room to the front desk. Personal computing became people computing. Users gained an unprecedented degree of control over what popped up on their screens. And they quickly became a savvy bunch to deal with.

In the span of a decade, factors such as choice and accessibility, falling costs, and rising performance flipped data processing from being load-driven to being demand-driven, so much so that today we no longer "process data," we "manage information." DP is now IT. And software, once an adjunct to any business, has now become fully absorbed by business. The two have become inseparable. This integration became apparent quickly. Even in the mid-80s, the dominance of this trend was making headlines in technology circles. And its impact was being seriously assessed. The effective management of software and technology directly translated into business success. This rationale extended a step further: for America to compete in a rising global economy, it needed resources for effective technology management.

That conclusion did not go unnoticed by technology theorists, politicians, and corporate strategists. These new technology dimensions were recognized as part of a permanent shift in the dynamics of information management. And the theorists, politicians, and strategists knew the weight of this shift. These disparate parties organized their voice into one and appealed to the U.S. Congress to establish a national resource for advancing knowledge of software engineering and technology, and to address what was seen as a growing need for effective technology-management models.

Congress responded by establishing the Software Engineering Institute at Carnegie Mellon University in Pittsburgh, Pennsylvania. The SEI was chartered to operate in the public interest as a federally funded research and development center. Placed under the sponsorship of the U.S. Department of Defense, the SEI began its mission with work on a framework for quality management in the arena of software development. That framework became the Capability Maturity Model.

At the time, quality management models for the manufacturing industry were in full bloom. The ISO 9000 series was enjoying broad interest. Japanese innovations like Just-in-Time delivery, Assembly-Line-Control, and LEAN were attracting worldwide press. Six Sigma was emerging at places like Motorola and General Electric. The SEI was taking a close look at all of these. And it was also dissecting the work of noted American experts on quality. The work and philosophies of quality pioneers such as Philip Crosby, Malcolm Baldridge, George Box, and Edwards Deming were explored and analyzed for application. This effort culminated in 1987 with the publication of Watts Humphrey's book Managing the Software Process (Addison-Wesley Professional). The book synthesized the critical thinking in quality management and applied it to a series of practical steps, organized by maturity levels, that an organization could undertake to manage its development projects. Later that year, the SEI used Humphrey's approach as the basis for version 1.0 of the Capability Maturity Model. The name reflects the attitude of the quality approach: the more mature an organization becomes in its use and management of process, the greater its capabilities grow.

The CMM was founded on two well-known quality principles. The first is the idea that "process works." In other words, in the manufacturing realm, where you execute a series of distinct steps to create a final product (whether that's coat hangers or surgical lasers), a proven, tested process will ensure better quality than a haphazard, ad hoc one. The second principle is "a performing organization is a learning organization." The idea here is that successful cultures succeed through continuous innovation and improvement, and for those traits to exist, the organization must operate in learning mode, in a mode where it regularly assesses its performance and looks for ways to do its work better. The organization welcomes self-consciousness.

Those two principles were new to the newly transformed technology industry. But the Department of Defense, the SEI's official sponsor, saw the value and was first to broadly adopt the model. Soon it was able to demonstrate CMM's effectiveness. That led to the CMM's wide dissemination. Within five years, over 5,000 IT organizations had adopted the CMM as a working quality model. The SEI meanwhile was taking the base concepts of process improvement and applying them to a wider range of IT disciplines. The original CMM was termed SW-CMM, since its primary focus was on process improvement for the tasks of software engineering. The SEI then designed a similar model for the discipline of systems engineering, SE-CMM. Later it shaped a model for integrated product and process development, IPPD, and Supplier Sourcing.

Each model found its niche in IT departments around the world. But soon, users discovered they were employing several models within the same organization to meet different but similar needs. They expressed the desire for a single integrated model that could be followed for systems engineering, software engineering, or integrated product development. The SEI saw this as an opportunity not only to consolidate several models into one, but also to simplify and, to an extent, "genericize" the requirements of CMM, no matter what its flavor.

The resulting integrated model was released in 1999 as CMMI. Then in August of 2006, the SEI released updates to CMMI (with some streamlines and consolidations, and the introduction of "constellations" of models) known as version 1.2. From this came CMMI-Development for product and process development, and CMMI-ACQ for acqusitions. In this book we discuss the CMMI-Dev model. For the sake of convenience, we'll refer to it simply as CMMI.

CMMI, then, can be seen as a gift from America to America, as a toolkit to help make American IT enterprise remain innovative, competitive, and productive. But it has actually become more than that. Today, we can see itas many people in other countries doubtlessly doas a gift from America to the world. In the following section, I'll look at the question of ownership regarding CMMI.