Feature
He wrote that “WCM has become an essential foundation for enabling successful digital experience efforts. And by doing so, it’s supporting one of the last things that corporations and brands can use to differentiate themselves.”
The article continues by looking at the expanding feature sets that are required of today’s new “sexy” (his words) tools such as visitor profiling, CRM, analytics, testing and cross channel reporting.
In almost all of these cases though, the enterprise isn’t starting from scratch. An existing WCM product will be replaced for one of these “sexy” new tools. So as marketers examine their needs and switch out to new solutions, they naturally start to wonder whether these types of products will meet all of the challenges they face. Will they enable them to create these experiences faster and more flexibly than ever before?
Unfortunately, it's still the case that when they turn to consultants or some of their more technically-minded colleagues for advice, the basic architecture or language of the solution gets in the way of viewing it as flexible and fast or not.
What these businesses need to realize is that it’s not what the product is written in -- it’s how it’s written that determines flexibility.
You Don't Have to Choose Between Scalable and Agile
When reviewing a new system, one of the key challenges that face large enterprises is speed. It’s almost universal now that marketing and communications groups want to move more quickly, and so a system that enables flexibility and agility is high on the requirements list. This is the point that the alleged (and I believe false) compromise is usually made. The enterprise has to choose whether to replace the existing enterprise-wide system with a series of lightweight Web CMSs or blogging tools that may not scale, or another enterprise system that may again slow things down.
This is where the language and architecture bias sets in. Opinions come racing in: “Choose a PHP based system -- it’s faster and more flexible.” Or it might be “choose a .NET system -- it’s built for developing enterprise-level solutions.” Or “choose a Java solution -- it’s more secure and scalable.”
Learning Opportunities
Webinar
Apr
23
AI: The Essential Vitamin for a Healthy CX
Join us as we unravel the mysteries of AI adoption and discover the key to unlocking a thriving CX ecosystem.
Register
Webinar
Apr
23
Navigating Market Dynamics: Leveraging Reputation to Propel Business Growth
Join us to uncover the secrets of mastering reputation management in today's competitive environment.
Register
Webinar
Apr
24
The State of Outsourcing: At the Crossroads of AI, Quality, and Cost Savings
Learn how companies can maximize the results from their outsourcing investments.
Register
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
In the end it doesn’t matter what the language is: it’s how the solution is built that determines success. Additionally, it doesn’t have to be an either/or type of choice. Just as there are solutions out there that are suffering from 10 year old product development problems, there are others out there that are continually built and/or rebuilt from the ground up to enable scalability and flexibility.
The Last - Not the First - Implementation is the Test
Most digital content experience projects start with a prototype and/or the first website. The challenge is that when an enterprise is selecting a system that will enable digital content experiences, they fall into the trap of judging flexibility and speed by how well the first implementation goes. The business makes a choice based on:
- How well the language of technology (e.g., PHP or .NET or Java) matches their internal or agency capabilities or …
- An installed versus cloud-based or other architectural decision
The first project or prototype goes well because everyone is focused on making the big system perform quickly, or the small lightweight system perform effectively. Whatever product decision then made is based on the staged world built around implementing a project, not on how the system will operate in the real world of marketing. It’s not the first implementation that counts. It is projects three through 10 that really start to drive home just how fast and flexible or scalable the new system really is.
The lesson? It’s the product that matters -- not the language it's written in. A Java system that was developed to be a highly governed, scalable enterprise digital asset management system but is now positioned as an experience manager of marketing channels will not be as flexible as a Java system that was built to manage omnichannel web projects. And vice versa.
But it’s not Java that’s the cause of that -- it’s how the product was built. Similarly, a PHP based website builder that was architected to quickly stand up blogs and small community websites isn't going to scale to the need of a global enterprise as well as a PHP product developed to handle complex language, millions of pages, workflow and other enterprise needs. But it’s not PHP that drives that -- it’s the product.
When a business is looking for one of these “sexy” new tools -- it doesn't mean that you have to abandon one language or one architecture over another. You should have the freedom to choose any language based on any requirement, and the solution should offer the right architecture for the need of the business. In the end, it is simply a function of looking at how -- and for what purpose -- the product was originally developed.
Title image by Alessandro Storniolo / Shutterstock.com
