by Lou Chapman - September 5, 2019
In our most recent blog post, Managing Servers Across Platforms – Platform Saturation, we discussed the problems that arise from managing a project on multiple platforms (products). These platforms could include; Azure, GitHub, Jira, OS Ticket, and more. While these platforms are meant to increase productivity and help teammates work together and efficiently they sometimes cause more work than they save.
In this post, we are going to look at another issue with managing projects across platforms – Duplicate Platforms. This is typically when organizations host the same asset across multiple platforms. For example, hosting with AWS or Azure while also hosting with a legacy server whether in-house or elsewhere can double workload and delay projects.
The biggest resource waster when managing projects across platforms are duplicate platforms. As mentioned above, duplicate platforms are when an organization is supporting two platforms that do the same thing. This could be keeping data on two different version control repo like GitHub and BitBucket. When there are duplicate platforms like these, an organization is tasked with maintaining updates, audits, and permissions for two platforms, instead of just one. Ensuring both platforms are up-to-date and can work together creates an abundant amount of unnecessary work.
Along with increased workload for maintaining both new and legacy systems, comes a heightened level of vulnerability. System admins now have to manage roles and permissions on both environments. Having more points of access to servers, databases, repositories, etc. can leave an organization more vulnerable than if they only used one. This is a point of concern for clients as well. When making decisions about digital service providers, security is a top priority. And a provider that uses fewer and up-to-date systems will always have an advantage.
In our recent focus group, we asked: “Do your clients or superiors need to be informed of [accessibility permissions] security changes?“ Of the 11 organizations represented, 6 answered yes. Showing that most clients need/want to be notified of security changes to their platforms.
Ideally, legacy systems would be dealt with by graceful degradation, we know that is often not the case. Our experience with LTS, branched, and forked software solutions whether OS, projects, or otherwise has indicated this. Additionally, replacing legacy systems is an expensive process. Most admins might have a hard time justifying spending time and money to change a process that is currently working fine. But as we have outlined, just because a system is working doesn’t mean it is working efficiently. So how can an organization organize these environments in an efficient way and with modern toolsets?
While completely removing legacy systems may not be an option, replacing their supporting services can reduce the number of platforms used. Supporting an outdated version control system in areas where a modern solution (preferably one already in use) also works would achieve this. For example, having SVN on one Windows server and GitHub on another. Swapping out SVN for GitHub could both streamline your repository management and modernize the platform. This example isn’t necessarily rebuilding the legacy system, just simplifying its maintenance. Using newer technologies that might be standard practice with other modern systems within an organization.
If you aren’t sure where to start in the process of updating or removing duplicate platforms, contact Arcane Strategies today. Our expertise can help your organization replace legacy systems that are causing inefficiencies in your processes. We offer services ranging from outlining the best options to hands-on full system replacement. You can send us an email at email@example.com or give us a call at (541) 649-2508.