In this blog post, we are honored to share the knowledge from guest author and analytics expert, Mike Norris, on planning and pitfalls to avoid for your analytics modernization initiative.
When considering an analytics modernization initiative, there are several questions to explore…Things are working now so why do this? What pressures are expected? What should the goal(s) be? What are things to avoid? What should a successful plan look like?
Why Modernize Analytics?
In Business Analytics, innovation is being delivered at unprecedented rates. There is constant pressure to leverage “what’s new” and hot. Hadoop, Data Lakes, Data Science Lab, Citizen Data Analyst, Self-service for all, insights at the speed of thought…etc. Sound familiar? For many leaders this is a time when they face large decisions on investment. Many start down new paths looking to deliver more capability and fall short. Others attempt the modernization path and struggle to keep commitment from leadership.
Many of these attempts to modernize result in the addition of new vendors, technologies, processes, and analytics offerings. This form of modernization provides a quicker initial win but leaves technical debt and overhead as it does not typically replace an existing part of the analytics puzzle but rather overlaps them. These types of “modernizations” are more of a leapfrog, and not one I would consider as “modernizing.”
Here is my definition of what I mean when I say modernization in an analytics context:
“Modernization is the improvement of the analytics we already have or the addition of functionality or capability to the technologies already in use. Modernization is always done to achieve an improvement goal. Goals should be defined via partnership between the user community and the IT/analytics leadership.”
These goals can be:
- Superficial – better sexier looking content or improved user experience.
- Functional – improved performance or added functionality and capability
- Extending – providing an embedded experience or adding additional projects and workloads.
Throughout my 20-plus years in the Business Analytics space I have worked with hundreds of companies and organizations helping and advising them on installs, upgrades, configurations and strategic plans and projects. It often pains me, when engaging late, to be the bearer of a dose of reality during modernization projects. So many begin without a plan or worse, with a plan and no validation of that plan. By far the worst ones are those that were a combination of IT and Analytics modernizations as an all-in-one massive project.
Pressures to Expect and Overcome
- Everything must be Cloud & SaaS – Cloud has many benefits and is the obvious choice for any net new strategy and investment. Moving everything from on premises to cloud because it is the company strategy coupled with a “by date” is bad strategy and comes from bad leadership operating in a vacuum. Ensure benefits and any impacts are understood before signing up to a date.
- Single sourcing everything – Yes, there are companies that can supply you everything you need. A single source vendor can sell you the benefits but are they real or perceived? The analytics space has largely been open and heterogeneous which allows you to go best of breed, so make sound choices.
- Newer products are better – Newer equals better might work for cars but not typically with software unless it is an offering evolution. Vendors with years of real-world experience and history appear slow to keep up but this is for good reason. These vendors tend to have a robust offering that others cannot match, and that offering has much more lifetime value as the use of them grows. Yes, some lag but that does not always indicate a replacement is needed. In many cases multiple pieces can exists if the dividing lines are clear.
- Rushing the giant outcome – Unfortunately, the time allotted is rarely accurate so it’s good to have milestones and smaller plans with victories defined to show meaningful progress and outcomes.
- It will all be much faster – This is a great goal and aspiration but not always reality. Offering architecture plays a huge factor, as does how well done any integration is done and co-location of surrounding dependant and supporting services and functions.
- Modernizing now future proofs us – As I said in the opener, the innovations are flying so this is an area that will continue to evolve. Always stay current with what you have and ensure updates are planned. After any updates evaluate new features and functionality to be leveraged or made available.
- Modernizing is just “upgrades” and will be easy – Its modernizing not upgrading. That means upgrades, updates, replacements and leveraging newer function and capabilities. Upgrade first then leverage new function and capability.
Preparing an Analytics Modernization Plan
Before doing any modernization effort I would suggest doing a few things that I will share to help improve success rates.
1. Determine the goals.
You cannot have a goal like, “To provide a fast, seamless source of beautiful analytics that allows for easy consumption and content creation.” This is a great sounding goal to get the project approved but is an overarching goal that’s fraught with peril and doom…it’s simply too big. Focus and create goals for a single technology change at a time with a measured desirable outcome. Modernizing in many cases must be done piece by piece and experience by experience. This means more smaller projects and goals.
People will argue that this means more time and overall effort and perhaps too many changes for users. In my experience, yes, this plan will look longer but is more reflective of the actual time it will take anyway. As for the frequency of user experience change, this can be handled by not pushing the results to production until you have a complete set of changes that make sense. The “do it all at once” modernization plans I have seen run 12-18 months longer than anticipated, which is much harder to explain. Worse is the pressure that is placed on the team executing the plan and the constant negativity that comes from challenges along the way. These also lead to large pivots resulting in leapfrog moves.
The biggest reason for focusing on smaller changes is that if your analytics break along the way, then it is much faster and easier to troubleshoot and resolve any issues. Fewer variables mean faster issue resolution. I know this sounds simple, but I will tell you that I have worked with more than one company who decided to do a monster modernization effort where the:
- analytics platform was to be upgraded
- query technology updated
- analytics platform moved to the cloud
- authentication method swapped out for a web Single Sign On provider
- a database vendor changed and moved from an on-premises owned and operated model to a SaaS solution
When things didn’t work, they spent tons of time and effort on determining what was causing the issue before getting to the actual solution. In the end, these “do it all at once” projects ran way over time and budget and yielded mixed results due to partial goal achievements and the negativity that surrounded the project. Many of these became just “get it up and running as best as possible” projects by the end.
2. Build a plan per goal.
The plan needs to include input from ALL stakeholders for transparency, completeness, and accuracy. My example here would be the changing of database technologies. Some vendors offer compatibility with other vendors and this helps with sales when they talk about time to value. Each database vendor will also try to push their position that they perform better than the incumbent. The issue is that these statements do not overlap. I’ve yet to see a workload move from one database technology to another with leveraging a vendor’s compatibility and improve performance of existing workloads.
Also, when changing database vendors / technologies you almost certainly get different levels of SQL compatibility, exposed database functions, and differing data types, all of which can wreak havoc on existing applications that sit on top. The point is that the plan must be validated with the people that can examine and determine the likely impact of such a major change. Experts must be engaged to eliminate surprises later.
3. Plan the plans.
As all the goals are teased-out, we may find that some of them can run in parallel. When using an analytics platform, we may find that different groups or business units are using different underlying components like databases that are to be modernized, so these can run parallel.
4. Examine all the plans analytically & clean up.
This is such an important step and one many omit. I implore you to use whatever analytics you have against your analytics. This is key to not wasting time and resources. Determine what data is dead, what content in your analytics platform is no longer used or relevant. We have all built analytical projects or content for a one-off task but most of us also suck at deleting it or cleaning up after ourselves. It is digital content that doesn’t cost anything to just leave up until the moment someone has to maintain, upgrade or modernize it.
Would it shock you to find out that 80% of your analytical content is dead, not used, has been replaced by a new version or has been broken for a long time without complaints? When was the last time we checked?
Don’t start any project that requires validation of analytical content without reviewing what needs to be validated and what needs to be cleaned up or trashed. If we don’t have any analytics to use against the analytics, then figure out how to get some going forward.
5. Evaluate that the modernization project and individual plans are holistically complete.
Let’s go back to the bad goal, “To provide a fast, seamless source of beautiful analytics that allows for easy consumption and content creation,” and break it down from a high level. There is likely an infrastructure change for processing memory and disk, a database upgrade or change, a move to a modern Single Sign On provider technology like SAML or OpenIDConnect, and an update or upgrade of the analytics platform. These are all good things and help modernize but we must remember that end users are stakeholders. If those users are getting the same content as they have been for years but just faster, then their level of satisfaction will likely be minimal. Beautiful content can’t just be for new projects and should be delivered to our largest group of consumers. Modernizing the existing content is rarely looked at but has the biggest impact on the users. This is especially important for administrators or anyone else on the team supporting the analytics platform. Not keeping those end users happy results in other tools being brought in to go around what the team is delivering with the end results possibly being disastrous. I’ll cover this topic in my next blog in a few weeks.
6. Last piece of advice.
Take backups frequently and do not do a modernization project in production only. Spend the effort to have a simulated production environment for large, wide-sweeping changes. This again will help minimize variables and differences between what works outside and inside production.
Good luck on your own modernization journey!
Got questions about your own modernization initiative? Contact us to discuss your needs and how we can help!
