娇色导航

This is the first in a multipart series exploring technology’s involvement in mergers and acquisitions (M&A).

I’ve been in IT longer than I’m willing to admit. Along the way, I’ve had incredible opportunities to tackle challenging projects. About 20 years ago, as principal architect at Direct Energy in Toronto, I was suddenly immersed in the world of M&A. I had zero prior experience, so it was all new territory.

Working alongside legal and financial teams, I quickly realized our goals aligned perfectly: managing risk. The legal team ensured the target company was legally sound, reviewing contracts, closing off obligations and assessing liabilities like payouts to long-tenured staff. Everything boiled down to cost and legal exposure. The accounting team did the same from a financial lens. It all made sense.

Why IT? My eye-opening role

The big question hit me early: Why was I there? I lacked legal or accounting expertise. The answer came when I was tasked with evaluating the target’s technical architecture — and translating risks into financial and business liabilities.

As Principal Architect, this was familiar ground. I reported back to the M&A leadership, and my insights proved not just valuable but essential to negotiations. In some cases, they helped avoid multimillion-dollar pitfalls. Over several deals, my feedback shaped outcomes, from price adjustments to deal structures.

This led me to develop a blueprint for technical due diligence, rooted in . Focused on risk and cost, it emphasized technical architecture and data architecture — spotting technical debt and data quality issues. Back then, “technical debt” was obscure outside IT, and data as a core asset was even less recognized. 

One nagging question persisted: Why hadn’t I been involved in M&A before? Why wasn’t technology routinely included, given the shared focus on risk?

The language barrier: Geeks vs. executives

The term “technical debt” wasn’t mainstream, making it tough to convey to lawyers, accountants and executives. Their languages aligned — business, finance, law — with shared specificity. But IT? We spoke a different dialect, full of jargon that obscured our business insights.

This cultural divide explained technology’s historical exclusion from M&A. The gap was mine to bridge. Over time, I learned to translate, framing technical risks in terms of dollars, downtime and competitive edge.

Bridging the gap: Building a technical blueprint

My counterparts had structured approaches: decomposing the business into key areas, gathering evidence on effectiveness and compliance. M&A isn’t cookie-cutter, but their blueprints provided focus.

I adapted TOGAF’s architecture development method (ADM) and domains — business, data, application, technology and security — to create an M&A specific blueprint. It’s not for solution design but for evidence-based risk assessment. Here’s how I apply these domains in due diligence:

Business architecture

Overlap exists with legal and finance, but IT’s lens is unique: assessing how operations impact data and systems. Chaotic processes yield chaotic data; effective ones produce reliable insights.

I examine about 10 key areas. Here’s a quick overview in table form: 

Data architecture

“Good decisions on bad data are bad decisions” (me, circa 2007). Data is an enterprise’s most valuable asset, yet often neglected. Poor data can cripple; great data accelerates growth.

In M&A, I scrutinize quality, lifecycle management, governance, ownership and analysis.

Companies are typically polarized: exemplary governance or barely functional. Data issues heavily influence deal pricing — more on that in a future post.

Application and technical architecture

Here, technical debt shines through, often via legacy systems. “Legacy” doesn’t always mean old; it means outdated, costly and valueless. Options range from retirement (economical) to forced upgrades (expensive). I’ve seen new systems built as instant legacies.

Security architecture

Critical during M&A, as deals attract hackers — sometimes derailing them entirely. With AI-driven threats rising, robust postures are non-negotiable. This warrants its own article.

Looking ahead

I’ve refined this blueprint over the years, applying it pre-acquisition for risk mitigation, post-acquisition for integration roadmaps and even defensively against buyer audits (increasingly common).

Future posts will dive deeper: data architecture’s pricing impact, security’s deal-killing risks and integration strategies. Have you championed IT in an M&A deal? I’d love to hear your experiences. 

This article is published as part of the Foundry Expert Contributor Network.
Want to join?