Mini Case Enterprise Architecture at Nationstate Insurance Jane Denton looked around at her assembled senior IT leadership team waiting to hear what she was going to say. Most were leaning forward eagerly, though some appeared more cautious. They were a good team, she knew, and she wanted to lead them well. A seasoned CIO, with a whole career behind her in IT, Jane was the newly appointed global CIO of Nationstate Insurance. This would be her last job before retirement in three years and she wanted to find a way to make a lasting difference in this company. Nationstate was an excellent company—Jane had done her homework. It was one of the largest in the United States, with a worldwide presence in personal and commercial insurance, and had recently been voted one of Forbes’ “Best Big Companies.” It had good systems, good user–IT relationships, and good people. But the company aspired to be great and Jane wanted to help them by taking IT to the next level. She knew that the world was changing—largely as a result of technology—and she knew that IT and its traditional approach to systems development was also going to have to change. “Our IT function needs to become more cutting edge in adopting emerging technologies,” she had told the CEO shortly after she was hired, “and we need to become more flexible and agile in our approach to development work.” Now she had this time and this team to accomplish her goals. However, it was much easier said than done. Like almost every large organization, Nationstate had a hodgepodge of different systems, data, and processes—most serving just one of its six business units (BUs). Nationstate’s decentralized structure had served it well in the past by enabling individual BUs to respond quickly to changing market needs but a couple of years before Jane’s arrival, recognizing the need for some enterprise thinking, the CEO had created a federated structure with some centralized functions, including parts of IT. So some of IT was now centralized and shared by all the BUs (e.g., operations) and reported directly to Jane, while the rest (e.g., system development) was decentralized. Each BU had its own CIO and IT staff who reported jointly to the BU’s president and to Jane. This potentially unwieldy structure was made more palatable by the fact that the business unit CIOs had great business knowledge and were well trusted by their presidents. In fact, it was central IT that was often seen as the roadblock by the BUs. She had never led an IT organization like it, she reflected, and in her first few months, she had made a considerable effort to understand the strengths and weaknesses of this model and how responsibilities had been divided between centralized enterprise services and the decentralized IT groups (each quite large themselves) in the business units. Now she thought she had a good enough handle on these that she could begin work with her senior leadership team (the BU CIOs) to develop a plan to transform IT into the kind of technology function Nationstate would need in the years to come. “I know you are both enthusiastic and apprehensive about transformation,” she said. “We have a great organization and no one wants to lose that. We need to be responsive to our business needs but we also need to incorporate new development techniques into our work, do a better job with emerging technologies, and begin to rationalize our application and technology portfolios. We have duplicate systems, data and software all over the place. Our CEO and the BU Presidents want to see us use our technology resources more efficiently, but more than that, they want our leadership in using technology effectively for the organization as a whole. We can’t do this if we’re all working in separate silos.” Heads began nodding around the room as she continued. “At present, every business unit has its own IT architecture and architects and each of you believe you are making the ‘right’ technology decisions but you are all doing it differently.” The head nodding stopped and a mood of wariness took over. “No one in our organization has the big picture of what we have and where we need to go. We have to learn what makes sense for us to do at an enterprise level and what’s best left in the business units. Architecting our technology, information, business and applications properly is the key to doing it right.” “What exactly are you proposing?” asked Owen Merton, CIO of the Casualty Division. “I think you’re right that we need an enterprise architecture, but I don’t want to lose the good work we’ve done at the BU level.” “Well, I really want to centralize all architecture,” said Jane. “I think that’s what works best in other organizations and that’s going to be the most effective way to make it work here. BUT . . .” she added, “I’d like to speak with each of you individually and with your senior architects before I do. I’m open to your ideas as long as they address the needs that I’ve just outlined.” Over the next two weeks, Jane listened carefully to what the divisional CIOs had to say. They all agreed with Merton that the relationships with the BUs were extremely important and centralizing architecture had to be done carefully. All of them had heard horror stories about the “architecture police” in other companies—hard-line techies who set standards and created blueprints and insisted on them being followed in spite of the difficulties their policies caused for the business. “Architecture can’t live in an ivory tower,” explained Vic Toregas, CIO of Claims. “It has to be rooted in the reality of our business and it can’t be seen to slow things down.” Jane agreed. “We must make sure that our architecture function is designed and managed to ensure rapid delivery to the business.” On the other hand, Nick Vargo, CIO of Group Health, was concerned that without a strong enforcement mechanism, standards wouldn’t be followed. “What’s the point of having standards if we don’t enforce them?” he asked. Jane’s head whirled. It wasn’t going to be easy to strike the right balance between developing a good, sustainable process that would provide a blueprint for where the company needed to go and enable the company to build the common capabilities it would need for the future, while delivering solutions quickly and flexibly for the BUs. “What we don’t need is a ‘Winchester Mystery House’,” she reflected, recalling the famous local house whose owners kept adding to it over many years with no overall plan. She became more worried when she began to speak with the BU architects, with an eye to appointing one of them as her chief enterprise architect. They seemed to be technically competent but were not what she would call “relationship people” or business strategists. The job, as she envisioned it, would combine strong leadership skills, a good understanding of the business, and excellent communication skills to translate why the business should care about architecture, with strong technical skills. Her day became a bit brighter when she began her final interview with Seamus O’Malley, the senior architecture manager of the commercial BU. As they spoke, Jane was impressed with his vision and pragmatism, as well as his strong communication skills. By the end of the hour she knew she had found her new chief enterprise architect. “I’d like you to take this new job,” she told him. “I think you are the right person to ensure we have the standards, tools and practices in place to develop a common architecture for Nationstate.” Seamus thought for a moment before replying. It was a great offer but he had his doubts that Jane’s plan would work and this situation had to be carefully handled. “Thank you for your faith in me,” he began diplomatically, “but I would like to suggest a slight modification to your plan. You see, I’ve been an architect in centralized organizations and there has always been an ‘us versus them’ mentality between the architecture group and both the rest of IT and the business units.” Jane recalled the horror stories of the “architecture police.” “So what I’d like to propose is a compromise. I would become Chief Enterprise Architect but I would also remain Senior Architecture for Commercial and involve the other BU Senior Architects in creating a strong enterprise architecture that works for us all. That way, no one will see me as just ‘the enterprise guy’ and whatever standards we set and decisions we make centrally will affect me in Commercial, just like they’ll affect all the other BUs. When the other business units see that I’m willing to eat my own dog food, I think they’ll be more ready to accept the standards and changes we’ll be introducing.” While not sure the compromise would work, Jane agreed to try it for a year and Seamus set out to build a centralized architecture function from scratch. With the authority given to him by Jane, all of the BU senior architects now had a dual reporting relationship—to their CIO and to him as the chief architect. At their first weekly meeting with the BU senior architects, Seamus outlined his role and agenda. “As you know, each of us has been individually responsible for developing an effective IT architecture for our business units but we haven’t done any coordination between them. That is no longer good enough for our business needs and I, with your help, have been given the job of establishing an enterprise architecture that will create an enterprise technology blueprint for Nationstate, which we will all have to follow in the business units. I want to work collaboratively with you so that we come up with a plan and processes that will work for each of us in the business units, as well as for the enterprise as a whole. We will need to build our enterprise architecture slowly but steadily so that people will trust us, and that means having good governance, good processes and a collaborative approach to this work,” he stated. “Our first priority is building strong relationships with both Jane and the other CIOs and our BU Presidents. Enterprise Architecture sits in the middle between these groups, so good relationships are essential.” “However,” he continued. “We are going to need a way to establish and enforce standards—enterprise ones, not the ones you have now—and this is going to be difficult to explain.” “I’ll say,” remarked Sarah Jensen, the senior architecture manager from Personal Insurance. “What do we say when the business asks why they can’t do something that’s important to them because our ‘standards’ won’t let them?” “That’s a good question Sarah,” said Seamus. “And it gets right to the heart of why architecture is important. We need to present architecture in ways that are easy for the business to understand, without scaring or threatening them. For example, we need an application reduction strategy designed to eliminate duplication, reduce complexity and save money. The business already understands the pain of having to jump from system to system and knows that owning two cars is more expensive than one. If we explain it to them in this way, they will understand the advantages of having a single system and a single workflow.” “But isn’t good architecture about more than cost savings?” asked Michael Lee, senior architecture manager from Claims. “We need to develop a foundation of common information, tools and processes so that we’re not reinventing the wheel going into the future. And someone needs to decide what new technologies we’re going to need and where we’re going to use them. There are so many new applications and devices coming out every day now, we’re going to be in a real mess if we don’t do this properly.” “You’re exactly right,” said Seamus. “These things do have to be managed for the good of the enterprise—both to make it more effective and more efficient. But it’s how we manage them that’s important. If we put lots of bureaucracy in place and don’t add value, no one is going to support us and they’ll find ways to undermine what we are trying to do. We can’t take a ‘field of dreams’ approach to architecture. We need to attach our work to real business value and real projects. Once our leaders understand this, we’ll get their support.” “So here’s our challenge,” Seamus told his assembled team a few minutes later. “We need to design an Enterprise Architecture function that does all these things. It’s got to be a process that comes up with the standards and guidelines that each of you can live with and support in the BUs. And, as you know, I myself will have to live with them in Commercial as well.” “Here’s what I believe we need to accomplish as soon as possible,” he stated, flashing a PowerPoint slide on the screen: 1. An enterprise governance process to set architecture strategy, policies and standards for technology, applications, and information that reflects the federated structure in the organization. 2. A means of monitoring that all new projects comply with the agreed-upon architecture while ensuring that this process doesn’t present an obstacle to getting IT projects completed quickly. 3. A process for allowing “variances” to the current standards, if necessary, and a way to manage them back to the agreed-on standards. 4. A means of identifying important new IT capabilities and services that should be shared by the enterprise. 5. A means of evaluating emerging new technologies and setting standards for them. 6. Identifying roles and responsibilities for the enterprise architecture function and the LOB architecture functions. 7. Developing a means of incorporating feedback and continuous improvement into our work. “I want to blend and weave our work into the architecture teams we already have in the business units as much as possible,” Seamus concluded. “This will keep us close to business needs and enable us to get enterprise value from the teams we have in place. And I don’t want to add any more process than we need to at an enterprise level. For example, if the Claims group needs a new technology, their architecture group could do the preliminary evaluation and make recommendations for what we should do. But we need to ensure that the resulting decision is a good one for the entire enterprise.” “I’ve got to report back to Jane in a month, so I’d like you to think about what might and might not work for your division and for us as an enterprise. I’ve scheduled a couple of working sessions for us over the next two weeks so we can hash this out. We have an exciting opportunity to take IT to the next level at Nationstate if we do this right, so let’s not mess this up.”
Purchase answer to see full attachment