The CASE "for" ITSM vs. The CASE "against" EA

by Jeff Tash, ITscout

Computer-Aided Software Engineering (CASE) is making a comeback, or is it?

I’ve argued that CASE failed because of its inability to live up to its own wildly unrealistic expectations. CASE was supposed to be about “automating automation.” The reason why applying the principles of CASE to the construction of software was doomed from the start was because of the lack of any precision or rigor in the definition of the development process. As I’ve said before, the problem when building applications, is that every other step in the process generally gets described by the phrase, “then a miracle occurs.” That’s why most IT shops have relegated CASE, as well as such artifacts as “information engineering,” to the dust bin of history along with such other relics as structured programming, flow charts, and data flow diagrams.

As the “art” of computer programming has evolved over the years, much has been learned. Object-oriented and service-oriented architectures are nowadays the norm rather than the exception. The software development community has discovered ways to model systems based on classes, responsibilities, and collaborations (CRCs). The importance of “use cases” has also become widely recognized and adopted. The most promising work for improving the application development process is currently coming from a highly pragmatic approach known as “agile modeling,” a movement led by some very enlightened innovators (people like Scott Ambler and Kent Beck).

One can readily find examples today where the spirit of CASE has endured, if not its original promise. Just look at the emergence of powerful Integrated Development Environments (IDEs) like Microsoft’s Visual Studio or Java’s Eclipse. But make no mistake. Nobody in the software development world is seriously talking about CASE anymore. There simply aren’t any renaissance “James Martins” out there preaching how computers are about to start programming themselves -- automating automation. Those ideas have gone the way of other over hyped technological promises, like personal helicopters or robot maids. I’m pretty sure the Jetsons are from the 22nd century.

Computer science, as it’s practiced at the start of the 21st century, still more closely resembles a craft than it does engineering. Isn’t it ironic how disciplines that include the word “science” in their name, generally aren’t? Think about it -- computer science, behavioral science, social science, political science. Real sciences -- physics, chemistry, biology, astronomy -- don’t try to impress you.

Instead of thinking of CASE in terms of the automation of business processes by IT, there is an up-and-coming alternative perspective that focuses on “enterprise IT automation.” Some people refer to this burgeoning new area of IT automating itself as IT Service Management (ITSM). Others call it Enterprise Resource Planning for IT (ERP4IT). The goal is a cross-vendor, comprehensive integrated solution for improving the efficiency of enterprise IT. ITSM is very focused on IT’s internal processes, especially enterprise change and configuration management. Adoption of an industry standard repository, perhaps based on OMG’s Metadata Object Facility (MOF) and XML Metadata Interchange (XMI), would greatly facilitate managing internal IT workflows and improving IT process-related analytics. Because IT’s understanding of how to operate federated enterprise data centers is significantly more sophisticated and mature than its knowledge of software development processes, there’s a good chance that an ITSM metamodel and repository initiative will not suffer the same fate as IBM’s AD/Cycle. CASE and ITSM seem like a reasonably good match.

There’s another school of thinkers who want to apply the principles of CASE to Enterprise Architecture (EA). For example, consider Zachman’s Framework or Gartner’s Expanded Architecture Framework. The former has its rows and columns, while the latter consists of layers, grids, styles, patterns, bricks, and domains. Collectively, I find both models to be incredibly abstract, obfuscated and complex. Both Zachman and Gartner also share a dogma which states that before beginning work on the development of an enterprise architecture, the first step is to describe the key drivers of the architecture, develop a scope for the architecture, and create the first pieces of a governance structure, including governance objectives, programs, and tasks.

Personally, I can’t get past the intrinsic complexity and levels of abstraction inherent in Gartner’s and Zachman’s approach. I can only imagine the clueless looks as IT tries to focus business managers on creating these frameworks. To the uninitiated this must seem like voodoo modeling. I’m struck by the sense that the only people who ever really understand what the structure and meaning of these models are all about are those experts who are entering the information. I can envision enterprises spending huge sums of money populating these models, and then stepping back and wondering what they’ve got and what they’re supposed to do with all this information they’ve captured.

I challenge these pundits who proclaim to possess sufficient knowledge and understanding of EA processes at a level of rigor and precision necessary for successfully automating automation. My advice regarding CASE and EA -- put your hand on your wallet and run.