Uncovering Technical Debt For Better Technology Integration

Approaching technical and security integration

What's forgotten in M&A strategy is the complexity of technology integration. Think about gobbling up companies, merging companies, or selling off to another organization. Very rarely is the technological discussion had early on. 

• Strategically, what are your security postures? 
• Are you a cloud company or a data center company? Most companies are somewhere in between. 
• What are your business line objectives? 
• How is IT connected to your business, and how do they drive technological decisions based on revenue growth or cost reduction?

When we talk with customers, we're usually involved too late. Ideally, we would be involved earlier. Integrating 30 to 40 different partners, products, and platforms across two organizations is extremely complex. Just the basic interactions in identity systems, like what you use to log into a computer and how those devices connect to secured interfaces, can take months of effort.

If you have two different organizations, what's the strategy for integrating them? Do we keep them separate and incur higher technical costs, or do we integrate them for broader long-term savings? That's a critical decision point for our customers. It's important to understand and acknowledge these costs early on. 

When we're engaged in an M&A discussion, we like to discuss the actual business goals and core objectives. Once integrated, do you want to kill a brand or keep it together? Are you taking on staff or intellectual property? Broadly, that's how we approach it: working with them at the front end and asking prodding questions where we see regular challenges.

We see a couple of other things in M&A regularly, particularly in the manufacturing and retail spaces. OT networks, like connectivity to manufacturing machines and point-of-sale systems, involve significant complexity. They are operational technology, a well-known concept in manufacturing but less so outside of it.

We look at a business's apps and security components, the platform on which those apps and security are applied, and how they are used operationally. It is very important how business teams interact with the systems provided technically by an organization. 

Often, the culture of how staff work at companies may differ from the organization acquiring or being acquired. These four aspects are crucial: the app side, the security side, the platform side, and the operational or cultural side of an organization.

Technology Integration

The first thing I always ask our customers is if they are familiar with the iron triangle of project management. It’s the concept of cost, scope, and time. These three factors are always present in any project, execution, or merger and acquisition. They are often depicted in a triangle, but I ask our customers to imagine them on a seesaw.

You can spend more money to reduce time or scope, or increase scope and reduce time, and so on. The reason I talk about this is that technical debt is not a finite equation; it’s a balancing act. If you don’t have much money to spend, your time and scope will likely increase to complete the execution. It's a critical thought process to balance these effectively.

Denmark is a GDPR-enforced country, meaning different security requirements in the EU compared to the US or other countries. GDPR requires specific technical abilities, data storage, security requirements, and compliance. 

There are significant fines for non-compliance. For platform integration, data locality is crucial. For instance, if you’re using Azure and the company you’re acquiring uses on-premise data centers in Denmark, decisions on integration must be made.

We talked about identity systems earlier. If one company uses Google Workspace and the other uses Azure or Office 365, integrating these systems is a significant challenge. This affects calendar sharing, email, authentication, and application access before full integration. 

From a security perspective, understanding the platforms and connectivity, whether SAS-based or data center systems, is critical. This involves discussions about SD-WAN, firewall platforms, VPN connectivity, and licensing costs.

Running two different systems is always more expensive than a single solution. Your security team would need to manage two toolsets, platforms, and user bases. It’s acceptable but comes with increased resource management costs. 

Finally, we need to address shared data and its sources. For instance, the other company is using Excel sheets, and you are using CRMs; that's a space from an organizational change management perspective. 

This is not just a technology discussion; it's also about how you will change that organization to fit into your environment and culture. If they're currently using Excel spreadsheets, we need to analyze how effective that is. Are we spending too much time managing data in Excel, or should we educate them on integrating with HubSpot?

A big part of the discussion involves data view. Moving on, we need to understand email and identity integration. Are you going to merge domain names and email addresses? How will you integrate security measures like multifactor authentication to protect users from phishing? What security tools are they using compared to yours?

We definitely need to do more digging on this. Another critical aspect is network connectivity. How much data do you need to share between your two organizations? If you want to share all customer base, network connectivity, particularly with software-defined WAN, is crucial. 

If you have direct circuits between environments or use a cloud brokerage for connectivity in your Azure environment, you need to consider how data platforms move and synchronize that data. For instance, if you use native Azure storage and they use an on-prem data center, how will you move and synchronize that data?

Long-term, do you plan to decommission the data center in Denmark and move to Azure or another cloud platform? Understanding the protocols for data transfer, the complexity of accessing that data post-migration, and the costs associated with bandwidth and data movement are vital. These factors can significantly impact costs in a cloud environment versus a data center environment.

AI and machine learning

A couple of things he mentioned are important to call out. One is the concern about data privacy when using ChatGPT. Be cautious about disclosing any intellectual property or customer data in those prompts, as there’s still uncertainty about data handling.

From a data platform perspective, there are several steps we can take, such as prompt logging for awareness, fine-tuning, and controlling the model, or even pulling the model into a private environment without using a public interface or API. From a GDPR perspective, it's complex.

Be careful with data from a company in Denmark, ensuring regulatory compliance, especially regarding the removal of data if required.

We should have a deeper discussion with our data science teammates and AI experts to understand your goals and how to integrate the data from the acquired company into your current data model, whether it’s based on HubSpot or another system in your Azure environment. Even if we use AI internally, both internally and in the application, it opens up additional considerations.

From an introductory discussion, it's crucial to think through the number of different platforms a customer has, including data centers and cloud environments. Many customers use multiple cloud providers, such as AWS, GCP, Azure, or others like Oracle.

We’re particularly interested in the complexity of connectivity between these environments, as network connectivity is often the first challenge and delay, especially for customers with physical locations.

The time to establish connectivity can be months. During M&A strategies, companies rush through finance, NDAs, and reporting but often delay involving the IT team. Starting earlier could save a tremendous amount of time.

ERP migration

When discussing a Fortune 500 company moving from SAP to Salesforce, those migration projects alone may take two years at an aggressive pace. The bigger the customer, the more integrated the system is into their business. For example, in manufacturing or retail, you cannot touch ERP systems because they are utilized constantly by everyone from the CEO to the packing and shipping staff.

These systems are tightly linked to the business itself, making the operational side of using these systems very complex. Often, customers do not know their business processes well or they are not documented accurately, leading to high, unplanned costs if not addressed early in the discovery process.

In M&A, IT staff are often impacted, with teams being merged or reduced. We have seen an increase in cyberattacks targeting companies during acquisitions due to the chaos and lack of knowledge between the merging organizations' IT systems. 

Publicly disclosed mergers can make companies targets, and assumptions about IT activities can be dangerous. Early involvement of CIOs or CSOs in acquisition discussions is crucial to strategize about potential incidents from day one.

Often, IT organizations do not fully understand each other's environments until well after the merger, leading to undocumented knowledge and unaddressed challenges. Awareness of security postures and potential weaknesses is critical for successful mergers and acquisitions, regardless of company size.

Synergy assumptions

There are two core components that impact the cost specifically from an IT infrastructure integration perspective. First, the industry has drastically changed with the introduction of cloud concepts. The idea of using a credit card for monthly billing is great in theory but challenging for a CFO trying to understand a budget, especially if the team doesn't understand their spending.

We've seen a sine wave effect where companies move everything to the cloud, then repatriate back to data centers, and then go cloud again. The real answer is somewhere in between. Managing a traditional data center was CapEx-based, with structured three to five-year strategies. 

Cloud, on the other hand, is an operational spending capability, going month to month. Merging these two budgets during an acquisition can result in double paying for three to five years as licensing and renewals roll off.

The traditional infrastructure industry has responded with as-a-service consumption models for data center infrastructure, allowing for more flexibility. Understanding the complexity of managing both cloud and traditional data centers is very difficult, particularly in M&A. 

The concept of FinOps, or financial operations, is crucial. Early on, you need to understand your current spend in CapEx and OpEx and your willingness to vary those as you go through an acquisition.

Second, you need to understand the strategic goals of the acquisition. Are you going to merge the IT footprints or run them separately? Operating two different tech stacks long-term will increase operational and licensing costs more than merging them. 

While the upfront cost of merging is higher, the long-term benefits are significant. However, companies often take on technical debt by managing two different organizations at higher cost for a short period before starting the formalized planning to modernize and centralize.

In M&A, there are always unknowns. We use the concept of VUCA (volatility, uncertainty, complexity, and ambiguity) to plan for these. Understanding the current landscape and having a clear strategic plan for integration is essential. 

For example, you might aim to have an integrated email environment on one platform within three quarters and half of your applications moved from a data center to a cloud environment within six quarters. This allows for working backward on the costs, effort, and labor required to achieve these goals.

Think of the iron triangle of project management. The seesaw concept helps our customers understand that a perfect world doesn't exist. There are always time, effort, and costs. It's about optimizing these factors to gain a strategic advantage and increase profitability.

This optimization must be in the context of the businesses you're acquiring. At Insight, where I've been for seven and a half years, we constantly merge and acquire other organizations. 

We've tried different integration strategies. Sometimes we run isolated organizations as separate business units to see their profitability, but this can reduce integration with legacy customers. 

Other times, we immediately integrate a newly acquired company, which can demoralize their teams. The truth lies somewhere in between, and we recognize that acquisition is a necessity in today's business world.

The technical approach to this process is crucial. My team of 210 understands these challenges, and we often bring in teammates with domain-specific knowledge from different regions or teams, whether it's retail, manufacturing, security, or government.

For sure. My team and I are in a unique position because we face similar challenges to our customers, particularly in the technology space. We're well-placed to learn from both good and bad experiences. We have a community-driven team that regularly shares customer stories.

For example, someone might say, "I just worked with this customer, and their situation is a mess, but look at what we can do here." We recommend solutions and tackle challenges, which is beneficial for our team. Insight does a great job of intentionally merging our pre-sales and sales organization with our internal IT function. 

This creates crossover functions where we work together on customer and internal IT initiatives, ensuring we share and utilize knowledge effectively. If we don't practice this internally, we can't expect our customers to do it. This is a significant challenge.

Working with Insight

My team is a true pre-sales team. We want to ensure what you're trying to achieve aligns with what we can provide. We aim to be honest and upfront. For instance, if you asked me to build a nuclear reactor, I'd probably say that's not within our capabilities, but we'd still support you in any way we can.

Most of the time, when we're involved in an IT-focused project, my team works on the pre-sales side. Our services are free to the customer, and our job is to ensure we're solutioning, designing, and helping build the roadmap. If we do our jobs well, we'd like you to purchase services or products from Insight. It's on us to show the value, which is why we share thought leadership.

This leads customers to think, "Hey, that team seems sharp; I should discuss my needs with them." Once we understand and scope the challenges, we have billable services if you want us to do the actual work.

Due diligence

We would have a scoping discussion as part of that pre-sales conversation. We go back and forth, working through the details. For example, if you think I know a thing or two, I'd suggest we meet face-to-face for a whiteboard session. This session is free, and the goal is to understand the process better with all the stakeholders involved.

During the session, we draw designs, identify risks, and outline areas needing further details. If you decide to proceed with our services, we take this information back to our service and scoping team, who determine the cost, risk, and scope of the engagement. This might involve purchasing products, firewalls, or devices as part of the solution.

One reason I joined Insight is that our pre-sales architects, including my team, follow through into execution for oversight. This is crucial because the same team that understands your context and business challenges from the initial discussions ensures that the delivery team meets those needs.

I continue to work with you throughout the process, making sure we deliver on our promises and maintain the customer relationship.

Our focus is on achieving quality outcomes for our customers to build long-term relationships, not just providing a one-time service. We invest heavily to ensure our customers get the right results, maintaining those relationships over time.

Managing costs

I'll put on my customer hat for this, as this is the first job I've had in an organization with a consulting group. We call ourselves a solution integrator, not a consulting organization, because most consulting firms don't consider product platforms and resell the way we do. We aim to operate between a traditional VAR and a GSI intentionally to maintain long-term relationships.

We don't charge all costs upfront for a pre-sales engagement because we may offset that with product sales or services. When I was a customer, I was very transparent with my account manager and architect. 

The relationship between the technical team and me was more important than the selling relationship. The technical team should guide what to buy, and the seller should determine the cost. My team is not a commissioned sales team; we focus on customer care and building relationships.

We work best with customers who are as transparent with us as we are with them. When I was a customer, we had a large data center migration project. We vetted three partners, negotiated costs, and discussed technical debt and risk. This transparency helps us become an extension of the customer's team.

No customer will disclose their full budget upfront, but understanding alignment and culture is crucial. If the customer's culture aligns with ours, we can work well together. We rotate architects in different regions to provide diverse perspectives and technical skills. This ensures we address challenges effectively and provide thought leadership.

The key is honesty. Tell us what you want and, more importantly, what you don't want. This clarity helps us focus and avoid irrelevant ideas. Trust and open communication are essential. We prefer starting with small, focused projects to build trust and demonstrate our capabilities. If we succeed in a small engagement, the customer will trust us with more significant projects.

Return on investment

There are many examples, but one that I'm most proud of involved a security incident we helped a customer respond to. ROI in a security context is different, and I need to be careful not to disclose information that could indirectly reveal who it is. From a security perspective, our organization has done an excellent job adapting by mixing pre-sales resources on my team.

When a customer calls with an issue, we get immediate teammates involved who are knowledgeable about the account, the relationship, and the technologies in use, whether they are in the cloud or a data center.

We also have capabilities for remediation, virtual CISO engagement, and response, including forensic teams. The ROI for our team, compared to some competitors, is extremely impressive. I can't provide further details to avoid disclosing sensitive information.

That's one example. Another one involves my personal career since I've been here. I've worked on many projects in manufacturing, where we've helped customers with significant modernizations. Some manufacturing organizations were very far behind in IT operations, using spreadsheets or even printed spreadsheets for optimization.

We started some of these projects six or seven years ago. Now, these organizations are among the most modernized, accurate, and machine-learning-driven manufacturing companies we work with. While I won't give specific ROI numbers, the projects have paid for themselves many times over.

We've also done a lot of work in the AI and ML space recently, particularly around Azure-based business and endpoints like co-pilot. Our data and modernization team continues to excel, tackling the hardest part: data gravity.

We've taken 70 to 90 data sets from organizations and turned them into one or two usable sets for machine learning and ERP systems. These examples highlight the impressive results and ROI our team has achieved.