Today’s companies need to be able to roll out digital products and services quickly to address customers’ ever-evolving needs. They need flexible technology systems and business processes to do that and to create lasting competitive advantage. For the past several years, many companies have been experimenting with two-speed enterprise architectures to achieve these goals. Under a two-speed model, the processes, software, and other differentiating functions or capabilities that support the customer experience are refreshed quickly and frequently. The capabilities that support transactional back-end functions, meanwhile, are updated more methodically to ensure system stability and reliability.
Companies can reap important benefits from building an enterprise architecture that is simultaneously fast and slow. Such an approach can prompt business and IT leaders to look beyond technology concerns and consider the range of process and governance factors associated with managing enterprise architecture. It can ensure that varying system requirements and desired rates of change in different business units and business functions are addressed appropriately.
In many cases, companies have taken a technology-first approach to deploying two-speed enterprise architecture, realizing small-scale successes along the way. The impact of the two-speed approach increases significantly, however, when companies put capabilities first. Indeed, we believe business capabilities must be the central factor for determining which parts of the enterprise architecture—that is, which technologies, working groups, and processes—should be on a fast track and which should remain steady state. IT and business leaders must come together to identify the digital business capabilities desired and how best to support them.
Understanding enterprise architecture
The typical enterprise architecture comprises discrete process, organizational, and technology elements, any of which can be managed on a fast track or a slow track depending on a company’s digital strategy. For instance, a company planning to launch a new digital offering would need to consider technology issues (what new types of software or other tools do we need?), as well as process and governance issues (how often should the software be updated, and who will ensure that it gets done?).
The emergence of automation technologies and microservices, as well as the shift toward agile and DevOps methodologies in product and process development, have made it easier for IT organizations to introduce higher-quality operations and deliver software and services more quickly across all parts of the enterprise.
From a technology-based point of view, it would seem that companies could thrive by standardizing on a single-speed enterprise architecture. But, in our experience, the enterprise architecture will still need to be managed at different speeds to accommodate process and organizational requirements. Consider a situation at a bank (or, for that matter, a company in any highly regulated industry). It might be perfectly fine for a product-development team to develop and test a good-enough mobile application, roll it back, and relaunch it at a later date. But while the technology elements of the enterprise architecture may allow for this agile approach, the organizational and process elements may still need to be managed differently. In this case, “fast failures” could lead to substantial financial losses or regulatory issues.
Clearly, a two-speed enterprise architecture is necessary, but companies still need to address a fundamental question: Which systems within that architecture need to move faster? To answer this, business and IT leaders need to start with the core business objectives. They must consider how the enterprise architecture supports various business capabilities and adjust technologies, work groups, and processes accordingly. In this approach, technology professionals collaborate closely with business- unit leaders, and technology decisions are aligned with the highest-priority business needs.
Emphasizing business capabilities
So which business capabilities should be fast-tracked within the enterprise architecture? Typically the ones that involve direct interactions with customers and areas where quick changes are required to create competitive advantage. One global bank that successfully implemented a two-speed enterprise architecture determined that, apart from introducing new online applications through which customers could transfer funds or update their personal information, it would need to change the back-end systems that supported the creation or modification of customer data. It wasn’t just the front-end systems that got faster; back-end systems of record needed to become part of the fast architecture, too. The result was a new and improved purchasing experience for customers.
In another example, a retailer wanted to improve the system that managed information about its products. Historically, the data within this system would be updated infrequently; in the parlance of two-speed architecture, it was on the slow track. As the retailer considered how it might launch new options for digital products and services, it realized that some of these offerings would require much faster changes. Product characteristics would have to be updated more frequently, and those changes would have to be recorded and reported differently. The retailer separated its product-information-management system into several modules, each of which could be updated at a different speed.
Working at two speeds
Enterprise architectures, by their very nature, are complex—and so is the process of transforming companies into digital organizations. But by putting capabilities at the center of their decisions about how best to implement a two-speed model, companies may actually bring order and accountability to their digital-transformation programs.
First, the entire digital transformation would be driven by an approach to enterprise-architecture management that explicitly accounts for the trade-offs among different business capabilities.
Second, a two-speed architecture could help companies balance resources more appropriately. Investing in new technologies, software-development approaches, and top development talent can help companies differentiate themselves from competitors. But it may be expensive to do these things across all business units. The very exercise of building a two-speed architecture can help companies set priorities. For instance, there may be a strong business case for speeding up the processes, technologies, and governance associated with application-development and customer-management groups. It might not be as necessary to do the same in the HR, property-management, or legal functions.
Finally, a two-speed architecture can help mitigate risk. In a typical bank, the architecture landscape today often comprises (mostly) legacy platforms, and the majority of staffers are trained on these older platforms. By using a two-speed IT model, instead of deploying a “big bang” approach to change, a bank could carefully stage its migration to new technologies and digital ways of working, thus mitigating its risk of failure. The bank could train employees on new systems or look outside the company for required expertise. And for those employees who are not comfortable with new methods and procedures, there would be an option to continue maintaining traditional, foundational systems—which certainly wouldn’t go away entirely in the midterm.
Two-speed thinking is not new, but with greater awareness and exploration of the method, it is nearing critical mass. Companies across all sectors are considering ways that two-speed enterprise architectures can help them deliver the best possible experiences for their customers. We believe that, to succeed, these companies need to take a capabilities-centered approach to deploying technologies, digitizing processes, and managing governance issues. The businesses that do can work more efficiently, optimize their investments, and ensure that employees are in roles for which they are best suited.