Has CASE Morphed into EA?

by Jeff Tash, ITscout

Do you remember Computer-Aided Software Engineering (CASE), a technology whose “hype curve” peaked way back when Ronald Reagan was still president? CASE’s popularity reached its zenith just around the same time that IBM introduced its AD/Cycle. Of course, that event also marked the beginning of what almost became the end of IBM (but for Lou Gerstner’s miraculous ability to teach an “elephant to dance”). So, what went wrong? Why did CASE fail so miserably? And, what does this ancient history have to do with what’s happening in IT today?

I’m convinced that what killed CASE was too many promises by too many vendors. The technology was utterly unable to live up to its own wildly unrealistic expectations. Back in the 1980s, all the pundits were pontificating about “automating automation.” Everyone wanted to ride the coattails of W. Edwards Deming, an engineer who made phenomenal contributions to the field of manufacturing with his seminal work on “continual quality improvement.”

The basic premise behind CASE is that software development is a form of manufacturing -- albeit one that most closely resembles a “job shop.” Successful manufacturing requires a well-defined process along with a bill-of-materials list of parts and/or subassemblies needed at each and every step of that process. Together these provide the grist that fuels ERP (Enterprise Resource Planning).

The original notion underlying IBM’s AD/Cycle strategy was to provide a “repository” so that the multitude of tools employed at the various stages of the application development life cycle could store, and share, its metadata (i.e., data about data). This was CASE’s equivalent of a bill-of-materials.

Back to Deming and his advocacy for total quality management (TQM). He explained how the key to achieving TQM depended on the establishment of effective metrics. He pointed out that if you can’t measure a process then you can’t improve the process. But, most manufacturing processes are quite complex. There are way too many possible metrics. If you try to measure everything, you probably won’t have enough resources left to build anything. Deming’s solution. Statistical sampling. Continuously tweak the process. Constantly measure. Strive for continual quality improvement.

Needless to say, Deming’s invaluable contributions revolutionized manufacturing, beginning first in Japan in the 1950s, moving to America in the 1980s, and finally spreading across the world today through globalization.

Why has it been so difficult to apply Deming’s TQM principles to the smaller universe of CASE? I’d argue the flaws with CASE are due to a fundamentally false assumption. It’s flat-out wrong to suppose that software development has attained the level of maturity one would expect to find in an “industrial age” manufacturing process. Software development, as it’s generally practiced today, more closely resembles what one would typically associate with a “craft,” rather than the qualities one would normally attribute to an “engineering discipline.” In my opinion, the processes used to build applications have barely moved past the “stone age” and are probably closer to the “iron age” in terms of their maturation. The basic problem in trying to formally define software development processes today is that every other step is still generally described by the phrase, “then a miracle occurs.”

It doesn’t matter whether you’re pursuing “six sigma” or ISO 9000, it’s not possible for TQM to succeed without effective metrics, and you can’t measure a process if you can’t define it. Hence, the failure of CASE. It couldn’t live up to its own hype. The very term has come to mean the kiss of death for any software marketer who dares to use it.

But beware. CASE didn’t die. It’s morphed, instead, into a new computer industry buzzword -- EA (Enterprise Architecture).

I’m personally quite troubled by the morphing of CASE into EA. I have a problem when experts insist that EA must be top-down and the process formally defined. Blindly following this approach will almost assuredly lead to the same fate as CASE. EA, itself, is still an incredibly immature discipline. It’s not ready for the rigors of formally defined processes and statistically sampled metrics. I prefer more eclectic approaches where EA can be practiced in a manner more akin to what’s referred to in the world of software development as “agile modeling.”

When it comes to EA and CASE, I urge you to be cautious. Let me remind you of the old adage, “if something sounds too good to be true, it probably is.”