 Please a warm welcome for Bob Weisman. Thank you. Make sure the clicker works. Great. Delighted to be here. Next. Okay, good. This is just the abstract. You've already seen that. Personally, what happens is I've been on the client side for 30 years. I was a member of government, mainly in defense for that. After that, I was 10 years over at CGI where I started the EA practice and insist that we start using open standards and the TOGAF. And this was back in 2004. So I'm a long-term supporter of open standards and some of the lessons learned might drive that home for you now. Most of my time now is spent doing pro bono work, working in the university, educating the people, as they say in French, Don Berceau, in the cradle. So we get the young students, we get them thinking enterprise architecture from the get-go. So I'll just give you a quick introduction. I'll come to you from some lessons learned. Now we're trying to distill 40 years' worth of experience into about 40 minutes. So as a consequence, I'll do my best to be fairly short and come out with some concluding material for that. Now we'll take a look at the issues. We've been working now in an electronic government. I have certainly since 1979. Okay, so this is nothing new. Yet in 2012, we basically ended up having systems where 55,000 Canadian seniors, for example, did not receive their public pension. You know, the public service basically responded while they didn't apply. People were living in poverty. We have to change the way service delivery. In 2016, we have a pay system in Canada that will replace one that was actually working, or replace several that was actually working, 80,000 public servants, 1,100 had to leave because they weren't paid for eight months. I mean, why are we still having these problems after more than 20 years of government transformation? And I think that is one of the issues that we really have to address when we're taking a look at saying, is why are we still having the same problems? Okay, for that. And you know, why? Government knew what age the citizens were and the government knew exactly who works where and what level. So there's somewhere still a mix up between the business needs and also getting the technology fielded. It's more just fielding technology. It has to work. Let's take a look. What is enterprise architecture? There are lots of definitions out there. For me, I just simply say, take much more of a business bend to it. It's explicit knowledge, an explicit knowledge of the enterprise context, assets, their relationships and their evolution over time. It's essentially rigorous planning. And when I talk to the business people, I say, this is not an IT paradigm. This is a digitizing the enterprise paradigm, but it's just business planning. I use it when I was in portfolio management. I used enterprise architecture as a tool. We didn't have an enterprise architecture. So we just call this strategic direction. We're planning an architecture-based decision making. We're basically combined. Okay, for that. And that was back in the 1990s. Okay, now the context and technology continuously change. You have to handle it. It's not a big problem if you plan for it. Okay, for that. And government context, and this is one thing that a lot of the enterprise architects don't get, is that it includes politics and legislation. Often when you're doing a government, you're going to have to change legislation. So you just have to take that into account. It's not a big deal. That's why governments are there. As the deputy mayor of Paris alluded to, it's that you have to change the organizational structure of the government sometimes to accommodate digitization. So you have to take a look at the enterprise from end to end when you're talking about digital government. Okay, for that. So it's a question of handling it. Now let's talk about EA. A lot of people talk about EA. You've got to understand that three main EA deliverables are where the organization is, where the organization is going to, and how to get there. If those three elements aren't present in an enterprise architecture, it's incomplete. I find a lot of people worry about one aspect of that particular one, namely the baseline or the target, and they forget about the other pieces. This is just planning 101. Okay, for that. And successfully guessing, you know, all EA is about business transformation. And when you're dealing with electronic government, you are transforming the way that the government's moving forward. All of these slides, by the way, should already be posted to the conference website. Okay, for that. What I really want to emphasize is don't frame business problems as IT problems. What I've often seen is that they wanted to solve, they had a business issue, and they said, well, let the IT guys handle it. We had one example, for example, in Human Resources, where they wanted to integrate several hundred systems, and they said, fine, we'll just use one application. So they tried to solve it at the IT folks. Every department and ministry modified the application so that there was no information interoperability between them. So the actual gain and the modification of the particular system didn't solve the problem. That's what we really need to take a look at the whole thing. And, you know, there's now no business service. The process does not use IT. You need to rewrite the book. We were working in defense, when we realized about digitizing, and I don't want to sound bellicose, but, you know, digitizing the battle space, we had to take a look at, not new legislation, but we had to take a look at completely writing all the doctor in every business processes. The forces had to reorganize. That's part of the driver for joint staff, joint forces, because we were trying to get away from all the differentiation. We had to transform the entire enterprise. It wasn't just throwing IT at it. And a lot of the broad times, you also have, like in modernizing service Canadians, where the associate deputy minister said, if we need to change legislation, let us know. And we said, fine. But invariably, the IT guy said, oh, we can't change legislation. The people started retreating back into, you know, very cautious, okay, for that. And that's one reason it's important, and we put that in the Togat 9.1, to think in terms of capabilities, in terms of delivering business value. The other thing is, you don't want to deliver it one fell swoop, you want to deliver it incrementally. So you take about chunking it out of capability increments. Now, from an IT and engineering perspective, I can guarantee you this is not the most efficient way of delivering. But you know what, it's the most effective way. And when you're taking a look at all these capability increments and capabilities, you always take a look at the people, okay, per process, and you take a look at the material dimension. This, by the way, came out of government, we put it into Togat 9. Okay, that was one of the reasons. We wanted people to take a look at the whole thing. Now, from a software engineering perspective, you always had people process technology, but people didn't practice it. Or they were doing it at the micro level, rather than at the macro level. You want to make sure that enterprise architecture is used appropriately. Some, the documentation still reads, and I have trouble when I'm finding document, finding business value. They're always talking about reducing the information and communications and technology spend. That's not why you do enterprise architecture. It's a transformational. You have to judge it on the value that it brings to the business. And that is one of the really important aspects that you have to focus on. And when you're talking about creating digital government, you're integrating management technology and knowledge management. So these are the things that enterprise architecture brings to the table. So when you're using EA, don't just use it, I want to reduce the amount of money I spend on ICT. That's not the reason you do it. It might be a byproduct, an outcome, but that's not the reason you do it. You're dealing with the e-government. You want to create, and this comes out of Jeanne Ross' book, Enterprise Architecture Strategy, what you want to do is have strategic initiatives, and you want to use enterprise architecture as a way of validating that the strategic initiatives are feasible. And that is a very foundation role. Essentially, EA becomes a rigorous planning, confirmatory planning for, you want to do this? How are you going to do it? What are the implications of it? It's a more detailed form of planning. And then you come out with your engagement model and then you come out with your foundation for execution. I would recommend that this, the Jeanne Ross book, a lot of the stuff in there was written about 2006 or 2007. That still contains a lot of seminal information about enterprise architecture. But this is the way you really want to take a look at enterprise architecture where it's an integral part of the enterprise building and strategy, planning and strategy for that. Integrative thinking, Roger Martin, the metaskill of being able to face and take two models and integrate them together for that. Now, what you're trying to do is take a look at various concepts and put them together. Because often, one model will not suit. That's one reason, for example, let's take Togaf. Often you have to customize that or integrate it with other models to make it worthwhile for the particular client situation. And in government, you need better model for each government's needs. I'm working with smart cities. They don't have the same concerns as the federal or provincial governments or state governments. So what happens is you can't use templated solutions. Often you have to take multiple frameworks put them together so that it suits the needs of the client. It's called integrative thinking. A lot of people are still, when you're doing enterprise architecture, where's the template? Fill in the template and away they go. That's not the way things work. Okay, for that. One of the other things in lessons learned that I find particularly important are mindsets. Now, when you're looking at the business literature a lot of it basically deals with how people think, how people approach things. And they come out with two different mindsets. One is called reliability and the other one is called validity. Let's take a look at the differences for them. Managers, they exploit the status quo. Those are the people that take an existing business model and essentially make it work really well. When you're dealing with, you know, it's consistent and predictable and you're dealing with algorithmic type of reasoning. You're dealing with persistence of the past. You're dealing with you want to eliminate bias. Oh, it's extrapolations of big data and the like. And those people need facts. They need board to say, well, this worked in 1925. This works here and this works here. So what happens is we need something here. They're the ones that are going to make your existing business really work well. But the thing is you also need people that are leaders and what happens is you're not just managers exploiting, you're not exploiting the status quo. You're creating a new status quo. You want to innovate and you want to take a look at outcomes. Okay, for that. You want to take a look at people that are generally heuristic, rules of thumb, ways of looking at things much more flexibly. By the way, this comes out of the body of knowledge of business design. Okay, for that. And you also want to take a look at breaking with the past. You want to make a change. Now when you're dealing with the past, you're having a, this is really transformational. And what happens is what worked in the past is not necessarily relevant to what's going to work in the future. Okay, for that. And a lot of the time what happens is you have to be able to accept risk. Most of the people that are reliability based, guess what? They don't like risk and they will not accept it. Whereas when you deal with people that are validity based, they're basically generally much more will manage it. Salavie. I mean you just basically carry on. There's risk walking across the street. Especially here in Paris. Okay, for that. And what happens is they deal with intuitive skills. So these are two different mindsets. Now where do you think what do you think that most governments have in abundance? They have the reliability mindset. That causes problems. They will let the existing business. Now if you've got everybody with a reliability mindset and you're trying to pitch the government and get it working it's going to be very difficult. What you need is a team. Because validity people don't think the wheels will fall off if you're not careful. You need a group that are basically both combined of reliability and validity mindsets. We were pitching new e-government concepts to a group of people at the assistant deputy minister level and those were the decision makers, senior executives and what, guess what? Every one of them around the table were reliability mindset and they said no, this is too much of a change. We wanted to go to life event based, for example what the deputy mayor was saying from Paris. Life event based planning rather than always program planning and pool planning and modernizing service. You wouldn't have anything to do with it because they were worried about the risk which is definitely there. Now where is enterprise architecture? In the management side of the house you've got the reliability mindset. You've got analytical insights or data rich. They're basically exploiters and they're dealing for perfection. They're going to go six sigma and they're going to grind all those products into the ground and then basically they're very risk averse. The leaderships the leaders are going to be validity mindset. They're going to be dealing with intuitive insights. It's not necessarily an extrapolation of saying this is a new possibility for the future and your data porn you're dealing with outliers. They're explorers, they're innovators for that. They said risk you're going to manage. Now and they're also used to dealing with a much more descriptive environment. Not learning by rote. What happens they'll say is well we'll handle these things. It's much more a horrific way of planning. Enterprise architecture has to be right down the middle. You have to have both because you can't go to a new state or you know you need the managers to make sure that your systems are working. I'm talking about systems in the big system word okay whereas the leaders are going to move it in the right direction. You need to have a combination of the two of them. Enterprise architects have to have both business design thinking. They have to have both management and leadership concerns involved in there. Then there's mind the execution gap. You've got your strategic vision. You've got the people and projects and operations. That happens all the time. They have a wonderful plan and the people on the ground actually building the stuff and running it have no idea what the planners want to intend. And enterprise architecture really has to fill this operational plans and architectures that space. In most cases I've seen they don't. Execution is a major problem. They have high level architectures and they don't grind them down to the solution architectures and the solution architectures end up being destroyed. Okay for that. So execution is not the only management framework and if management frameworks have to work in cooperation you know you get the guys you're not aligned you know you've got the keeping the lights on you've got the people the unconstrained programmers that want to just I want to build something I can't help myself I want to build it. You've got the CEO throwing up his hands because he has no idea how the plans are being operationalized. The clients are not happy people for that. And you've got the business execs and the CIO trying to play referee between all these different conflicting requirements. This is not trivial. You've got to sort it out for example. Now in the new governance frameworks that are developed out by the information system by the auditors essentially. They differentiate governance from management. Issue of governance is often strategic and a little bit woolly whereas the management people is tyranny of the immediate. They're always worried about the stuff that's going wrong. I've seen entire meetings of senior executives dissolve because the blackberries aren't working properly that day. I mean guys focus you've got people working on that. Okay for that. And you also coordinate the plan build and run aspects. Now enterprise architecture really has to address all of those communities. Especially the planned site. That's where the enterprise architecture creates its benefits for that. Now part of the problem is if enterprise architecture isn't there. Guess who's got 90 to 95% of the budget. Operations maintenance. So guess who is going to be calling their shots to people running the system and they're worried about the tyranny and they're not going to be your innovators. So this is one role that enterprise architecture really has to sort out in a reasonably coherent manner. Okay for that. Now one of the ways you can do it is by at least having an integrated repository. I know I was working with, I had the pleasure of working with the auditor general and we were auditing some of these large apartments and you know what's the status of a project. Well it depends what system you asked. We had one project that was both green, yellow and red in terms of deliverables. The only reason it was green is because the project manager decided to cut the scope and cut out the various elements that were needed by the other projects in the enterprise architecture but the enterprise architecture wasn't consumable. And he said well it's on the book it's on page 242 at the bottom of page, at the bottom of the page in a footnote. I said you know that might be given a bit more prominence. Master data management is not a trivial exercise and if you want to share amongst various projects you've got to make sure that when you put it in your architecture project managers don't all of a sudden take off and change it. Okay for that you want to make sure the initiative synchronization works. We did this in the United States is we didn't call it enterprise architecture as part of the IMIT plan so we were sponsored by the deputy minister. Okay so that was the highest public servant in there and what we did is we put in a governance framework and then we put in a project management framework. They didn't have it and then essentially what they did is we put in like who's providing what to whom and we made sure that everything was totally integrated through the governance framework. It worked quite well but this is where they had a department that had all of a sudden been put together it ended up being a gold did they want the gold medal from the state of New York for that. So that was a good lesson learned. Also what happens is most projects now end up being generated bottom up. You have some person folding a help desk and then all of a sudden before you know it it's turned into a massive project. Okay it's tactical projects that are being generated. What you have to do is you have to enable strategic project management. Now that does not mean that you forget about tactical project management but you've got to integrate it governance in a lot in the IT field especially they separate governance for operations and maintenance from governance for capital. So you've got people fixing a system that you want to get rid of. You can't do that. When you're dealing with digital governments you really have to make sure that all of your spend is put on the table and you know what's happening. Now I'd like to say that's abnormal but I started my life as a civil engineer we were doing civil engineering planning we had the same issues but it was integrated. So we didn't have that conflict. In civil engineering that was resolved. That's one reason why I came into IT as a user representative. I just said this is chaotic. This is another example from Australia where we essentially looked at where does our enterprise architecture fit. I don't expect you to read everything but all I'm saying is right now we had the business level then what we did is and that was business accountability then we essentially created the business in IT architecture with strategic capabilities and we had the architecture working with the business folks then when it came down to the architecture when it came down to the architecture you saw the colors were simply used on one page to see whose turf was where and I hate to use the word turf as sort of an anglicism for empire whatever this sort of thing because everybody has their own and they don't want anybody playing in it. But this way we did we took a look with the building architects and what we did is over here is that everything was linked together and essentially the implementation of migration planning a lot of that was done by the project management office or at that time was the deputy minister in charge of the assistant deputy minister for delivery they didn't call it project management they called the delivery this is not a bad thing to do in your preliminary planning is to figure out how well these things are done it's important that enterprise architecture is done it doesn't mean that the enterprise architecture cell has to do all of it matter of fact it's much better who owned enterprise architecture here with the government and you want to bring all these groups together this is a good way to basically approach it for that. Now you got to take a look also at the EA value proposition the executive dilemma right now is they've got every consultancy and you know group pitching their own methodologies and these methodologies are stovepipe I belong to about 10 different professional associations I spend most of my time just saying you realize that they're doing this already and you might want to use this and basically acting as a maven as a coordinator okay for that it's a real problem because the executives don't know which one to basically put together and that's one reason with enterprise architecture can sort of create sort of a cohesive glue between these various frameworks that alone is a huge value proposition and in government especially everybody's got their own territory okay so as a consequence you need somebody to say this is how the territories will interact with one another okay for that now one of the things too is from your talking about the value proposition is we have to understand we're going from first generation where we essentially automated the manual processes and right now the applications are dying and the infrastructures is dead to second generation where we're actually changing the business most countries are in that and you know what it's all the first generation people that are still around and you're trying to do the same things they did in first generation not really it's the second generation requires a holistic perspective so this is just simply you know 2G and all these other expressions this is important to understand to bring on board okay for that now one of the problems you have is because this is sort of this is just an artifact from first generation IT this is complicated it's too complicated and one of the enterprise architecture value proposition should be keep it simple it got the tower of Babel there talking about 28 different languages you've got the language issue you've got the interoperability issue there's a simpler way of doing that okay for that stickiness remember lessons learned this is again government is supposed to be a learning organization they don't remember so in 1995 in one department we had a wonderful plan which was integrated with the enterprise architecture we had segment enterprise architectures everything worked well well 2016 all the segments were building and they didn't have enterprise interoperability because they forgot about the overarching architecture and now what happens is all the segments are creating their own enterprise architecture with each other because they need it I mean this is a lesson that was learned why are we having to relearn it and these are the things and when you're pulling out artifacts from 20 years old and saying well we need to do this I just say why don't you try this as a baseline that's one advantage of being old and being a pack rat you just keep this stuff around the unclassified material and you say I'm not going to do it for you you've already done it and give it back to the clients so it's an interesting time now you also want to have rollback and release management this is just simply motherhood or it should be there was a document management system fielded in government and in 2014 they didn't update of it they didn't have they went straight into production with the update and for two weeks everybody in the department had no access to their documents so they said afterwards two weeks well we fixed it nobody was going to use that again it was back to shared files and folders because they didn't trust the central system okay for that pay 2016 again issue 80,000 or 300,000 public servants received incorrect pay there were probably about 2,000 that were not paid at all for 8 months 1100 left the public service in order to pay for their daycare okay for that 720 are still without pay now as we speak this is not a trivial problem so as a consequence we really have to take a look at you've got to take a look at the lessons learned they were learned the best practices for a reason I don't know where we're making these mistakes again quality of services I've also seen in government service level agreement they're not using service level agreement for shared services and that's causing a major problem quality of service is not a nice to have it's mandatory and again in the auditing role you end up seeing a great deal of this lessons learned IT failure take a look at this 1997 61% of projects failed okay well it went down 50% guess where we're at right now 61% and again it's the same old issues project goals and expectations which you do in your enterprise architecture weren't put in requirements were unclear insufficient technical knowledge problematic technology I went to a a paper that was written in 1986 called the prison report some of you might remember that or not and the failure factors were identical I mean this is 1986 and now it's 2016 there's something wrong with stickiness okay for that for that lessons learned and also I just want to make just a point is that innovation is not project failure when you're doing your fail fast item make sure that you have good ideas but you have a place to try them out keep the tires don't if you're going to create a project they have to build something so make sure that the concept of the project before you create a project is works before you make it a project and funded and get it forward so you can innovate in the innovation facility in your sort of your sandbox then what you do is you create a project I guess I've had people disjoint architecture at the project level you're going to get silos post implementation integration headache e-government the main asset is information okay it's not and you know and stakeholder management for example you got to know what information they need in all types of forms it's not just database data okay for that case study information sharing they've got 10 layers of process decompositions mountains of enterprise architecture the problem was the executives didn't want to share the data okay and again so you got that cultural issue as well managing service for Canadians information-centric analysis it's key to getting your services properly sorted out we're going from program based service delivery where people have to pull for programs into life event based service delivery this is a huge transformation where you say this is the situation of the client what services multi-jurisdictional are available to the client and this has been proving to be a major issue because people don't have the same viewpoint of client just trying to integrate federal government services let alone integrate the provincial municipal is a nightmare okay for that this was an example of selling the information model client-centric service delivery where we essentially said they belong to a segment now remember older people are segments they don't have smartphones some of them do but most of them don't they belong to a segment they have life event it uses a channel to access an interaction point to describe a need that they have to get services and benefits they're helped by government and service providers they collaborate and activity and then they get an integrated service offering so I might simply say as I've turned let's say for example I turn 65 well all of the government's all of the government services from all the levels of government come over and say congratulations you're 65 here's your bundle of services from all of us you're dealing with one stop shopping this is a very powerful model this is the digital e-government of the future this by the way came from 2006 it still hits a lot then you have to have this integrated delivery model but this is one way of just illustrating some of the potentials of e-government and you're going from that enterprise decision making this is no surprise to most people decision quality is terrible because they don't have decent information holdings it's an absolute disaster in many cases information management perspectives part of the problem with information is that you're dealing with various communities you got the library science you've got records and archives you've got programmers you've got data scientists you've got IM executives and you've got stakeholders so what you have to do is reconcile it's more than just data in a database this is one of the things too is when you're dealing with the information take a look at a holistic view of it the rise of the chief DJ data or digital officer what is the issue why do we need a chief data officer you have chief information officer well guess what you get to now it's turning into the CTO is chief knowledge officer chief data officer and they're basically separating their responsibilities into IT and information management now you're dealing with IT you sort of want to say take a look at the definition of IT we put in the TOGAF 9 to avoid this problem doesn't seem to have made much of an impact life cycle management information related and related information and technology within an organization sorry the last one is technology so the whole idea was to be information centric and the entire way that we're doing enterprise architecture for that there's also lesson 7 which is show business advantages to the stakeholders prototype prototype prototype so they can visualize the capability understand the possibilities and take get buy-in transiliance is something called if you can't absorb change we were trying to do major changes and we're dealing with people that didn't have the educational background to have a clue as to what we were talking about and in one nation the presentation we could give it when we changed nations we had to give a different presentation we were dealing with different stakeholders and this is one of the things you really have to understand is if you want to do a change you have to make sure that the people have those skill sets in order to change in both technology and management e-government is not a technology problem it's a business it is an enterprise problem I don't want to use word business because that's a business segment it's an enterprise wide problem that you have to take a look at and you really have to have a combination of education and mindsets to take a look at the new capabilities in the business context now let's take a look at Voli v. Gant okay at the time this was the state of the art so the architecture basically the architect had to come up and said how are we going to build this this was this was great this was a basically the prototype for Versailles and on Fouquet I found out that you shouldn't compete with stuff you know when it comes down to Louis Vuitton's but that's another thing so what happens you have the conceptual view and then you end up having the logical view of how the pieces all fit together generally speak when you're putting your e-government together keep architecture in place for that this is an example I'll just quickly go through it of how you basically take a look at an oil spill-up in the Canadian north and you get all the different government departments they say well this is our part this is what we do this is how the resources have to be put together and then you come up with the information outcome right decision, right time, right information and you take a look at the foundation architecture but you do this with the enterprise wide view and then you're dealing with how you share information between the various government departments this is an illustration of the business scenario it comes right out of Togaf for that so you take a look at that the business scenario in context you've got your corporate strategic objectives you've got your business scenarios that becomes part of your vision you have use cases which are based on your scenario and you have your test cases and then you have your learning cases your training cases as well but you notice here this doesn't very much from the previous one that I showed you from MIT that was put out as enterprise architecture strategy it's where your business scenarios validate that the strategic objectives are doable are feasible and when you're dealing in the military for example we were dealing with multi-billion dollar projects we ended up having innovation facilities and environments where he just makes us say well what works we had a combination of subject matter experts, scientists, engineers, operations research and simulation simulation is a great tool it's much underrated okay and I know that virtual reality will be the way we'll be shopping in not too distant future use a synthetic environment how many companies have a synthetic environment it's not as similar to the skunkworks that Lockheed had this is something to take into consideration but I've yet to see a government where they have a place a simulated environment where they can basically say would this service be good I mean there's this whole part of the whole open government type of exercise you've got to be opportunistic and be flexible a plan as a common basis for change that's the way you've got to look at an enterprise architecture people talk about it being agile well it's dynamic I mean it's always been that way it just hasn't been implemented that way why too many reliability people and they end up saying the plan is the plan is the plan we will follow the plan you take a look at building blocks that's a way of chunking out business value and we did a case study in health where we essentially had various government departments and we came out with ways we just said one pagers and we said these are the clients these are the technology stakeholders trying to quantify what exactly was the issue and also what solution was being put in place to resolve that so this is part of your enterprise architecture it was all business related technology was just one of the items that was involved for that lesson 9 the person with the gold makes the rules make sure that your enterprise architecture is in the right place in the US federal enterprise architecture enterprise architecture is part of planning and budgeting and that's the way it should be put in place because if you don't have control over the money you can have the best architecture in the world you're not going anywhere security and privacy you're going to have to have it's often ignored until too late I've just tons of examples where they tried to fix it after the thing was fielded and cost 10 to 100 times more to implement the security architecture for that and when you're dealing with big data the real challenge is that you're integrating information systems and critical infrastructure through SCADA systems control systems this is a major problem a major challenge you've got to make sure you architect for that you don't want a person on a smart phone hacking into your water purification plant within a city so you got to make sure also privacy make sure you get it right privacy is becoming a major government concern people give information and they should be the ones to control where it goes so in conclusion I would say is that one of the things for the government we really have to take a look at is open standards they're absolutely key we got to focus on information interoperability and standards such as the open data element framework that we have here within the open group are good ways and the enterprise architecture implementing these standards are good ways to move forward sharing information is difficult we have also squeezing the technology social innovation gap normally we have technology then we have social innovation enterprise architecture should be seen as a way of trying to get value out of these new technologies as quickly as possible okay and that's what it means and time means money in government and private sector for that IMIT skills for the future they've been focused in the back in the past on platform and infrastructure they're going to be up here in the knowledge enterprise environment decision support analytics right now a lot of people are hiding their head there was one CIO he basically ended up spending all those new resources on people that were on infrastructure and platform rather than retraining people for analytics guess where those people are the CIO groups being disbanded okay for that so concluding EA is a solid planning methodology it's a management discipline it's a business transformation methodology it also describes where you were where you want to get it's also an integrated framework so it serves many purpose EA works just do it end to end that's the main conclusion so that's my question last thing I'll say is we get together for the second e-government another e-government for the conference July 2017 in Ottawa