Analysis: Supersize My Frameworks, Please

In a time of supersized mergers and consolidations and supersized data centers, developers may well spend the next couple of years demanding supersized, or application mega frameworks, too.

Enterprise applications, especially, are no longer immune to individual application stacks that were specifically created to tackle logic on a single tier. With the increasing need to make development more efficient, software architects are pushing the limit by mixing multiple application frameworks that span horizontally across multiple tiers in the hopes of solving complex problems with little coding. And why shouldn't they, right?

Solutions are not so straightforward. Take a car, for instance and picture the driver of the car as the developer. Consider that all of the major parts of the car are frameworks created by different groups of workers around the world. For the car to work, each part has to work in concert with all other parts. For that to happen, parts have to follow design standards, conform to similar engineering specifications and most of all, they have to fit neatly.

But this has not yet occurred with the frameworks we have today. Mashing up some of these frameworks into solution templates requires considerable work from architects. Software architects have a plethora of frameworks that they can use in their arsenal. And yes, many of the well known frameworks like Ruby on Rails and Struts are stable and testable, and for the most part live up to their reputation.

Almost all frameworks today are designed to be generic, mutable and cohesive. But not integrated.

Software architects must become part mechanic/part engineer to make the code from multiple frameworks functional and readily usable by different levels of developers. This is now the state of affairs in many corporations that are implementing large scale frameworks to solve complex business problems.

How did it get this way?

At one time or another every enterprise application has had its code made reusable. Over time, patterns emerged from logical constructs of units of code. This commonality led to what we know now as application frameworks, which are nothing more than libraries designed for specific programming tasks -- algorithms that developers need in their everyday lives and don't want to repeat. No sense in recreating the wheel.

Eventually, re-usability led to the creation of design patterns (largely during the 80's and early 90's) to solve vertical solutions. It was a kind of bunker mentality. Every stack worked in a silo. And code to glue these frameworks was made to solve specific business problems. This mindset crept into Java, almost from the beginning. .Net also accepted this model.

Fortunately, the important work done by the open source community is slowly changing the old way of creating frameworks. Component-based frameworks, including integrated frameworks that use the model-view-controller design pattern, are acting as overarching architectural frameworks. For instance, the S#harp architecture uses the new ASP.Net MVC framework to combine the Sprint.Net and NHibernate into a horizontal architectural template. Sprint.Net and NHibernate are .Net equivalents of the original Java frameworks.

But the emerging mega-frameworks are still relatively new concepts and have not yet gotten to a point of being cartridge-ready solutions. Still, software architects and developers are forced to address horizontally based frameworks in order to build scalable systems under tight deadlines. Many details have to be manually created in order for the frameworks to fit into a mega-framework. New techniques like Mashup eventually might lead to new design patterns that could help reduce the up-front work now done by companies to make frameworks into usable solutions.