First Independence Bank

Do We Really Need Another Connection?

When two banks come together, IT teams start identifying ways to connect the environments through domain trusts, identity synchronization, shared access, mail forwarding and application integrations, all mechanisms designed to help two organizations operate as one.

Most of the time, those decisions make sense. People need access to systems, business operations need to continue, and customers shouldn't feel the impact of the transition. The problem is that temporary solutions have a way of becoming permanent ones. Nobody planned for them to become permanent. They just never went away.

Over time, they become another thing to manage, secure, troubleshoot, document and support. During our acquisition, one of the early discussions was whether we should establish a domain trust between environments. From a technical standpoint, it would've worked. Domain trusts are common and can simplify access during a transition. But I kept coming back to one question. If we're planning to retire the environment, why are we building new dependencies on it? That question ended up shaping a lot of our decisions.

Designing the End State before Connecting Systems

One thing I've learned during integrations is that it's easy to become focused on solving today's problem. Somebody needs access, an application needs to work, and data needs to move. The quickest solution is often to build another connection between systems.

What gets overlooked is the end state and what the environment should look like when the work is finished. Once we focused on that question, the path became much clearer. Instead of building connections between environments, we focused on moving people and services into the destination environment.

Core banking applications were centralized through a common RDS platform. Users were migrated into new mailboxes rather than relying on long-term forwarding between organizations. Files were moved into SharePoint and governed through modern identity and access controls. Printing was consolidated into a single PaperCut platform. None of these decisions was particularly exciting. That wasn't the goal. The goal was to reduce complexity.

It Adds Up

One of the things I've come to appreciate in IT is that complexity compounds. A single domain trust isn't difficult to manage. A single synchronization process isn't difficult to manage. A single coexistence solution isn't difficult to manage. But environments are rarely made up of a single thing.

Over time, more integration gets added, more exceptions are created, and more dependencies appear. Eventually, you end up supporting things that nobody would intentionally design that way today. The cost isn't usually the initial implementation.

The cost is everything that comes after it, including monitoring it, securing it, explaining it to auditors, troubleshooting it and training somebody else to support it. That's the part that gets underestimated.

Choosing Migration over Integration

This isn't really about domain trusts. It's about challenging the assumption that integration is always the answer. Technology teams are problem solvers. When two systems don't talk to each other, our instinct is to build a connection.

Sometimes that's the right decision. Sometimes the better decision is to remove the need for the connection entirely. Move the user, move the data, centralize the application, retire the old environment, and keep moving forward. Looking back, that's probably the biggest lesson I took away from the project.

Before building another trust, another synchronization process, or another integration point, stop and ask a simple question. Are we solving a temporary problem, or creating something we'll still be supporting five years from now? Because in many cases, the best bridge is the one you never build.