The value of standards over standardization

by Satty Bhens, Partner at Digital McKinsey and Leader of Digital Labs and Jake McGuire, Consultant, McKinsey

Recently, a Chief Digital Officer asked us for advice about standardizing on a single web framework. He was concerned because the organization’s marketing team had recently decided to use React (a web framework developed by Facebook) while several of the business units had standardized around Angular (a web framework developed by Google).

The question was not about the technical merits of each framework. Instead, the CDO wanted to understand if having a standard JavaScript web framework across the enterprise would have benefits, and if so how they should decide on which framework to choose — especially given the fast pace of change in web front-end frameworks.

Large enterprises often experience fragmentation in web tools between teams

So, how do enterprises end up with multiple frameworks?

The most common cause of framework fragmentation is the pace of change. The rapid progression of web frameworks and stop/start project investments has saddled enterprises with a constellation of enterprise and business applications with different and aging toolkits. We do however see this churn slowing down for enterprises as JavaScript — as a language and ecosystem of frameworks and tools — catches up to other first-class languages.

With this web fragmentation enterprises experience a number of challenges:

Productivity. Developers learning a new framework will experience a period of diminished productivity as they move through the learning curve. Developers re-incur this dip in productivity every time they begin working with a different framework.

Dispersed Expertise. Having multiple frameworks causes expertise to be spread thin across the enterprise. Bottlenecks occur when an expert in a particular framework is unavailable to help unblock a developer problem, while other experts in other frameworks may have capacity that could be utilized if they used the same standard technologies.

Interchangeability. Multiple frameworks prevent developers from moving fluidly between teams based on demand, availability, or interest. Instead they get locked into teams based on their knowledge of a legacy framework. Furthermore, there is little interchangeability of common functionality between teams, such as a reusable component developed for one product that can be leveraged off-the-shelf by another product.

Maintainability. Multiple frameworks create a long tail of applications with aging technology that fewer and fewer developers know or want to maintain. For example, a state-of-the-art Backbone application from 2011 may be an infeasible chore to maintain in 2018.

While fragmentation causes issues at enterprise scale, there are also issues with rigid enforcement of standard web frameworks:

Innovation. Mandating a single framework slows innovation by ignoring useful features in newer frameworks. Teams may push back against innovative design when what delights customers is difficult to achieve with the standard framework. We have also seen teams locked into a standard solution’s way of solving a problem (e.g, an ASP.NET Web Form as the standard pattern for presenting and order page) which makes it hard to see new, innovative ways of improving user experience.

Mismatches. The standard framework may not be the right choice for all types of applications. Angular may be perfect for a dynamic data visualization but perhaps overkill for a static page with little interactive functionality. As a result, developers have to shoehorn functionality into a single framework’s way of solving a problem.

Recruiting. Great developers are excited about learning, and many are willing to take pay cuts to work with the latest technology. Enterprises are competing with startups that offer learning opportunities and the ability to retool with new skills; with standardization they risk driving away some of the highest performers who want to learn regularly.

Lock-in. Selecting a single framework puts enterprise at the mercy of that framework’s maintainers. We have experienced entire features being put on-hold indefinitely or critical bugfixes going unaddressed for months.

“Back of the napkin” outline by Jake as the team thinks through the challenges of frameworks.

We believe large enterprises can reconcile these competing issues with a hybrid approach that combines the benefits of standardization with the flexibility of multiple frameworks:

(1) Select a go-forward framework for all new development and review this choice on a regular cycle. Allow alternative frameworks to be evaluated and used for newer, more innovative use cases. This allows organizations to reap the benefits of standardization in situations where framework choice has little technical impact (e.g., account signup forms) but retain some flexibility for applications that need specific capability not provided well in the standard framework (e.g., real time, dynamic data visualization).

(2) Commit to building a deep bench of JavaScript experts versus framework experts. Expect senior engineers to be well grounded in JavaScript and have experience with multiple frameworks. Give them a big voice in the framework selection and exception processes. Many of these senior practitioners will be testing new frameworks, observing trends, and staying close to implementation-level details.

(3) Embrace end-to-end automation. Most importantly, build automated tests into everything teams create or change. This is critical for maintainability, and it is especially important for developers who will need to fix critical issues many years in the future when the standard framework is now legacy. Furthermore, a robust automated test suite provides guardrails for developers by catching unintended regressions in real time.

This approach prioritizes standards over standardization. Enterprises should focus on quality through baseline standards — modularized components, rigorous automated test suites, automated packaging, DevOps, monitoring, etc. — rather than a web framework. The decision between Angular or React is less consequential than the commitment to baseline standards. This commitment will enable enterprises to migrate quickly and effectively when the next innovative web framework comes on the horizon.


Header Photo by Dayne Topkin on Unsplash

In-line drawing by Jake McGuire, Consultant, McKinsey

Special thanks to Christian Lilley, Oscar Villarreal, Brent Pabst, Dave Kerr, Aishwarya Singhal, Farhad Ghayour, and Thomas Newton for sharing your expertise for this article.