Many CIOs at large incumbents have made a startling discovery about digital natives: those businesses often don’t have architects or at least anyone with the formal title of “enterprise architect.” With CIOs increasingly moving their organizations to an agile DevOps operating model, that discovery has prompted much questioning about whether they still need architects, and if so, what they should be doing.
While incumbents can learn plenty from digital natives and adopt many of their practices, eliminating the architect role shouldn’t be one of them. That’s because digital natives have the benefits of a highly skilled and experienced workforce operating in a start-up culture on a modern architecture with few legacy issues.
Development teams in most incumbent organizations, however, don’t enjoy those benefits. They are used to workarounds such as creating direct point-to-point connections because, for decades, that’s been the only way to get things done. The reality is that most organizations still need architects. In fact, our research with Henley Business School is clear: digital transformations suffer when architects are not involved (Exhibit 1). Technical debt increases, and fewer services are reused.
Expanding the objectives of enterprise architecture
The objectives of, and demands on, enterprise architecture (EA) are changing rapidly as the importance of technology in driving business value increases. The EA function is a core element of the foundation that both enables and accelerates the tech transformation that companies need in order to compete in a digital-first world. In this kind of modern environment, the objectives of the EA team are threefold.
1. Enable strategic decisions
Setting strategic direction has always been an important EA task, but with many companies becoming increasingly digital, it has become a business-level priority. In the past, major failures affected only the IT budget. Now, they affect the entire business. In a typical retail environment, for example, a major flaw in the overall architecture, such as an integration architecture that doesn’t scale well, would lead to a slight increase in IT costs but only a minor impact on the margin. With a substantial portion of sales moving to online channels, however, the same mistake could cause an outage with substantial lost sales.
Similarly, EA decisions, such as where to establish a shared solution across countries or business units and where not to, can have a direct impact on the business’s strategy and operating model. Take the retail world again. When an enterprise architect decides whether checkout and payment functionality is implemented in two systems—the point-of-sale (POS) terminal and the e-commerce system, for example—or one, it is not only a big investment decision with a $100 million price tag, but it also has a massive effect on the operating model and the company’s ability to realize the corporate vision of becoming an omnichannel retailer.
For these reasons, digitally advanced companies create a plan for the future and engage enterprise architects to figure out a system that can enable it (Exhibit 2).
Would you like to learn more about McKinsey Digital?
2. Ensure reusability
In the past, ensuring reusability was mainly a cost consideration, which meant development was generally treated as a one-off. Pilot functions that were developed and tested quickly often became permanent, but they scaled poorly and led to greater technical debt.
In another case, a retail company implemented an algorithm that calculated the final price after all promotional offers into its e-commerce system. The need to support mobile checkouts, however, then led the retailer to decide to build out this feature a second time. With complex and rapidly changing promotion mechanics, this duplication inevitably led to diverging results and therefore to a bad customer experience when the promotion shown online was not identical to the one in the store. EA plays a crucial role in avoiding such outcomes by ensuring that new solutions reuse established functionality. This not only avoids wasting time on reinventing the wheel but also helps ensure a consistent customer experience. Architects should facilitate the discussion between product teams around features and solutions, make it easy to find all features available for reuse, and ensure close alignment with the strategy.
3. Enable development speed
The flexibility and responsiveness of a digital business are severely hampered if those traits aren’t also reflected in the tech foundation layer. This means that enterprise architects need to manage a consistent technology stack that comes as a “batteries included,” ready-to-use platform for new development teams. EA can deliver on this by providing two things: all the technology components that teams need to develop, deploy, and test new functionalities, and a curated set of “patterns”—best practices on how to store data, integrate with other teams, and perform other common tasks in the everyday life of a product team.
The practical changes needed in the enterprise architect’s role
The enterprise architects of a modern tech organization have to operate very differently than they did even three years ago. Rather than being the traditional “protectors of the system,” they need to become much more practical in the way they help IT deliver business value and drive engineering excellence. In our experience, this requires three big shifts.
From technology theorist to pragmatic communicator
Traditionally, enterprise architects needed to be able to translate business needs into IT requirements or figure out how to negotiate a better IT system deal. That’s still important, but now they also need to be able to talk to board members and executive teams about the business implications of technology decisions, particularly around M&A.
If the CEO wants to be able to acquire and divest new companies every year, the enterprise architect needs to explain the system landscape that requires, and in a merger context, what systems to merge and how. If the company invests in a new enterprise resource planning (ERP) system, the enterprise architect should be able to articulate the implications and the effect on the P&L. This level of conversation cannot be based on boxes and diagrams on PowerPoint, which is often the default but a largely theoretical approach. Instead, enterprise architects have to be able to use practical “business” language to communicate and articulate the ROI of architecture decisions and how they contribute to business-outcome key performance indicators. This change is apparent across leading digital incumbents, where EA tends to communicate more at the CXO level than with suppliers and so needs different skills (Exhibit 3).
How to become ‘tech forward’: A technology-transformation approach that works
From system advocate to engineer
In the new world of agile and DevOps, many architects are unhelpful—and sometimes worse. That’s often because their coding knowledge is outdated or based on a theoretical understanding of IT issues, so their advice and recommendations are often wrong. They will, for example, push for innovations in products that are simply not useful to the business or adopt a new user-experience (UX) framework but not have the necessary capabilities to use it correctly.
Instead, they need to think and operate more like engineers. Modern enterprise architects need to be able to speak credibly with operational engineers, for example, about how to decommission systems to reduce technical debt. They have to know how to change code to achieve desired outcomes. Those who think this kind of “get-your-hands-dirty” problem solving and action is beneath them may find their usefulness to the organization dwindling.
In practice, it’s rare to find an enterprise architect who is fluent on both the business and IT sides. But they must, at a minimum, have deep expertise in one and be proficient in the other.
From enforcer to coach
Enterprise architects have been infamous for being a wall of “no” as the enforcers of IT rules and guidelines. There was good reason for that, but with more flexible systems and automation taking over many architecture-related policies, there is no longer the need for “laws” documented on paper. Rather, rules and guidelines need to be integrated into the deployment mechanism. That way, the developer receives feedback and a suggestion for good practices on the respective topic in a timely, helpful way.
This approach reflects the need for modern EA to develop a customer-oriented mindset by supporting colleagues in finding solutions for what they want to achieve. EA can then provide relevant documentation, training support, and clearly defined data products that are reusable by all teams.
Practical steps for a CIO to modernize EA’s role and function
As the foundation of a business’s IT, EA needs to carefully consider undertaking changes. We have seen some companies move too aggressively in freeing their EA function, only to meet with chaos as “agile” teams moved without guidance or coordination. Above all, the changes need to be practical.
Clarify accountabilities
Often it is not clear who is actually accountable for EA objectives. Defining such accountability is an important task for the CIO, but it must be accompanied by a mandate and decision rights so the appropriate leaders can deliver on their responsibilities. The most successful approach puts in place a few strict rules, such as prohibiting any non-service-based communication between teams, rather than propagating a lengthy catalog of rules that are often hard to enforce.
Build an architecture mindset across the company
In most digital-native companies, everyone is either an architect or thinks like one. Incumbents with high digital aspirations need to embed that same mindset by educating the entire company on why good architecture is important and how it can impact the business. That can mean, for example, demonstrating that if the integration architecture of an online store doesn’t work properly, the website will be slow and customers will leave, or clarifying to the board how a root-cause issue in the EA has a substantial impact on the top line.
Nurture soft skills within the architecture team
Architecture teams generally have deep analytical skills and experience developing sophisticated frameworks. What they too often lack, however, are the communications skills needed for stakeholder and change management (Exhibit 4).
Architects need to move away from PowerPoints that emphasize structure and systems to focus instead on understanding the language of business: scenarios, P&L impact, ROI, risk, trade-offs, and so on. These skills require dedicated training and capability-building programs and a greater commitment to partner with the business.
Find new enterprise architects
While training enterprise architects and coaching them to make the necessary shifts can help, in many cases CIOs can accelerate change only by hiring talent with the relevant skill set from the outside. This talent is not easy to find, but the odds of attracting someone good improve when companies understand what the best architects want. They are attracted to interesting problems and making a difference. According to our research with Henley Business School, money, while important, ranks sixth as a motivator for top EA talent. They also want a meaningful role in modernizing IT and decision rights to effect the necessary change—which means CIOs also need to raise the profile of EA: in many organizations, most people don’t know if an enterprise architect even exists.
We have seen on multiple occasions that using an anchor hire, such as an experienced architect who has been working for a leading tech player, can be a catalyst for a technology transformation. These people will typically not only bring their experience in how “things are done the right way” but also have the kind of experience that enables them to have deep technical discussions with developers.
For most companies, EA isn’t going away anytime soon. But by both embracing EA’s role and evolving its skills, companies can make it the bedrock of their tech transformation.
