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 you Sanjog. Thank you for having me here.

Sanjog: Oh the pleasure is all ours. So, you get two titles, so you get two paychecks so the chief architecture–

Dean: No– [crosstalk]

Sanjog: All right, great. So Dean the reason we wanted to have you on the show and discuss the specific important topic is, while we’re 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: Well 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 IT can bring forward and hopefully meet in the middle of negotiating good solution. It needs to be very interactive, communication needs to be upfront and early on before projects of really even left the ground. So I think an EA or an enterprise architect, it’s that 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: Now what you just defined today, if you were to go to any shop which is more going towards a agiled 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 from me. So would you say EA is not for such organizations?

Dean: 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 the agile projects, 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 to include that information. So I think agile as well as it 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 it is at the beginning of it.

Sanjog: So that said, would you say that enterprise architecture is more of a tactic which is essentially utilized to fix an organizations working or would you say it is a little more strategic and off a higher cause which is to give an organization a purpose?

Dean:I think you could fit into either camp. If your intent is to align to a business strategy, if I were doing a project that’s going to implement some new business strategy to open up some markets 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 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: 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 had a strategy level that you think? So I’m trying to basically discuss enterprise architects over whether it’s a tactic or is it part of strategy?

Dean: 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 is a project makes sense and it’s something you can actually deliver that brings the benefits that you would see in the business case. So, enterprise architecture have to be able to cover both camps. 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 need to be adjust to.

Sanjog: 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 off 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 often organization or on the other side people say that you’ve got to have a good culture of adoption or from embracing something new and different, for you to even put the EA in place. So what comes first?

Dean:  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 moving parts of an organization that starts to created a blueprint. And that in and of itself, starts to create a strong culture and starts to change the culture. Do you start with architecture to change a culture or do you start with the architects 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 architects need to be part of a culture that think strategically, that evaluates things not just in the context of a project. But in the context of the entire organization of business strategy that needs to be delivered.

Sanjog: Now that we have defined to some extent what enterprise architecture is and where it can impact or how it can impact perhaps. What is the current state in your view? I’m sure you have lived through the years so the 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 it has it caught up?

Dean: I think in the some cases enterprise architecture is still viewed a little bit as an ivory tower and think there’s certain deliverables and so forth that enterprise architects produce is part of 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 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 work.

Sanjog: So suppose you would take Zurich or any other place where you may have worked or you may know your peers who maybe in other companies fielding the questions coming from top management, that okay, you have this group here who is doing something and yes, you can explain the things that you explain just 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: It’s 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, 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 that, 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 is 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: 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 etc. Now as anything progressive or anything which is seen in a light where it is progressive, it is looked outwards, which 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: It depends on the business unit you’re in within the Zurich. The unit that I’m at 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 ministers are our customers. So we have to think about how they interact with us, how they would do business with us. So we have all of our enterprise architects tend to focus on how 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 systems in keep common interfaces so that we can put things together more quickly and turn around changes when there are product changes or things than 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 from our chief claims officer reminds us often. We’re not just in business to make money or in business to put people’s lives back together when something goes wrong. We share the risk with them and it’s very important to us.

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 I suppose to many– other people. We’re in the chip– we’re in the business of putting things back together when things fall over.

Sanjog: So when you look at the word architecture as part of this whole phrase enterprise architecture, you essentially are expected to do it 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 good being somebody else is dealing with the customer and they say, I want X, Y, Z capability, a business capability or a technology capability to be created in order for us to do certain function. Do you think enterprise architects should limit their role to saying, your wish is my command, we will draw a line there and we will 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: I think it’s got to 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 within to begin with. When you start digging into what’s the value of it, what does it do for you and perhaps even proposing things that may be easier to do upfront, we could get more value at this point in the project by starting 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 leader’s vision and the vision of the enterprise architect.

Sanjog: Would you think that you would ask to or you’re 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: I think that’s absolutely expected of us. I think there’s more pressure than ever, an IT to come up with innovative ideas and innovative solutions. And so we try to actually build that through a funnel and approval process to bring in front of our leadership highlight some of the ways, technology innovations have come forward in the ways, we think we could apply to our business. So we are definitely expected to bring things forward and we do quite often.

Sanjog: Let’s take a quick break listeners, we will be right back. Let’s talk about the different challenges this enterprise group may be facing across multiple organization. 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 there’s 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: 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: Well, as 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 must. And the more sponsorship, the more you can engage them as stakeholders and people who actually start to raise their expectations 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 C-suite has to understand support and sponsor this activity.

Sanjog: Now if you are looking at those areas, specific areas and we have seen in many cases the enterprise architecture, could have issues because as you mentioned like people don’t interpreted    properly, so there could be multiple interpretations, different levels of prioritization and 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 degrees have to present architecture adhere to within the organization. These are the challenges which have actually being 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: And 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 architecture out of a central capacity, out of the proverbial ivory tower. And ingraining them or abetting 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. But where they sit at the table with the leadership team as things begin to bring that enterprise architecture perspective, from upfront also know what kinds of things they need to prepare for so that they’re not caught off balance. Okay, projects approved, now go to find 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. 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 topics, perhaps we’re looking to evolve a blueprint or a framework or standardize on something new. We also look at projects and we review with them as peers. And a peer review of enterprise architects, well, it doesn’t sound like as much fun as it might be, to us, 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 projects solutions better. Sometimes coming out of it, which changes we didn’t anticipate. But with that whole group brought together as a community or a panel if you will, we’re going to make the decisions better for the organization.

Sanjog: When you look at an organization as a unit and as 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 the 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 parties?

Dean: 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 patterns 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 the never ending challenge though. When you think about how the chain of supply would be for any industry that needs change as it moves down the different layers in the supply chain. So you’re always going to have to adjust to. 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: Oh, definitely it does. And so as you said there is some room there, and we’re 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 us enterprise to really be seen as a strong link in that value chain, what would be happening in that enterprise architecture domain?

Dean: Well, industry standards help us to align to a single vernacular integration pattern. So I think if 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 right out of the gate and long term. However, that standard may not cover enough of the information that meets our particular products or particular broker or program needs and so forth. So that’s what 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, I want to 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: The 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, we will be back once we have developed a 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 maybe. But that collaboration portion is missing so it is more like a black box. And if 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: Well, it comes back to that common language and the common perspective. I mean we have established what we call our fourth year 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 and how information is moved around the support processes. 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 perspective.

Sanjog: And during the time when you’re going out there and drawing pictures, do you think there could be changes in business that would be happening or disruptions that could be happening some decisions may be made. But then since you are considered as a separate unit, do you think there is a implied understanding or explicitly stated guideline that anytime, any change is happening, even though we might be busy making pictures, you’ve got a comment 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: This is where I would say this needs to be more viewed as a process. 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 that in the room. And it’s not my name, it’s by rules, 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 provides updates as changes to that may have occur.

Sanjog: So would you say that when we go about doing say a current state diagnostics off where we stand, when you suppose coming into an organization and invited and say, Dean, 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 form as, what would be our first steps?

Dean: My first steps would be to look at the business capabilities and identifying what are the areas where they’re seeing, issues or their aspirations for the most – evolution of those business capabilities. And use that as the language that you begin anchor on. Go through your business capability at a fairly quick rate. But come through with some measures of, does it meet expectations or does it not meet expectations, if not come up with a couple of bullets that explain why it doesn’t meet expectations. So that you can very quickly generate a heat map to indicate these are the areas we need to focused on, and you can start to look at the heat map of capabilities and draw boxes around and say, if we go invest in this area we might affect two, three or four of those capable in a positive way. You start the conversation from that perspective, you keep the business of the people through the entire conversation. Then when you start to come back around and initiate projects, 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: That’s great. So let’s take a quick break listeners, we will 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 they and 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 will be right back.

Sanjog: 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 effect 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: The rule of an enterprise architect is, ideally like as we’ve discussed already, a strategist in 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.

The role of an enterprise architect can’t be somebody who sits behind a monitor and just makes pretty physio diagrams all day. They have to be able to communicate it. They have to be able to convey the vision. And they 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 its 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: 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 has 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: Well I guess, I would ask the question, if they’ve been looking at business capabilities and they truly understand the gaps of current state and the aspired state but the business unit would be looking for. And baring my two 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 sense. 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. And sometimes that takes 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 diagrams a city planner would put together. Unless, it’s actually delivering the vision that they’ve been espousing is part of their communication.

Sanjog: 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 you know 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 are ousted or are they out of repurposed within the organization. So where does that lead and EA groups? So, can you fastrack that in somehow? So that 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: Well, 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, and focus 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 cook toast in two weeks. And so that’s where I think the reality checks that we as enterprise architects need to have is to someone stay away from shiny objects. Make sure there’s business justification for what we’re doing. And be very clear up front, we are looking out for the businesses best interest. That’s a dialogue that I think every business leader appreciates.

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. And 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.

Sanjog: 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 in driving down spent. And if that’s the case then your focus on the initiatives needs to be to look at opportunities for ways to lean out the organization through IT driven initiatives. And we’ve certainly had our experience with those. 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 utilization and drive up some of the cost. Some of them are other situations perhaps we talk about mobile as a disruptive platform. In a property and casualty insurance world, we decided, let’s go look at mobile, let’s create a center of practice for mobile environment. 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 and IT, it should include business privacy concerns and legal concerns and all of those pieces and you put the people in a 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 is it going to do? What’s the business benefit of doing it? And then we’re able to help drive them forward 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, right? 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: I use the term business architecture in 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 is no alignment, there’s a convergence, then why is business architect abstracted from EA, why both of them are not one?

Dean: Well for us, Business Architecture sit 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 compose processes into tasks. And then, the enterprise architects come to the table and say, this is how your world works, this is how the system 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 are 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: 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 they are and the goal is not same as those and that’s why they are not talking perhaps the same language. So the reason I’m bringing this up is because you ought 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’re seeing over and over. What do you think about that approach?

Dean: Well, I think Business Architects and Enterprise Architects aren’t that different. And if I were to take any one of our enterprise architects or a 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 skills, that this person is also a five person. 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. We need to understand the changing those things that are going to be very difficult 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 ally and a message and a common language.

Sanjog: I’ll give an example of security. So I was having a discussion with a bunch of CISO’s at an event and the discussion was how do you justify security because it is also a soft sell. So a gentleman came up with an idea, or they have 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 in 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 mention is any of a scoffed at.

Dean: Well so there’s a couple of things there. I think the statement about having Information Security is part of your project management framework, is a good one, it’s what we do. In our larger projects we will have some level of security analyst or even a security architect engaged in the project the very beginning. I mean, not unlikely 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 approved 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 deliverables to actually present it to the design review team. And then gain alignment that this is the right thing to do, we’re using what we should and the new things that are coming in as new, are the things we all support.

So 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 as eyes on the horizon and the strategy and the project manager has eyes on the tasks, due dates, deliverables and resources and enterprise architecture is simply one of the resources.

Sanjog: 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 Pied Piper for the enterprise architects in the company plus also who is 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 a 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 the skills for you to justify yourself to be the leader of your group? Please stay tuned listeners, we will be right back.

Sanjog: 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 off 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 learn here?

Dean: Well, for CIO is – he is been in this business for decades and he’s seen how the organization has operated. He is seen patterns, he is seen things that have occurred that worked well. And he sees things that haven’t worked well. The institution of our role of a chief architect started over a decade ago. And he was my manager and 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 with 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 on and so on in 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 disciplines. And 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, it’s the span of you that you have to have. You no longer have the time to deep dive into the latest version of Dotnet 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 is head of IT for Canada for us now. He was a great coach. 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. And that was really the coaching was given very, very early on by him and I took it very much to heart and has led to my successes in 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 to 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 what becomes fun.

Sanjog: If you were to develop a boot camp for EA, including which churns out the right to level quality of enterprise architects and the chief architect, what would the playbook look like, what would that curriculum look like?

Dean: 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 capabilities. 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 the 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, they are going to be the first one has to sing a song in a 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 and there are some great certifications to get if people are just interested in the thinking and an enterprise architect works. There’s Tobit and Togas, 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 align in your own world.

Sanjog: Typically it’s been seen that people who have gone from technology background or the ones who are invited in to do 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 compatible candidates for 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: I think that 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 an 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 some things, you have to go talk to vendors and understand the 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 in a round hole.

Sanjog: If you had to give advice to other leaders who may be CIO’s or other technology leaders who are finding that their EA practices floundering or it’s not really creating the value that they thought it should, what should what should be the first few things they ought to be doing to fix that?

Dean: Well, I think 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 cost. 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. And some of the things that our project managers do that help us, is producing racy matrixes. 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 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 to get assistance, to getting to the areas where I need to grow. And expecting people to grow. I think that is the culture that needs to happen is. 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 an IT or in a business. That’s what I would recommend is think about it like you would any other problem what do you expect to get out of an enterprise architecture, what’s your vision and then building a plan to get there.

Sanjog: 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 newer better things or more things that they ought to be doing?

Dean:  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 IT. If they understand how systems connect to each other, they understand integration patterns. As they understand how we build stuff and what we do with things. It’s going to reduce the amount of explanation and documentation and so forth 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 so forth. So I think 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 fairly excited about when I get the opportunity to sit down and start working on a piece of it.

Sanjog: On behalf of this show and our listeners, I 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: Thank you very much again, I appreciate the opportunity to be on the show.

Sanjog: Beautiful. Thank you so much. And listeners, hope you enjoyed it. Please like us on Facebook, search for CIO Talk Radio, please be sure to follow us on Twitter. Thank you again for listening to CIO Talk Radio. This is Sanjog Aul, your talk show host. Till next week, take care and God bless.