“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”Melvin E. Conway
As the COVID-19 pandemic continues around the world, the demand for digitization in banking isn’t slowing down. Bank branches, once an effective sales channel, are closing rapidly; their performance continues to decline as more people opt for mobile and digital banking. Even before the pandemic, McKinsey research shows that branch performance was on the decline; from 2015–19, the contribution of branches to core unit sales declined by 20 percentage points. In parallel, the demand for digital has continued to rise: top performers in 2019 saw digital-sales penetration that was 13 times higher than the worst-performing banks.
Banks must scale their digitization efforts quickly, yet many don’t have the capital or IT infrastructure to support rapid transformation. Thus, banks are looking for ways to achieve economies of scale. Institutions that already have solid digital capabilities or hard-to-find technology have become attractive targets for acquisition.
However, in most cases, banks fail to realize such benefits because they move right from the merger to attempting a digital transformation, neglecting to make much-needed complexity reductions in their IT environments. Of course, the idea of achieving digital at scale is exciting, which is why banks tend to make common missteps, such as underestimating the challenges of simplifying the technology stack or relegating the digital road map to IT. To achieve economies of scale, organizations should observe the six common practices shared by the few banks that have managed to reduce their IT complexity, which we present in this post.
Complexity as a function of scale
To understand the effects of complexity on economies of scale, we analyzed 50 global banks, comparing the number of applications a bank has versus its asset size (exhibit). We found that the number of applications in the environment is a good measure of IT complexity. We define applications in line with The Open Group Architecture Framework (TOGAF) as an operational IT system that supports business functions or services. This definition also implies that more applications always mean more complexity—for example, monolithic applications would be counted as several applications with this approach.
The result was surprising: we typically expect logarithmic or at least sublinear behavior to translate to economies of scale, meaning we would have expected the banks to need fewer and fewer applications to manage a larger asset size. However, we found the best fit to be a linear function:
typical number of applications = 2.69 X asset size (in $ million)
In short, we observed that IT complexity scales linearly with the asset size, meaning banks that increase in size and complexity typically won’t achieve economies of scale. While a few outliers are positioned significantly below the linear curve, this is not the norm. Of course, banks with different operating models (for example, more-corporate banking) require different numbers of applications, but this range does not explain the general trend.
Linear scaling also suggests that banks design their systems to be as complex as the organization itself. For instance, if a bank has an extensive line of financial products, it might build custom capabilities for each distribution channel. Similarly, if more resources are available, banks will likely use them to develop more complex systems. In addition, the number of customers is not an indicator of the potential to capture economies of scale. Our analysis found that banks with many customers in less-developed countries operate at a significantly lower cost base than similarly complex banks in more-developed countries.
Mastering economies of scale
Few banks have mastered the task of reducing their complexity. However, executives should note these six common practices of successful organizations:
- Focus on simplifying the underlying technology stacks and the number of interfaces. Businesses often push for customizations and features they consider critical, but these additional capabilities further complicate the existing IT system. When features are chosen appropriately, no IT system should typically require more than 10 to 20 percent customization.
- Use appropriate benchmarks. Banks often benchmark against institutions of similar asset size. Instead, they should measure themselves against competitors—including those in less-developed countries—with an equal number of retail or corporate customers.
- Move toward a fully automated, cloud-based DevOps model (either private or public). Many organizations might put off automating IT tasks because they don’t plan on moving to the cloud anytime soon. However, a lack of automation makes achieving digital at scale (and migrating to the cloud quickly) nearly impossible.
- Adopt strict architectural governance that limits complexity. Many banks may take an opportunistic approach to technology simplification and interface reduction, whereas prioritizing opportunities to decrease interfaces is the best way to reduce complexity.
- Hire only the best IT talent and adopt an agile operating model. Banks that understand the importance of the IT organization may still fail to invest in it with a long-term view. Instead, organizations should first transform IT by attracting the right talent and restructuring it to operate in an agile fashion before putting IT in charge of leading the digital transformation.
- Get buy-in at the executive-committee level. Complexity reduction cannot be enforced. Rather, it requires a behavior change starting at the top of an organization. That is why executives must have knowledge and appreciation of the investments needed to build a digital platform as well as an understanding of the platform’s inherent complexity.
These practices can help organizations define their road map to an ideal target state. By finding ways to streamline IT, banks can simplify their organization and finally capture those elusive economies of scale.