Not since launching the Broadleaf Commerce framework in 2009 have we had a more significant release. Version 3.0 continues our goal of providing the best platform for custom commerce development.
Our team started this release with three major objectives that were heavily influenced by community and customer feedback.
- Removing the technical debt from our admin
- Simplify common customizations
- Increase the modularity of the framework overall
3.0 Objective #1: Remove technical debt
Technical debt is costly but hidden issues for many companies. In a 2010, article, a Gartner report estimated global technical debt at $500 billion dollars. The problem with technical debt is that it is hard to justify the cost to remove it. The benefits are difficult to justify in the scope of a single project. On the flip side, the longer the debt lasts, just like a credit card, the higher the interest compounds the problem.
At Broadleaf, we make technical stack decisions with the enterprise architect in mind. Our senior architecture team consists of engineers who have built enterprise commerce systems for over ten years. When choosing GWT as our admin platform, we felt it was the best alternative at the time for building a robust, desktop like application for managing products, offers, and content. Many Broadleaf Commerce developers chose us for our Spring based architecture and found working in the GWT based admin to be difficult. As we added in more features to the admin, we found that our development velocity suffered largely due to the technology and development patterns it required.
So, we made the difficult decision to remove this technical debt from Broadleaf Commerce and to rebuild our admin using a fully Spring MVC compatible solution. While we could have spent this time building commercial features and potentially selling more services and licensed products in the short-term, we strongly believe that this was the right decision for us and for you to make this investment.
We are now benefiting from faster development velocity, faster build times, and faster runtime execution of the framework. We expect to see an ROI on removing this technical debt within the year. Your ROI, as a Broadleaf Commerce customer / developer will be almost immediate.
3.0 Objective #2: Simplify Broadleaf Customization
The Broadleaf Commerce framework is designed to support almost any type of customization. That being said, there are certain types of customizations that keep coming up. We've made an effort in version 3.0 to simplify several of these common customizations. Here are a couple of examples:
Broadleaf Commerce offers easily extensible workflows where you can add custom logic to operations like add to cart and submit order. Prior to 3.0, extending workflows required you to copy and modify the out of box configuration. With 3.0, we provide a way to modify workflows without the negative side effects of copying the out of box configuration.
Annotation based admin configuration
While in 3.0, developers can extend any part of the admin by creating custom SpringMVC controllers and views, the fact is you probably won't have to. We provide an elegant admin annotation library that allows developers to build complex admin UIs by annotating a JPA domain. For example, with a line or two of annotation / configuration, users can reorder fields, remove fields, or even add new fields or structures.
In addition, we are currently soliciting feedback from business users who utilize our enterprise admin every day. In future dot releases of 3.x, you'll see the benefits of these usability studies making their way into the product.
3.0 Objective #3: Increase Modularity
Customers using an enterprise commerce framework have to be concerned about upgradability. Early adopters of Broadleaf Commerce found that we were adding features to the core framework at a pace that was difficult for their internal development team to keep up with.
We made several changes to our development process and to the product in general to address this concern. First, we now are adding most new functionality via "modules". These modules represent code that can be weaved into the Broadleaf Commerce solution as needed. For example, Broadleaf Commerce provides an Inventory module. If you want to use that module, you can easily weave that module into your solution. If you don't need that module, you won't be forced to use an upgrade that includes that feature.
Investing in a modular architecture provides the following benefits:
- Upgrades to the core framework will be less frequent and only when absolutely necessary
- Customers add only the features they need when they need them
- Partners and independent broadleaf commerce developers will be able to develop their own modules
The 3.0 release of Broadleaf Commerce provides tremendous benefits to current and prospective users of the framework We've positioned the admin with a technology that is more flexible, modern, and extensible than any other commerce platform.
We've enabled a modular approach that will allow us to grow the platform without requiring customers to undergo major upgrades but also empowering them to absorb significant commerce features on a timeline that they choose
We are excited about this release and think that the closer you look, the more you will be as well. We look forward to continuing to serve the Broadleaf Commerce community and customers.