 apologies for the earlier confusion with the audio, but hopefully you can hear this clearly and I look forward to presenting to you. As you can see the title is Global State of the Year for 2022, so this was completed in January 2022, so therefore it's really a reflection of what people were doing in 2021 versus the previous years. I'm going to provide some context now, which I think is really important for you to understand the way that Forrester thinks about enterprise architecture and the way that value is delivered. So this follows on from the previous conversation, but it does use some of the approaches that you've heard from the other speakers. So in context what Forrester does every year is say rather than have really pedantic discussions about what is EA and everyone getting really upset about certain definitions or the meanings of certain words, we've always found it better to say well what is the value of EA and the best way to actually find out that rather than have in a comfort zone type of approach is to us practitioners. So every year info world and Forrester have a EA award ceremony where we ask Forrester and non Forrester clients to present to us how their EA practice is contributed to delivering value. So they're going to provide us insights about the organization and EA's role in delivering value. When we actually analyzed all of these responses and we've been doing this for well over a decade now, what we actually find is that when people explain about the way that their organization focuses, there are some organizations that are very focused on strategy. It's all about corporate strategy and it cascading down through the organization. So eventually you get the delivery or execution of that strategy. However, we have just as many clients who say that they're a project driven organization. They don't really have a strategy business units come up with their own initiatives. They get funding and it's very tactical and they do changes. So if you do that as a continuum, what you'll actually find is that your organization may be somewhere on that line. It's not any that you're definitely 100% strategy versus 100% project, but you're somewhere along that continuum. The second sort of analysis that we do is the orientation of the EA practice, the mission of the EA practice. Has it been constrained by the champion of EA, whether that be the CIO, CTO or whoever to only focus on technology or is it more open that we want you to provide business values so there's a business orientation? So if you actually put that into a 2x2 grid as I'm showing here, what you can actually see is that there's four quadrants and that's what we call EA archetypes. So the winners primarily focus on one of these quadrants. So when we say primarily focus that means that 60% plus of their effort is focused in that area. They spend the remainder of their time on the adjacent quadrants. So if your technology strategy at EA, you may spend 60% plus in that space, but you obviously need to translate the business strategy. So it's some space in the business strategy and you also want to ensure that the technology project is delivering the tech strategy. So you're going to be in there. So that is, it's an L shaped model and that's what you find in all of these. You very rarely see people do the diagonal. Now there's a couple of things that also come out of this research that when we look at failure and when I say failure, that doesn't mean that the architects are a failure. It's about their positioning. They're not perceived as delivering value usually for a number of reasons. The first reason is most chief architects would like to be in that top left hand corner in business strategy. In their view of the world, enterprise architecture delivers most value when you do business strategy top down architecture if you want to call it that. However, if the issue is time to market and it's down in the bottom right hand corner, you now have a mismatch. If your chief architect is trying to focus on business strategy that the business actually want a reduction in time to market, they want it on the delivery side. So when you have a misalignment, you are going to be perceived as not delivering value. The other thing that we find is that, and there's a strong argument for this, that enterprise architecture is all of these things. In our experience, every enterprise architecture practice which has tried to do all of these things delivers too little to too many people. They are not perceived as delivering value. So they don't really have a value proposition. Their mission is confusing because they're everywhere and they'll get pulled who have chance loudest. So the failure side is really important to understand and that's why the window is it's very clear what they're actually doing. The second point is that EA is not static in that the problem space may actually be in the tech project EA space. So your EA practice is providing reusable components, standards, reference archers, patterns or the usual buzzwords so that they delivery teams can deliver a quicker, more effectively, consistently. There's quality there. Once that becomes BAU and everybody's using these standards in that, EA now has the opportunity to move into another quadrant. The debate here is now skills, competencies, capabilities and you've seen that through Chris's discussion on the learning. If you're in technology project, you probably want people that are very technically biased in that if you're an Oracle house, you want Oracle expertise. If you're Cisco, they would Cisco Windows, Windows and it goes on. However, if you're not going to move to tech strategy, you don't want that. You want open-minded. You want people who will challenge and explore all technologies to come up with the right technology for your organization. So evolution doesn't mean that you move one EA team into another area. There's also an argument that when you look at each of these quadrants, they're serving different stakeholders who want different services, have a different level of expectation in value. They probably want to be served by different set of competencies. So when you look at all of this, what you'll actually find is, yes, EA is going to focus on one of the quadrants, the others are going to be supported by an EA ecosystem. So let's have a look at what the data says. So this is what you can see. Three years data. I could have provided more, but let's just look at it for three years. What you can actually see here at the top is there was a significant increase in technology strategy from 42% to 67%. And I called this in my reports, the Great Reset VA. And the reason that I said that is, if you look at previous years, technology strategy EAs have been declining. And the reason that they've been declining is because more and more EA practices were moved in above the line into the business area, and they were becoming business-driven, value-driven, outcome-based driven EAs. What we saw last year was effectively a major change. Could be many reasons, chance at high probability at something to do with a pandemic. The fact that we now needed to focus on remote working, sustainability, resilience, and all of those issues. I might be wrong, but that would be my take on this. It didn't have any impact on the technology project and what you saw on the business side, they declined. They declined because people went on to take strategy. So even though tech strategy has been the strongest or the primary focus of clients, there had been over three or four years a decline every year. Now we've seen a big spike. Now what we do here is, as you can see, the question is rank these. So we don't say tech strategy. We give a statement. And if you understand the statement, you will understand that that statement is only true for tech strategy. So they're actually ranking them. So this is showing you the number one ranking for each of those organizations. So let's have a look at the relationships. As we see here, the light green in nearly every area, you can see that the light green has been growing. See, EA's have got out of their shell because one of the things that was very ever done in many EA practices, they didn't have a relationship with people outside their own domain. Architects could talk to architects, but they didn't really have a relationship with people outside. That has changed. And you can see it through nearly every year. There has been an increase in EA getting out there and working with other people. So this is quite good. Interesting, there was a slight decline online at business and there wasn't much in supply chain. And you wonder why we've just got a figure. We don't know the reason for that. There doesn't seem to be a specific reason for that. In fact, you can even see dates to governance second from the top where you see a decline as well. I can't explain that, but that's just showing you that for some reason, they're not increasing the collaboration in those areas. Is it because they're at a level they're acceptable with? Who knows? That's just something to try and sort of look in your own world. Do you have relationships with all of these people? And do you need it? Because the important thing is that the relationships will depend on the previous slide and you know what your mission is. If you're to serve business people, then you would expect to have good relationships with the business people. If it's you're serving the tech project space, then your relationship will be with the project manager, solution architects, delivery teams. You're serving different people. You have different relationships. So what you can actually see here is okay, so we're building all of these relationships, but who's actually supporting us? Who's got the back of the EA? Who are the people who are championing us when there's maybe something hits the fan and things like that? So what you can actually see here and I think this is the most disappointing data every year as I expect it to be glowing. All you can see at the bottom, the strongest is IT leadership and you would always hope that. You would hope that IT leadership see the benefit in the EA, but 64%. That's not really outstanding, so what is it with certain IT leaders in the EA? Why aren't they the advocates? Why aren't they shouting about it? And then as you go here, security I would expect, but the next one, why really the delivery teams and operational teams, why is that dev and infrastructure less than 50% advocate of EA? Is there really an issue here with you helping them by you providing reusable components, things that help them do delivery to market quicker, higher quality? What is it that's caused that tension and friction? So this is alarming. So this is why I say this is disappointing. In the previous slide, we saw about all of the growth in relationships, but this slide is actually telling you that if something goes wrong, these guys won't hold you back. They won't be protecting you. They won't be supporting you and things like that. So this is alarming. So I think you've got a long way to go. Most EA has got a long way to go to get advocacy from their stakeholders and that may be because they're not seeing the value that you profess. So here's another thing to consider. The person who determines whether you're valuable is the person who consumes your service products you're offering. You can champion your own value and say, oh, the value of this service is X, but if it's not perceived as value by your stakeholder, then you're probably not doing the right thing. So that means you should co-create your services with your stakeholders. So I talked about the ecosystem. So let's have a look at it. On the left hand side, these are all the different types of architects that we are experiencing within forestry clients. Now, I'm quite sure when you look at the ones at the bottom where you can see all these 90 and 80 percenters, all of that you're going to know. You have those in your organization. What you may not know is the ones at the top, which are all the business focused ones. And I would argue to a certain extent that these are all the specializations of business architecture. So if we think about people, these are people architects. They're understanding roles. They're understanding job families. So when you as architects suggest that a capability is unbundled to a third party, that has an impact on your people when you automate a capability. Again, it impacts your people. So the people architect may sit in the human growth or human resources, human capital asset, whatever group you have. But there is somebody who understands that. They understand all the building blocks and relationships of people. And when there's a change to the organization, they understand the impact of people. The organization architect. You heard this in previous discussions or presentations today, operating and business model. That's what these people do. How to organize, how to build an ecosystem with your partners. This is organizational architecture. So most see in the organization as a black box and how it interacts with the other black boxes in your market and the broader community ecosystem. You'll see fourth one down experience. Note it doesn't say customer experience. Customer experience, employee experience, partner experience, any stakeholder experience. These are people who understand customer journeys, the experience, your moments of truth. So they know how to architect it. And then digital. These aren't digital technologies. These are people who understand how to do digital business. So you can actually see that there's quite a few here. So I mean, just looking at experience, 42% are faster clients who've got an experience architect or someone in the business world that is architecting the experience. They are part of the broader ecosystem. And this is why I often, I wouldn't say frown. I challenge our clients when they say they have an EA team. Because it usually means in their little world that this small team does enterprise architects. They are very much dependent on all these other. So it's really an ecosystem, a cellular organization, if we'd like to use that word. So technology is driving EA demand. So what you're actually finding is that these are areas that is creating demand for EA. So when people are saying that I think in one of the presentations, someone say from 2016, the EA's has become very, very important. These are the types of things from the business side, really, that are forcing EA to get involved. And this is probably why you saw all of those relationships building at the bottom. Employee experience. We keep on talking about the shortage of tech talent. How do you retain your staff? How do you keep engaged employees? How do you develop them? This is all part of the employee experience. This is where your people architects in, your experience architects as well. They're all involved in this and it will impact your organization. So you get all these other different types of architects and their subject matter experts in those areas. Doesn't mean an EA can't facilitate the discussion, but you are dependent on the input from all of those people. If we specifically look at technology that they're exploiting or experimenting with, I don't think there's going to be anything on this list that you don't already know. At the bottom, you would expect lots of people focusing on automation. 82% of people are focused on intelligent automation. You might call it smart automation. Cyber security and privacy, very, very big. This is going to be an interesting one for EA because in certain countries like Saudi and I know there's others, the cybersecurity people are no longer allowed to report into IT. They must report directly to the board. So now you've got the two different groups working together. Who's doing the security architecture? Is one just doing policies and the other one is doing the implementation, the frameworks and that? Who's deciding those governance risk and compliance? Again, we see 79%, but as people move to become agile, you'll hear empowered and trusted governance. So is EA or architecture governance now being done by different bodies outside of an architecture review board? And I'm sure you'll have your views. I've said for many years, I think the ARB is dead, but everyone has an opinion on this. So this shows you all of the technologies that are driving EA focus. You might want to talk about, well, how's EA organize who they report to and all of those sort of things. So obviously we have all of those questions, but the one that is gives a nice little story is this one here that we've always seen EAs in a hybrid model. So it's really a combination of the ones above. So if we look at centralized, not much change over the last two years. So still predominantly EA is a centralized team. What you then see is that there's embedded in product service and customer teams. And you can see that there's an increase from 8 to 13%. I think we have to be conscious when we interpret this, because when you actually talk to the integrated product service and customer teams, none of them have an EA. What they're really telling you is that they have a architectural capability within the product service or customer teams. And that usually means there's a solution architect or a domain architect. Scaling is very much a matrix model. So it's really a derivative of centralized because you're actually being seconded to a probably a project team. And then embedded in the strategic planning function, this is always nice to see. So all of those organizations that they're saying that EA should be a business strategy EA, this is where they're going. They're going into the strategic planning function and they're out of IT altogether. Now there are going to be many organizations that don't want the responsibility and accountability for the EA teams. They'll probably say, I want you aligned to the strategy. I want you centralized, aligned to the strategy and planning. So that's where you'll see in people. Again, you will have your own views. These types of questions, they all seem good. But the one thing that doesn't really come out a lot in all of these organizations is different parts of your business will be at different levels of maturity. So you may have some legacy environments where things that are a bit chaotic and it makes sense to have a centralized EA to look after them. You have others which are fast moving and things like that and maybe like your digital organizations, maybe as better as have embedded integrated product service and customer. So you may find that you have different operating models for different parts of your business based on their maturity. What you can actually see here is in the previous presentation on the importance of the EA, there was a bit of a discussion about the measures and metrics. Everything that I said was correct. What you can actually see here is a subset of the measures and metrics that people focus on. Everything that you see in the sort of bottom half of this list is what you would traditionally see in an EA practice. Very much on the quality of the architecture, productivity of the EA team. That's what you really focus in on there. That's all wonderful stuff. Has absolutely no value to the business. It has value to the chief architect so that they can improve the services and the offering that they provide. So this is what we call internal measures and metrics. You need them, but they're not really for communication outside of the EA role. If you now look at everything at the top, this is where you get into my preferred areas, architecture contributions to revenue, financial value of the architecture. A bit further down, architecture contributions cost, architecture, processor speed. These are a bit more upside in. This is what the stakeholders want to see. How are you helping me generate revenue? How are you reducing my costs? That's the types of things. You just are cogging a machine, but you should be able to present when some architecture has been implemented before and after. What is the impact? Everything you heard in the previous presentations. So I think it's very, very important. And the other thing that's very key was that you've got to communicate in the language of your stakeholders. If you were actually talking to your chief operating officer or the equivalent, he's probably going to be focused on efficiencies. So he wants to know things about the efficiency of business operations. If you go to the risk manager, it's going to be at risk mitigation. Go to CFO, definitely financial. When you go to line the business and maybe a bit higher into corporate reports, that maybe it's bottom line. Who knows, but it's going to be probably financial. Maybe it's going to be about market growth or something like that through introducing new digital channels or whatever. So the important thing is to look at the measures and metrics. And the ones that we find that are particularly good EA practices are moving away from balanced scorecard type report into OKRs, but you can't do it unilaterally. The whole organization has to be doing OKRs. You can't just do it in one piece. So there is the constraints of the organization. Tooling, an enormous amount of focus on tooling. Always surprising. Look at the bottom one. In the last survey, 82% are using Microsoft tools, so they're not using an EA tool as their primary tool. So what you can actually see along here is internal strategic planning tool and at the top the vendor strategic planning tool. So it's nearly 40% that have a planning tool of some sort. Probably all it's focused on is investments and delivery against the goal. It's not doing architectural mappings that we would traditionally set. And right in the middle there, COTS commercial off the shelf EA tools. Now I actually do the analysis of the EA tool market. 54 vendors support the EA market. Some of them a little more than drawing tools. Others are big beasts that do considerably more than EA. But by EA having all of that functionality, they're able to build the ecosystem as other subject matter experts come in and see the information. The 30%. So this is a big opportunity for EA vendors. Why are people not using the tools? It's an enormous growth area. And then the other thing that I'd really like to say about this is if you're not using an EA tool, just think of your productivity, the accuracy of your architectural decisions. If you're relying on documentation in Microsoft documents, there is a high probability that the data in the document does not reflect what is actually in the physical environment. Now that's obviously going to be true in a tool. If you don't have the right interfaces to your CMDB application portfolio management and that you may not have accurate information, particularly if you're not updating the source, but you put yourself at risk. And you don't want EA being a data entry clock. So the last slide is really just to show you because we've heard a bit about agile today. So where are people on this agile journey? So we look at four factors when we're looking at this. And on the left-hand side, we say this is traditional EA. On the right-hand side, we say this is agile EA. You might have your own view of what should be at the ends of these continuum. So if you look at command and patrol, you can say architecture review board. Everything goes through the architecture review board. Trusted governance is basically the delivery teams are empowered and trusted to make certain architectural decisions. You can see people are on the journey. And going by being skewed to the right-hand side, that's quite a journey people are going on. If you go to the next one, mandated framework versus agnostic, obviously you could say mandated is Togath. Agnostic does not mean that you do not have a framework. When we talk about agnostic framework, it means that people are cherry-picking. They may be taking something from Togath, something from Zachman that someone mentioned, something from IT for IT, from your digital playbook or book of knowledge. So people are cherry-picking what's right for them in their environment. So they're not being, their EA practice is not constrained by a framework or the compliance to a framework. They're actually being pragmatic and choosing the bits that help them do architecture for their environment. The perfection of a speed versus speed over perfection, always a big debate. Traditional people want to dot the i's and cross the t's before you move forward. On the other side, they accept that you're not going to get 100% accuracy and then maybe some failure. There is a bell curve there at the moment. So when people are on the journey, it would tend to suggest there's still too immature that I think there's probably speed over perfection from an architectural point of view. There have been probably more failures than what people wanted, so that's why it hasn't moved over to the right-hand side so much. And then waterfall versus agile. So waterfall means you're doing everything by project, and then there's the agile. And you can see it's a right skew at the moment. Will it skew much more? Big debate. I'm a big proponent of only do agile where agile makes sense. Only have dedicated teams where it makes sense. Others will have a different view. So the important thing is that you choose what's right for your organization to deliver the value. Is the presentation for you? Because this is the recording now and we didn't have time for it working in a live environment where you could ask questions. If you do raise questions, I'm sure they will be forward to me and I'll do my best to answer them for you. So thank you very much.