Enterprise Architecture IT Strategy & Business Alignment

How Effective Is Your Enterprise Architecture?

Your organization may have dedicated Enterprise Architecture (EA) groups as the custodian of the what and how IT systems and applications should enable business processes. Is it driven by ideal state scenarios or empirical evidence of what works? How are you refining and leveraging your Enterprise Architecture to develop a solid foundation for handling future demands and disruptions?

Contributor

    • Dean Pipes, Chief Architect and Chief Technology Officer, Zurich Insurance

Transcript

Sanjog Aul [00:00:00]:
Hello and welcome to this segment on CTN, which is CIO Talk Network. To learn more, please visit ciotalknetwork.com and now the topic for today is How Effective Is Your Enterprise Architecture? The guest for today’s show is Dean Pipes, who’s the Chief Architect and Chief Technology Oficer for Zurich Insurance in North America. Hello Dean, how are you?

Dean Pipes [00:00:21]:
I’m well, thank you. Sanjog, thank you for having me here.

Sanjog Aul [00:00:24]:
Oh, the pleasure is all ours. So you get two titles, so you get two paychecks to the Chief Architect, Chief Technology, Officer. All right, great, so, Dean, the reason we wanted to have you on the show and discuss this specific important topic is while we are trying to disrupt in business processes, in the business models and even in technology, and we are looking to build a solid foundation for handling whatever the current and future demands are being placed on us, we wanted to talk about the different scenarios based on which or ideal scenarios based on which an organization may be developing its enterprise architecture or maybe leveraging heuristics and empirical evidence to do the same and then in what all ways is EA, which is enterprise architecture here positioning itself for basically effectively meeting the demands for today’s business and for tomorrow. So when we look at this, one of the question that does come up is that why is enterprise architecture looked at from outside in as something either not understood or why is it even necessary? Could you shed some light on that?

Dean Pipes [00:01:36]:
Certainly the practice or the discipline of enterprise architecture is probably not something that most people have even heard of. In an organization that’s larger and more mature and has had an opportunity to delve into this enterprise architecture, their first step is to start to delve into creating a common language, a common means to communicate so that you have IT understand what the business is looking for, from a business capability or business process perspective and then to be able to have the business understand what things can IT bring forward and hopefully meet in the middle and negotiate a good solution, it needs to be very interactive. Communication needs to be upfront and early on before projects have really even left the ground. So I think an EA or an enterprise architect, your main focus is to align an organization so that fixing inner workings and giving purpose to projects is clearly agreed to at the beginning rather than somewhere in the middle.

Sanjog Aul [00:02:30]:
Now what you just defined today, if you were to go to any shop which is more going towards agility or agile approach, they say I would not know upfront everything. So I want to be able to maneuver and tweak things as I go along and that’s what works for me. So would you say EA is not for such organizations?

Dean Pipes [00:02:50]:
No, I think agile projects, we have several agile projects that we run here. They fit perfectly into systems where you’ve got a good idea of what the capabilities need to be, even if you’re not quite certain how each feature is going to be implemented but you know, the agile project, the myth around that has always been that agile means that there aren’t requirements and that there isn’t a process but truly there is, and there is a role for an enterprise architect to make sure that as we move down the path and we look at any of the enterprise level components or services or data entities that we might touch, that we actually understand them and expand the blueprint, include that information, so I think agile is a wealth, is a perfect fit in any organization that you’re trying to move forward with your application development in a more expedient manner and deliver what the business expects, even if they don’t know what to do at the beginning of it.

Sanjog Aul [00:03:38]:
So that said, would you say that enterprise architecture is more of a tactic which is essentially utilized to fix an organization’s working, or would you say it is a little more strategic and of a higher cause, which is to give an organization a purpose?

Dean Pipes [00:03:56]:
I think it could fit into either camp, so if your intent is to align to a business strategy, if I were given a project that’s going to implement some new business strategy to open up some market, to optimize a portfolio, or to just simply make things more operationally efficient, you take that from a vision perspective and you bring it forward and you give that project a purpose but you’d put that within some guardrails that the enterprise architects would define. Now, the same guardrails that you would create or frameworks in some case could turn around and fix other areas of the organization as well. A framework or set of guardrails done well has the ability to fix things beyond a single project and I think that’s the important role of an enterprise architect.

Sanjog Aul [00:04:38]:
So would you say that putting those guardrails is primary purpose, and then when I spoke about the word purpose or the higher cause that the organization works towards, would you think that if you build the right type of guardrails, it could give it the shape that it is supposed to get, or is it primarily at a strategy level that you think? So I’m trying to basically discuss enterprise architecture, whether it’s a tactic or is it part of strategy.

Dean Pipes [00:05:05]:
Well, I think that’s where I’m in agreement that it’s actually both. So enterprise architecture is applied within a project as a tactic. However, enterprise architects should be involved in the planning cycle. They should be sitting with business leadership early on to help define and shape the strategy and make sure that what you bring forward of the project makes sense and it’s something you can actually deliver that brings the benefits that you would see on the first phase, perfect, I think you have to be able to cover both the camp. There are times where you have to look at a disruptive technology and you have to go adjust your enterprise architecture to make room for something new and so in that case, you’re really fixing something based on a disruptive technology or innovation that you need to adopt.

Sanjog Aul [00:05:47]:
So if you look at enterprise architecture and the type of roadmaps that we create and we want to actually get that implemented or become the very DNA of all systems and processes that are embedded with respect to technology or IT specifically, would you say that embedding is what helps create a culture of an organization, or on the other side, people say that you got to have a good culture of adoption, of embracing something new and different for you to even put the EA in place, so is it a what comes first?

Dean Pipes [00:06:25]:
Well, I think enterprise architects who are diplomatic and have good communication skills will define the architecture in a way that many people can buy into it and support it and once you start to build processes around enterprise architecture to govern projects and govern the large building parts of an organization that starts to create a blueprint and that in and of itself starts to create a strong culture, it starts to change the culture. Do you start with architecture to change a culture, or do you start with the architect to change a culture? I think that’s almost a chicken and egg kind of question but at the end of the day, the enterprise architect need to be part of a culture that thinks strategically, that evaluates things not just in the context of a project, but in the context of the entire organization, a business strategy that needs to be delivered.

Sanjog Aul [00:07:13]:
Now that we have defined to some extent what enterprise architecture is and where it can impact and how it can impact perhaps. What is the current state in your view? I’m sure you have lived through the years where enterprise architecture discipline itself was morphing and or trying to adapt to what the changing rules of business and the rules of it were. and now where we stand, where do you see it? How much of a match or has it caught up?

Dean Pipes [00:07:42]:
I think in some cases our enterprise architecture is still viewed a little bit as an ivory tower. I think there’s certain deliverables and so forth that enterprise architects produce as part of the really the discipline and practice that aren’t easily consumed or understood by people who don’t do that for a living but I do think that the value of enterprise architecture has started to show the number of times you have to come back to a system and change integration, because perhaps you built the integration with the future in mind, the component reuse, the ability to focus in on the experience of your employees in a user interface and making sure that your user interface can be flexible without a lot of code rework. I think those things are starting to show the promise that enterprise architecture is a worthwhile investment and we certainly feel it here at Zurich.

Sanjog Aul [00:08:32]:
So suppose you would take Zurich or any other place where you may have worked, or you may know your peers who may be in other companies fielding the questions coming from top management that, okay, you have this group here who’s doing something, and yes, you can explain the things that you explained just now in terms of what enterprise architecture does, but show me the money, show me why it’s there and what is your total cost of ownership of keeping this group alive but then what’s the ROI for me putting this group in place? Is it all soft or you could have a hard measure.

Dean Pipes [00:09:05]:
It, a little bit of both. If you look across a small microcosm of a company, enterprise architecture is a little bit harder to measure. If you look across a larger business unit such as ourselves, we certainly see the value in the ability to reuse things, right, the ability to build that enterprise component or service one time and use it in multiple places, we can measure that. When you start looking across a global organization like we are, you can also see where common platform patterns and common integration patterns start to generate some reuse of the learning and the education that went into making the decisions in the first place. So the thing is though, I would also go back to a conversation I had with an HR officer a long time ago.

Dean Pipes [00:09:51]:
He said, I’d love to be able to figure out how to associate each individual’s time with the bottom line on a balance sheet that’s difficult to do and in a space where most of what your work isn’t tangible. We don’t develop code typically. We don’t touch the systems themselves, typically. It’s a little harder to measure that and account for it, except in outcomes that are sometimes two to three or four years out.

Sanjog Aul [00:10:17]:
So if you’re looking at the enterprise architecture, it’s typically seen a company and internally so you’re directing your focus internally to see where I can tweak these things, et cetera. Now, as anything progressive or anything which is seen in a light, where it is progressive, it is looked outwards, which is customer centric, which is related to the ecosystem or the marketplace, how much of that EA focus is shifting from just being pure internally to making it outwardly focused, so, it is seeing in the same direction as the rest of the organization is.

Dean Pipes [00:10:55]:
It depends on the business unit you’re in within Zurich. The unit that I’m in, the Property and Casualty division, we primarily do most of our work through brokers and program administrators. So touching our customer is something that there’s usually a layer in between us and our customer but that being said, that really means that our brokers and program administrators are our customers, so, we have to think about how they interact with us, how they would book business with us. So we have all of our average architects tend to focus on how do the systems work today, how do people use it, what are the pain points, how do we make our processes more efficient, how do we simplify our system and keep common interfaces so that we can put things together more quickly and turn around changes when there are product changes or things in the industry that we need to respond to, that’s one element of it. The other side of it is really we do touch all of our claimants directly and our claimants have to be able to reach us, be able to navigate and work very quickly with us, so the folks in our claims enterprise architecture area, they’re very aware of how our customers work and how we do this.

Dean Pipes [00:11:58]:
Our Chief Claims Officer reminds us often, we’re not just in business to make money, our own business put people’s lives back together when something goes wrong, we share the risk with them and it’s very important to us, so our customer focus tends to be when something has happened that we need to go and help somebody with, so that’s a little bit different for us. We’re not on Amazon selling books to millions of people or many products as opposed to many other people. We’re in the business of putting things back together when things fall over.

Sanjog Aul [00:12:30]:
So when you look at the word architecture as part of this whole phrase, enterprise architecture, you essentially are expected to deliver a blueprint which will serve well to a specific need, which is itemized or expressed by someone who is in a product ownership capacity. So which could mean somebody else is dealing with the customer and they say, I want XYZ capability, a business capability or a technology capability to be created in order for us to do a certain function. Do you think enterprise architects should limit their role to saying, okay, your wish is my command, we’ll draw a line there and we’ll start working backwards or do you actually go back and ask why, so that even before you start working on something, you are not just only building the best blueprint you could, but you also are keeping the company relevant by challenging those decisions?

Dean Pipes [00:13:24]:
For I think it gotta be a dialogue and music to my ears, whenever a business leader comes and says I have a business capability, I want to create or change or modify or so forth, I mean that’s the language enterprise architects love to sit with to begin with. Then you start digging into what’s the value of it, what does it do for you and perhaps even proposing things that maybe easier to do upfront. We could get more value at this point in the project by starting with this capability or this change to the capability. We could deliver it in multiple different ways and hopefully in the best scenarios it’s always a partnership with the business leaders vision and the vision of the enterprise architecting.

Sanjog Aul [00:14:02]:
Would you think that you are asked to or you are expected as an enterprise architecture group to go beyond just feasibility of what is being asked for and wear your creative hat as well because I’m just comparing that to someone who is building a house and they have their whims and fancies and preferences and they go to an architect, so the person may say yes, I can make this or I cannot make this, but instead of that they also start wearing the hat of a designer and say hey, have you tried this design or that design?

Dean Pipes [00:14:32]:
So absolutely expected of us. I think there’s more pressure than ever on IT to come up with innovative ideas and innovative solutions and so we try to actually build that through funnel and approval process to bring in front of our leadership and highlight some of the ways technology innovations have come forward in the ways we think we could apply it to our business, so we are definitely expected to bring things forward and we do quite often.

Sanjog Aul [00:14:57]:
Let’s take a quick break listeners. We’ll be right back and now let’s talk about the different challenges this enterprise group may be facing across multiple organizations, different organizations that are trying to implement it. Not everyone may be fully cooked, they may or not already be fully mature but if they have started their journey or they’re somewhere in between, or perhaps they have brought it to a point where it is actually in place, where all are the challenges in terms of building it, implementing it and even keeping a good governance structure in place. So please stay tuned listeners for the next segment. We’ll be right back.

Sanjog Aul [00:16:34]:
Welcome back. So Dean, if you had to inventory, say the top challenges which may be related to how an organization attempts to build it, to maintain it and or to sell it to rest of the organization so that it’s embraced, where are the gotchas and pitfalls?

Dean Pipes [00:16:53]:
Well, it has many things I think in a large complex organization, having your senior leadership aware of and minimally aware of and supporting something like enterprise architecture is really a mod and the more sponsorship, the more you can engage them as stakeholders and people who actually start to raise their expectation of your IT areas, developing enterprise architectures and growing people into these enterprise architect roles, the more you actually have that become ingrained into the organization itself and I think that’s always the starting point, the faith, we have to understand, support and sponsor this activity.

Sanjog Aul [00:17:32]:
Now if you are looking at those areas, specific areas, and if we have seen in many cases the enterprise architecture could have issues because as you mentioned, like people don’t interpret it properly, so there could be multiple interpretations, different levels of prioritization on how much they should adhere and or even listen to the folks from enterprise architecture and then a flavor of understanding which could lead to fragmentation of how much or to what degree is enterprise architecture adhere to within the organization. These are the challenges which have actually been outlined by people who have been dealing with it, whether as enterprise architects or people who are the end beneficiary of it, so how do we deal with this?

Dean Pipes [00:18:21]:
We’ve gone through a couple of different evolutions of how we organize around enterprise architecture and I would say the model we have today is working well for us today and what we ended up doing is we ended up moving the enterprise architects out of a central capacity, out of the proverbial ivory tower and ingraining them or embedding them into the leadership teams that support the different areas of the organization, such as claims and underwriting and financial and so on and so forth. That way they sit at the table with the leadership team as things begin to bring that enterprise architecture perspective from upfront and also know what kinds of things they need to prepare for so that they’re not caught off balance, okay, project approved, now go define the architecture. It should be something that happens really at the same time. It should be done in parallel, it should be understood in parallel

Dean Pipes [00:19:08]:
but we’ve certainly seen that fragmentation occur, so we also get our enterprise architecture community together once every two weeks and we spend two hours talking through either enterprise architecture topic. Perhaps we’re looking to evolve a blueprint or a framework or standardize on something new. We also look at projects and we review them at peers and a peer review of enterprise architects. While it doesn’t sound like as much fun as it might be to many people, some of the things we talk about are complex, difficult decisions to be made and together as a group, we always find that we are able to look at the project solutions better, sometimes coming out of it with changes we didn’t anticipate but what that whole group brought together as a community or a panel if you will, we’re going to make the decision better for the organization.

Sanjog Aul [00:19:58]:
When you look at an organization as a unit and a self contained unit, that’s great. Where we know all different pieces, the way they are going to move and we to some extent have either control or influence on them but if you look at today’s enterprise, it’s not truly just those four walls. It is also connected to the partner ecosystem and your enterprise architecture, if it doesn’t support that integration across value chain, then it renders our own enterprise as the weakest link in that value chain, which of course has its own risks and costs, so do you think enterprise architecture discipline has evolved to include the integration with external products?

Dean Pipes [00:20:41]:
It has, there’s plenty of room to go. When I think about program administrators, systems and our ability to unify on a single interface so that they can book business easily, quickly and seamlessly with us, we’ve definitely made a lot of progress with the major systems. The integration pattern and perhaps even the data models that go into those sometimes require changes on the other side, so sometimes there’s a translation layer that has to go in between, so we’re definitely invested in and continue to invest in our ability to integrate better with our partners. I think that’s a never ending challenge though. I think when you think about how the chain of supply would be for any industry. The needs change as it moves down the different layers in the supply chain

Dean Pipes [00:21:25]:
so you’re always going to have to adjust to, well, we now need to track this attribute, we now need to track this type of information and then that ripples through the whole value chain. Does that make sense?

Sanjog Aul [00:21:35]:
It definitely does and so as you said, there is some room there and we are just trying to figure out if integration, so if you were to really take the remaining challenge or what you would like to see happen in this world of integration, for the enterprise to really be seen as a strong link in that value chain, what would be happening in that enterprise architecture domain?

Dean Pipes [00:22:00]:
For industry standards, help us to align to a single vernacular and integration pattern, so think of the accord format for our industry. The more we can get into the basics of operating within that model is going to make things easier out of the gate and long term, however, that standard may not cover enough of the information that meets our particular product, our particular brosure or program needs and so forth, so that’s when we have to come back to the table and start figuring out do we go push the industry standard, do we just implement this with a given part of our supply chain, part of our partner ecosystem, or do we just make the changes on this particular one and get on with life because it’s not going to be something worth investing in for long term and those are the types of conversations we hope to have internally and externally.

Sanjog Aul [00:22:48]:
One of the pitfalls that has been shared by the community with us is that when we are creating the enterprise architecture, after gathering the initial business requirement, the enterprise architecture group may end up saying, oh we’ll be back once we have developed the blueprint versus making that whole blueprint creation process being truly collaborative, where they are also given an insight so as to how are you going about doing it. While they don’t need to become the technical people that the enterprise group may be, but that collaboration portion is missing, so it is more like a black box, EA group becomes a black box to the rest of the organization, which also creates distrust. How do you open up that black box to the rest of the organization and also benefit as a result?

Dean Pipes [00:23:36]:
Well, it goes back to that common language and the common perspective. I mean we have established what we call our four tier architecture so that when we’re describing changes within an environment, you would talk about it being at the top tier, which is the UI, or it could be at the services layer, which is how things integrate at how information is moved around the support process, it could be at the business component layer that we’re actually making changes, or perhaps at the data layer and if we have that agreed to mindset walking into it that this is how we describe the work we’re about to do, we can then be transparent about how we’re thinking about evolving it and we can talk about the implications both from an IT perspective as well from a business.

Sanjog Aul [00:24:18]:
And during the time when you’re going out there and drawing pictures, do you think there could be changes in business that could be happening or disruptions that could be happening? Some decisions may be made, but then since you were considered as a separate unit, do you think there is an implied understanding or explicitly stated guideline that anytime any change is happening, even though we might be busy building pitch making pictures, you got to come and report back to us so we can incorporate it versus you go back in circles multiple times, or even worse, not go through circles, but present something which is not as relevant as when you started.

Dean Pipes [00:24:58]:
This is where I would say this needs to be more viewed as a process, right? This is the process of the discipline of enterprise architecture. I will deliver the following deliverables in a draft state at this milestone of the project because we have that defined in our project management framework. The project manager expects you to deliver during a certain point and then there’s a review that occurs and here are the key stakeholders, sit in the room and it’s not by name, it’s by role and so each project can follow that same pattern that helps to create a predictive side of it. It also helps to ensure that the enterprise architect is at the table developing these things and helping to drive the conversations from an architecture perspective early on and provide update as changes to that may occur.

Sanjog Aul [00:25:42]:
So would you say that when we go about doing say a current state diagnostics of where we stand? When you suppose coming into an organization and invited as say a consulting is invited as a consultant to an organization which wants to develop an enterprise architecture, how would you get started with this current state diagnostics on where it stands and does it even have an informal enterprise architecture which we need to formulas? What would be your first steps?

Dean Pipes [00:26:11]:
My first step would be to look at the business capabilities and identifying what are the areas where they’re seeing issues or their aspiration for the most evolution of a business capability and use that as the language that you begin to anchor on. Go through your business capability at a fairly quick rate, but come through with some measures of does it meet expectations? Does it not meet expectations if not, come up with a couple of bullets that explain why it doesn’t meet expectations, but that you can very quickly generate a heat map to indicate these are the areas we need to go focus on them and you can start to look at that heat map of capabilities and draw boxes around and see if we go invest in this area, we might affect two, three or four of both capabilities in a positive way. You start the conversation from that perspective. You keep the business at the table through the entire conversation. Then when you start to come back around and initiate project, you can point to how the project is going to start to remove some of the pain points or establish new features or business capabilities along the way. That’s how I would start.

Sanjog Aul [00:27:14]:
That’s great. So let’s take a quick break listeners. We’ll be right back and let’s talk about funding and the sponsorship and the support from people above us and people, the ones who we need to work with and the end business user who’s supposed to embrace enterprise architecture group is in a position of influence versus the position of control. How do you make things happen inside out, but also with the required level of sponsorship, support, blessing and adoption for whatever you create. Please stay tuned listeners. We’ll be right back.

Sanjog Aul [00:28:50]:
Welcome back. So it’s definitely not as easy when you have only a position of influence versus a position of control within the organization that you are trying to impact. So Dean, from your vantage point as the Chief Architect alone, I know you’re a CTO as well but if you were to look from that vantage point, what is your best way to get the support, the sponsorship and adoption from all parties?

Dean Pipes [00:29:20]:
The role of an enterprise architect is ideally like as we’ve discussed already, a strategist and a forward thinker and has some vision. So I tend to take the mindset of I’m going to study something, I’m going to understand the business capabilities as they sit today or disruptive technology and how it might fit into the organization and my goal would be to paint a picture that talks about the future and present it as such that I’ve seen the future, I’ve been there, I know what it looks like and why we need to get there and here’s the path forward, right, so the role of an enterprise architect can’t be somebody who sits behind a monitor and just make pretty visual diagrams all day. They have to be able to communicate it. They have to be able to convey the vision, and they then garner sponsorship for not only the work they’ve just done, but doing more work like that. So I think showing and telling is probably the most important aspect of being an enterprise architect. It’s back to those communication skills, and I almost want to say salesmanship to the business leaders who would buy into it and want to move forward.

Sanjog Aul [00:30:23]:
So now that you said that, I’m assuming that you’ve been able to successfully lay a path for other successors who could follow your footsteps but to some extent, when you say that we should be communicating well and demonstrate the type of leadership that is to be demonstrated, that still is kind of fuzzy for people who may have tried it but have not been successful. What are your questions for people who may be listening and saying, okay, I would like to do it better, but don’t know how, because whatever he said, I tried.

Dean Pipes [00:30:56]:
Well, I guess I would ask the question if they’ve been looking at business capabilities and they truly understand the gap of current state and the aspired state that the business unit would be looking for and bearing in mind too, business leaders obviously have lots of different personalities. In some cases, perhaps you shuffle the enterprise architects around where one person has a slightly different approach than another. You share domain knowledge and you work through some things and perhaps it’s a personality fit that needs to make much and our enterprise architects all have to operate within the mindset of we don’t move forward unless the business agrees to it which means we have to be thinking about business solutions and until the business believes that, until the business is convinced that you are working toward their best interest, your credibility is always going to be challenged

Dean Pipes [00:31:43]:
and sometimes they take years to develop at the senior levels of an organization because senior leaders are very busy and the last thing they want to do is be sitting thinking about the diagram the city planner would put together unless it’s actually delivering the vision that they’ve been delivering part of their communication.

Sanjog Aul [00:32:01]:
So you just mentioned that sometimes that trust building or that camaraderie that you are expecting between the EA and the business takes years and more than any time before, now we are most impatient as business as executives and most people who may have come in into an enterprise architecture group may not even have the choice or a chance to prove themselves before they’re ousted or they are repurposed within the organization. So where does that lead an EA group? So can you fast track that in somehow so that people at least get a chance to show what they want to show? So what have you seen done in other organizations or other peer groups that you may know who may have built some sort of an agile approach to getting EA adopted as a group, as a discipline within the organization?

Dean Pipes [00:32:53]:
I think one of the keys for myself and the enterprise architects I work with here is that it’s all about the business strategy or project objectives, so not focused on that. We just focus, focus, focus on those things and remember that we always have the other members of our C suite as our stakeholders. So don’t go build the million dollar kitchen when all somebody wants to do is hook toast in two weeks. So that’s where I think the reality check that we as enterprise architects need to have is to somewhat stay away from the shiny object, make sure there’s business justification for what we’re doing and be very clear up front. We are looking out for the business’s best interest. That’s a dialogue that I think every business leader appreciate.

Sanjog Aul [00:33:39]:
So if I were to, in simple terms define what a business truly wants to do or does, it wants to grow through profitability and innovation, it wants to save through any efficiencies it can bring about, it wants to keep its crown jewels safe, which is to keep the organization secure and it wants to sustain through any disruption. Those are the things that it wants to do. Yes, IT happens to be there enabling it and to that end, enterprise architecture is a means to an end to get there. How much of your alignment is to those four objectives that a business has versus one box at a time?

Dean Pipes [00:34:22]:
I think it depends a lot on the economic environment that you’re operating within. There are definitely annual initiatives where sometimes your focus is on operational efficiency and driving down spend and if that’s the case, then your focus on the initiative to be to look at opportunities for ways to lean out the organization through IT driven initiatives. We’ve certainly had our experience with those, right? We have looked at optimizing our data centers, we’ve looked at virtualization, we’ve looked at consolidating things into platforms to make things run at a higher level of utilization and drive out some of that cost and then there are other situations. Perhaps we talk about mobile as a disruptive platform and a property and casualty insurance world. We decided, let’s go look at mobile. Let’s create a center of practice for our mobile environment.

Dean Pipes [00:35:11]:
Let’s understand what the tools would be, let’s understand what the process would be and let’s define those things. Let’s make sure we do have some governance but that governance isn’t just enterprise architecture. It should include business privacy concerns and legal concerns and all of those pieces and you put the people in room and you say, this is now the vehicle by which a mobile project would get approved and it consists of business people bringing forward ideas. I want to do a mobile app. What are they going to do, what’s the business benefit of doing it, and then we are able then to help drive that forward.

Dean Pipes [00:35:40]:
So part of it is knowing what we’re going to need to have to do as soon as the business is aware of something that they want to do. A little bit of a crystal ball there, So we have to be forward thinking and we have to have our ears to the ground. We have to be looking at what the technology companies are bringing forward, so we always have it in our hip pocket to be able to have the conversation when the moment is right.

Sanjog Aul [00:36:02]:
I use the term business architecture on the last segment and that particular group is gaining steam and it is actually becoming more visible. The million dollar question is that when in the past then IT used to be different from business, now IT is part of the business embedded in it. There’s no alignment, there’s a convergence. Then why is business architecture abstracted from EA, why both of them are not one.

Dean Pipes [00:36:31]:
Well, for us, business architecture sits still within the architecture practice, although it is a different group but the expectation is that they’re helping us to create the business models. We need to be able to see capabilities, we need to be able to decompose capabilities into processes. We need to be able to decompose processes into tasks and then the enterprise architect come to the table and say, this is how your world works. This is how the systems support that to work, so now you have a partnership with business architecture to be able to better describe the real world implications of what changes or disruptions or innovations you might be bringing into the environment, so while it is a separate group and it is a different practice, it’s very much focused from a business inward versus enterprise architecture is from the IT inward.

Sanjog Aul [00:37:19]:
So Would you rather have those business architecture people become the pseudo business analysts of sort or the liaison with the business because they are talking the lingo that business understands and let them become the translators for you versus EA group trying to become the business architecture group where their end goal is not same as those and that’s why they’re not talking perhaps the same language. So the reason I’m bringing this up is because you opt to be one if you could be, or you could have this layer in between and you don’t have to battle with that translation challenge that we are seeing over and over. What do you think about that approach?

Dean Pipes [00:37:59]:
I think business architects and enterprise architects aren’t that different and if I were to take any one of our enterprise architects or our business architects and create a rating system that says from a given technology, one being low and five being high, this person is a two, but from a business domain this person’s actually a five and from a communication and leadership skill set, this person’s also a five, that person would obviously lean towards being a business architect. If I reduce the business knowledge slightly and then increase the IT knowledge, you might be more aligned with the enterprise architect side but the question becomes how do you grow and make sure that the business architects understand the technology and the landscape that you already have? I mean, we’re a century old company, we have a lot of technology and some of it’s been around for decades. They need to understand that changing those things are very difficult and costly but by the same token, your enterprise architects have to understand how the business works. So while there’s some negotiation that would happen between them, at the end of the day it should come out with an aligned message and a common language.

Sanjog Aul [00:39:06]:
When we are looking at, say, I’ll give you an example of security, so I was having a discussion with a bunch of CISOs at an event and the discussion was how do you justify security because it is also a soft sell, so, gentlemen came up with an idea or they’ve actually implemented is to create a line item for security in each project so that you can say that without this security audit or a proactive approach to evaluating how secure this particular change or project is going to be, it will not go through and that’s how they were able to connect it to some sort of an ROI and a business case and since we have spoken about funding and getting it funded on a regular basis and sponsorship, what is the possibility of EA being embedded at a project level versus the ivory tower which you mentioned is anyway, scoffed at.

Dean Pipes [00:39:58]:
Well, there’s a couple of things there. I think the statement about having information security as part of your project management framework is a good one. It’s what we do right and our larger projects, we will have some level of a security analyst or even a security architect engaged in the project in the very beginning. I mean not unlike what you might do with procurement if you know there’s going to be a lot of procurement activity, so, building the project team up front should include all of these disciplines. Now in our case, before a project is proved to move forward for funding, before it actually goes to the final council for approval to execute, it has to make it through the gate of enterprise architecture, which means somebody has to be assigned to the project to deliver the enterprise architecture deliverable, to actually present it to the design review team and then gain alignment that this is the right thing to do, where we’re using what we should and the new things that are coming in as new are things that we all support. I think that in and of itself creates a project team that has a resource plan that project managers are very good at managing and in an ideal world, your enterprise architect eyes on the horizon and the strategy and the project manager has eyes on the tap, due date, deliverables and resources and enterprise architect is simply one of the resources.

Sanjog Aul [00:41:16]:
Talking about leadership we’ll take a quick break but when we will be back, let’s talk about how do you put the right person at the top for this EA group, enterprise architecture group for them to be able to be the pie piper for the enterprise architects in the company plus also who has the capability, the charisma, the influence that they can take the business along in the right direction. This is also dependent on how this individual brings the enthusiasm, the communication, the passion and also has respect in the community and is strategically minded. How do you get all in one leader and since you are a Chief Architect, would love to learn from you Dean. How did you acquire these skills for you to justify yourself to be the leader of your group. Please stay tuned listeners. We’ll be right back.

Sanjog Aul [00:43:12]:
Welcome back. So it has been a very common problem where EA failed because of the leader who, while understanding the enterprise architecture as a discipline, did not have the leadership skills and did not have the appropriate background to develop the organizational structure, the staffing, and on top of it, did not have the communication, the passion, enthusiasm, respect and strategic mindset. So how do you get this unique animal to first of all be identified or groomed from within or maybe identified from outside to take this top role and what happened with you, how did you land here?

Dean Pipes [00:43:54]:
Well, our CIO is he’s been in this business for decades and he’s seen how the organization has operated, he’s seen patterns, he’s seen things that have occurred that work well and he sees things that haven’t worked well and the institution of our role of a chief architect started over a decade ago and he was my manager in mentor for years and we used to have the conversations of how do you develop an enterprise architect? Where do they come from? Which really means an enterprise architect typically starts as somebody either as a business architect who’s learned the technology or as a technical or solution architect who’s continued to expand their scope and expand their span of influence and that person becomes somebody who naturally project teams gravitate towards. I would like to have so and so on my team because last project we were on, it went great and I want more and then that person over time grows into different domains and disciplines and then hopefully through coaching and mentoring, that person will rise to the level of an enterprise architect. Now when I say rise to the level of an enterprise architect, to me that really means the span of view that you have to have.

Dean Pipes [00:45:05]:
You no longer have the time to deep dive into the latest version of dot net that came out. You need somebody else to do that and provide you a good summary and teach you the things you need to know and why that would be important and then moving into the chief architect role, as I said, I had a great mentor in this role. He’s head of IT for Canada for us now. He was a great coach. You know, be close to the business, go make your value known with the business, go do the things that are important as an enterprise architect and those things will speak for themselves. That was really the coaching that was given very early on by him and I took it very much to heart

Dean Pipes [00:45:40]:
and has led to my success and the continued evolution of my career here. Our CIO, though, and his leadership team all know what the architects do. They all understand that it’s a necessity. They’re all bought in and so the eyes turn to us when it comes to going through these various project reviews. We are held accountable for making good decisions and when you have an organization that’s changed the culture to expectation versus necessary evil, that’s when it becomes a real career opportunity and that’s when it becomes fun.

Sanjog Aul [00:46:15]:
If you were to develop a boot camp for EA, including which turns out that the right level or quality of enterprise architects and the chief architect, what would the playbook look like? What would that curriculum look like?

Dean Pipes [00:46:33]:
Well, it would start out by saying, day one, if anybody utters a term about technology, I’m going to ask you to do something like dance on the table, do something you don’t want to do, sing a song. Let’s keep the conversation around technology. Let’s keep the conversation focused in on how do we describe capabilities, whether they’re technical capabilities or business capability. How do we derive the conversations that we want to have with the business so that we continue to further that strategy and then the next part of the agenda would be to talk about what is that business strategy and what can we be doing to help either protect, enable or accelerate the delivery of that strategy. It should all be strategy driven, it should all be conversational and if somebody starts talking about, “oh, we should just go implement this new framework”, well, they’re going to be the first one that has to sing a song in the room, and then start doing the job of an enterprise architect as it’s appropriate in your organization. There are also great frameworks out there. There’s some great certifications to get,

Dean Pipes [00:47:37]:
if people are just interested in the thinking and how an enterprise architect works, there’s obit and togap. I mean, those are some great classes to go take. Even if you’re already a practicing enterprise architect, you’ll learn a few things and you’ll find a few communication mechanisms or perhaps a few concepts you want to apply in your own world.

Sanjog Aul [00:47:55]:
Typically, it’s been seen that people who have come from technology background are the ones who are invited into the enterprise architecture group. Do you think there is value in you transforming some people from business who would not be tempted to think technology and then business be better candidates, or at least comparable candidates for the EA group because that’s going to bring you that healthy mix which you’re looking for in the first place versus trying to transform a person’s fundamental DNA.

Dean Pipes [00:48:26]:
I think that is a great opportunity if you can find one but one of the key characteristics of that individual needs to be that they have a curiosity and interest in the technology and oftentimes people who have spent their entire career in the business haven’t really been all that interested in any of the technology that an enterprise runs. They learn just enough to be able to do their job but you have to have some curiosity, you have to spend some extra time learning something. You have to go talk to vendors and understand their roadmap so that you understand what the next major release could bring to your organization and if there’s not that natural affinity, that natural curiosity, then it’s going to be a little bit of a square peg and a round hole.

Sanjog Aul [00:49:07]:
If you had to give advice to other leaders who may be CIOs or other technology leaders who are finding that their EA practice is floundering or it’s not really creating the value that they thought it should, what should be the first few things they opt to be doing to fix that.

Dean Pipes [00:49:31]:
A lot of times we go to a root cause analysis and we think that we’re going to find a solution within the root cause. Sometimes simply taking a step back and defining what your objectives are and expecting people to deliver new objectives is really what leaders need to put forward. A very clear sense of deliverable, a very clear sense of accountability. Some of the things that our project managers do that help fun is producing raci matrix version and when you see your name in that column and you’ve got an R underneath you and you’ve got to go do something, it becomes very clear this is the work I need to go do. If I don’t have the skills or if one of my colleagues doesn’t have the skills to deliver that, I need to go get help. I also need to have that culture that says I can reach out to my peers, my colleagues, and get assistance to getting through areas where I need to grow and expecting people to grow. I think that is culture that needs to happen

Dean Pipes [00:50:21]:
as enterprise architecture isn’t magic, It is a discipline, it is a practice. It’s something that can be taught and it’s something that can be defined within a process and if you think about it from those terms, then it’s just like fixing any other problem you may have in it or in a business. That’s what I would recommend it. Think about it like you would any other problem. What do you expect to get out of enterprise architecture, what’s your vision and then building a plan to get there.

Sanjog Aul [00:50:48]:
One last question. 30 seconds. If you had to get a crystal ball, or perhaps not crystal ball, the way you see the enterprise architecture evolving, what would be the best way organizations can prepare besides doing the things which you mentioned to fix the problem but if they are to get ready for the future, what would be the new or better things or more things that they ought to be doing?

Dean Pipes [00:51:13]:
I think enterprise architecture is something that more people could be aware of and more people could think about and it’s almost irrespective of their role in IT. If they understand how systems connect to each other, if they understand integration patterns, if they understand how we build stuff and what we do with things, it’s going to reduce the amount of explanation and documentation and show course that the enterprise architect would need to do and I actively see that happening in my organization. Every project manager that I work with ends up knowing more about the technology than I think they expected to and if I’ve done my job well, they’re excited about it, they’re interested in it, they wonder how it’s going to play out, they wonder how the next version is going to look like and show for it starting. Enterprise architects also need to have a bit of an energy to them, a bit of an excitement. There isn’t a single project on my plate that I don’t get thoroughly excited about when I get the opportunity to sit down and start working on a piece of it.

Sanjog Aul [00:52:08]:
On behalf of the show and our listeners, I’d really thank you Dean, for sharing your thoughts on how effective is enterprise architecture for an organization, how to diagnose that and how to fix it, or perhaps move it to a point where it is ready for the future. Thank you so much again, Dean.

Dean Pipes [00:52:27]:
Thank you very much again. I appreciate the opportunity to be able to show it to you.

Sanjog Aul [00:52:31]:
Beautiful. Thank you so much and listeners hope you enjoyed it. Please like us on Facebook, search for CIO Talk Network and be sure to follow us on Twitter and LinkedIn. Thank you again for listening to this segment on CIO Talk Network. This is Sanjog Aul, your talk show host. Till next week take care and god bless.

Download Podcast
Apple PodcastGoogle PodcastSpotifyPandoraiHeartRadioSoundCloud, TuneIn, and Stitcher. Find other syndication channels here or search CIO Talk Network podcast on any other app.
Explore More

Contributors

Dean Pipes

Dean Pipes, Chief Architect and Chief Technology Officer, Zurich Insurance

Dean Pipes is Chief Architect and Chief Technology Officer for Zurich Insurance in North America. Zurich Insurance is a global leader in managing risk. In North America, Zurich is one of the largest commercial property and casualty insurers... More   View all posts

Transcript

[advertisements]   Sanjog: The topic for today is how effective is your enterprise architecture. The guest for today's show is Dean Pipes who is the Chief Architect and Chief Technology Officer for Zurich Insurance in North America.   Hello Dean, how are you?   Dean: I'm well, thank... More  
Add Comment
Click here to post a comment

Advertisement

Zones-Service Banner-MPU-350x250
Dean Pipes