As I mentioned in my last post, software frameworks are so deeply embedded into our lives as software architects and software developers. So, when I was assigned the task to develop a web application to automate the tedious manual tasks for the technical support team, my first reaction to such an challenging business requirement is asking myself the question, “What framework should I use?”. If nothing comes up, I will say to myself, “Aha, my chance comes” and will happy to roll up my sleeves to build one.

I guess all enthusiastic programmers are alike. Otherwise, we won’t see so many open source frameworks out there in Sourceforge, Java-Source and Apache. People just like to write more and more frameworks and secretly (or openly) hope that one day the framework will be as popular as Struts or Spring.

In fact, writing frameworks can bring many substantial benefits to the project:

  • Reusable: Same as software libraries. Frameworks can be reused. If the same problem needs to be resolve in several scenarios, why keep reinventing the wheels?
  • Time saving: Once the framework is established, development can be simple and easy. Developers can focus on specific business requirements without worrying about infrastructure. It saves overall development time and more importantly saves future development time. A solid architecture based on well designed frameworks will make future maintenance very easy.
  • Consistent behavior: Wherever the same framework is used, the same behavior can be expected because the workflow is defined by the framework.
  • Enforce a consistent coding pattern: Developing codes on a well-defined framework is must less flexible than free-style coding. Some patterns must be followed to make the codes work with the framework. That means more conformity and better maintainability.

However, too many times we witnessed the frameworks developed in-house went sour.

  • Time consuming: Developing a good reusable framework requires a lot time and energy. Will take the best developer group’s best efforts to develop a sound framework. For a new project, developing the framework may delay the initial time to the market. 2TP011
  • Future is unpredictable: The assumptions for the future use/extension to the framework go wrong a lot of times. Significant efforts spent ahead in building the framework may be wasted due to the wrong assumption.
  • Too flexible or too rigid: A good framework must walk a fine line in regard of flexibilities. A design that favors flexibility may lose the control and open the door for problems, while a rigid design may limit its reusability.
  • Too abstract: A flexible and powerful framework usually introduces many layers of abstractions. That makes the codes very hard to understand for future developers who are in charge of code maintenance, especially after the original authors left.
  • Too few documents: Many times, the framework developers are too busy developing to write proper documents. (maybe also due to job security). That makes the framework difficult to use. It contradicts to the very reason for building a framework.

Third party frameworks, especially the popular, well established, open source ones, seem to be the preferable solution.

  • Solid design and quality: Since the developers are dedicated to resolve the challenges for the framework, they usually will have more expertise in that particular field. A popular framework is heavily tested by many users and that usually lead to better quality.
  • Better documentation and technical support: Although it may sounds contradictory that third party frameworks are better supported than the in-house ones, it’s true most of the time. The reason is the third party vendors are forced to produce more documents and provide support in order to gain market share while in-house development teams lack such market pressure and incentives.
  • Satisfy developer’s self interests: Any framework requires significant learning time. For a new developer, learning a popular third party framework is much more useful to his/her future career than learning an in-house framework unknown to the outside world. So, it’s no wonder the in-house framework is not popular for new comers, although they are cherished by the “old-folks” who build them.

But, the third party frameworks are not immune from headaches. It can give us as much trouble as the in-house ones.

  • Hard to pick the right one: To start with, there are so many of them out there. It’s very time consuming to acquire the necessary information about each one of them to make the informed decision.
  • Overkill: This is true for most of the projects. For a framework to gain widely acceptance, it must be very rich of feature, flexible and extendible. The result, very complicate! For most of the projects, the popular framework will be an overkill with many irrelevant features. The deep learning curve may seem unworthy of the initial investment.
  • Risk of being hijacked: Since frameworks are so essential to the architecture, it’s easy to fall into the trap of deep dependency to the Vendor. It will be good if we code through some industry standard interfaces, like JSR 94 for Java Rules Engine, to achieve Vendor independence. Otherwise, we lend ourselves to the mercy of the Vendor. This is the exact reason I choose the Java Camp instead of MS camp, FREEDOM!
  • Black box: Although most of the popular frameworks are open source, we seldom download the sources. The framework implementations easily become the black box to us. When something goes wrong, we don’t know if it’s our codes or the framework codes. Debug beyond our codes is not easy. Even we have the framework codes, due to its complexity and abstraction, it’s not something easy to understand like Sunday newspaper. (Who says that’s easy?)

Okay, we are back to square one. What I am trying to say is that there is no silver bullet to resolve all our challenges. No matter we choose to use an existing third party framework or write our own, we need to carefully evaluate the requirements of our project, the resources/strengths we have, the time to the market and the maturity of the technology.

Back to the project I am working on right now, due to the limited the time and simple requirement to start with, I chose to write a very simple Business Process Management framework that will do the job for phrase one. It can be extended to phrase two with more functions. But, if the project goes on very well and expect to grow substantially, I plan to replace the simple framework of mine with an established open source BPM framework like jBPM from JBoss. I tried my best to keep a good object oriented design with clearly defined interfaces. So, I can easily port the codes over to another framework. The key point here is being Agile and don’t be afraid of refactoring work.

The job to establish the right frameworks for our business critical applications is never easy. But, that’s exactly the fun for good architects and developers!

More To Read: