News

Ovum Analysis: Rediscovered frameworks look familiar

• By Gary Barnett
• June 17, 2002

[WEEK OF JUNE 17, 2002] "Frameworks" are receiving a lot of attention in high-tech circles -- again. Framework is a term used to describe a wide array of "things" that provide IT developers with some degree of pre-built functionality. Definitions can range from the middleware frameworks embodied by application server technology, to the development frameworks offered by advanced development tools to application frameworks in the form of pre-built components that allow you to quickly add functionality, like profiling or commerce capabilities, to a Web application.

For the more cynical, an equally valid description of a framework is "something that hasn't been finished."

My interest in the recent bout of enthusiasm for frameworks stems from the fact that if one were to undertake a technology archaeological project, you would find that frameworks have visited earth before. Frameworks formed the basis of most of the high-end Computer-Aided Software Engineering, or CASE, tools of the early to mid-'90s, which promised the same benefits in terms of productivity, time to market, quality, re-use and so on that the "new' frameworks of the 2000s are promising.

Will the latest generation of frameworks succeed where their forebears failed? I'm not exactly sure.

One of the big downfalls of CASE and high-end 4GL tools was vendor lock-in caused by proprietary languages and libraries. Clearly the "language" issue has changed. Outside the world of Wintel (which has a very rich framework in the form of .NET), Java is the lingua franca of the lion's share of all new development projects. But the language is only half the story when it comes to lock-in. Frameworks can lock you into a particular approach. You can't just recompile using vendor B's framework if you fall out with vendor A.

Other shortcomings remain as well. Frameworks require users to give up a degree of flexibility, and they typically have a steep and costly learning curve, which gets steeper as the framework gets richer. The biggest shortcoming, and the one I think will cause the greatest pain, is that frameworks are only effective and only pay for themselves if applied properly and consistently by the developers in an organization.

The framework approach is 40-percent technology and 60-percent methodology, and there is little evidence that we're any better at that than we were a decade ago.