It didn't matter to the man who hired Kevin O'Connell that SEI's newest employee didn't have a background in finance.
Nor was he concerned that O’Connell didn’t possess hard coding skills or experience managing IT. SEI needed someone to oversee the trust and banking software portion of an $11-billion corporate merger, and O’Connell’s new boss believed the former Navy officer was the ideal person for the job.
Like his peers at SEI, Kevin understood that every SEI client wants and needs to grow. It was SEI’s imperative to partner with clients to help successfully manage that growth, be it organic or through acquisition. O’Connell was about to enter the eye of a merger storm, and see the depth of SEI’s commitment to its clients.
What everyone knows, of course, is that so many business mergers fail. Adding one company to another may look good on paper, but the reality is far messier, involving clashing corporate cultures, battling IT departments and persnickety software programs that don’t play nice with each other.
This particular merger was between a big bank and a huge, multi-national bank that was an existing SEI client. In this case, the huge bank was absorbing the big one. SEI had accepted responsibility for transitioning 75,000 accounts from one to the other, a task made more complicated by the fact that the companies ran on different software. For several months after the data migration began, the newly integrated platform connecting the banks had been slow and balky. It wasn’t for lack of manpower or computer horsepower. The bottlenecks were created by the sheer scale and scope of transferring so many accounts to SEI’s client.
The multi-national bank had run for many years on SEI’s long-tested and highly reliable TRUST 3000® platform. The predecessor of the SEI Wealth Platform℠, SEI’s new state-of-the-art wealth management solution, TRUST 3000 launched in 1968, when banks’ trust departments ran largely on paper-and-pencil accounting. With TRUST 3000, SEI pioneered the use of computers for handling vital operations, such as settling trades, posting mutual fund income and processing payments.
Much of the processing occurred overnight, after trading hours. And it was during this batch processing that the system would sometimes grind to a halt, unable to complete all its tasks and calculations on deadline. Instead of being up and running by 7 a.m., in plenty of time to do the testing necessary before trading started the next day, the network was, on some days, coming online late.
The multi-national bank was getting antsy. This bank had been an SEI client for more than 20 years. In fact, it had been one of the first to sign on, when SEI chairman Al West founded the company and coded software on punch cards. To this day, the client remains one of SEI’s largest and strongest relationships. So it came as no surprise when the edict came down from the top of SEI that the entire company would make this merger a top priority.
There are no traffic lights in the middle of the Atlantic
It was a lot of pressure, but O’Connell took it in stride. Before joining SEI, he had earned a degree in electrical engineering from Notre Dame and spent six years in the Navy as the navigator of a destroyer. There he had had his first brush with real pressure — the kind that can tie your guts in knots if you let it, when one slip-up could mean the difference between life and death.
O’Connell was fond of saying that there are no traffic lights in the middle of the Atlantic, and it’s amazing how often two ships can meet in the vast, roiling seas. Often, it seemed to him, in the middle of the night.
Once, O’Connell had a five-minute window to help a pilot land his chopper in angry weather. While steaming in formation, Kevin calculated the course, taking into account the choppy seas, strength and direction of the wind, and angle of the helicopter’s approach. Because the helicopter pilot couldn’t see through the fog, O’Connell advised him to hover while he maneuvered 8,000 gross tons of steel beneath him. The pilot hit the flight deck just as his helicopter ran out of fuel.
While he had years of experience with Navy hierarchy, O’Connell soon found out that titles meant very little at SEI. Everyone is expected to be a leader, earning their leadership through successes in tough projects, in the line of fire. And the projects rarely came any tougher than this one.
It was the kind of high-pressure situation that required O’Connell to put aside emotion so that he could focus on the extremely complicated task at hand. There was a lot of uncertainty, and a fair amount of risk, but O’Connell felt that a steady hand, long hours and the right team would get the job done.
What lay ahead of O’Connell and his team at SEI was somehow making the incredibly complex manageable, and quickly coordinating the vast resources needed to implement solutions, all within a rigid timeline.
Back in the Navy, though O’Connell had been the one steering the ship, it was all about the team. Everyone from the lowest deckhand to the captain each had to do their individual jobs to help that pilot land on a blustery night in the mid-Atlantic. O’Connell took that core tenet with him to SEI.
It was always team first
Assigned to O’Connell’s team was Bob Amadio, a computer engineer and an expert in creating scalable systems. The two flew to the global bank’s data processing center. O’Connell began working there with bank staff, as well as back at SEI’s headquarters in Oaks, Pa., to attack problems one glitch at a time‐the usual difficulties that pop up when a bank migrates newly acquired accounts to its software. Meanwhile, Amadio studied the overnight batch-processing situation, which was causing the biggest headache.
It didn’t take Amadio long to uncover the specific constraint that was slowing things down and hindering efficiencies: “ticklers.” In bank parlance, a tickler is any scheduled event in a system. For instance, if you want to autopay your mortgage every month for the next five years, you can schedule that disbursement out of your bank account. If you want to do that in a trust account, you are, in essence, selling an asset, collecting the cash and then distributing the money.
Add to these ticklers the usual trust activity that goes on as clients buy and sell stock or mutual funds, and the network generates a whole lot of new data every day. Every night, the system processes all these changes. But with 75,000 new accounts added to the bank’s existing ones, Amadio could see that the system was suffering from information overload. Instead of the system going through all its processes in 12 hours, it was taking much longer.
Amadio’s first thought was, “Wow, we really have to crunch a lot out of this.” He studied the network architecture and could see that a big chokepoint had to do with workflow procedures. Before processing any new trust data, the system had been designed to make a snapshot of the entire network. When Amadio discovered this protocol, he shouted at his computer, “No, no, no! You can’t back up the system now. We don’t have enough time to back it up now.”
Amadio quickly realized that while this was a serious workflow problem, it was also a fixable one. The previous protocol had been fine when there were far fewer accounts, but was not when an avalanche of new data was being created every day. There was no reason backing up had to be done at night. It could happen anytime, and even run simultaneously with the system during work hours in a mirroring effect. But Amadio couldn’t simply make this change. Because SEI serviced so many wealth management firms, he would have to engage a team of engineers at SEI headquarters who would recode that portion of the network architecture and significantly enhance the overall workflow procedure.
When Amadio phoned his boss, John Steinmetz, back in Oaks, and explained the situation, Steinmetz knew that it was very important. O’Connell was told that company founder Al West had taken an active role in this one, and was even coming in to bug test software. Steinmetz needed little convincing to commit his team. He advised Amadio to do whatever was needed to keep the bank up and running, while Steinmetz and his team reworked TRUST 3000 by instructing backups to happen at another time.
Next, one of the developers wrote a program that interrogated the data, and sent only changes to the database. Instead of doing a dump of everything every night, the team moved to what Steinmetz called “an add-change-delete model.” Only new data were backed up each day.
Soon after, the bank was up and running at 10:30 a.m. That’s a good start, O’Connell thought, but not good enough. He, Amadio and their team at SEI still had a long way to go to get the system up by 7 a.m. But O’Connell recognized that simply re-jiggering software to get more work done by early morning was not the goal here. SEI was not aiming merely at a technology conversion. SEI uses technology to transform a business, a process much more ambitious, complex and far-reaching. Business transformation is accomplished only through visionary leadership and real-life testing, and with problem-solving that aims at exponential gains in efficiency and capabilities.
This was a time for collaboration as well as transparency
With his eye on that ultimate goal, O’Connell was dealing with a cascade of difficulties. Some of TRUST 3000’s 800 various software applications dated back from the very beginning of SEI, and had been written in a potpourri of software languages. So it was not surprising that the deluge of data spawned by the merger was causing conflicts. One of TRUST 3000’s trickier programs depended on these backups being completed before it would execute another program. The application would then run at the tail end of that, and it seemed to take forever. Amadio told O’Connell, “It ran like a pig because it had never seen that kind of volume.”
This was a time for collaboration as well as transparency. O’Connell and Amadio decided to bring in the developers for a virtual meeting with the client. What do we need in to fix this? What is it doing? Why is it taking so long? As they dissected the problem and the developers sifted through the code, they found that some of the applications were going haywire, deleting data before adding it back. “Why are we doing that?” Amadio asked. “Can we make these ‘deltas?’”
Using delta logic simply means to identify changes in data and apply only those changes. This approach is not only used in wealth management investment processing, but is also common in video games and cartoons. The characters may move, but the background stays the same. SEI’s software was doing the equivalent of completely changing the background every time a character took a step. Instead of updating the 5,000 accounts in the system that had changed, it was updating all 75,000. It was one more step in empowering the banks rapid growth: the system had to be enhanced to think differently.
Once Amadio, Steinmetz, O’Connell and SEI’s developers figured out what had to be done, the team had to convert into code. “The development team was all pumped up,” Amadio says, “They were excited for a new challenge to further scale the platform. They were literally pinging me all hours of the night, saying, ‘How’s it going? What step is going on? What job is running right now?’”
As soon as Amadio spotted a chunk of code thrashing about, a developer would immediately jump in to fix it. O’Connell practically lived at the bank, coordinating efforts among its technologists, who handled the hardware, and his SEI technologists, tasked with the software. Everyone was running purely on adrenaline, feeling part of a greater whole. They knew that the clients’ success, not to mention SEI’s, depended on getting this right.
After implementing these delta logic changes, Amadio was pleased to see that the bank’s system was going live at 8:30 a.m.
Not bad, but they still had a way to go to give the bank the capacity it needed to transform its business. Their search led them to look at the creation of reports. Say you buy shares in a mutual fund, or there are changes to your money market account, or whatever. The system was designed to generate a report at night during the tail end of the batch cycle, where a lot of processes that weren’t time-sensitive were stashed. But these reports didn’t have to be created then. They could be created earlier, as long as they were available before wealth advisors logged into the system to check their clients’ accounts.
There is nothing quite like learning by doing
After resetting this problem, SEI’s programmers dug deep into the code to fix other glitches that kept popping up. And 11 months after O’Connell’s first day on the job, the network was virtually problem-free, coming online at 7 a.m., with the capacity to handle the huge scale the client needed it to handle to accommodate its aggressive growth plans.
Back when this merger occurred, migrating 75,000 accounts was an extremely tricky proposition. Since then, SEI has successfully supported this same firm through two more very large-scale acquisitions. The bank remains a critical business partner for SEI, relying on SEI’s teams to continue to support the transformation of its business. All the lessons about migrating big data on a massive scale to complete such large mergers have been poured into the backbone architecture of the SEI Wealth Platform. The result? It took over 40 years to build SEI’s TRUST 3000 business across the U.S. wealth management industry — and that experience allowed them to deliver the SEI Wealth Platform globally in less than 10.
There’s nothing quite like learning by doing.
After the merger was declared a success, O’Connell was anointed SEI’s in-house “fixer”, quickly gaining the reputation of someone unafraid to take on any challenge, no matter how daunting. And while O’Connell is a project manager, the one in charge, he’s adamant that it’s always a team effort.
And while some wealth management partners can be risk adverse, O’Connell and SEI welcome the big challenges. They’re dedicated to being a transformative partner for your business.
It’s this team-first approach that has helped O’Connell, over the 17 years he has worked at SEI, manage many other big and complex projects.
O’Connell lives by an SEI mantra — never be afraid to fail. Some of the greatest successes are born of failure.
O’Connell and his team personify this every day. That doesn’t mean it’s always smooth sailing. Sometimes things go wrong and it’s a while before he can get the ship righted. But one thing Kevin O’Connell will never do is give up.