How Does Your Technology Legacy Impact Your MarTech Architecture?
By now I hope you are starting to understand there are some foundational items that are precursors to worrying about what your martech stack looks like. In my first post we discussed organizational alignment, then we discussed change management. Now let’s dig into the next topic that is down a level: adapting your business processes and tools.
Everyone has a legacy, and everyone thinks it will be critical to their future strategy. Prepare yourself for what I am about to say: it may not be. What is going to hinder or help you is the legacy technology and how your company is armed to move that into the future. In my previous articles, I outlined how organizational alignment and your ability to manage change will be keystones to your success in building and optimizing your technology. How you utilize, manage or sunset your legacy technology and data is the next brick in the foundation.
Once upon a company split…
To illustrate the importance of accounting for your legacy tools and technologies, I would like to share a recent client story. A long-term customer let us know they would be splitting off from their larger parent company. They were excited as they saw an opportunity to start from a clean technology slate. We thought it was very positive as well.
Their marketing automation system had numerous, very customized configurations that made its management difficult and error-prone. They had long ago reached the basic field limits because of unstructured, unscalable practices. In addition, the client had a complex technology environment in which they utilized multiple CRMs (from different vendors). They had several disparate business lines, each with different needs and requirements from a data model perspective. Their parent is a long-established company with very entrenched ideas and practices.
To move the company forward at the speed required to meet their timelines and objectives, the business owners for the technology made several executive decisions around how they would change processes (and consequently, technology configuration). These decisions were colored by the culture of the parent company and influenced by their knowledge of the past and future. They were very confident at that time.
Fast forward to the teams getting trained on the new technology. Suddenly, questions about the old platforms and old data resurfaced. While the decision-makers had accounted for many of the legacy systems and processes that the team had been using, it became clear that they weren’t aware of every facet.
How could this have been done better?
These unexpected questions had the potential to derail the client’s progress. How do they move them forward without losing momentum? They obviously should have looked at their legacy systems more thoroughly at the beginning. Remember, however, that one of the keys to managing change is being agile, not rigid. To embrace a more agile framework, the first step should be to understand the use cases for the legacy technology and data. Once those scenarios are understood, the project team can assess whether the systems and data will persist Go to the full article.