Cloud Platform
Site Building with Config Kits
It's well understood that a robust, API-first Content Management System (CMS) is a crucial part of a Composable Enterprise. What's discussed less often is the degree to which the implementation approach for the CMS can also contribute to the key ideals of a Composable Enterprise: being able to quickly innovate, evolve, and adapt to changing market conditions.
In addition to being able to integrate with the other elements of your MarTech stack, your CMS is a key touchpoint for how you interact with customers and stakeholders. As such, it should reflect the kind of insight-based, data-driven decision making that is the hallmark of technology adoption in the modern marketing stack.
You may have heard of MVP web development, Lean Startup, or Growth-Driven Design. They're all examples of approaches that embrace the idea of launching a website as quickly as possible, to start collecting data and customer feedback. That, in turn, allows for rapid iterations based on analysis, to put the effort where it will have the biggest impact. Instead of spending months (or in some cases, years) building a web application that may be outdated by the time it launches, getting your site launched quickly means starting the cycle of innovation sooner.
We've talked previously in this blog about how Acquia Site Studio can help your development team launch in a fraction of the time, but today we're going to focus on another element of the Acquia CMS that will help you realize your goal of being a composable enterprise.
While the specifics of every website's requirements are unique, at a high level we see common patterns. For example, higher education websites often have a faculty directory, which has significant functional overlap with a hospital website's physician directory, or the board of directors and staff listings that are common to websites that support organizations that vary widely in size and the kinds of industries they operate in.
Long ago Drupal used to have purpose-built modules that would address these kinds of functional systems, but with the advent of CCK (now the Field API in core) and Views, everything changed. Now a site builder could create a content type for information that needed a specific data structure, like a person, job listing, or location. Then they could build a view to list them, potentially offering exposed filters to help visitors find the exact information they need. While this has made Drupal more flexible and significantly more powerful for addressing the unique needs of any particular organization, it does add to the level of Drupal knowledge required to start building Drupal websites. What if there was a way to keep the flexibility of using powerful site-building tools, while empowering site builders to quickly assemble the major parts of their websites?
The great news is that Drupal's built-in configuration management capabilities make this easier than ever. You can create a module without any PHP code, just YAML configuration files to let Drupal know about the module and its dependencies, as well as the configuration you want to create.
These modules can be a great way to promote modular reuse of common systems that are needed for websites: an events calendar, a staff directory, a locations map, and so on. By including the configuration for a content type and one or more views, a site builder can quickly create the essential structure, and then customize with additional fields or features, such as categories or exposed filters.
You can create these kinds of modules yourself, and Drupal Console or drush will make the process easier. There are a number of community-contributed modules that use this approach, and it's also how we equipped the Acquia CMS to provide the most commonly requested website features, out of the box.
In the Acquia CMS we've included a number of options to help you get your site built faster:
You can use these with contrib configuration kits and any you've created yourself, to set up as many areas of your site as possible, with maximum efficiency.
In addition to speeding up your time to market, you'll also free up your developers to spend more time on custom development. Every hour you save them from performing a rote task that is the same every time is an hour they can spend on innovation, making the final result better address the needs of your site visitors.
What's more, this approach helps to drive consistency. By making sure that content types, views, and other configuration entities are named and set up in ways that won't change between projects, it makes any custom code created to work with them (CSS, JS, PHP, etc) more portable between projects as well.
We hope on your next web application build you'll be able to leverage these time-saving modules to assemble your site faster and with a richer feature set. If you'd like to learn more about how to create or use these kinds of modules, you can see them in action in a recent talk I gave at DrupalCamp NYC2021.
Cloud Platform