How To Avoid Team Obstacles When Designing A Large Scalable Framework
By Reynold Bhatia
In today’s blog, we touch on the ways you can customize and design a full-sized framework that allows you to manage multiple brands and projects under an existing framework.
A scalable website structure is crucial to any business because it means your company is utilizing your technical systems to their fullest potential and are getting the most out of your investment. Additionally, having the proper framework increases productivity levels, adds adeptness to teams, removes risks, delivers plans, and saves resources.
How can you tell when it’s time for a new framework?
You know your framework is in good shape when your teams feel empowered because very little improvement is needed in terms of organizing, prioritizing, and completing important tasks within your microsite. Everything is simple and streamlined.
Your team could be in need of a new, scalable framework when your days are filled with software redundancies, long repetitive steps, miscommunications, and mismanaged content.
The challenge in designing a large scalable framework
As larger businesses acquire smaller businesses, development teams find themselves working with clients with multiple brands under their umbrella. We see this all the time and it creates two central needs:
- for all brands to fall into the same technical architecture, allowing consistency and standards across all brands and channels
- the ability to easily upgrade when newer versions of each technology are released
One of our clients, a large American energy retailer, was facing this exact challenge. They had multiple brands under the same umbrella and needed to aggregate all of their websites into the same technical architecture.
Their goals were pretty straightforward. We had to:
- ensure upgrades and changes could be easily performed and not affect business-as-usual tasks for their teams
- account for possible future mergers or acquisitions and new product releases that would need to be added down the road
- train their internal teams concurrently and without disruption
Keep it simple
The solution, in this case, is to simplify by housing various brands under the same umbrella through the use of tech stack architecture.
You might be thinking, “Why would we put different brands under one umbrella when they are meant to remain completely separate?”
When you have a proper framework in place, it’s much easier to manage multiple websites, as well as onboard and retain your set teams. Still unsure? Here’s an example to clarify.
Scenario: Your teams are managing multiple sites: Marketing OE (online enrollment), OAM (Online Account Management), etc. However, every time a change or update is needed, they need to go through a long list of steps to ensure everything rolls out smoothly.
With the framework Content Bloom built, you can customize a template to suit your specific business needs, removing any and all unnecessary steps, thus shortening the overall upgrade process and minimizing risk.
How to build a customized framework
For our client, we worked in partnership with IT Architect Sreedhar Sundaram to implement the “cookie-cutter” approach to develop the first site and used that site as a reference for all others. This is, of course, approached in a customized way to simultaneously take care of unique requirements and common items across all brands.
Note: For our client, we implemented SDL Web 8.5 as the CMS and the DXA 2.0 framework in Java built with Maven as the web application. These technologies were chosen based on various factors, but keep in mind this solution could be implemented on any technology and is not specific to SDL Web or DXA.
The key here is modularity – the creation of smaller modules for features on the website to better manage them and the common modules used for features across the brands.
Here is a visual depiction of the technical layout for this solution.
- The core modules/features are the ones that are common across all brands
- Each brand has its separate features which could be similar to other brand features or unique to the brand
- All brand modules have a dependency on the core modules
- Here the web modules are standard DXA code modules that depend on all the other modules for code like .jsp’s, .java, and other front end related assets
- All of the custom code goes in the feature modules which makes the web modules empty with only the standard code that comes with DXA
- We want to keep a minimum number of feature modules to avoid the over-management of modules; so the number of feature modules actually depends on the requirements and can be adjusted.
Adding a new brand
Adding a new brand is quite simple.
- Create a new repo with the new brand’s web module and the feature modules
- The feature modules for the brand can be similar to an already existing brand
- Add dependencies to the core modules so that the common code can be utilized
Upgrading to a newer version
Since the web modules are empty, other than the standard code, only the web modules need to be replaced with the newer versions. In our case, we just have to replace the dependency jars with the upgraded versions and the framework is upgraded to a newer version. We only upgrade brands based on whether it is a client requirement.
Of course, testing will be obligatory after this process, to ensure the feature modules still work with the newer versions, but there will be minimal work required to update the business logic in these modules for the upgrade.
- Modularity makes it easy for debugging
- Minimal effort required for the upgrade
- Can scale up to N times, of course, limited by the hardware power
- Caching and other performance processes can be kept standard across brands
- Most of the post-go-live issues already have a resolution following the steps from the previous brands
- Too much modularity means maintaining repos at a granular level
- Modifications to the core/common modules need to be carefully monitored as it affects all the brands and requires a special process for updates
This framework has been really helpful. As our client unceasingly acquires newer brands, it makes it easy to bring those new brands onto our technical architecture, as well as simplifies the onboarding process when it comes to training the client’s team to maintain the websites and the content.
The takeaway here is that building customizable, scalable systems is crucial to your business’s success. As your company expands, so must your technology. Having the proper scalability in place ensures your business development will never be at risk of becoming stunted.
To learn more about our team’s SDL expertise you can contact us for a free consultation and follow us on social media.
Get the latest industry news, articles, and updates.
(No junk. Just the good stuff.)
How Composable DXP Connects You to the Best Tools for Business Success
Enterprises are leaving behind their traditional CMS in favor of a digital experience platform
How Moving from Drupal CMS to Contentful CMS Could Benefit Your Business
Your IT team has just notified you they want to migrate your CMS from Drupal to a headless CMS. A headless CMS is definitely something to get excited about for technical team members. For marketers and other non-technical departments, the process might seem a bit overwhelming, or at least that’s what you’ve heard. You might […]
What is Contentful CMS?
Learn about the Contentful platform, its benefits, and why companies opt for this headless solution.