In the upcoming weeks we plan to share a number of documents that we've created that will help those interested in learning more about Frameworks, techniques, SDLC, and software architecture. There are three audiences that we have in mind; technology managers (like myself) who view things from the business (e.g. strategy, ROI, competitive advantage, and value) perspective, intermediate developers who want to grow their skills, and advanced developers who are looking for additional perspectives.
In preparation for a large insurance focused Enterprise CRM application for one of our customers, we've been gathering requirements (use cases, domain modeling, business analysis, etc...), determining implementation strategy, application architecture, and finalizing the technology stack that best meets the requirements.
As a part of that effort we evaluated the major ColdFusion MVC Frameworks, and are publishing our analysis (authored by Jon Messer) to the community. Although we have extensive Model-Glue II skills within the team, we have decided to move forward with the ColdBox Framework.
The analysis document explains why, but from a casual perspective here's my synopsis (the technical management perspective).
The project we're working on has undergone months of planning – lots of analysis over how the business functions, process engineering, domain modeling, use cases, usability analysis, you name it. In putting together the technology stack, the same spectrum of tools was evaluated from data modeling tools, database servers, data warehousing, reporting & analytics, to front end technologies like Flex.
Obviously it would take a year to do an exhaustive review of all the options and wouldn't necessarily yield significant value - so usually the evaluation was a trivial sanity check. But regardless of the type of technology or methodology, it came down to a BUSINESS decision. Meaning it's not about determining not what the best technology is, but rather what the best option for the business is.
Few would debate the merits of MVC, so when it came down to making a choice for a ColdFusion Framework the considerations or evaluation criteria that mattered to the business include:
- This is the foundation to many other considerations.
- Strong documentation helps reduce learning curve, and it makes the team function efficiently by reducing wasted time through trial and error.
- Development Velocity:
- This is an umbrella category that encompasses many things.
- It has to do with how fast developers can learn the Framework, how agile we can be, reduced time on maintenance, reduced time on defects, reduced overhead, standardization, how long it takes to ramp up new developers, unique features of the Framework, etc...
- One option is you could write your own Framework, but the question is what is the value in doing that? Its opportunity cost – those man hours could have been spent elsewhere. More importantly, leveraging the efforts of those who have built these Frameworks effectively makes your team bigger (as if they built it for you).
- Strengths of the team:
- You want to always play to your strengths.
- It's why companies will sell off divisions that have nothing to do with their core strength. Another technology may be hands down better, but if you can get to market using your existing skills faster than having to learn new ones, that's an important factor.
- In this case we have team members with extensive Model Glue skills, but at the same time have a diverse skill set.
- Third party risks:
- When you utilize a small open source initiative (small in the sense of number key project developers), there are risks.
- As a manager you want to always cover your bases, even if the likelihood of an issue is minimal. Taking risks is good, but make your risks based on information (vs. emotion) where the value outweighs the risks.
- To mitigate these risks, we made note of:
- Development activity
- Size of community
- Published Roadmaps
- Published Bug tracking system
- Though, in the worst case scenario you could manage the Framework yourself, and even better if you architect your Model right you can swap in a different Framework. In Jon's evaluation he did exactly that, and had the same application running on 3 of the major MVC Frameworks, including one Flex front end, all using the same backend Model.
- Professional Support.
From a technical level, our own experiences and research showed that all the MVC Frameworks we evaluated were generally equal in performance and scalability. However we found that ColdBox offered distinct advantages in other areas; particularly the toolkit nature of the project which offers various features like debugging, custom exception handling, interceptors, and AOP error logging abilities, but also the fine grain ability to hook in and extend the Framework.
From a business perspective, it was a no brainer. The level of documentation rivals professional technical publication teams. And the high degree of long term persistent development activity on the project provides security in the sense that these guys have an unlimited amount of passion to remain committed at that level for so long.
So a tip of the hat to the folks behind the ColdBox Framework for an outstanding job (Luis Majano, Russ Johnson, Rob Gonda, and Sana Ullah). We look forward to their continued efforts, and we hope to contribute to the project as well.