On January 1st, 1939, senior partners Van Burger, Lou Froehlich, Dave Foster and Jack Pershing (son of WWI General John Pershing) founded Pershing & Company. The newly formed Pershing quickly established itself as a provider of fast and efficient trade execution for firms outside of the New York Metropolitan area, even in spite of three of its senior partners going to serve in World War II.
Following the war, Pershing would spend the next half century growing from providing regional financial services to the NYSE and AMEX to becoming a global financial solutions provider with offices all over the world. In 2003, The Bank of New York acquired Pershing and would later, in 2007, merge with Mellon Financial Corporation, resulting in Pershing's current state: a subsidiary of BNY Mellon.
The Challenge
Startups have the luxury of engaging in the iconic "pivot": revisiting their core business model and everything they're doing from first principles. Enterprises, on the other hand, cannot just change this way.
As a wholly owned subsidiary of a company the size of BNY Mellon, Pershing understands that organizational change is complex and hard-won. This alone presents a significant challenge to a company looking to modernize the way it builds software. But layer on top of that the regulatory concerns that apply to a global bank, and creating a nimble software organization becomes downright daunting. In fact, it requires a holistic transformation approach.
Enterprise-level agile and DevOps transformations have become relatively common these days. But the fact that many organizations are trying them doesn't necessarily mean that they are all succeeding, and it certainly doesn't imply a one-size-fits-all approach for success. Each transformation success story is unique.
In the case of Pershing, they are taking a tip-of-the-spear approach, wherein an early-adopting reference group prototypes modern practices and then evangelizes and socializes them with the rest of the organization. Derek Evans, Pershing's director of DevOps, is at the forefront of that effort.
Evans' challenge as a leader of the bank's DevOps transformation is thus easy to explain but extremely complex to implement. He has to take an enterprise from a world of two-hour builds and IT tickets to request deployments to one in line with modern DevOps practices and capable of keeping up with the rapidly evolving needs of the bank and its customers. All of this needs to be accomplished while maintaining regulatory compliance and satisfying a justifiably risk-averse group in upper management.
Today, Pershing has 1,300 clients worldwide and manages 2 trillion dollars worth of assets on their behalf. But in spite of all of their success and their status as a subsidiary of one of the world's major banks, they have never forgotten that all of their client relationships are personal. Maintaining personal relationships at global scale in an ever-changing marketplace requires a significant investment in technology.
“We can deliver product owners 66 percent more [functionality] than before.”
The Solution: Better Tools and Culture
How have Evans and Pershing begun to address this challenge? There are two essential planks to organizational transformation, and those two planks are tools and culture. Evans has been addressing both.
From a culture perspective, he's created a pocket of innovation by establishing credibility and trust with upper management. Before his tenure, Pershing and other subsidiaries had an attitude of "Oh, don't do that—we don't know what the bank's going to say." Now, he and his organization feel empowered to take a "better to beg forgiveness than ask permission” approach, but with the blessing of upper management. And he's affected this cultural change by repeatedly demonstrating the business value of the changes they're making, often through the compelling use of hard metrics.
Hard metrics, of course, are impossible without the other pillar of transformation: improved tooling. Evans' organization has, for instance, reduced the time for builds from two hours to seven minutes or better. Instead of filing a ticket with IT to promote code to another environment, Pershing now makes use of Git tags and web hooks to do it automatically, without friction.
As Evans explained it, "We can deliver product owners 66 percent more [functionality] than before." These are the sorts of concrete improvements that attract the attention of a managing director and inspire trust.
Evans and team have achieved this capability through the adoption of an entire toolchain: a CI/CD pipeline, automated deployments, modern source control tools, infrastructure as code, automated testing, and automated open source governance enabled by Nexus Lifecycle. They are now smoothly pushing code through their environments and into production with very low cycle time, and they're doing it with the risk mitigation capabilities enabled by automated open source component analysis and validation of their software's bill of materials. Not only can they push software more quickly, but they can also catch and remediate defects earlier in the development lifecycle. Thanks to Nexus Lifecycle, development teams can immediately understand when open source components are using a non-compliant license, are architecturally outdated, or plagued by known security vulnerabilities.
The Outcome: Measurable Improvements and a Promising Future
Pershing's transformation remains a work in progress. But there is, nevertheless, an outcome to report. Without significant early gains, transformations can easily stall and be abandoned by the organization. The fact that BNY Mellon is doubling down on theirs indicates that the cultural changes and tool adoptions within the initial reference organization, Pershing, have been quite successful.
But the work continues. And like the first half of a tip-of-the-spear transformation, one could argue that the second half has two core planks as well: continued innovation and broader socialization. In other words, Evans' next steps are to continue Pershing's improvements while driving adoption throughout the rest of the bank.
Nexus Lifecycle figures quite prominently into Evans’ plans on both fronts. Pershing has increased its output capability tremendously, but Evans knows that bank-wide adoption of those techniques is predicated upon de-risking the process and ensuring regulatory compliance.
On the continued innovation front, Evans plans to continue his metric-driven approach and apply it to securing his software supply chain. Today, he has a grading system for release candidate health within Nexus Lifecycle, but he plans to expand on that significantly by factoring in additional components to that score while also making individual concerns accessible to upper management via readout. He reported being able to “create a view that allows a managing director or enterprise architect to go into it and see ‘Oh, here's our open source component health and here's a view of our technical debt across open source components within our application portfolio.’”
When it comes to considering broader adoption, simple conveyance of information matters a great deal. When Evans' organization pushes software one day, he often gets phone calls the next day from upper management with questions like, "What's our risk exposure on our application portfolio?" With the help of Nexus Lifecycle, he can answer this in half a day with a forensic search, but he intends to leverage reporting and views that will allow him to answer that question immediately—or better yet, just allow managing directors to see it for themselves.
Evans' plans for disseminating his prototype approaches are obviously predicated upon upper management buy-in. But even with their blessing, socializing a transformation with the broader enterprise can be a challenge, especially in the face of skeptics and late adopters.
Nexus Lifecycle has actually helped Evans get a jump on that - and it’s done so in an interesting way. Nexus Lifecycle offers IDE integration for developers in the form of a plugin. With Pershing's adoption of Nexus Lifecycle, developers in the organization have organically begun to use the plugin. They find the component intelligence that it provides to be invaluable; as Evans put it, "Everybody loves the immediate visibility it provides them with regard to security and compliance or their component choices. They also love the immediate guidance it provides to alternative component versions when an initial choice is found to be out of compliance."
In this fashion, Nexus Lifecycle has helped Evans achieve one of the rarest feats possible in a transformation—the prospect of rolling out a risk mitigation strategy that satisfies upper management while delighting the engineers responsible for building high quality applications. It's a refreshing change from a world where, all too frequently, governance and innovation produce so much friction as to be at odds.
Conclusion
Evans is in the middle of a monumental task. He expressed it simply: "If I had to boil it down, I'm responsible for transformation." That's simple enough to explain but incredibly complex to implement.
So far, he has enjoyed success by being disruptive enough to drive meaningful innovation while making sure that he can conspicuously show metrics and data to prove his efforts are having a measurable positive impact on BNY Mellon. To date, that has involved a huge emphasis on improving delivery efficiency via automation and cultural change. "We can produce functionality and new applications really, really fast, and that's gone exponential," he explains.
But as his vision shifts to the future, his focus is on automating validation of the health and safety of the work product they deliver so quickly and then rolling that validation out across the enterprise. For that, he's depending heavily on Nexus Lifecycle.
