Drupal Planet

Mediacurrent: Making the Business Case for a New CMS

3 months 2 weeks ago

Have you ever decided on investing in a product or service, but require approval from executive sponsors before proceeding with your purchase? Or do you like a product or service, but are hesitant to make the investment in it because it’s costly?

If either of these scenarios describes the situation you’re in, a business case is an excellent thinking tool that can help you with your decision.  A business case articulates the rationale for investing in a product or service in terms of numbers. It is often presented in a formal document, but may also be presented through more informal methods like a spreadsheet or even a single slide in a slide presentation. It further provides a way to make your case to nontechnical decision-makers without needing to provide the specific intricacies about the method or approach to your desired product or service’s implementation. 

To build a business case, perform the following steps: 

  1. Define the options to evaluate
  2. Determine the costs of each option
  3. Determine the benefits for each option
  4. Recommend an option based on cost and benefits

Let’s look at each of these steps more closely.

Defining Your Options

When evaluating a new product or service, you instantly are faced with two options: purchase the new product or service, or stay with what you have. In many cases,  decision-makers start with a bias toward the status quo because there is no cost in transitioning to new technology and the business process that goes along with it. Further, if a new product or service is being considered, its competing options should be considered as well, for example, if you’re considering Drupal as a web content management platform, consider WordPress too.

Let’s illustrate with an example. Say you have a proprietary, licensed legacy content management system (CMS) that is poorly performing and difficult to maintain. You and your company are no longer happy with it and want to make a change. Your budget is limited, so an open-source solution is more attractive because it carries no licensing fees. Drupal is certainly an attractive option, but as just stated, add WordPress as an option. This brings our options to the following:

  • Drupal
  • WordPress
  • Status quo CMS

In a real-world scenario, it’s good practice to consider more options than this, including evaluating proprietary options like Sitecore and Adobe Experience Manager. For the sake of simplicity, however, let’s limit our example to the ones we’ve listed. 

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are approximations only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the three options. These entail the licensing and build estimates for each option. This illustration assumes a simple implementation with little to no customization. Please note that these numbers are for illustrative purposes only. Real-world figures, driven by project requirements, will certainly differ.

Cost

Drupal

WordPress

Status Quo CMS

Initial License

$0

$0

$0 (already paid)

Build

$100,000

$50,000

$0

Total

$100,000

$50,000

$0

 

It comes as no surprise that the implementation cost of the status quo CMS is $0, because, after all, it has already been bought and configured. The licensing costs of all three options are $0 because Drupal and WordPress are open source offerings, and the license fee of the status quo CMS has already been paid. Had Adobe Experience Manager or Sitecore been considered, their license costs would be non-zero. In our example, we budget more for the Drupal build than that of WordPress because in our experience, with Drupal’s greater power and flexibility comes greater complexity, and that typically translates to greater investment in development hours. 

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs. To reiterate, these numbers are for illustrative purposes only. 

Cost/year

Drupal

WordPress

Status Quo CMS

Maintenance and Support

$20,000

$10,000

$50,000

Ongoing License

$0

$0

$10,000

Total

$20,000

$10,000

$60,000

 

Factoring ongoing costs makes it immediately apparent that the status quo CMS is costlier in the long term, both in maintenance hours spent and in annual licensing.  As with their initial implementation costs, Drupal’s ongoing costs are greater than those of WordPress because, again, of Drupal’s greater complexity.

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue (again,  just an illustration), the following table summarizes the benefits of each option. 

Benefit/year

Drupal

WordPress

Status Quo CMS

Annual revenue

$200,000

$150,000

$100,000

 

Finally, we see where the investment in Drupal’s complexity pays off; its greater functionality typically means a greater ability to meet ever-evolving needs. We translate this in our example to a greater annual revenue than that of WordPress, and both CMSs, being more functional than the status quo CMS, are capable of generating more revenue. 

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison:

The above graph makes the following assumptions:

  • In Year 1, the Drupal and WordPress options earn no revenue because they’re being built
  • Likewise the status quo CMS is earning revenue in Year 1 because it has already been built

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, staying with the status quo CMS is the best option.
  • If your organization is willing to make a moderate up-front investment for moderate long-term benefit, WordPress is the best choice.
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, then Drupal is the way to go.

Admittedly, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

BADCamp News: San Francisco Drupal User Group welcomes in the new year

3 months 3 weeks ago
San Francisco Drupal User Group welcomes in the new year Mon, 12/21/2020 - 12:00 volkswagenchick Mon, 12/21/2020 - 07:58 Do you miss BADCamp and the rad community that comes along with it?? We do too!! But you know what?! We still get together at least once a month for San Francisco Drupal User Group (SFDUG)... and SFDUG is gearing up for the new year, and we want to introduce the exciting winter lineup!! Drupal Planet

Axelerant Blog: A Complete Overview of Drupal Migration & More

3 months 3 weeks ago

With the launch of Drupal 9 in June 2020, the topic of Drupal migration is fresh on everyone’s mind. We will be delving deeper into the nitty-gritty around the topic in this blog. 

Migration is the process where the content from the old site, converted into the desired format and is saved in the new site. Sometimes, migration is a simple activity of mapping the source content to the destination content types and sometimes, it is a bit more complicated.

Let's take a comprehensive look at the Drupal migration process in context to the recently launched Drupal 9, and what’s involved in migrating from different versions. Here's what we will be discussing about:

01. Drupal 7, 8, and 9

02. Migrating Then and Now

03. Drupal to Drupal Migration

04. Migration from external sources

05. What’s More?

Mediacurrent: Making the Business Case For a New CMS

3 months 3 weeks ago

Have you ever decided on investing in a product or service, but require approval from executive sponsors before proceeding with your purchase? Or do you like a product or service, but are hesitant to make the investment in it because it’s costly?

If either of these scenarios describes the situation you’re in, a business case is an excellent thinking tool that can help you with your decision.  A business case articulates the rationale for investing in a product or service in terms of numbers. It is often presented in a formal document, but may also be presented through more informal methods like a spreadsheet or even a single slide in a slide presentation. It further provides a way to make your case to nontechnical decision-makers without needing to provide the specific intricacies about the method or approach to your desired product or service’s implementation. 

To build a business case, perform the following steps: 

  1. Define the options to evaluate
  2. Determine the costs of each option
  3. Determine the benefits for each option
  4. Recommend an option based on cost and benefits

Let’s look at each of these steps more closely.

Defining Your Options

When evaluating a new product or service, you instantly are faced with two options: purchase the new product or service, or stay with what you have. In many cases,  decision-makers start with a bias toward the status quo because there is no cost in transitioning to new technology and the business process that goes along with it. Further, if a new product or service is being considered, its competing options should be considered as well, for example, if you’re considering Drupal as a web content management platform, consider WordPress too.

Let’s illustrate with an example. Say you have a proprietary, licensed legacy content management system (CMS) that is poorly performing and difficult to maintain. You and your company are no longer happy with it and want to make a change. Your budget is limited, so an open-source solution is more attractive because it carries no licensing fees. Drupal is certainly an attractive option, but as just stated, add WordPress as an option. This brings our options to the following:

  • Drupal
  • WordPress
  • Status quo CMS

In a real-world scenario, it’s good practice to consider more options than this, including evaluating proprietary options like Sitecore and Adobe Experience Manager. For the sake of simplicity, however, let’s limit our example to the ones we’ve listed. 

Determine the Costs of Each Option

Two different types of costs need to be considered when evaluating options, the cost of the initial implementation, and the ongoing and operating costs once the implementation is complete. The following two tables approximate these costs. Note: these costs are approximations only to be used as an illustration. Actual costs can only be calculated once detailed requirements are considered. 

Implementation Costs

The following table summarizes theoretical implementation costs for each of the three options. These entail the licensing and build estimates for each option. This illustration assumes a simple implementation with little to no customization. Please note that these numbers are for illustrative purposes only. Real-world figures, driven by project requirements, will certainly differ.

Cost

Drupal

WordPress

Status Quo CMS

Initial License

$0

$0

$0 (already paid)

Build

$100,000

$50,000

$0

Total

$100,000

$50,000

$0

It comes as no surprise that the implementation cost of the status quo CMS is $0, because, after all, it has already been bought and configured. The licensing costs of all three options are $0 because Drupal and WordPress are open source offerings, and the license fee of the status quo CMS has already been paid. Had Adobe Experience Manager or Sitecore been considered, their license costs would be non-zero. In our example, we budget more for the Drupal build than that of WordPress because in our experience, with Drupal’s greater power and flexibility comes greater complexity, and that typically translates to greater investment in development hours. 

Ongoing/Operating Costs

After implementation, each option incurs recurring costs. This is a critical consideration in evaluating options that often gets overlooked, and we recommend you always factor in these costs in your decision. For our example, the following table summarizes those costs. To reiterate, these numbers are for illustrative purposes only. 

Cost/year

Drupal

WordPress

Status Quo CMS

Maintenance and Support

$20,000

$10,000

$50,000

Ongoing License

$0

$0

$10,000

Total

$20,000

$10,000

$60,000

Factoring ongoing costs makes it immediately apparent that the status quo CMS is costlier in the long term, both in maintenance hours spent and in annual licensing.  As with their initial implementation costs, Drupal’s ongoing costs are greater than those of WordPress because, again, of Drupal’s greater complexity.

Determine the Benefits of Each Option

For investment in any of these options, a benefit is expected, particularly in expenses saved or new revenue earned. Focusing on annual revenue (again,  just an illustration), the following table summarizes the benefits of each option. 

Benefit/year

Drupal

WordPress

Status Quo CMS

Annual revenue

$200,000

$150,000

$100,000

Finally, we see where the investment in Drupal’s complexity pays off; its greater functionality typically means a greater ability to meet ever-evolving needs. We translate this in our example to a greater annual revenue than that of WordPress, and both CMSs, being more functional than the status quo CMS, are capable of generating more revenue. 

Recommend an Option 

When we combine costs with benefits as described above, we are left with the following comparison:

The above graph makes the following assumptions:

  • In Year 1, the Drupal and WordPress options earn no revenue because they’re being built
  • Likewise the status quo CMS is earning revenue in Year 1 because it has already been built

So, in this example scenario, we can draw the following conclusions:

  • If your organization is prioritizing short term results, staying with the status quo CMS is the best option.
  • If your organization is willing to make a moderate up-front investment for moderate long-term benefit, WordPress is the best choice.
  • If your organization is willing to make a greater up-front investment for greater long-term benefit, then Drupal is the way to go.

Admittedly, our example scenario is overly simplistic. In reality, detailed requirements can radically alter both the costs and benefits of any option one considers. We at Mediacurrent have performed this type of analysis for some of our clients to help them with their technology investment decisions and can do the same for you. Please contact us to learn more!

ADCI Solutions: The must-have Drupal module Social Sharing

3 months 3 weeks ago

The majority of modules for social sharing of web pages - are Drupal blocks that have these social media integrated by default. You don't have a chance to officially add any social service that you want to your site. A back-end developer of the ADCI Solutions web studio talks about his fundamentally different module for social sharing of web pages. Its name is Social Sharing.

Visit the link for the full essay. 

Nuvole: CMI 2 at DrupalCon Europe 2020

3 months 3 weeks ago
Configuration management initiative update and recap of DrupalCon Europe 2020

Last week was the virtual DrupalCon Europe and I had the pleasure to present CMI 2 updates together with Moshe Weitzman. Attached to this post are the slides.

It was a strange DrupalCon, no travelling and home made food and good coffee are of course a nice change but I am not sure it makes up for not meeting Drupal friends in person. I enjoyed the hallway track and visited the "virtual booth" of sponsors and it was a nice way to randomly meet people like one would at a in-person event. But presenting a presentation to just the screen without seeing the audience was a new experience.

I presented the CMI updates under the overarching goal of standardising the way configuration management is approached in Drupal. After the big API addition last year we focused on updating contrib to use this new API. A particular highlight is the testing framework for modules upgrading from config filter to the new core API.

Another highlight is of course the new drush deploy command which Moshe presented. It executes the steps to update a drupal site where new code has been pulled. In particular it executes a database update, config import and running of deploy hooks.

Deploy hooks are the same as post_update hooks, but they are meant to be run after the configuration is imported. But instead of putting them in your mymodule.post_update.php you put the code in mymodule.deploy.php. They are not meant for contrib modules, but rather for custom code that a site relies on. For example it allows you to add content to fields that you created via config. More information can be found in the deploy hook documentation

Lastly I attended a very interesting BOF around distributions. I did not initiate it but I was very happy to observe the exchange of ideas and approaches between maintainers of different distributions. I hope more collaboration will happen next year in this space and hopefully more distributions join forces to find a way core can assist the development of distributions.

Tags: DrupalConDrupal PlanetDrushDrupal 8Attachments:  CMI 2 at DrupalCon Europe 2020

Nuvole: CMI 2 at DrupalCon Europe 2020

3 months 3 weeks ago
Configuration management initiative update and recap of DrupalCon Europe 2020

Last week was the virtual DrupalCon Europe and I had the pleasure to present CMI 2 updates together with Moshe Weitzman. Attached to this post are the slides.

It was a strange DrupalCon, no travelling and home made food and good coffee are of course a nice change but I am not sure it makes up for not meeting Drupal friends in person. I enjoyed the hallway track and visited the "virtual booth" of sponsors and it was a nice way to randomly meet people like one would at a in-person event. But presenting a presentation to just the screen without seeing the audience was a new experience.

I presented the CMI updates under the overarching goal of standardising the way configuration management is approached in Drupal. After the big API addition last year we focused on updating contrib to use this new API. A particular highlight is the testing framework for modules upgrading from config filter to the new core API.

Another highlight is of course the new drush deploy command which Moshe presented. It executes the steps to update a drupal site where new code has been pulled. In particular it executes a database update, config import and running of deploy hooks.

Deploy hooks are the same as post_update hooks, but they are meant to be run after the configuration is imported. But instead of putting them in your mymodule.post_update.php you put the code in mymodule.deploy.php. They are not meant for contrib modules, but rather for custom code that a site relies on. For example it allows you to add content to fields that you created via config. More information can be found in the deploy hook documentation

Lastly I attended a very interesting BOF around distributions. I did not initiate it but I was very happy to observe the exchange of ideas and approaches between maintainers of different distributions. I hope more collaboration will happen next year in this space and hopefully more distributions join forces to find a way core can assist the development of distributions.

Tags: DrupalConDrupal PlanetDrushDrupal 8Attachments:  CMI 2 at DrupalCon Europe 2020
Checked
1 minute 33 seconds ago
Drupal.org - aggregated feeds in category Planet Drupal
Subscribe to Drupal Planet feed