Lessons From Building a Multi-Brand Web App
By: Eric Potter
The first set of challenges I want to talk about are the ones that didn't involve technology. Programmers are often quick to jump to the technical side of the project. But for multibrand projects, it is important to have a solid non-technical foundation before the development begins.
The original web application was developed with a specific personnel and specific roles in mind. More generally it was designed to be used by people within the organization of the partner. Some of the functionality made assumptions about people being available in certain roles. The brands that were added to the site didn't all have people that slotted into those roles the way the original brand did. This presented some challenges up front.
In hindsight, I can see that we were trying to use software designed for one organization in a different organization. This wasn't insurmountable, but it did take some additional coordination between various teams before the software could provide value.
Marketing professionals work very hard to establish a brand identity. Working with 6 different marketing departments presented an interesting challenge of coming up with something that worked for all of them. For the developers, that meant that we needed to rename the site and come up with a new layout. It also meant that we changed much of the verbiage on the site.
In addition to the non-technical challenges, we had technical hurdles we had to jump over.
One of the biggest challenges was modifying the database to hold data for all of the companies. While they all sell similar products, they all have subtle and important differences. One thing we did that worked particularly well was to have database schemas that are specific to some of the brands. This meant that when there was data that was unique to one of the brands, it was apparent to any developer because of the schema that it was in. I'm confident this prevented many bugs.
Something that took more time than I would have guessed was changing the division identifier from a single character code to a 5 character code. The original system used a single character code because there were only a few divisions. Because the expanded system had more than 26 divisions, we switched to a larger identifier. It wasn't hard to change the data type in the database. It was a lot of work to update all of the integration points to either work with the new codes or convert back to the appropriate older codes.
Some of the systems that the site integrates with are 20 years old. So updating these systems to work with the newer data formats was a special challenge. It was the first time I had worked with a COM application in a very long time.
Because of the differences in how the different brands operate, there were times when the code had to behave differently depending on what brand was using the software. Using the Strategy pattern worked very well for these scenarios. We implemented the differences in behavior in strategy classes. We used a factory to instantiate the correct strategy object for a given brand. The resulting code cleanly separated the concerns of the different brands.
The strategy pattern allowed us to encapsulate code that was specific to individual brands. But there were also times when the application needed to share some behaviors between a subset of the brands. In these cases, we utilized the decorator pattern. We wrote the shared behavior in a decorator class that we could apply to one of the strategy classes.
Summary of Lessons Learned
- Applications are built with assumptions about the personnel in the organizations that will be using it. If you are going to expand an application to be used in a new organization, identify these assumptions and address them early.
- When you are estimating the effort it will take to start using an existing application in a new organization, make sure the integrations are well understood and properly documented. Make sure you cover the physical connections and the data formats.
- Identify behavior that will be different between the various organizations. Use design patterns appropriately to keep the code clean as you add functionality.
- Businesses can get a lot of value out of using existing software applications in new ways. But it does present unique development challenges. You need to address these challenges properly to maximize the return on the investment in the additional development effort.
About Eric Potter
Eric is a Microsoft MVP and Software Architect for Aptera Software in Fort Wayne Indiana, working primarily in the .Net platform. He has been developing high quality custom software solutions since 2001. He is also an adjunct professor of computer science at Indiana Tech. He loves to dabble in new and exciting technologies.