Archives

Management

Now this is a roadmap…

So True…

Had this emailed to me from McKinsey newsletter, it is very true. Enjoy.

 

Five enterprise-architecture practices that add value to digital transformations

Enterprise-architecture teams can play an integral role in transforming companies with technologies. New survey findings and firsthand experience highlight the practices that matter most.

What does it take for traditional companies to create value with digital technology? McKinsey research suggests that successful digital reinventors—digital natives and digitally transformed incumbents—employ a range of approaches, such as investing boldly and adopting cutting-edge technologies at scale. Efforts like these can run into various difficulties, though. In our experience, a push to launch more digital applications can make a company’s technology landscape increasingly complex and difficult to manage, to the point that it impedes transformation programs.

Things don’t have to be this way. A new survey by McKinsey and Henley Business School highlights the need for enterprise architects to facilitate digital transformations by managing technological complexity and setting a course for the development of their companies’ IT landscape. These responsibilities fall within the typical enterprise-architecture (EA) team’s remit, which is to manage the way that all of the company’s IT systems work together to enable business processes. But not all EA teams carry out their responsibilities in the same manner. Survey respondents who described their companies as “digital leaders” indicated that their EA teams adhere to several best practices (see sidebar, “About the survey”). These teams engage senior executives and boards and spend extra time on long-term planning. They track their accomplishments in terms of how many business capabilities are deployed, while implementing more services. And they attract talent primarily by offering people appealing assignments, ample training opportunities, and well-structured career paths. Below, we take a closer look at these best practices and their benefits.

1. Engage top executives in key decisions

A number of EA teams we know have helped accelerate their companies’ digital transformations by participating in discussions of business strategy, which deal increasingly with technology. When we asked survey respondents about their involvement with various stakeholder groups, 60 percent of those at digital leaders named C-suite executives and strategy departments as the stakeholders they interact with most. By comparison, just 24 percent of respondents from other companies said they interact most with C-suite executives and strategy departments.

2. Emphasize strategic planning

The survey results also indicate that EA teams at digital leaders maintain a clearer orientation toward the future than teams at other companies. One hundred percent of respondents from digital leaders said their architecture teams develop and update models of what the business’s IT architecture should look like in the future; just 58 percent of respondents from other companies said they adhere to this best practice.

Another key difference emerged when we asked respondents how much time their companies devote to strategic planning. Respondents who said their companies’ EA teams devote a higher-than-average proportion of their capacity to strategic planning were also more likely to say they create added value for their organizations. (On average, respondents said strategic planning takes up about one-fifth of the EA team’s working capacity.) Teams that spend more capacity than average on strategic planning were more likely to report delivering sustainable business solutions, making greater contributions to the benefits of projects, and gaining wider recognition within the enterprise.

Given the versatility of enterprise architects, leaders may be tempted to assign them to help resolve urgent problems of various kinds. However, this can cause the architecture team to spend most of its time solving problems and little or no time on advance planning. As a result, the drive to quickly fulfill demand for particular applications takes precedence over the thoughtful design process that is required to maintain a cost effective, flexible, and resilient IT environment.

3. Focus on business outcomes

At a high level, digital transformation involves reshaping business models with advanced technology solutions. This puts a premium on collaboration between business functions and IT. In our experience, a lack of coordination between business and IT hinders large transformations. We have seen that such disconnects sometimes originate in the posture of IT functions: instead of concentrating on the enablement of business priorities, they focus excessively on the delivery of technology solutions as an end in itself.

According to our survey, EA teams at digital leaders appear to avoid this trap. Respondents from digital leaders were more likely to say that EA teams contribute “high” or “very high” benefits to business and IT.

4. Use capabilities to connect business and IT

We’ve seen that an EA team can better align the IT function’s priorities with the business’s priorities by tracking its accomplishments with respect to the business capabilities that it delivers, rather than the sheer number of technology applications that it implements. Capabilities are self-contained business activities, usually belonging to an end-to-end business process, that result in discrete outcomes: for example, predicting a customer’s next purchase so that a website or a call-center representative can make suggestions.

This use of capabilities stood out in the survey. Respondents from digital leaders were more likely to say that their EA teams use capabilities as their primary grouping for the delivery of milestones toward their target architecture. Further grouping capabilities into business domains (which generally correspond to business functionalities such as finance or customer management) can have the additional benefit of allowing an EA team to shape the IT landscape according to the business strategy.

The survey results show that digital leaders are also distinguished by how they structure their IT landscape. Digital leaders have implemented three times as many services as other companies. When it comes to integrating applications, a smaller proportion of their integrations consist of point-to-point connections between two applications (56 percent versus 76 percent at other companies), which lessens their “technical debt.” Respondents from digital leaders were twice as likely as respondents from other companies to say that their companies are piloting architectures based on microservices, which are independent components that developers assemble into software applications.

5. Develop and retain high-caliber talent

Because EA departments play an important role in digital transformations, we’ve seen that IT leaders do well to staff them with motivated, highly skilled professionals. Yet our experience also suggests that enterprise architecture’s long-held reputation as a mundane field with limited room for advancement can create challenges when it comes to attracting top talent.

The good news is that prospective hires appear to be drawn toward exciting work that offers opportunities to learn and grow. Our survey results indicate that enterprise architects generally seek interesting challenges, recognition from their peers, learning opportunities, and structured career paths. Respondents from digital leaders were more likely to cite peer recognition, education, and well-defined career paths as features that appeal to their employees. They were also more likely to say that they offer enterprise architects the chance to pursue career paths in departments other than enterprise architecture.

Capturing the opportunity for enterprise architecture

For EA teams, supporting successful digital transformations involves more than implementing well-chosen technology solutions. It requires an operating model that aligns governance, processes, and talent models with the business’s needs and promotes effective collaboration between business and IT. The survey findings, along with our experience in enterprise architecture, suggests that four moves can help EA teams advance their companies’ digital transformations:

  • Translate architecture issues into terms that senior executives will understand. Enterprise architects can promote closer alignment between business and IT by helping to translate architecture issues for business leaders and managers who aren’t technology savvy. Engaging senior management in discussions about enterprise architecture requires management to dedicate time and actively work on technology topics. It also requires the EA team to explain technology matters in terms that business leaders can relate to.
  • Draw capability maps to link IT priorities with business needs. Capability maps appear to be effective communication aids for enterprise architects: respondents from digital leaders were more likely to report using capability maps (80 percent) than respondents from other companies (38 percent). Focusing on business processes can lead companies to end up with multiple systems that perform similar functions, such as customer-relationship management. Concentrating too much on technology can cause EA teams to organize their work around building applications rather than enabling the business.
  • Start with a clear target architecture and strategy. Digital leaders spend more time on planning the future and building a strategy to achieve it. EA departments also need to balance their long-term planning activities with meeting the business’s day-to-day demands.
  • Provide training that helps enterprise architects to succeed. The enterprise architect of tomorrow needs similar skills to those of his colleagues on the business side: communication, coaching, problem solving. Without these skills, architects won’t be able to bridge business and IT perspectives. Companies can revise their training programs and development paths so they place greater emphasis on business and management acumen.

With these tactics, EA teams can build stronger working relationships with senior executives and managers—and thereby position themselves as strategic partners in their companies’ digital transformations. Source here.

Two Speed IT…

Is the concept of two-speed IT over, possibly even before it got started? This article seems to think so…

Back in 2012, as established companies began to make a serious push into digital, BCG advocated a concept known as “two speed IT.” It was something of a compromise—a very necessary one. If IT organizations were going to support digital initiatives, they needed to work in faster, more flexible, more collaborative ways. Yet management often viewed these methods—based on principles set out in 2001 in the Agile Manifesto—as untested and maybe even a bit wonky. Two-speed IT was a way of saying, Don’t worry: you can use the new techniques for new areas like digital, and the traditional approach for mission-critical core functions.

It was a good idea at the time, but times have changed. Today, two-speed IT is a compromise that companies can no longer afford to make. The future of IT is one speed: all-agile. That’s not just because agile has proved itself at countless startups and major technology companies—and for all types of software development, digital and nondigital alike. It’s not just because agile’s footprint is expanding to industries like banking and insurance. (See “Ensuring Digital Readiness in Financial Services,” BCG article, April 2016.) And it’s not just because today’s companies can draw on fleshed-out playbooks when implementing agile. (See “Five Secrets to Scaling Up Agile,” BCG article, February 2016.) More than anything, it’s because two-speed IT creates—or will create—significant challenges for companies that continue to employ it.

Two-speed IT was a great intermediate stage, but it is not a long-term solution. And its term is up.

The Problems with Two-Speed IT

With its iterative development cycles, multidisciplinary teams, and continuous testing, agile represents a sea change from the traditional “waterfall” approach, where development flows sequentially from conception to testing and where separate teams take over at each phase. The differences between the models—and the processes, culture, and even mindset they require—make the appeal of two-speed IT easy to understand. But operating at two speeds, we have observed, creates three problems.

It’s harder to attract and retain talent. Recruiting and developing top-tier talent are perhaps the most important challenges  that CIOs face today. You can’t do great things without great people. But two-speed IT puts companies at a significant disadvantage in the war for talent. The organization is effectively split into two parts—each with its distinct, and inevitable, culture. There is the “fast” group, which is seen as doing all the exciting, cutting-edge work. And there is the “slow” group, which is viewed as doing the staid and traditional work. The dinosaur projects. The dull stuff.

It’s not hard to guess which group everyone wants to join. This causes a problem because having top talent in the slower group is particularly important. Here is where the hard challenges of transforming legacy systems are tackled—and where the larger part of IT spending still goes. But when people see themselves as stuck in the slow group with no chance to switch sides, they’ll look for opportunities elsewhere.

Two-speed IT, we are seeing, leads to talent drain. It also makes it harder to hire talent. Today’s digital generation looks for—and expects—a workplace that emphasizes the flexibility, cooperation, and adaptability that are hallmarks of agile.

It leads to “hurry up and wait.” In today’s IT environment, fast-moving agile initiatives increasingly rely on core and legacy systems. Consider, for example, a digital front end that links to a back-end platform. In such a case, two-speed IT means slamming on the brakes. Fast-moving projects will often run up against—and be delayed by—slow traditional test-and-release cycles. What could have been running tomorrow is now set to run after the summer—maybe. This “slowest common denominator” issue is becoming increasingly problematic as digital applications become more central to business and must interact closely with core systems.

It keeps the larger organization from realizing the benefits of agile. Within many two-speed companies, there is a well-entrenched notion that, changed world or not, the more methodical waterfall approach is still better suited for legacy and very large projects. But it’s not. Large projects are particularly susceptible to delays and rising costs, and tend to have very low success rates. Part of the problem is that testing comes only at the end of the process, so errors are found late in the game, when fixes become time-consuming, difficult, and expensive. Agile, with its iterative cycles and continuous testing, finds and corrects errors as development progresses. There is no last-minute—and nightmarish—back-to-the-drawing-board scenario.

The waterfall approach works well when the goal is fixed—if you know, for instance, that you need to build a bridge across a river. But in today’s IT realm, fixed goals are the exception. Whether it is a digital front end or a core business system, requirements change frequently because of customer feedback, competitors’ moves, evolving regulatory environments, and alterations made to associated systems.

Agile-related processes incorporate change better than waterfall methods do because they were designed to incorporate change. This adaptability is something the entire IT organization—not just part of it—needs to benefit from.

In a world where customers have more choices than ever before, the ability to develop core systems faster and more flexibly is crucial. To quote Peter Jacobs, the CIO of ING Bank Netherlands: “I would rather work agile at my core bank system than at the channels.”

Making All-Agile Work

While a single speed can “spread the wealth” of agile throughout the IT organization—and beat back the challenges that two speeds create—the model won’t work without the support and commitment of senior leaders. They can mobilize the troops and help steer—and, when necessary, push—the initiatives and changes that will ease the move to all-agile. A number of steps, we’ve found, are particularly crucial.

Identify and empower agile champions. Two-speed IT has helped companies get agile up and running in part of their organization. The experience and talent already developed can be harnessed to spread agile concepts—and knowledge—throughout IT. The most enthusiastic and communicative agile team members can serve as mentors to those just getting started—providing insights on what works, what doesn’t work, and how to do things better.

Create the right technical environment. Legacy systems are not a deal breaker for agile. Indeed, agile’s main principles can be translated to work on any project, and industries that still rely heavily on legacy applications and infrastructure—such as banking, insurance, and aerospace—have already started to embrace, and benefit from, agile.

But there are modern technologies and practices that can make the agile approach more effective. A decoupled architecture—in which applications, infrastructure, and data interact with one another through standardized interfaces like APIs and microservices—allows teams to work more independently of one another. Now they’re in control of their own development speed (and if one service breaks, just that service is down—not the whole system). Companies can also increase speed and efficiency—often dramatically—by combining agile with techniques like continuous delivery and continuous deployment of applications. This reduces the manual tasks—and the resources—required. Companies should be taking these steps anyway to improve their responsiveness and accelerate their digital transformation.

Implement agile in an agile way. A large established company is likely to implement agile very differently than a startup will. After all, bigger, older organizations must account for the layers of processes and hierarchy developed over the years. Similarly, agile will take different forms even within a single organization. Whereas one team may find two-week sprints optimal, another may determine that four or six weeks work better. Agile on a legacy mainframe, meanwhile, won’t look the same as agile on a mobile shopping app. And because some projects, like a major enterprise-resource-planning transformation, won’t lend themselves to going live in little pieces, agile may mean releasing code to the testing environment—but not the production environment—every day. Agile is a flexible set of principles, not a rigid doctrine. It should be implemented in that spirit.

Offer incentives to middle management. Agile changes the role of middle managers. Eventually, many of the coordinating tasks that have historically fallen to them will disappear. In agile, managers are much closer to the content and the technologies. While they still have some traditional managerial responsibilities, like recruiting and evaluations, they now work in the teams themselves. And on these teams, they are equal to every other member—serving, for example, as a fellow developer. Instead of instructing others, they work as coaches and advisors.

Given these shifts, it’s easy to understand why middle managers would resist the migration to agile: they can see themselves losing control and power. How to avoid this perception? One way is to start getting these managers closer to the front—in both body and mindset—through education, training, and participation in agile conferences and the agile community. KPIs used in measuring a manager’s performance should be tweaked as well. They should encourage the quick development and deployment of features but also tolerate some failures as long as the overall system stays stable. This is much more in line with how agile works.

Develop a digital culture. Migrations from two-speed to all-agile IT won’t happen overnight. And with the war for talent continuing, it’s important to send a message—to current and prospective employees—that agile and the workplace it creates are the company’s future. Hackathons—marathon sessions where teams compete to develop software and even hardware—have been used to foster a fast-moving “think outside the box” culture. (In fact, Facebook’s ubiquitous “like” button traces back to a company hackathon.) The idea is to take steps that let technology experts know that they can stay—and succeed—as technology experts; that, contrary to the old days and the old ways, they don’t need to take a managerial position to make a career at the company.

Establish joint business and IT teams. One of the hallmarks of agile is the cross-functional team, in which members representing the business and IT work together. Migrating to agile means breaking down organizational barriers and fostering communication and collaboration across once-isolated domains. (See The Power of People in Digital Banking Transformation, BCG Focus, November 2015.) Flexibility is crucial here, too. A key tenet of agile is that someone from the business side serve as the “product owner.” But for IT4IT products and tools, such as telepresence, it will make more sense for this owner to come from IT. Once again, the experience and practices already developed on the agile side of two-speed IT can prove invaluable.

Taking Agile Even Further

Unlike two-speed IT, the all-agile model is a long-term solution—and not only for the IT organization. Think about the main principles of agile: short iterations that enable teams to quickly spot errors and react to changes; collaboration in multidisciplinary teams; and progress that remains visible—and tested—as work continues. These are principles that can be utilized to great effect throughout a company, increasing its responsiveness to customers and competitors alike.

Already, we are seeing agile move beyond IT into areas such as product management and marketing, and functions that include human resources and risk management. (See The Agile Marketing Organization, BCG Focus, October 2015.) Spotify and ING are notable examples of companies that are bringing an agile style of working to IT and the business alike. (See “Building a Cutting-Edge Banking IT Function: An Interview with Ron van Kemenade, the CIO of ING Bank,” BCG article, December 2015.)

Today’s businesses are under mounting pressure to get products to market and systems deployed while minimizing risk and delay. Two-speed IT was an important step in gaining experience in new and better ways to do this. Now it’s time to take the next step. A return to a single speed—one based on agile principles—will improve efficiency and outcomes across all technology delivery and, ultimately, across the company. The result: better experiences for customers—and a competitive edge for the business.