The enterprise architect who supplies his or her development teams with custom or off-the-shelf frameworks often eliminates common programming tasks and application requirements. But frameworks can sometimes be too confining, or deliver far more than what’s needed for the project.
This raises the question: What are the ingredients for success in terms of application frameworks, or are they even worth the effort?
There have been cases, such as with Microsoft’s ActiveX Template Library, where a good framework can eliminate a lot of skeleton code that developers would otherwise need to write repeatedly. This isn’t universal, however. For instance, when I first began using Java, some colleagues created a framework to “make it easier to work with this new technology.” It failed because the Java platform was straightforward enough; there was simply no reason to put anything between it and the developer. (Java EE is another story altogether.)
Frameworks: The Spice-Rack Analogy
Joel Spolsky wrote a blog years ago called “Joel on Software.” One entry, entitled, Why I Hate Frameworks, describes the pains of sorting through and reading dozens of feature lists, and draws an analogy to building a spice rack with a “universal hammer.” All too often, frameworks built with good intentions end up forcing teams to conform their project to it.
Research and experience have taught me that frameworks that are an API/library combination with some extras (described below) are generally more successful than those that force developers to conform their programming style to them. Apache Commons, Cocoa, jQuery, Microsoft’s .NET, Ruby on Rails, the Zend Framework and Spring are good examples of this, while Enterprise JavaBeans is considered by many to be a bad one because of its complexity.
What are the qualities an enterprise architect should look for in a framework before setting out to have one built or used in the enterprise? The framework should:
- Provide cross cutter code (i.e., logging).
- Provide skeleton code for reuse.
- Avoid what I call “magic,” or hiding too many details.
- Avoid forcing development paradigms.
- Implement proven patterns (i.e., model-view-controller).
- Focus on APIs.
- Avoid facades that hide other APIs.
However, as enterprise architects, we need not only these qualities but also a more formal approach to framework design and usage.
Role Modeling: A Formal Approach
Frameworks can be described as black-box, white-box, or some combination. Black-box frameworks are usable as is; you simply use the framework API and its objects. A white-box framework is usually a set of interfaces to be extended by your code.
Either way, frameworks need to be integrated into your own projects in some way in order to be useful. This is where trouble often starts, if a framework adds too much complexity, or is too basic to provide any benefit.To help avoid either problem, use the concept of role-based modeling for frameworks. Whether you're building a framework or evaluating an existing one, role-based modeling provides a way to support four important qualities:
- Separation of concerns: Classes should be distinct, and each class's purpose should overlap as little as possible.
- Patterns: The implementation of acceptable patterns is key to providing reusable models that are the cornerstone of any framework.
- Class complexity: This involves understanding and describing how classes interact at the interface level.
- Object collaboration: This describes how class instances interact at runtime. This goes beyond class complexity, since it mixes in other elements such as data structures, memory usage and persistence.
To address these, role modeling formally describes how one object uses another. In short, an object must take on one of only a few well-defined role types when it uses another object. Role types are similar to class relationships, such as uses, extends or contains, but take into account run-time collaboration as well. Role modeling as a whole describes the collaboration of all the objects in your framework according to their role types. This controls the relationships and minimizes the complexities in your framework, making it easier to learn and extend for future use.
Where Do We Go From Here?
I asked two fellow enterprise architects what they thought about frameworks these days, and their opinions were in line with mine: Frameworks aren’t obsolete, but most organizations often get it wrong when building them.
Why is this? Often it's because frameworks are derived from a successful project and repurposed (often bringing too many characteristics of the original project with it), or designed by committee, with not enough consideration to how they might be used by a family of actual software products.
The consensus among us three is that, in most cases, it's best to find a popular framework that's well documented and successful in the industry, and extend it from there using role-based modeling to ensure usefulness, and avoid complexity.
Where do you stand on the frameworks question?