The DIY challenge
Switching from one software platform to another is an "adventure" for any company. But it’s a particularly challenging one for enterprise companies. It reminds me of those flipping houses shows where people invest in a rundown property with the goal of reselling it at a higher price. Often in the middle of an episode, the remodelers face unexpected challenges that require them to invest more money or overcome additional hurdles.
That process strikes me as similar to switching from one Content Management System (CMS) to another. While the potential rewards are significant, the challenges can seem overwhelming. Maybe the IT department is overburdened with implementation tasks, or perhaps the marketing team is under pressure to gain more flexibility in content creation (or simply needs to modernize their CMS). In any case, it’s usually a smaller part of the organization that seeks the change – and are also the ones expected to provide the budget and the effort.
When only a small group of stakeholders are involved, management often shies away from the necessary investment and drags its feet on the implementation date, forcing the team to make do with the existing platform. This in turn can lead to extremely customized ecosystems, often stretched far beyond their original capabilities. The substance of these systems, in fact, changes almost to a "point of no return," ultimately requiring a complete rip and replace of the original CMS.
Within these massive projects, the gathering, consolidating, and documenting of every requirement from every stakeholder is often impossible. Do any of these sound familiar to you?
- New stakeholders suddenly materialize in the middle of the project
- Third-party systems (previously unmentioned during original project scope) now appear
- Key employees go missing when they're needed the most
To deliver on time, you have to make compromises, sacrifice use-cases, and funnel in more money (and personnel) or you'll have a never-ending project, because the needs are changing faster than development can deliver. You end up spending years developing a system based on incomplete requirements and hoping against all odds that it will fulfill all future requirements.
But "Rip & Replace" is not what I had in mind when my boss said I needed "R&R"
We all know this is what you sign up for when you decide to flip your software system, right? No! It doesn’t have to be that way. Why not make the switch gradually? Start by quickly addressing the biggest pain points first, then maintain an agile backlog of additional requirements. Flip one content or placement at a time and eventually you'll get through them all.
This is the core idea of an agile process. But you need more than a process. You need a CMS that actually supports this approach: one that is flexible and extensible in the delivery itself, that can empower your business, but that doesn’t need to “own the glass” or implement every aspect of the overall page to successfully deliver partials. And furthermore, one that continues to deliver when you need it to take over the online experience completely.
So where do I start?
With the right CMS, you can focus on your biggest pain points and flip them to "joy spots" one at a time. Let's start with a critical content area, such as your web presence, your mobile presence, your store kiosk solution, your print design, or even your intranet applications. Within that area, there might be particularly tough beasts to tame, such as campaign banners that constantly changing. You can get or augment this content from your new CMS and keep the rest of the content on the page or app as it was for now.
This approach gives you maximum freedom and helps your important customer touchpoints shine. Your business can then focus on maximizing the impact of these focal points by shortening the time between recognizing market need and delivering content to meet that need.
This way, business teams gain experience and management sees an immediate financial return. Which means IT can continue to migrate more functionality from the old system to the new CMS, modernizing approaches and technologies along the way. And which in turn empowers the business even more – eventually resulting in the complete replacement of the former ecosystem with a new CMS and other integrated systems.
That's flipped out. Can it really be done?
So how can these existing sources be augmented? There are basically two strategies. You can either:
- Get the augmented content as ready-to-go HTML fragments that can be inserted into predefined spots within your content.
- Use the classic headless approach: deliver "raw" content as JSON and let your existing rendering applications figure out how to display them in each channel.
The first approach is a proven one that many of our customers have applied successfully. It works great when your end-output is all HTML-based. Look for a system that provides deep, pre-built integrations with the leading eCommerce systems such as IBM, SAP, etc. (You can read more about how CoreMedia customers handle these challenges).
With the second approach, your mobile developers and web developers can keep their existing framework. You don’t need to train your whole development team for the new technology stack all at once. And you have the option to replace the legacy technology for each output channel individually, whenever need demands and time/budget allows.
How to choose? Should I just flip a coin?
Let’s first examine the first strategy in more detail. At first glance, using HTML (i.e. ready-to-use fragments) requires less implementation effort on the client side. Your old CMS doesn't have to know anything about your new content, it's just slotted in among the old content. This makes life easy for only one rendering target.
However, the complexity of this solution increases if you want to re-use these HTML fragments for multiple targets, such as websites and mobile apps (not to mention your kiosk points or digital signs). The new HTML fragments must fit into your existing content from a dimensional standpoint, and must also support dynamic behavior in order to "play nice" in responsive situations, such as switching from desktop to tablet.
Graphic Flip
To meet these challenges, you can either fit the HTML specifically to each rendering target, which includes fitting into the ambient CSS and JS frameworks, or you can bundle the whole package together into an IFrame-wrapper, including their own libraries to define styling and behavior. The second option sounds like a "neutral" one-size-fits-all scenario, but might affect the responsive capabilities as well as limit the interaction options for the rest of the page. In either case, the developers must be very strict in determining whether specific styling rules are part of the fragment source or part of the frame.
With a more modern and flexible CMS, however, you are free to pursue both neutral as well as the target-specific solutions, since templates can be adjusted easily to each kind of HTML output.
But how do I flip without flopping?
If that scenario gives you nightmares about tangled webs of dependencies, you could consider the headless approach. This scenario delivers content as structured JSON from the CMS to the consumer without any opinions about how it should be styled, giving a clean separation of content and presentation.
The same content could then feed, for example, the Angular-based single-page website and the JSP-driven kiosk content at the same time. The transmission footprint of this JSON is much smaller than the full blown HTML version. Furthermore, the CSS and JS definitions are clearly delivered by each rendering target individually, avoiding the interaction problems between two sources of styling.
Graphic Flip
When getting your content delivered as JSON, the main work is to transform the raw, but structured data into beautiful, styled output. This has to be done for each channel individually, but this further breaks down the task into independent steps that can be done over time.
What should I consider when choosing a flip target?
Whichever strategy you choose, your new CMS should be able to transmit any kind of content in the delivery technology (HTML, XML, JSON, etc.) of your choice. And it should provide guidelines on content creation to sustain a unified presentation to the world. For both patterns, you should be able to augment specific placements on specific pages, or empower your editors to add whole new sites through the CMS without consumer code changes.
CoreMedia is a good example of a CMS that supports all of this. With CoreMedia’s flexible delivery approach, requesting specific content pieces is no more complicated than entering a URL like you would use to call a webpage. These strategies could use relative URL segments (e.g. ”/kitchen/knives”), SEO-segments (e.g. “/quality-knives”) or simply technical IDs (e.g. “/42”) to address content. With additional parameters, the content output can be customized for individual pages or personalized for individual users. Fallbacks can also be implemented to cover the cases when the consumer can’t map the request to known content.
Both strategies allow you to follow a proven “grow-as-you-go” adoption method, and both provide the flexibility that comes with an agile project methodology. Popular CoreMedia features such as deep eCommerce integration, personalization features, time-based publication or our user-friendly Studio are available in these augmentation scenarios as well. Businesses see results very soon after projects start and can influence the project process by providing valuable early feedback. Combined with the benefit of not needing to train your whole development and business user teams in a new technology from one day to the next, this reduces the risk of major directional changes that can be so frustrating during the project lifecycle.
Properly considered, this gradual "flipping" approach can be the solution to many business challenges and difficult projects that may otherwise never be successful. So maybe it’s time to analyze your most difficult solution challenges and learn more about implementations with CoreMedia. Visit CoreMedia to get more information on the CoreMedia platform or schedule a demo.
