The Evolution of the Organizational Architect

After nearly two decades, technologists and strategists are still working out a productive alliance in the business world. Many companies accept that information technology enables their competitive edge, but their efforts to partner it with business are failing. A critical disconnect persists between strategy and technology, which is why a company can spend years planning IT initiatives and implement only half of them. Or why a bank can outsource its failing IT function in the mid-1990s and still be unhappy years later when IT has improved but its business processes have stagnated.

Part of the problem is that strategy has become a moving target — it’s hard to build a technology platform to support visions based on capabilities a company might have. To explore exactly how difficult it is, we surveyed chief executive officers and chief information officers at 97 companies in the United States, Europe and Australia that had moved or were moving to e-business.1 Predictably, most were responding to an increasingly volatile business environment by shrinking their development and planning cycles. Half don’t extend plans beyond a year, and half of those with infrastructure plans update them quarterly. Some companies prefer to keep even short-term planning loose, calling themselves “managers of change” or “providers of project solutions.”

The shifting competitive landscape is creating a larger gap between strategists and technologists. Executives are busy creating and refining visions and have little time to focus on technology. Technologists are busy keeping the platform current and have little time to understand the business in depth. Said one IT consultant, “These guys have a great vision, good infrastructure, useful information and strong operational systems. Now how do we get them to understand what it all means?”

Without a mechanism to force communication, each group retreats into its specialty — a state worsened by outsourcing. As one senior manager remarked, “We tell them [the supplier] what we want, and we get exactly that technically, but that’s all we get. What we really want is a dialogue about our changing needs.”

The widespread frustration with traditional attempts to align business and technology seems to argue for a greater organizational transformation. Companies we surveyed agreed that e-business strategy is a moving target and that IT planning cannot keep pace. They even agreed that the best solution was a flexible, integrated platform — one designed to accommodate the business vision and give the widest range of competitive freedom. The sticking point for most companies was how to get business executives and technologists to agree on what the vision required.

Many companies wrongly assumed that strategists and technologists would talk to one another or that one side, typically IT, would take on the alignment. The IT director of a large utility company commented, “The company wants to pursue e-commerce, but I can’t get anyone to articulate what the e-commerce model will look like in two to three years.” Strategists, on the other hand, wanted IT to provide critical links to business partners but offered no project governance to enable those links. Managers wanted IT to update the technology infrastructure, yet retain the old applications. Extra meetings to bring the two sides closer resulted in overload. Commented one senior executive, “Now I have to be a technologist, and listen to them talk technology on top of my day job.” In a multinational chemical firm, business-unit CIOs were being dragged into operational “emergencies” rather than helping establish, coordinate and lead strategic options.

Some companies looked to the CEO or CIO to bridge interests, but rarely did either role have the right combination of skills and mind-set. The “believer” CEO, who sees IT as central to business management, was rare.2 Even a CIO who had the trust of the CEO’s inner circle typically had a shallow understanding of organizational design.

Finally, a few companies believed they shouldn’t even try to prepare for change, but rather should handle developments as they occur. Typically, this approach resulted in a high level of frustration. (See “The Cost of Short-Term Reaction to Change.”)

Among companies that were successfully aligning business and technology, we identified a series of bridging activities that amounted to the creation of what we call the organizational architect, someone who is neither all strategist nor all technologist, who guides the translation of a strategic vision to a flexible, integrated platform. Organizational architects sustain a dialogue between visionaries and technologists as they define and design the right combination of structures, processes, capabilities and technologies — one that has a greater chance of being responsive to the organization’s goals. Thus, true synergy becomes possible: The platform is shaped by the vision and the vision is reshaped by the characteristics of the platform that enable the vision.

What an Organizational Architect Does

Organizational architects work with both strategists and technologists to identify and grow the organizational and technical capabilities needed to see a vision through to its supporting platform. The architect must be someone other than a CEO or CIO, but the support of key executives is critical, and the architect must be trusted by the CEO’s inner circle. Someone who has directed a strategic change is a good candidate as an organizational architect. A strategy director could become an architect, but only after spending some time with technologists to gain a deeper knowledge of platform issues.

The architect sees the vision through three main translation phases. (See “How a Business Vision Translates to a Flexible Platform.”) The activities involved in each phase are far from sequential, involving substantial amounts of reviewing, revising, negotiating and iterating.

Phase 1: From Vision to Organization

In a hypothetical case, suppose a retail bank has the vision “Be our customers’ trusted partner.” (See “Translating a Retail Bank’s Strategic Vision.”) After iterative questioning, the organizational architect makes the vision more concrete: “Become our customers’ sole provider of banking and financial services by simplifying their lives.” Being customers’ “sole provider” implies a focus on relationship management. “Simplifying their lives” could mean consolidating all accounts and providing the customer with a single, personalized proposal annually. The architect discusses the vision with the CEO’s inner circle, and they decide to emphasize the customer relationship over simplification.

The organizational architect then sets design parameters for the organizational structures, processes and capabilities that make the vision possible. Relationship management is seen as core and therefore stable, so the architect designs a structure that is based on customer segments, which the bank will manage differently according to its profitability. To reinforce customer trust, the bank will need to measure, monitor and evaluate its processes. Profitability comes from selling to established customers, so the architect designs an organization that supports cross-selling.

The next step is to identify the parts of the vision in which flexibility is critical. One is customer segments, which will change as the bank learns which customers generate the most profit. The bank needs some way to learn about and model customer behaviors and swap customers and services among business units. It also wants to remain flexible about how it will supply products. It could develop all its own investment and insurance products. It could act as an intermediary for other companies’ branded products. It could rebrand those products as its own. The organization must therefore accommodate both new product development and product sourcing.

At that point, the architect either moves to the next translation or pushes back issues that could make it hard to realize the vision. If the bank has no experience buying financial products, it could grow the capability in-house over three years or it could acquire it. The architect identifies a trade-off between the benefits of getting the capability quickly and the challenges of an acquisition, which he or she presents to the CEO’s inner circle.

Phase 2: From Organization to Technology Requirements

The architect now works to map the bank’s organizational needs to platform characteristics. The core organizational requirements can be dealt with straightforwardly. The customer-centered design implies a single portal for all customer information for all channels, the ability to track all contacts with customers and an efficient process from initial customer contact to product/ service delivery.

The bigger challenge is to define the technology required for the organizational flexibility identified in Phase 1. The platform must support not only the creation and maintenance of home-grown products but also connections to financial services companies that already have the products. If the bank decides to acquire product sourcing, the platform must make it easier to absorb and integrate other systems, perhaps by adopting standard technologies. However, if the bank wants to improve its own product-development capability and time to market, it will need the right combination of component and reusable technologies; rapid development skills and tools; management processes for tightly defined, short projects; and relationships with responsive IT suppliers.

Phase 3: From Technology Requirements to Actual Platform

The architect is now ready to get a fix on reality by talking with technology experts about what they can actually do. The starting point for this dialogue is the existing technology, which at worst could be a collection of point solutions, a hybrid of partially built systems and facilities, or at best a custom-built or installed platform.

Consider that the bank has a hybrid platform with a unified customer database for all savings and investment accounts. Suppose also that the technologists say that at a modest cost they can extend the database to incorporate loans and mortgages, but that they cannot integrate customers for all other financial products without a major platform update. They are confident they can build a new platform to support the required organizational flexibility, but to support product sourcing they must use unproven security technology.

Given that input, the organizational architect identifies two options. The first is to install a new customer-centered platform with innovative integration, which is extremely risky. The second is to consolidate the platform for banking, retain a separate platform for insurance and investment products, and build integration. That creates an organization that is flexible (it can deliver the best product to the right person) and safe (the structure keeps banking products separate from other offerings).

To refine the vision against what’s achievable, the architect feeds all the choices back to the CEO’s inner circle. Because they are aware that the bank has limited experience cross-selling other financial products on top of its banking services, the executives decide to exercise the second option. By retaining the bank’s core business, they reassert the “trust” part of the original vision, plus they can fence off insurance cross-selling and thus manage any risk associated with their lack of expertise. They can retain more radical ideas, such as offering physical security and legal services, because the secondary platform isolates any risk to the core banking service. The clincher is the extra flexibility provided by the organizational structure and platform, which would let them easily float or sell off the non-banking businesses or add acquired businesses.

Partnership Principles

Although no company had an organizational architect that was performing the exact tasks outlined in our scenario, we saw several “naturals” — leaders of high-tech companies or unusually business-savvy CIOs — who were following similar principles. The most advanced practice is within the IT industry, where senior executives typically understand how strategy, organization and technology interrelate. Two noteworthy examples are Larry Ellison, CEO of Oracle, and Gail Burke, COO of Macquarie Bank, an Australian investment bank.

Several other companies, notably high-tech startup travelstore.com and Melbourne utility CitiPower, have bridging mechanisms similar to that of an organizational architect. Many others — IBM, Electrocomponents, Lloyds TSB, Tesco, Hewlett-Packard, Siemens, Deutsche Bank, Entertainment UK and, most obviously, Charles Schwab — acknowledged that a closer technology-organization partnership was needed to get more return from their technology investment.

From these companies, we identified a common set of principles that are fundamental to an organizational architect’s success.

View Technology and Organization as Equal Influences

Oracle’s adoption of a single e-business platform combined with its centralization of business-support functions is an outstanding example of treating technology and organization as equal sources of flexibility.

Ellison established three tenets. Use a single-instance infrastructure. Instead of having a distinct system and database for every business process in every country, he opted for a single global version of each Oracle application system and each database. Put the Web first. Oracle makes the first implementation of every application Web-enabled so that employees and customers have immediate access. Consolidate both organizationally and technologically. Oracle created a global operations infrastructure based on four shared service centers located in different time zones to provide common, 24-hour availability worldwide, and the company consolidated IT and marketing functions at the center.

Through these processes, Ellison built an organization and platform that will give Oracle considerable flexibility to compete on a wider scale than it does now. The platform eliminates duplication and intensifies the use of self-service. Ellison has been able to simplify the product by streamlining licensing contracts, for example. With global marketing, he can communicate his message nearly effortlessly.

Many companies are encouraging their key technologists to add some business skills to their expertise. Macquarie’s infrastructure team focuses on developing staff who understand the company’s business, culture and environment. The bank’s use of divisional account teams has helped it understand the precise business focus needed to develop forward-looking platforms.

Other companies opt to recruit the right combination of skills. CitiPower’s CIO, Gill Lithgow, faced with the challenge of creating a platform to support unspecified e-business futures, hires only people who have capabilities in at least two of three areas — operations, implementation and strategy — and who are “outward looking and technically aware.” Phil Smith, CIO at Royal & SunAlliance, an insurance provider, thought those involved in creating future business flexibility should be “chameleons with cast-iron skins” — comfortable in technical and business contexts but inured to the hostility of conservatives in both. Utility Thames Water goes further. Its innovation unit combines key executives with technology architects, who experiment with and roll out new customer-focused technologies. By colocating innovation architects with those who build the operational platform, Thames Water helps ensure that business innovation pays off.

Standardize and Centralize

The ability to operate across organizational boundaries is proving essential to flexibility. At a minimum it requires some standardization and central control. When Oracle consolidated its applications and collapsed its 140 product and pricing databases, 70 human-resources databases and 97 e-mail databases into single global versions of each, it simultaneously centralized IT management. Had it not done so, regional managers would have been tempted to undermine the platform with local systems.

Most multinational corporations striving to globalize without an organizational architect have gone overboard by extensively centralizing and standardizing operations whether they needed to or not. When cost was the driver, consolidation and standardization were key technology requirements. When customer demand was the driver, a common face to the customer and sufficient back-office integration were more important. IBM’s global procurement initiative was a rare example of balance. Because IBM evolved the initiative from clear objectives within a defined scope, the company was able to make just the necessary organizational and technology changes.

Macquarie proves that the whole business need not be centralized so long as there is some central oversight of core technologies. The bank operates some 40 distinct but closely related business divisions organized into seven groups. According to one division director, it is “almost a federation of entrepreneurs that trade under the Macquarie name.” Through the 1990s, Burke, the CIO before taking over retail operations, worked to maintain a platform that would free the divisions to pursue their individual agendas. Her concern was as much for cost as for flexibility and cross-business synergies. By 1999, limitations were revealed in this previously successful platform — lower availability, performance, scalability, responsiveness to business change, flexibility of cost structure and speed of deployment. The limitations were glaring in light of Macquarie’s rising need to accommodate growth, change and speed in its strategic planning. The challenge, according to Liam Edwards, head of the company’s infrastructure team, was to “change the tablecloth without disturbing the cutlery.”

Macquarie already had a powerful central infrastructure team — a third of the bank’s 700 IT staff — so it was used to strong leadership in establishing a common platform. It was also used to standardization being driven by business issues rather than being for its own sake. As Edwards pointed out, “Infrastructure as a unit is becoming more important. … Every channel to market now depends on the way technology works.”

At CitiPower, Lithgow created a Program Office to ensure that all active projects were standardized on his e-business blueprint and that they served key business objectives. (See “Organizational Architecture at CitiPower.”) Lithgow summarized his reasoning in January 1999, when he was appointed CIO: “As an organization we have to become incredibly flexible, while at the same time getting a new identity and culture and supporting that with tools and capability.” In March 1999, he began building an organizational blueprint and technical and process capability that enabled e-business —even before knowing many of the applications.

For Lithgow, the blueprint is indivisible because every action, no matter how small, affects something else. If a customer changes her address, it affects the customer relationship (billing and payment), sales and marketing (offering future services), metering, contracts and settlements, and so on.

Manage Change Intelligently

It is not enough simply to recognize the importance of partnering organization and technology or even to standardize and centralize. Companies must also create the right drivers for change so that everyone will accept the organizational change that, in turn, helps a platform succeed. Ellison changed the way Oracle measured its national directors’ performance so that they would be more cost-conscious. At the same time, he offered the services of the unified infrastructure at no charge to the directors’ cost line so that the director would be motivated to adopt the new infrastructure.

It would have been easy for IBM to take a strictly technical approach in adopting a self-service platform for its internal processes, but more than five years of reengineering general procurement had taught it the importance of restructuring, redesigning roles and responsibilities, retraining and communicating extensively.

Most companies understand that change management must follow the evolution of the vision and platform, or even the most superbly designed infrastructure can become disconnected from the business end. Macquarie illustrates that prolonged balancing act, having perhaps one of the longest and most substantial track records in evolving its IT platform. In the 1990s its focus had been on cost management. By the end of the decade, the business wanted more freedom to pursue strategic options. Its infrastructure update now supports new mission-critical initiatives. Burke made this possible by convincing Macquarie to create a common platform and establish the staff and processes to manage it centrally. That groundwork enables Macquarie to remain flexible and change as the platform evolves.

Match Capability and Ambition

Oracle is unusual in its ability to deliver a complete vision. More often, either the organization or technology can be serious impediments that an organizational architect must change or work around. Many ambitions are simply not achievable.

A global distributor, having established itself as an e-business, with its award-winning catalog site, attacked the buy-side of its business. It set up a global procurement unit, but then found it lacked the necessary common technology. Thinking carefully about its fragmented infrastructure and the reasons for it, the distributor decided against a single global enterprise resource-planning (ERP) package and opted for regional packages integrated across three platforms. It was still able to benefit from aggregated purchasing within each region. The solution, while not ideal as in the global package, was still better than the status quo.

At travelstore.com, founder Darryl Mattocks described his nirvana as a business process with “no human intervention whatsoever.” However, he soon discovered that he could not easily interconnect his systems to those of the global distribution system providers and so could not provide a fully automated process from inquiry through reservation, itinerary generation and payment. The company scaled back its ambition and accepted that some parts of the business should remain manual.

Still, some technology attributes may enlarge the ambition. A funds management company recognized that it could separate its technology systems enough to support an independent business that could sell its administration services. The potential for shedding its back office helped clarify the company’s vision as an asset manager and innovative developer of funds-management products.

The existing technology is the starting point for realizing any vision. (See “How Existing Technology Affects Future Flexibility.”) In the worst case, which is still common, the existing technology is a collection of point solutions. Integration is through point-to-point connections that are expensive to build or change and are unreliable. Thus, the company must accommodate any new initiative independently of existing solutions and rarely achieves the desired business synergies within a reasonable budget or time.

If a company with this enemy within platform is serious about having a prepared response to strategic options, it must start from scratch. The benefit is a clean slate; the drawbacks are cost, time and risk. The organizational architect has to balance between sticking with a reactive approach based on technology that becomes increasingly complex and inflexible and riding the risk-return potential of a new platform.

In the best case, the existing technology is a coherent platform that’s either flexible (custom-built) or dependent (installed to support an already integrated suite of ERP applications). The organizational architect must understand the enablers and constraints. In ERP, for example, the software vendor helps ensure that the system stays current by offering periodic upgrades. Applications typically grow toward customer-relationship management and supply-chain management. Technology growth generally involves innovations, such as Web and mobile implementations and object orientation. Although ERP is coherent and integrated, if it is tied to the organization’s structure when it is installed, it becomes structurally inflexible: As one CIO described it, “ERP is like pouring wet concrete over your organization — restructuring means reimplementing [the package].” The organizational architect and technologists must discuss the trade-offs between what the technology can and can’t do and the feasibility, time, cost and risk of extending it.

Between the best and worst cases is the patchwork platform, composed of partially built systems and facilities linked through an integration strategy. These platforms are the hardest to understand because they are idiosyncratic. Often the technologists cannot tell anyone how flexible they are without specific examples, and the organizational architect must resort to scenarios in talking about platform capabilities.

Investing for the Long Term

“Business leaders of the future will be technology architects,” pronounced the head of one of the companies we surveyed — a $1.5 billion business. We agree that business leaders must pursue flexible platforms, but we disagree that business leaders should become technologists. Even leaders now acting as organizational architects, the Ellisons and Burkes, must eventually hand their mantles to others. Organizational architects have distinct skills that complement and complete the skills of CEOs and CIOs and overlap core IT capabilities.3 Forward-thinking companies —those that want to avoid technology development driven by short-term imperatives — already have roles akin to an organizational architect. Others agree that such a capability is necessary.

If organizational architects are inevitable, and we believe they are, it makes sense to plan for the role rather than just stumble into it. The logical first step is to assign the responsibility to a very senior manager who has seen it all and is well respected throughout the organization. The new organizational architect in turn will begin to assemble and train people from within and outside the company to take over the role. We have seen this kind of development process succeed in a multinational manufacturer. We have also seen a financial services CIO take on the role and then cede the work to several people on both the business and IT sides.

An organizational architect is a significant investment for a business, so it will be important to underwrite the position even though it is essentially a staff function with no immediately visible commercial benefits. Persistence will be required particularly in difficult economic times. It is always easy to ax such investments on the grounds that to have a future, you must survive the present. However, if companies make inappropriate technology decisions while in survival mode, they may find that the future has suddenly become irrelevant.