Enterprise architecture: time to get the business to sit up and take notice

McKinsey's latest advice to enterprise architects who want to overcome organizational inertia and make a difference.
Written by Joe McKendrick, Contributing Writer

The key to attaining running a lean and agile enterprise technology infrastructure is embracing enterprise architecture. However, many organizations still relegate EA teams to peripheral roles while they spend countless dollars, euros, pounds or rupees cobbling together creaky IT infrastructures -- budget sinkholes that just barely deliver.

Photo: HubSpot

Oliver Bossert and Jürgen Laartz, both with McKinsey, just published a list of "10 practical ideas for organizing and managing your enterprise architecture." There's a lot of great guidance in here, and I'll surface some of the most salient points, as they cut to the very core of what enterprise architects and EA proponents should be thinking about in the year ahead.

EAs don't yet have enough leverage in today's enterprises. A thread that weaves its way through many of Bossert and Laartz's ideas is that many organizations may have enterprise architects and EA teams, but don't provide these people the leverage to influence overall IT strategy. If anything, EA tends to remain a "siloed" activity -- even though their roles are to tear down the silos. "Companies should give EA departments more responsibility for certain big-picture decisions -- for instance, approving new IT-related projects or changes to the technology landscape," they point out. To overcome organizational inertia, EA proponents need to identify executives or professionals who can step up to leadership roles and challenge the business to develop a greater vision and cohesion for its information technology strategy.

EA needs to reflect the business. Another theme running through the McKinsey authors' ideas is that EA practices are as varied as the enterprises they are designed to serve, and shouldn't be shoehorned in. It can't be said enough, of course, that EA teams need to work closely with the business, and ultimately, the goals of these efforts are about advancing the business versus implementing technology just because it may be shiny new cool stuff. In addition, the organization of EA teams themselves need to be in tune with the business organization. For example, an organization with disparate businesses -- supporting both manufacturing and retail, for instance -- may require separate EA teams and approaches. At the same time, there should be clear lines of accountability for EA teams, such as "giving the chief architect in the EA department the final decision on and accountability for any changes relating to technology standards."

EA can be a great career path for both IT and business professionals. This is especially the case in organizations that fully embrace EA, with opportunities to weave technology and business thinking together to build digital enterprises. This becomes a self-fulfilling cycle, Bossert and Laartz point out. "Greater responsibility may help the EA group attract the operations and leadership talent it needs to design and support IT systems effectively," they point out. "For many EA staffers, being seen as a valuable contributor to the bottom line may be more of an incentive than receiving incremental monetary rewards."

EA activities, like everything else, need to be measured. This is more difficult than measuring the results of a single IT initiative. EA is similar to acting as conductor to an orchestra, with many different sections -- strings, horns, drums, and so forth -- playing a key role in producing the beautiful music. EA touches many IT projects, as well as the related activities of business units.The McKinsey suggest starting small and simple, "using business-specific metrics that account for interdependencies--for instance, how many applications and how many point-to-point interfaces are involved in the project, how many applications are demonstrating overlapping functionally, what portion of the overall application-development effort is dedicated to integration testing, and whether management tasks are easier and less costly as a result of the pilot project." These proof points can then be presented across the business to continue the EA effort across the enterprise.

Editorial standards