week 1-3 635 harsha

ContentServer3.pdf

Home >Information Systems homework help >week 1-3 635 harsha

December 2015 (14:4) | MIS Quarterly Executive 195

Executive Summary Chubb’s enterprise architecture (EA)

has evolved considerably since it was reported in this journal in 2012.1 The need to continually adapt to changing technologies and demands can make a solution that worked well a few years ago unsuitable for the current business climate. Chubb moved from a difficult to enforce federated model to consistent centralized standards and shared services to enable the digital organization it sought. To make the transition, Chubb selected a leader with management and leadership skills rather than technical expertise. The major components of the new EA are target architecture and EA practice. The target architecture ,consisting of architecture principles, architecture governance, conceptual reference architectures, and emerging technology, is designed to maximize integration. EA Practice oversees five domain disciplines: IT Strategy and Governance, Application, Technical, Information, and Platform architecture. While multiple sources of business value were created by the new EA, its implementation faced important challenges in terms of loss of dedicated staff and fuzzy lines of responsibility. On the upside, Chubb is now adept at handling demand management and IT leadership development. Chubb has reached the next level of EA maturity.2

1 Developing an effective enterprise architecture at Chubb Insurance, MIS Quarterly-Executive, V. 11, No. 2 (2012). 2 On July 1, 2015, ACE acquired Chubb.

The Jewel in the Crown – Enterprise Architecture at Chubb

Heather A. Smith Queens University (Canada)

Richard T. Watson University of Georgia (U.S.)

The Company

The Chubb Group of Insurance Companies deliv- ers property and casualty insurance products and services to businesses and individuals around the world.

It is the 12th largest property and casualty insur- er in the United States and has a worldwide net- work of some 120 offices in 25 countries staffed by 10,200 employees. Chubb reported $51.3 billion in assets and $14.1 billion in revenues in 2014 and is a Fortune 500 company.

Chubb’s leadership in the insurance industry is not only based on its size or longevity, but also because it works to consistently build lasting relationships with its customers and thousands of independent agents and brokers. The company aims to deliver excellent service and innovative, scalable, and specialized products backed by financial strength and third-party endorsements.

The Jewel in the Crown – Enterprise Architecture at Chubb

The Organizational Adaption Problem

Adaption is a central problem of economic organization.3 In order to persist, firms must continually react to competition and changing demand. In the digital age, an Enterprise Architecture (EA) can determine the speed of adaption. If an EA is a hindrance, then the firm cannot co-evolve as fast as its competitors. Alternatively, a flexible EA can enable an enterprise to set the pace of its industry’s evolution by responding to changing market forces with alacrity and integrating new technology rapidly and successfully. An EA is not static. As a critical platform for enabling adaption, it must be adapted to enable the organization to prosper. This case describes how Chubb transformed its EA to support organizational adaption.

A mechanical watch contains a series of jewels, which can be made of sapphire, ruby, or diamonds in the highest quality watches. Jewels have low predictable friction and thus increase a watch’s accuracy when used for bearings. Thus, it is not surprising that Chubb’s EA is depicted as its “crown jewels.” Ideally, an EA is a set of bearings upon which an organization can pivot with minimal resistance when it needs to adapt.

Redesigning the Crown Jewels Jim Knight had no doubt he had a winning

EA organization when he became CIO in 2008. “Our EA is the glue that brings business and IT together,” he said in 2011.”4 Chubb’s EA was considered comprehensive, well-developed, and mature. But over time, new technologies, growing demand from the business for better information, pressures to innovate, and the ever-present demand to drive greater efficiencies from IT prompted Knight and his senior leadership team to re-evaluate and redesign the role of EA and the whole IT function.

The subsequent redesign of EA in 2012 created a centralized mechanism to integrate IT solutions to enable the designed digital

3 Tadelis, S., & Williamson, O.E. (2012). Transaction Cost Eco- nomics. In R. Gibbons & J. Roberts (Eds.), Handbook of organiza- tional economics. Princeton, NJ: Princeton University Press. 4 Developing an effective enterprise architecture at Chubb Insur- ance, MIS Quarterly Executive, V. 11, No. 2 (2012).

organization. From Knight’s point of view, EA serves as “the crown jewels. When you get EA right, everything else falls into place”.

Redesigning the EA Function At that time, EA at Chubb was led by Chief

Architect Patrick Sullivan, who strove to bridge business and technology through architecture. EA was originally conceived as a federated function, drawing architects from Chubb’s seven lines of business. Between 2006 and 2012, Sullivan made great strides in building a strong EA function with a comprehensive strategy, standards, governance, and key enterprise-shared assets and solutions. But there were problems with this approach. “In a federated world, EA is like herding cats,” said Sullivan. “Although everyone’s well-intentioned, local interests tend to trump the needs of the enterprise.” Since standards were often viewed as “advice,” they were difficult to enforce.

Furthermore, in the intervening years, the field of architecture itself had matured and developed into several separate disciplines that now required specialized skills. “We needed to continue to rationalize our existing suite of technologies and applications while also developing a consolidated plan that was better attuned to business convergence, emerging technologies, and accelerated change,” said Sullivan. “IT at Chubb required a broader, enterprise point of view that stressed consistency, standards, and shared services.”

“We needed to look at the bigger picture, provide vision, and connect the dots between our current state architecture and the digital organization we wanted to become,” said Knight. “I felt if we centralized architecture we could build a better foundation, which would lead to improved execution, and would in turn deliver maximum IT value to the organization. I felt that EA would be super-critical to ensuring that we identified the right building blocks, put them together properly, and pushed new ways of thinking – both in IT and in the organization.”

To this end, Knight created a new centralized Enterprise Architecture function in 2012, consolidating line-of-business (LOB) architects into the enterprise IT organization. He added a demand/resource manager to ensure that architect skill sets were further developed and effectively deployed and appointed Sullivan Chief

December 2015 (14:4) | MIS Quarterly Executive 197

The Jewel in the Crown – Enterprise Architecture at Chubb

Enterprise Architect. Knight also appointed an EA Practice Lead to manage architects on a day- to-day basis while building out the practice in a number of key areas, such as vendor product assessments, supporting delivery teams, problem resolution, and developing strategy and roadmaps. The EA Practice Lead would do the “heavy lifting” involved in EA (see Figure 1). Knight deliberately chose a non-traditional structure with “fuzzy” responsibilities – “more like clouds that overlap” to encourage the EA and other IT leaders to collaborate.

The initial EA Practice Lead, Shweta Pandey, was selected for her management and leadership skills rather than technical expertise. While Sullivan focused on strengthening architecture governance, she guided the newly formed group toward the new centralized model while matching her resources with projects. Over time, Pandey and her leadership team led this significant organizational change, ensuring positive outcomes. Relationship building with stakeholders across the organization up and down the hierarchical chain was key to the success of this new approach. “The effort to manage such a change was huge, requiring creative leadership and management skills, and endless energy, persistence, consistency, and compassion,” she recalled.

In 2013, the EA department divided its staff into four specialized architecture domain teams: Information, Application, Technical (including Security and Emerging Technology), and Platform Architectures. This new engagement model then needed further definition of roles and appropriate engagement both within and outside the EA function. A new, more technical EA Practice Lead, Ramesh Pandey, was appointed in 2014. “There have been some growing pains,” Knight admitted. “We needed more clarity on roles, but we’ve mostly worked this out now.” One of these growing pains was the departure of Patrick Sullivan in early 2015. Following this, Knight appointed Ramesh Pandey as both Chief Architect and EA Practice Lead to ensure EA had one vision, one direction and one message. “Ramesh is a strong leader with excellent technical skills,” said Knight.

The redesigned, centralized EA function has a broader scope and a mandate to enforce its principles and standards. It has two major, somewhat overlapping components: Target Architecture and the EA Practice.

Chubb’s Target Architecture As Chief Architect, Pandey’s role is to design

and maintain Chubb’s new Target Architecture with senior IT and business leaders, work collaboratively with both business and IT to educate them about goals, and ensure that the decisions made and projects undertaken are in compliance with this architecture through governance. Chubb’s Target Architecture Vision, developed in 2014, clearly articulates both its current enterprise architecture and its envisioned target architecture, defining these terms as follows:

Current Enterprise Architecture is the structure of the core set of systems and processes of the organization, including business capabilities and the integration of relevant technical capabilities, presented from the enterprise point of view. It documents the current state of IT.

Target Architecture is the high-level vision that shows the relationship between business goals and future IT solutions, looking strategically across the enterprise. At Chubb, business unit and product line application development are not part of its future target architecture. Instead, the vision outlines a holistic, long-term prescriptive

Figure 1: Chubb’s Initial Centralized EA Function

The Jewel in the Crown – Enterprise Architecture at Chubb

architecture that will serve changing business needs while maintaining a long-range perspective and position on technology trends. Although recognizing that a target architecture is iterative and evolutionary, it serves as a plan for where the organization wants to be in five years’ time (see Figure 2).

Chubb’s historical, siloed approach to IT investment inhibited agility for several reasons, including misaligned IT and enterprise strategy, IT solutions built based on technology trends rather than desired business outcomes, duplication, and lack of coordination across individual business units. The target architecture aims to maximize the value of future IT investments across the organization while still meeting local business needs.

The target architecture is divided into four major components designed to guide IT investment and development decisions:

1. Architecture Principles. These are general rules and guidelines intended to be enduring and seldom amended. These state that all elements of enterprise architecture should:

● Be business oriented with a business-driven design that supports business priorities, provides maximum return on business investment in technology, and enables operational efficiency, flexibility and agility.

● Use information as a key corporate asset to support agility in implementing transactional solutions while enabling

more robust and comprehensive levels of business analysis.

● Incorporate key architectural qualities which address the non-functional expectations of systems, including usability, adaptability, performance, extensibility, availability, scalability, recoverability, maintainability, and upgradability.

● Promote consistent architecture following standards that are compliant with the target architecture.

● Eliminate technical risks by planning for and removing obsolete technology, determining when to acquire new technologies, and stressing reuse and purchased software over custom building.

● Reduce technical debt by addressing the inefficiencies that build over time in all systems and applications resulting in increased effort and cost to enhance, maintain, and integrate applications.

● Take a holistic approach when making architectural decisions, seeking to leverage technical solutions across multiple areas of the business and reduce technical sprawl.

● Reduce overall complexity by minimizing supported software versions, reusing existing components, and utilizing common design patterns.

● Follow proven standards and processes to guide the development of IT solutions, including: the EA governance process, a

Figure 2: The Relationship between Chubb’s Enterprise and Target Architectures

December 2015 (14:4) | MIS Quarterly Executive 199

The Jewel in the Crown – Enterprise Architecture at Chubb

common SDLC, and tool and technology selection process.

2. Architecture Governance. This is the practice by which all domain architectures are managed at an enterprise-wide level. It establishes the controls, compliance obligations, processes, and practices to ensure the effective introduction, implementation, and evolution of architectures in the organization. Achieving the target architecture requires a more prescriptive approach than in the past. “Previously, we brought people together to discuss what should be done,” said Pandey. “Since everyone interpreted the rules differently, we had applications unique to one line of business. Now we’ve eliminated teams from each business domain and have implemented a crisp set of about 50 architecture compliance rules based on the TOGAF framework (see box).

Every new project must be issued a “building permit” at its outset.5 At this time, the Architecture Governance Board assigns one or more architects to the project and determines which of the five new EA domain review boards will need to assess work at various stage gates (see Figure 3). “Typically, an application architect is assigned to a project,” said Lance 5 Any project that introduces a new capability, technology, is customer-facing, involves vendor construction, uses obsolete or unap- proved technology, involves significant complexity, or deviates from a compliance rule requires an architect. Exceptions are allowed for fixes, refeshes, and small changes.

Martin, the Process Manager who coordinates EA governance. “This architect works with the development team and shepherds the project through each review gate beginning with project conception and carrying through solution analysis, initiation and business requirements, design, and building.”

At each stage gate, the assigned architect must validate and sign-off on the project’s

compliance with architecture rules. Artifacts and design documents must be submitted for reviews and signed-off. If a deviation is required, it is flagged and a remediation plan put in place and monitored rigorously. “In the old process we had no way to check that these IOUs had been fixed,” said Martin. “Now, deviations must be either corrected immediately or, if based on a compelling business need, allowed with a

TOGAF

The Open Group Architecture Framework (TOGAF) is a detailed method and set of sup- porting tools for developing enterprise archi- tecture. It may be used freely by any organiza- tion wishing to develop enterprise architecture for use within that organization.

http://pubs.opengroup.org/architecture/ togaf8-doc/arch/

Figure 3: Chubb’s New EA Governance Framework

The Jewel in the Crown – Enterprise Architecture at Chubb

remediation plan or with a change to the Target Architecture.”

Although the process sounds complex, Martin explained that governance is not a bottleneck. “The Chief Architect and EA Practice Lead and the Board members meet weekly to review all new permits and determine which architecture boards need to be involved in future reviews.” Peer reviews are also conducted before stage gate reviews. The result is close to 100% compliance with the target architecture in 2014.

3. Conceptual Reference Architectures. Supporting Chubb’s overall target architecture are eight reference architectures for specific domains:

● Business architecture maps business capabilities needed to reach the company’s goals and objectives.

● Application architecture describes the logical structure of software supporting both existing business capabilities and the company’s strategic imperatives.

● Information architecture defines both the major categories of data/information in the organization and the terminology used from both a Chubb and an industry perspective.

● Technical architecture describes the enterprise technologies and assets that support both information and application capabilities.

● Policy administration describes a consistent, holistic policy administration capability.

● Advanced analytics aligns with information architecture and introduces new components that address the needs of big data.

● Content management addresses the technology and solutions to maintain and improve Chubb’s investments in this area.

4. Emerging Technology. Finally, the Target Architecture document outlines a process to accelerate innovation and explore technological advances. It describes an R&D lifecycle and outlines key considerations for research to enable

Chubb to drive ideas to reality through rapid development and prototyping. Architects from the technical architecture domain team also create and maintain a technology enablement roadmap of projects that address current and potential key business drivers, such as analytics, social media and collaboration, mobile and remote computing, virtualization and cloud computing, and open source.

The overall goal of this target architecture vision is to move the organization away from application silos towards an integrated enterprise-wide architecture that will provide an agile foundation for successful business execution, analytics, measurement and reporting, and serve as an aid to IT investment decision management (see Figure 4).

Chubb’s Enterprise Architecture Practice

As EA Practice Lead, Pandey oversees five domain disciplines: IT Strategy and Governance, Application, Technical, Information and Platform architecture. The responsibilities and roles of the architects in these domains are specialized and actively involved in delivery and execution than previously.

To create the new architecture practice, the teams required a careful balancing of internal and external skills, explained Ron St. Clair, Chubb’s Chief Development Officer and Pandey’s boss. “We were strategic about where we placed those with good Chubb knowledge and those with outside experience.” In EA, this particularly involved building up the Information Architecture domain team. Of the seven architects in this area, five are new and are the “best and the brightest” in the field, according to Pandey. In Application Architecture, however, most of the team came from individual business units after architecture was centralized and several senior developers also became architects.

The responsibilities of each domain team are outlined below (see Figure 5):

1. Application Architecture. This is the largest architecture team and provides cross-organizational leadership to guide application construction, deployment, ongoing performance, and the continued

December 2015 (14:4) | MIS Quarterly Executive 201

The Jewel in the Crown – Enterprise Architecture at Chubb

F ig

ur e

4: C

hu bb

’s T

ar ge

t A rc

hi te

ct ur

The Jewel in the Crown – Enterprise Architecture at Chubb

evolution of individual applications and the broader application portfolio. The team ensures that applications are aligned to the Target Architecture and develops this architecture and transition plans for individual applications, application areas, and the broader application portfolio. Serving as the primary contact for architecture services and deliverables for project teams, application architects ensure the appropriate engagement of other architecture teams, enforcing standards, ensuring compliance, targeting the development and use of reusable designs and shared services across applications, and providing mentoring and knowledge sharing. “With this new centralized design, we’ve broken the boundaries of the individual Chubb application architectures and made application architecture more visible,” said Pandey. “It now has much more impact and facilitates better knowledge transfer.” The new EA function requires architects to be much more involved in projects than in the past. They are now assigned to specific projects for their entire life cycle, working three to four projects at a time. The architect’s role is to shepherd and mentor the development teams, ensuring they follow standards and best practices,

and providing peer reviews for other development projects.

2. Information Architecture (IA). This team defines the vision and designs the solutions that address current information needs and positions the organization for future ones. It develops strategies that improve data integration, quality, and delivery across the enterprise. Information architects are called into projects when application architects identify a need for them, but also take the lead on information-specific projects. As well, they design solutions and maintain roadmaps for enterprise information-centric solutions, such as Master Data, Business Intelligence, Reference Data Management, Metadata Management, and Predictive Analytics. Finally, IA educates business and IT professionals about the value of information architecture. “Our information architects have a huge role in coaching our development teams, educating business and IT about opportunities, and transferring knowledge about the tools,” said Pandey. For example, an intervention by the IA team showed development staff a much faster way to deliver results with a new tool.

Figure 5: Enterprise Architecture Domain Teams

December 2015 (14:4) | MIS Quarterly Executive 203

The Jewel in the Crown – Enterprise Architecture at Chubb

3. Platform Solutions Architecture. This team identifies and designs reusable technical capabilities that provide the building blocks for robust, cost effective and flexible business solutions such as business rules, integration, Salesforce.com, enterprise content management, PeopleSoft, location services, the digital portal (user interface and experience), the development platform, and print. Highly specialized team members develop strategies and roadmaps for specific platforms, establish and enforce standards, provide platform- specific design expertise, and undertake high level design for projects in these areas.

4. Technical Architecture is responsible for defining, designing, and operationalizing a vision for the underlying technologies that are foundational for the application, information, and platform architectures. This team also works with Pandey to research and analyze emerging technologies and technical solutions. It develops and owns strategies and roadmaps for the technology portfolio across the enterprise and works with the business unit teams and infrastructure to prioritize and plan technology upgrades and initiatives. “We want this group to be proactive and bring new technologies to the development teams,” said Pandey.

5. Security Architecture (within Technical Architecture) defines, designs, and enforces security architecture best practices and standards, including encryption and confidentiality considerations, in network, storage and security technologies. The team also defines and establishes identity management strategies as well as design and development standards to meet security, audit, and legal requirements. It is responsible for working with the primary architect to educate others, contributing to design artifacts when security is involved, and ensuring solutions are adequately secured.

6. IT Strategy and Governance implements the target architecture, develops execution roadmaps, and drives execution in

collaboration with the other EA disciplines and IT functions at Chubb. It oversees governance, the building permit process, and IT compliance adherence, and ensures applications are built or integrated with accepted standards and in alignment with Chubb’s approved target architecture.

In addition, Pandey has identified a number of organizational gaps in which architecture can play a key role. For example, no group owned system performance. “We had one complaint of a transaction that took three minutes to process,” he explained. “Our team was able to assess the problem and work with the developers to fix this unacceptable time.” Similarly, systems often run into performance issues when they add more users. EA assists with these problems to deliver real business value. It has also taken on test strategy development and validation responsibilities, identifying common components, and post deployment review and lessons learned. “We have become the ombudsman for IT,” Pandey stated. “When something falls through the cracks, we step up and own it. This helps build credibility with both business and IT.” Figure 6 shows how this role is expanding each year.

When two important projects experienced major challenges shortly after IT’s centralization, Pandey demonstrated his organization’s value. One project, which had already taken six years and involved 20 people in the siloed IT structure, was deemed such poor quality that the users said it would have a negative impact on their productivity. To avoid a complete collapse of this project, Pandey suggested the new consolidated EA team take it over and “lead by example”. Working with the development team, the project was delivered successfully in six months and was welcomed by its users. The second project was so delayed that the funds from business to support the development were exhausted. EA took over the project and was able to deliver it in six weeks. “We bring lots of experience and discipline to our work,” explained Pandey. “We would rather not do this, but we serve as last resort delivery experts.”

Pandey’s ultimate goal is to guarantee every project’s successful delivery. He pointed out that although project managers can oversee timelines and deliverables, they are not as technical as architects. “Only a senior architect can validate if a job is done at the level expected from a

The Jewel in the Crown – Enterprise Architecture at Chubb

quality and completeness perspective,” he said. He wants to provide this type of oversight for all Tier 1 projects in collaboration with the PMO and Development teams. “It’s a great partnership with strong results,” he said.

An Architecture-Centric IT Function

Knight reported that when the organization changes were implemented in 2013 and early 2014, “We faced skepticism from the business and concern that they were losing their staff, but after first centralizing architecture, the whole transition went remarkably smoothly.” The new organization was designed around delivering complete IT solutions to the business (see Figure 7).

“We are now organized around disciplines, rather than supporting lines of business,” said B.C. Verniero, the head of Business Process Services, Strategy, and Operations. His organization acts as the new front end of IT, working with business leaders at a very senior level to provide thought leadership for Chubb’s digital strategy, the business’ strategy for IT, and business processes (or what some would call business architecture). “There is so much change happening and so much convergence going on, we needed to take a fresh

look at our business needs and capabilities,” said Verniero. Previously, the Chief Architect had taken the lead in identifying business capabilities and how much to invest in them, “but as we became more mature, we recognized that we were falling behind in this area and needed to do more work with our Lines of Business (LOB) to proactively anticipate future needs and collaboratively align them with our technology roadmap and target architecture.”

This new function addresses several key issues for IT as a whole. First, it helps business with envisioning what they want to accomplish. Dio Toregas, a Vice President and Senior IT Strategist in this group, explained, “I work with the business from the point where there’s something they want to accomplish. Then I help them do high level solutioning – both what functions they want to accomplish and also how IT might be applied.” Toregas helps create future business solutions, keeping IT in mind. “I’m always looking for opportunities to satisfy both an immediate need but also to set the stage for the next step,” she said. “I look for patterns and components and then use business analysts to fill in the details.” For example, one LOB wanted an online function for agents to access some underwriting information but Toregas recognized a broader

Figure 6: EA’s Growing List of Responsibilities

2015

Code Review

Detail Design for Top 10 Tier 1

Top 10 Tier 1 Oversight Last Resort Delivery

Formal Tech Leadership Development

Demand Ledger Review Analysis

Monitoring Tool and Process

Post Deployment Review and Lessons Learned

Common Component Build – Assembly Line

Architecture Position Papers

BI and Analytics Support

Arch Intro Conceptual Design High Level Design

BRD Review-Sign Off

NFR Capture Support

Detail Design – Review-Sign Off

Solution Analysis

Vendor Assessment BP, CHear and Governance

NFR Review-Sign Off

S & O Support and Estimation Application Roadmap

Capacity Planning

Performance Testing Strategy Review

War Room/Rescue Digital Support

2014

Arch Intro Conceptual Design High Level Design

BRD Review-Sign Off

NFR Capture Support

Detail Design – Review-Sign Off

Feasibility Analysis/Design

Vendor Assessment BP, CHear and Governance

NFR Review-Sign Off

S & O Support and Estimation Application Roadmap

Capacity Planning

Performance Testing Strategy Review

War Room/Rescue Digital Support

Core EA Responsibilities New EA Responsibilities Future Anticipated EA Responsibilities

December 2015 (14:4) | MIS Quarterly Executive 205

The Jewel in the Crown – Enterprise Architecture at Chubb

need to have a complete client account file. “The business would never have built it this way, but when I described how we could build this smaller function with the potential to fill a much bigger business need, they were enthusiastic,” she said, “There’s really no such thing as IT strategy,” said Verniero. “It follows the business. Therefore, we must understand business’ strengths and weaknesses so that when it moves, we know. Then we can develop a consolidated IT solutions plan for the enterprise and determine the sequence in which different projects should be developed.”

Another new, quasi-architectural IT function is Analytics. IT’s Chief Analytics Officer, Upendra Belhe, joined Chubb in early 2013. His responsibility is to “change how we think about analytics at an architecture level.” IT is central to this vision. “There can be no change these days without it,” said Belhe. “Analytics and IT are two sides of the same coin.” In this role, Belhe is charged with ensuring that data provisioning is carefully considered and representing the business when it requires IT services in this area. “I sign off on the quality of these projects,” he said, “and I work closely with both infrastructure and architecture to help them bring discipline to this work.” Belhe works with the Enterprise

Architecture teams to help them understand the business need and incorporate an analytical way of thinking into their work. “I want them to understand these things before they make tool choices,” he said.

In addition, Belhe works with information architecture to help build Chubb’s information management (IM) ecosystem and with Pandey to develop the vision, strategies, governance, standards and processes for IM. Belhe is also helping Verniero’s group incorporate new ways of thinking into its long-term business solutioning.

The new IT model integrates EA and development under a single Chief Development Officer, Ron St. Clair, an executive who joined Chubb in 2013. His organization comprises 60% of the IT function with about 550 people. “We’ve always had infrastructure centralized but done development and architecture in the lines of business,” St. Clair said. “When each of these groups was smaller, you could get by with adequate processes, but with a large, centralized organization we have the opportunity to become more efficient. My goal is to bring more rigor, maturity, and standardization to solutioning.”

Phil Folz is the SVP in charge of Development Services, reporting to St. Clair. He is a 25 year Chubb veteran, with many years experience

Figure 7: Chubb’s New IT Function

The Jewel in the Crown – Enterprise Architecture at Chubb

as IT Controller. “Centralizing the delivery of IT solutions was a big change for the company,” he noted. “But it has been good to bring all the technical people together. We’re trying to develop a discipline-based IT delivery function focused on five areas: project management, business analysis, development, testing, and architecture.” The new IT model, which created separate business analysis and project management functions, grouped the two technical disciplines together under St. Clair. It staffed up EA with senior developers, splitting the design function into high level design (done by EA) and detailed design (done by Development). The new relationship between Development and EA is still being worked out and reflects Knight’s penchant for “fuzzy lines” and somewhat overlapping responsibilities. “We’ve had to darken the lines a bit,” Folz stated. “But we’ve worked closely with Ramesh to address this appropriately and architects are now mentoring our junior developers to help them grow both their technical and soft skills. We’re placing a lot of emphasis on coaching and mentoring in both Development and EA these days at all levels.”

“This is an unusual model, but a good one,” concluded St. Clair. “It fits the problem that we had at the time and we’ve got a strong IT leadership team that is intentionally well-balanced between Chubb experience and outside experience. Jim Knight was very strategic about how he built this model.” The heavy focus on EA contrasts with a focus on speed to market in other organizations St. Clair has seen. Having a more mature architecture function initially means more work upfront but ensures alignment with both enterprise and technology strategy and ultimately results in a better return on IT investment,” he said.

The Business Value of EA “The overall goal of EA at Chubb is to deliver

business value to the organization in several key ways,” said St. Clair. These include:

● Total business-IT alignment ● Reduced IT total cost of ownership ● Improved application, information, and

technology portfolio management ● Minimization of information overlap and

duplication

● Increased IT responsiveness and speed to market

● Regulatory compliance ● Increased spending on emerging

technology and innovation. But such long-term goals tend to get lost if

short-term value is not delivered. Although there were questions from business about the new EA and IT organizational models during the transition period, the model is demonstrating its strength as specific challenges are solved. “When two critical projects got into trouble last year we were able to parachute in the best talent and deliver them,” said St. Clair. “The business saw then what a difference EA and centralized IT can make.”

There is general agreement among IT executives that the new model of EA is delivering value to the business. “We have better business engagement,” said B.C. Verniero. “They’re more confident that we won’t fall behind. The business feels it can access better intellectual capital.” Dio Toregas agreed. “We are able to look for bigger opportunities that a single business unit would never build; we can satisfy an immediate need and still set the stage for the future. The business isn’t questioning our value anymore. They wouldn’t call me if they didn’t recognize the value we bring. You must earn it.” “There’s a much greater focus on business need rather than tools,” added Uphendra Belhe. “And this is refreshing.” According to Pandey, “We have a more consistent environment and are more efficient and rigorous in our disciplines, leading to better quality and more flexible solutions,” Pandey said. He added that Chubb has gained two major enterprise-wide capabilities with the introduction of improved integration competency and platform architecture.

Centralizing IT talent has also been beneficial. “This has fixed our biggest problem,” said Knight. Verniero added, “The business now gets resources that are the best fit for their projects.”

Those outside IT appreciate the new structure. “Chubb now has better long-term and strategic planning reflecting an enterprise point of view,” said Dan Paccico, Senior Vice President and Controller, who is in charge of Chubb’s strategic planning and budgeting as well as enterprise risk management. “With the elevated role of EA we can see what building blocks we need and how to pull them together. It’s a big help in making corporate

December 2015 (14:4) | MIS Quarterly Executive 207

The Jewel in the Crown – Enterprise Architecture at Chubb

decisions.” He also noted that the new structure facilitates IT involvement with business initiatives at all stages. “We tell them our long-term needs in financial reporting and they then break these down into smaller phases, making sure that the needs of the other business units and our analytics group are supported by the final solution.”

Jon Bidwell, SVP and Chief Innovation Officer, sees the value of the new approach in enabling more R&D. “We’re faced with a fire hose of new technologies these days,” he said. “We need to quickly be able to figure out which are relevant now, which might be in the future, and which are irrelevant. And we need thoughtful ways to engage the business in discussion or everything’s an endless distraction.” EA provides a framework to indicate where new technologies fit. He particularly appreciates the single point of contact in IT to help him assess new technology. “EA has developed a solution template that helps us decide what’s relevant quickly and undertake a rapid proof of concept. It’s a virtuous system that ensures we don’t lose what we’ve learned and we know when to pursue a new technology.” Since all innovation relies on technology, EA helps explain how everything fits together – especially helpful when dealing with “Executive magazine syndrome.” “In the past, this knowledge was all in pockets around the organization. Now we can say to anyone who asks, ‘here’s where we are with this technology’. It speeds communication and cycle times. It’s critical,” said Bidwell. It is also a method that illustrates how the different vendors work together and facilitates the development of solution networks of experts, which Bidwell foresees as being essential in the future. “EA helps us to know what we know when we need it and to knit stuff together quickly.”

In the past, the business tended to jump quickly to solutions and develop a pipeline of IT projects without a rigorous vetting and proof that the projects would deliver value. With support from EA, proofs of concept are developed quickly.

Knight summed up all these perspectives, noting “if we get architecture right we can not only deliver tactical benefits, we can also be more strategic, and this is really where it pays big dividends.”

Challenges and Critical Success Factors

Significant organizational changes are rarely smooth and the centralization and reorganization of EA and IT at Chubb was no exception. Many of the challenges arose from two areas of uncertainty:

1. Loss of dedicated staff. Moving first the architects and then other IT professionals from the lines of business into a centralized function caused localized concern about losing dedicated staff and alarm that important local projects would lose out to higher priority projects. Shortly after the centralization of IT was complete, two significant projects appeared to be losing out and issues such as three minute transaction times were not immediately fixed. But the IT senior leadership team “really owned these problems,” said Folz, and “created a ‘war room’ under Pandey to recommend remediating actions. They admitted they had problems and addressed them.” Presently, many enterprise business leaders recognize the advantages of the new model in moving the enterprise agenda forward. Although reviews are still “mixed,” Knight and his senior IT leaders have spent much of the past three years educating business leaders in the reasons behind the changes, resulting in greater understanding of the value that can be achieved. “We spend a lot of time speaking about the business outcomes we are trying to accomplish. We don’t speak about architecture,” said Verniero.

2. Fuzzy lines of responsibility. Knight’s new IT function was modeled on the new EA function, with deliberately fuzzy lines between related areas. As might be expected, this caused problems in both EA, IT and also in the business. “The lines of responsibility in IT are fuzzy,” said Pacicco. “It’s still unclear how IT processes work, particularly at the planning stages. You need to bring many people into conversations. There’s role clarity on paper but not totally in the processes as yet.” Knight understands these problems

The Jewel in the Crown – Enterprise Architecture at Chubb

and has worked to clarify them – up to a point. “I want people to know where the lines are, but I want them to be lines, not walls,” he said. Knight stresses that the new structure reflects the desire to incorporate more situational leadership, rather than hierarchical leadership, to capitalize on people’s skills and play to their strengths. It also reflects the greater uncertainties involved in moving into new areas, such as R&D, information architecture, more strategic business and IT planning, and analytics. These areas are each very heavily weighted in favor of more senior leadership involvement. “There’s definitely more work at the senior level upfront,” said Pacicco. “The new work we’re doing must bring everyone together at the planning stages. But the payoff will be in speed, quality, better outcomes, and reduced risk at the back end.”

The new EA and IT models also have two major strengths, which helped smooth the transition and improve their ability to deliver value:

1. Demand management. “Our biggest problem was talent management,” said Knight. “Under the old model, people were allocated to different lines of business. Now we can place people where they are most needed.” To this end, each major sub- unit of IT has a Demand Manager whose job is to ensure that the right people are assigned to the right projects. “This is a very challenging job,” said Pandey. “There’s lots of juggling going on and it’s very dynamic.” Demand management not only helps give each senior IT leader a picture of what resources will be needed in his or her area over the next one-two years, it also helps identify needed skills so they can be developed or acquired appropriately. “Demand management gives us a resource and skills plan to factor into our overall project planning. It also highlights gaps and ensures that key skills do not become a bottleneck, said Verniero. “Our demand manager ensures that architectural assignments are optimized and that people are cross-trained,” said Pandey. “This was a big selling feature of the plan to centralize

EA.” Demand managers are also responsible for developing staff skills. Thus, they may assign a project to someone who may need to learn a new skill and establish a mentor who can coach them along the way.

2. Education, coaching and mentoring. Chubb has long placed a strong emphasis on developing the next generation of leaders. The importance of mentoring and coaching is stressed by all senior IT leaders. From the most senior leaders on down, coaching and mentoring is considered part of everyone’s job. Pandey focuses on the architects in the Tier 1 or top priority projects and expects more senior staff to develop more junior ones. For example, information architects are expected not only to assist a delivery team but also to transfer knowledge to them about key IA components and concepts. Application architects work very closely with development staff and business analysts to teach them different ways of working. In fact, in his 2015 plan, Pandey has explicitly incorporated mentoring and coaching leadership into the formal processes of EA and 20% of more senior architects’ time will now be allocated to this work. Ron St. Clair, Knight, and Verniero, who have more business-facing roles, each spend considerable time educating business leaders on the whys and hows of the new architecture role, the target architecture, and ultimately the new IT organization. St. Clair and Pandey also work with each line of business annually to review its portfolio of applications and educate it on the need to reduce complexity and the value of adopting enterprise solutions. In this way, in the past few years, Chubb’s application portfolio has been reduced by 50%, moving the organization well down the path towards its desired target architecture.

Conclusion The new EA function at Chubb is the next

logical step for what was already a highly mature EA practice. It underscores both the evolution of EA and its increasing centrality to how IT is delivered in organizations, and the evolution of the

December 2015 (14:4) | MIS Quarterly Executive 209

The Jewel in the Crown – Enterprise Architecture at Chubb

IT function itself as it moves deeper into the strategic heart of the company and away from the simple manufacture of systems. Today, EA is integrated into almost every aspect of IT work and is at the forefront of every major new strategic initiative at Chubb. Its mission is nothing less than revolutionary, bringing coherence and structure to the formerly piecemeal approach to delivering technology and engaging the company’s most senior leaders in planning IT work. Knight, St. Clair, and Pandey are confident that this approach will deliver significant value to the organization, although they admit this is very difficult to measure. “We’re working at the nexus of change,” said Pandey. “We’ve done the tough parts; now we’re revving up the engines and ready to take off.”

About the Authors

Heather A. Smith Heather A. Smith (heather.a.smith.queens@gmail. com) has twice been named by the Communications of the Association for Information Systems the world’s most-published researcher on IT management issues. A Senior Research Associate with Queen’s University School of Business, she is the author of six books on IT management, including IT Strategy: Issues and Practices 3rd ed. (Prentice Hall, 2015) which is widely used in many IS and MBA courses. A former senior IT manager, she is currently co-director of the IT Management Forum and the CIO Brief, which facilitate inter-organizational learning among senior IT executives from large firms such as EMC, Bell Canada, Deloitte, Scotiabank, and Fairmont Hotels. She also works with SIM’s Advanced Practices Council and Queens University on a variety of research projects and case studies. In addition, she has consulted and collaborated with organizations world-wide, including: Viktoria University, Sweden, the Information and Communications Technology Council, the Institute for Citizen-Centred Service, British Petroleum, TD Bank, Canada Post, Ecole des Hautes Etudes Commerciales, the OPP, Boston University, and the Bank of Montreal.

Richard T. Watson Richard T. Watson ([email protected]) is a Regents Professor and the J. Rex Fuqua Distinguished Chair for Internet Strategy in the Terry College of Business at the University of Georgia. He is the current Research Director for the Advanced Practices Council of the Society of Information Management and a former President of the Association for Information

Systems. In 2011, he received the Association for Information Systems’ LEO award, which is given for exceptional lifetime achievement in Information Systems. For several years, he has been a visiting researcher at Viktoria Swedish ICT engaged in establishing and applying Maritime Informatics to the European shipping industry. He is an Honorary Visiting Professor at Xi’an Jiaotong University.

Copyright of MIS Quarterly Executive is the property of MIS Quarterly Executive and its content may not be copied or emailed to multiple sites or posted to a listserv without the copyright holder's express written permission. However, users may print, download, or email articles for individual use.