Scoping and Estimating a DXM Implementation

I was at a partner last week when they asked two questions that comes up fairly frequently:

1. "How do we architect an implementation using Crownpeak?"; and 
2. "How do we scope and estimate a Crownpeak DXM implementation? We're used to using CMS X." 

Designing a solution

The first question is straight forward once you understand the DXM decoupled architecture piece -- design the solution you need and want, based on your experience, expertise and environment constraints and independent of Crownpeak.

Once you have that design, look at which elements need to be under content editor control. Some of this is obvious -- press releases or blog articles for example, some is less obvious such as translated text for interface labels, or icons, or non-visual configuration items. These are all your content managed items.

Next, figure out how the content managed items should be made available to your system -- HTML pages, HTML fragment, ASP.Net files, PHP scripts, JSON resources and so forth. These will be the first templates you will need to implement.

The key message here is this: put content management in your application, rather your application in content management.

Monolithic CMS systems require you to extend their platform with your application features because you are constrained in terms of technology stack and feature set to the choices made by the CMS system.

Headless CMS systems solve the problem in a similar way by focusing on delivering "abstract" content rather than an application.

In my meeting last week, the technical team wanted to build a React front-end talking to a .Net back-end exchanging JSON through an application-specific API. Great! That is a perfect fit for Crownpeak DXM.

Scoping and estimating

Now we turn to the second question and the answer is a little trickier and must be dealt with in two parts. The first part is the underlying application design and build -- this is completely independent of Crownpeak at this point so use whatever your expertise tells you to arrive at a scope and estimate.

The second part depends heavily on the hosting decision: where is this application doing to be deployed and who is managing that hosting. The choices boil down to one of two options: Crownpeak hosting or non-Crownpeak hosting. 

Crownpeak Hosting

Crownpeak offers hosting on a managed service basis, meaning that we stand up the infrastructure for a hosting "pod" -- a minimum of a pair of web servers behind a load balancer and CDN. Customers and partners have a choice between a Windows-based setup (Windows Server, IIS, .Net) or a Linux-based setup (Apache Web Server, Apache Tomcat JEE server, Java).

Crownpeak hosting is convenient for the vast majority of Crownpeak customers as it fits in well with the "no installation or provisioning required" ethos. However, in order for Crownpeak to meet its security credential requirements, access to the Crownpeak hosts is extremely tightly controlled -- the only process that can connect to the hosting is the CMS itself. This means no remote desktop; no remote shell access; no FTP access, nothing.

As you can imagine, this introduces a significant hurdle for most implementations. How do you deploy your application code? How do you examine the logs to determine what caused a problem in production?

This has an impact on scope and effort because you need to ensure that everything for your application is in the CMS so that is can be delivered to the hosting servers. If it is going in the CMS, you also need to consider whether to use templated or digital assets.

This works for HTML+JS applications but is a challenge for anything more sophisticated -- especially if your team already has an implementation build and continuous deployment process you want to use.

Either way, this is where the second round of template identification happens.

Non-Crownpeak Hosting

If your application is not on Crownpeak hosting, let's assume that you have a route to deploy directly to this hosting from your development environment / CI. In this case, the scope for the CMS implementation is limited to just the elements of your application that are under content management.

Summary

In conclusion, it is clear that although you have the freedom to choose your technology and architecture when doing a Crownpeak implementation, one of the critical decisions depends on how much access you the developer have to the hosting.

The impact of this decision becomes more pronounced the more complex the web application becomes. If you're creating an HTML-based campaign site with 5 pages, then there is very little difference in scope and effort. When you're planning to build a React front-end talking to a .Net back-end API and all this being built from a repository by a CI system, the scope and effort increase dramatically.

Solution	Crownpeak Hosting	Non-Crownpeak Hosting
Static HTML/CSS/JS	Content templates	Content templates
Static HTML + dynamic elements driven by Search G2	Content templates Search G2 handlers	Content templates Search G2 handlers
ASP.Net / JEE web application (page-based)	Content templates Search G2 handlers Application page templates	Content templates Search G2 handlers?
SPA( Single Page Application) + JSON data	Content templates Search G2 handlers Application templates	Content templates Search G2 handlers
SPA / HTML + Javascript UI Server-side API code JSON data	Content templates Search G2 handlers UI templates Server-side code templates	Content templates Search G2 handlers

I will be posting follow-ups to this post with case studies to help you get a feel for what estimates and actuals for real Crownpeak DXM implementations look like.