Sitting in a meeting taking notes on her laptop, a software developer sees an email pop into her inbox from someone in the field.
“We’ve got a problem; the app isn’t working.”
Like many in her position, this developer wears many hats, and she’s responsible for resolving production issues. This problem turns out to be a need for more RAM in the database server. Knowing the resolution for the error, this story’s hero has two paths: the traditional path or the innovative path.
Chosing a path - traditional vs. innovative
If our hero chooses the traditional path, she’ll have to leave the meeting to go physically fix the problem. This means finding the proper server in the datacenter and getting additional RAM modules installed. Once installed correctly, she will need to ensure the operating system and database server software can address the memory properly and that the database eventually performs as expected.
If we choose the “innovative path” for our hero, she can simply open the management console on her laptop and make a one-line code change to increase the memory needed in the server. That change is automatically progressed into a test environment to validate the infrastructure change and sends a notification to the infrastructure director for approval, which automatically triggers the infrastructure change to be pushed live. This happens in minutes. Our hero doesn’t need to leave the meeting. There is no more delayed work out in the field, and she had hardly any distraction from the meeting she was in to begin with.
Why a tech partner can lead to new thinking within your business
Whether in billing, inventory management, customer service or oil & gas production, all companies reach the inflection point our story just described. The question companies must ask themselves when it’s time to upgrade or make changes to their systems is if they want the traditional path or the innovative path – and with that comes the question of whether they should develop and maintain technical solutions in-house, or work with a technology partner.
While the idea of a partnership may require a shift in tradition for many legacy companies, the right partner brings outside perspective that can provide a needed shift away from established silos and legacy culture by embracing the humanness of the organization and leveraging technology and process to help break those silos down. The choice of technology partners is crucial because that will set you up for a successful innovative path rather than chain you to that relationship long term.
Tech partners vs. tech vendors
When a company has limited developer and IT resources, a technology partner can take on data engineering and application development work for them. But this is where one key differentiator comes in: They need a technology partner not a technology vendor. Working with a partner, the company gets the necessary solution they need, but also the training to support and maintain it themselves. By focusing on what’s called in the tech world “Day 2 operations,” a technology solutions firm works itself out of a job, leaving the company that hired them prepared to scale and troubleshoot without having to spend money monthly to continue working with a vendor.
Companies often focus on the here and now, developing only what’s needed to solve their immediate problem and not the operations required to support that. Unfortunately, those companies often also find themselves chronically connected to a tech vendor, spending much more money than they would have if they’d taken a pause at the beginning of the project, chosen with a technology partner and considered the ongoing maintenance and support the solution was going to need once the project deliverables were complete. It’s a powerful tradeoff. Development and operations have historically had a very hard line between them but creating DevOps as a culture saves time and money.
As a technology partner, Blueprint always approaches a problem thinking about when we won’t be there anymore – what our partner’s ability will be when it comes to continuing without us. Training the partner to take over is key. Vendors often look at a continued relationship as revenue for themselves. Blueprint’s goal is to step in as an extension of a company’s team for as long as it takes to do the work, but we want to deliver something they will be able to support and maintain themselves. To accomplish this, Blueprint focuses on those Day 2 operations from the outset. We include proper training along with the development and data engineering work taking place and put a heavy emphasis on automation, helping the company follow the “innovative path.”
Focusing on automation and DevOps removes all of those burdens and allows clients to reliably repeat the processes and solutions built by the partner however many times they need to. So, when they want to add a new feature to an application or compute space in the cloud, they don’t have to build it, put in the manual work to test and deploy it and then trouble shoot all the problems, they have an automated pipeline that deploys any changes within the automation pipeline.
Most IT shops are familiar with the “traditional path” – that’s how it has been done forever. But at Blueprint, we happily train the people we are working with so they can take the more efficient innovative path, working ourselves out of a job. Our day is made when we are not needed anymore because our clients don’t need us to create a new database, or to spin up a new computer in the cloud somewhere to run something new – we taught them how to support and maintain the system themselves.
Pivoting to this automation not only cuts the need for a technology partner, but also frees up the developer’s time, allowing them to focus on finding new ways to add value to the company. We are serious about meeting you where you are and untethering you from a technology vendor that don’t get the job done.
Let’s have a conversation about your business’ needs and how Blueprint can work itself out of a job for you.
