When planning a major website development project, there are many factors to consider but one of the most important is selecting the right architectural approach for your website. Whether you’re a marketing leader or technology leader, a few critical factors - future-proofing, scalability, and Total Cost of Ownership (TCO) - will help you determine the right approach. Considering these elements are crucial to ensuring your site not only meets current needs but also adapts and grows with your business over time.
To guide you in selecting the right architectural approach, we've developed a series of questions and discussion topics that will help you make an informed decision. First, it is important to understand the three main architectural options:
What is Traditional (Website) Architecture?
💡 Traditional website architecture is what most website managers and content editors are familiar with - it is a monolithic approach where the frontend (user interface) and backend (server, database, and application logic) are tightly coupled. This design makes development and management straightforward, as all components operate within a single, unified system for example a Content Management System - CMS, like Wordpress or Drupal would manage both the frontend and backend. However, the simplicity this affords can lead to challenges when scaling or adapting to new requirements.
What is Headless Architecture?
💡 Headless architecture decouples the frontend (the user-facing interface) from the backend (where content is stored and managed), enabling content to be delivered seamlessly to multiple platforms via APIs. This approach provides flexibility, as the same content can be reused and tailored for websites, mobile apps, digital kiosks, or other emerging channels. For a website, this could be Wordpress, Drupal or any of the numerous headless CMS available like Storyblok or Strapi with a more modern frontend technology such as React, Next.js or Angular.
What is Composable Architecture?
💡 Composable architecture is a modular approach to application design that allows developers to build applications quickly and easily by breaking down complex systems into small, independent, reusable components. This strategy promotes code reusability, which ultimately saves time and money. With a set of modular components like microservices, headless applications, and API-based SaaS solutions, businesses can customize their architecture to meet specific needs. This flexibility enables seamless integration of best-of-breed technologies via APIs, without disrupting existing functionality or overburdening developers. Similar to headless there is still a CMS and a separate frontend technology but the integration of other components makes this architecture stand on its own.
What is your Overall Architectural Goal?
Understanding the primary goal of your architectural approach is fundamental to the success of your rebuild. The approach can vary based on whether you prioritize design, content, or system modularity.
- Traditional (Design First): This approach prioritizes visual and user interface aspects before focussing on content and functionality. It’s a conventional method that ties the design and content together from the start. Amazing designs and websites (like the Denver Zoo) are still possible with this approach but it comes with certain limitations as outlined below.
- Headless (Content First): Here, content architecture takes precedence. Content is delivered to any device via APIs, allowing for a more flexible, content-driven strategy.
- Composable (System First / Modular First): This method starts by breaking down the system into modular, interchangeable components. The headless CMS is just one piece of a broader, more flexible architecture.
How Often Do You Plan to Rebuild Your Site?
The frequency with which you plan to redesign or restructure your site should influence your choice of architecture.
- Traditional: A complete rebuild is often required when redesigning the frontend, which can be time-consuming and resource-intensive.
- Headless: Content is managed separately from the frontend, allowing for easier updates and redesigns without a full rebuild.
- Composable: Components are independently replaceable or upgradable, enabling teams to iterate on specific parts of the system without affecting the entire site.
How Flexible or Reusable Is Your Content, and Where Will It Be Delivered?
Content flexibility and reusability, especially across multiple channels, are key considerations.
- Traditional: This approach often requires more developer involvement for content management, and adapting content for multiple channels can be complex.
- Headless/Composable: Content can be reused and presented in various ways, delivering seamlessly across websites, mobile apps, and other channels. APIs ensure consistent content delivery and branding across platforms. A great example is our work with The Broad Museum, where we implemented a unified backend system to streamline content delivery to both their website and their progressive web app (PWA).
What is Your Overall Plan for Security & Scalability?
Your site’s architecture should align with both current and future security and scalability needs.
- Traditional: More susceptible to security threats because the frontend and backend are closely coupled so users interact with the backend through the frontend; this approach often requires downtime for updates.
- Headless: A decoupled architecture reduces vulnerability to attacks as the backend is only exposed through APIs, and updates can be made without downtime.
- Composable: The isolation of components allows for detailed access controls and security practices tailored to specific parts of the system. Each component can be independently developed, maintained, and scaled.
What Are Your Goals for Speed and Performance?
Site speed and performance are crucial to user satisfaction and business success. Site speed results in an improved user experience resulting in higher conversion rates and improved SEO performance.
- Traditional: This approach often faces server and platform-related bottlenecks, making performance optimization challenging. Each time a page is loaded the frontend has to make a request to the backend for content.
- Headless/Composable: Frontend code is delivered via globally distributed CDNs, reducing latency and improving load times. Our recent rebuild of the Goodhire website resulted in a significant boost to site performance and a 28% increase in MQLs immediately post-launch.
What is Your Budget for Hosting and Ongoing Maintenance?
Balancing the cost of hosting and maintenance with your budget is essential for long-term sustainability.
- Traditional: Hosting costs are typically based on traffic and server usage, which can fluctuate. Traditional websites are typically lower cost for the initial build because the frontend and backend already work together seamlessly, however, the long-term TCO can be significantly higher due to a need for a complete rebuild for major design or UX updates.
- Headless/Composable: With frontend code delivered via CDNs, hosting costs are generally lower, offering more predictable and manageable expenses. The upfront cost to build a headless or composable website is typically 20-50% more expensive than a traditional website but with it being unnecessary to do full rebuilds to redesign or restructure the website, the TCO is lower over the long-term.
Conclusion
Choosing the right architectural approach for your website rebuild is critical to its long-term success. By considering factors like your architectural goals, the frequency of rebuilds, content flexibility, security needs, performance targets, and budget, you can make an informed decision that aligns with your business objectives and sets your site up for future success.
Summary Comparison
Traditional | Headless | Composable | |
---|---|---|---|
Definition | A monolithic approach where the frontend and backend are tightly coupled, e.g., Wordpress or Drupal. | Decouples the frontend from the backend, enabling content delivery via APIs, e.g., Storyblok, Wordpress, or Drupal with React. | A modular approach using microservices, headless applications, and API-based solutions. |
Primary Goal | Design First: Prioritizes visual and user interface aspects. | Content First: Content architecture takes precedence. | System First: Focuses on modular, interchangeable components. |
Rebuild Frequency | Complete rebuild often required for frontend redesigns. | Frontend can be updated independently; no full rebuild needed. | Components can be replaced or upgraded independently, avoiding full rebuilds. |
Content Flexibility and Delivery | Requires more developer involvement; adapting content for multiple channels is complex. | Content is reusable across websites, mobile apps, and other channels via APIs. | Highly flexible; content seamlessly delivered across multiple platforms. |
Security and Scalability | More susceptible to security threats; downtime often required for updates. | Reduced vulnerability as the backend is exposed only through APIs; no downtime for updates. | Isolated components allow tailored security practices and scalability. |
Speed and Performance | Faces server and platform-related bottlenecks; frontend must request content from the backend on each page load. | Frontend code delivered via CDNs reduces latency and boosts performance. | Frontend delivered via CDNs; optimized for speed and scalability. |
Budget and Costs | Lower initial cost but higher long-term TCO due to the need for full rebuilds for major updates. | 20-50% higher initial cost than Traditional but lower long-term TCO due to independent updates. | 20-50% higher initial cost than Traditional but offers the lowest long-term TCO by minimizing rebuilds. |
Unsure what’s right for you? We’re happy to provide our advice to your specific situation - don’t hesitate to reach out or download our free RFP template to guide you through the process!