 Good morning, everybody! Hopefully that you can hear me for this microphone. Otherwise I'll shout. I'll be ready to kick off, welcome all. My name is Andrew Josie, I'm from the Open Group. Here I'm VP of Standards and Certification at the open group, so I look after the standards process. which is the rules of how we develop standards. I also run our certification business, so I won't be talking particularly about Togaf certification, but I am able to answer lots of questions. Have you got questions about what we've been doing with the certification program here today? We're here at the Togaf user group, today we're looking at the Togaf standard 10th edition. A particular aspect of it is what we call the Togaf series guides, and I'll put that into context as well in a minute in my first session. So we'll be having a welcoming group of speakers, basically these are all authors of the various parts of the standard. So authors of the Togaf series guides, and I'll be introducing them. We've got Dave Hornford here, Chris Frost, and Dave's actually doing two. And Celine, I think I saw she was here or she will be here in a minute. Celine is also going to present and I'll introduce our speakers as we go. We're running up until one o'clock, I believe, is that correct? There are some books that are giveaways if you'd like copies of the Togaf standard. They are actually downstairs where the coffee is, we've got a table just in the corner of the room with lots of books on. So if you need a copy of any of the volumes of the Togaf standard you can go down there and get that. I brought a small selection up here, I didn't bring them all. OK, so I guess without further ado we'll kick off. I'm going to talk briefly, give you an introduction to the Togaf series guides and what they're about. Let me just see if I can get this going. OK, so I'm going to be giving you a very quick look at the Togaf standard, a look at how we've organised it, how we've reorganised it, why we've reorganised it. One thing we had heard in the development of the Togaf standard was that our practitioners wanted more guidance, better guidance, more topical guidance. The way we've facilitated that is actually by making a big change to the structure. We'll be talking about the structure. By changing the structure we're actually able to add a lot of extended content. You'll see that the book has changed. If you imagine Togaf for the book, the standard being the book used to be like one single book. I think it was 500 or 600 pages and now that's actually been split out. That bit has been split out but now we've actually got in total 28 documents as of just this last week. It was 26 when we launched last April and we've actually added two new documents to that. I'll explain a little bit more about that as we go along. This is the modular structure. This is a diagram showing you how you can find the standard. If you imagine the open group has the open group library. That's where we put all of our standards in across the different topics. If you see those five boxes at the top there. I think actually I might even have a laser here. If you look at these five you'll see various topics. Togaf, Arcumate, IT for IT, DPBot, Security Library. If you click into the Togaf library that brings you into our content specifically around the Togaf standard. We have a number of items in there. There's white papers guide supporting material for the standard. Then we have the standard itself. If you look at the standard now you'll actually see it's divided into two types of content. We've got what we call the Togaf fundamental content. You can think of that as almost equivalent to what was the 9.2 standard. We've actually modularized that so we've actually broken that out from one book into six documents. That is considered the stable and enduring content so that is really the what. What we've added to that is a set of documents called the Togaf series guides here which are supposed to be the how, the how to. The idea is they'll be more dynamic, they will evolve and we'll be adding new content which is indeed what we've just recently added two new Togaf series guides to that content. If we look at the standard as I mentioned there are basically the six documents, the Togaf fundamental content and to that we've actually added 20 Togaf series guides. This is the picture as of last April so this is one year ago and what I haven't had time to do is to update this slide to add the two new documents that we've added. When you look at this we've got here in customer master data management, we've just added also metadata management as a new one and in the business architecture area which is up here. We've also just added business capability planning as a new Togaf series guide. If you go out to the standard now you will see an additional two documents there. The standard is available in a number of different formats so as you see here at the front and as you'll see downstairs we have the hard copy edition. So there we've taken a selection of the documents, we've not printed all 28 documents, I think there's equivalent of about 15 of them are actually encapsulated in the hard copy. You can pick up things like there's an architecture development method guide and that actually includes the three documents that are sort of related to that topic area in them. A little tip for you there if you look at the colour of the spine, the green actually means it's fundamental content and the purple actually means it's a Togaf series guide. We also have what we call our digital editions so we have a sort of a little graphical entry. You can go if you go to the open group homepage, you click down to the Togaf standard 10th edition, you get this sort of graphic that you can then click in that takes you into the text version. One thing that we wanted to do with the standard as we came along to the 10th edition was to ensure continuity so if you're familiar with the version 9 standard 9.2 you will recognise a lot of the content. You'll see things like just the catalogue, matrices and diagrams, you'll recognise obviously the architecture development method, the crop circle, the partitioning models. All those things are brought forward and those are in the fundamental content. Just explaining how we reorganised the fundamental content so we took the one book and we sort of split that out and this has been split into these six guides. You can see the architecture development method being supported by techniques, a guide on how to apply the ADM, the architecture content capability and governance. Things like architecture board, architecture compliance and so on. Then you've got your Togaf series guides which into work with the fundamental content. What we're here today is to look at some of the Togaf series guides. As I mentioned these are really about how to configure, how to use the Togaf standard so rather than the what that is in the fundamental content we have a series of books. As I mentioned it's now 22 so there's the six fundamental content documents and the 22 Togaf series guides. I'll cover a range of topics, I'll give you a couple of slides, a very brief look at some of these and then some of our speakers today will be taking you in, diving deeper into the documents. There we go, so there are what we call, some of the content organisation reflects what we have on the digital online edition so if you go to our website, in fact if you go to pubs.opengroup.org slash Togaf standard that's the direct URL to get into the online edition. You'll see that we actually tend to reflect some of these categories in there so you'll see that we've got the general how to so this is developing an EA following the ADM. We've actually got practical advice written by members of the open groups architecture forum how to apply the method for developing an EA. So that was something we were sort of missing it was always the what before rather than some actual practical advice. What does it mean in practice and Dave Hornford is here today he's the author or one of the lead authors of that book and we'll be able to tell us more about that. We've got guidance on digital technology adoption using the Togaf standard in a digital sort of first enterprise so we've got guidance on that. We've got domain specifics we're particularly strong in business architecture so I think there's now seven it said six on here there were six at the time I put this slide together but as of this last week there are now seven business architecture Togaf series guides. We've got a new study guide as well so if you look we've got a business architecture sort of set and we've also now got a certification around that area as well and there's a new study guide just been finished. We're working on data and information architecture in fact Celine the scope at the back is here and she's been leading that activity she's actually going to tell us about a new Togaf series guide that they're working on on sustainability. But she's been leading that and we've now got two documents there at the time this slide together we had customer master data management we've just added metadata management as well. We address agile agile methods so there's a couple of Togaf series guides that look at how to apply the ADM with agility you know applying the ADM using sprints how to you know generally organize your enterprise architecture in an agile manner. We have a set of reference models some of these you will see we've carried forward from the version nine point two standard but also we've added some new ones such as a digital business reference model the government reference model. We have specific guidance on setting up and establishing an EA team and again we're going to look at that particular Togaf series guide in today's session so I won't give away too much about that but also just say we've just also launched what we call a certification credential for being a Togaf EA leader. Now with all of this stuff you may be asking how can I get started. Well the good news is we've got a white paper and introduction to the Togaf standard 10th edition and that really explains a lot of the motivation about the changes we made. So if you want to you know read up on why you know how we came to this new structure in this new organization it's all described in there. It also gives you a few recommendations about how you can get started from different views. You know if you're an enterprise architect if you're a sort of a manager if you're a leader you know where would you actually start with this documentations that how would you approach it. You know how do you get in there. And also for some people who are really into the details we got an appendix that sort of goes into the gory details about what we changed in the Togaf fundamental content as we went forward because obviously one thing we'd like to do is always sort of continuous improvement quality sort of changes to the fundamental content. As I mentioned we have a digital edition so obviously we're 26 documents it's a vast amount of content so we're trying to think about you know how can you approach that content. So what we've come up with is digital the online edition that is supposed to make it easier for you to navigate and search all of the content and that will be evolving continuously. So in fact if you were watching the site in the last week you will have noticed it expanded and there were two new documents integrated into the online edition. So just give you a picture of the online edition here. If you do go to the starting page it does give you links into the white paper that I mentioned. So you know if you want to get started you want to read the white paper you can just click on that link and it will take you straight into an online version of the white paper as well. We've got search capabilities and then obviously we've got all the documents that you can jump into here as well. One thing that is new is the ability to provide feedback by the digital edition. Before it's been quite hard to be truthful it's been quite hard to give us feedback and so we tried to make that much easier now. On every page in the online digital edition you will see these little bug and comment icons and you can click on that and it will pop up a form. It prefills some of the information of the form basically telling us where you are in the document and you can give us your comments and that goes back and that basically gets filed into a GitLab tracker. So it's an issue which is then raised with the architecture forum with the standard developers and it's been quite good. I think all together so far in the year we've had about 50 comments so far and some of them are things like well I'm not sure about that content and we're like well that's a subjective thing so obviously that goes back to the standard developers and they'll consider it. Other times they spark oh you made a typo here so that's great because then we can go right we'll go fix that and obviously in our tool chain we've been refreshing the content as we go along. So it's a way to really shorten that cycle of finding those bugs because when you've got that amount of content there's bound to be some issues in there and sometimes they're things like caused by our conversion tools. We're taking documents written in a number of different formats and trying to present them as HTML as best we can. So that's really what I wanted to talk about today just to give you the very brief look at the TOGF standard. Explain a little bit about how we modularized it and changed the structure and then just give you the quick very high level view of some of the TOGF series guides and we'll be handing over to our next speaker. I think it's you Dave you're up next aren't you to talk about the leaders guy. I think no they don't have you got your apologies for a little bit of a bit of a change over we need to do here. But Dave's going to be talking about the leaders guide which we do have lots of copies of so if you do want to get a copy of the leaders guide. Leaders guide how to set up an enterprise architecture practice. So Andrew went through the basic structure of the TOGF standard and one of the things I find very interesting. When we're doing version nine release nine people were saying so big the document is so big because it was 600 pages. It's now about 2700 pages. And the distinction is 150 pages on how to run an E18. You have 150 pages on the practitioner's guide on how to actually exercise the ADM. There's about 800 pages on how to do business architecture. The transition from the what to the how is absolutely critical. And what I'm going to talk to for this session is what's in the leaders guide. What's in the structure of how to enable an architecture team. Where do you go what are what are the essential roots of it. So the pieces I'm going to talk about one is deliberate design. What is it that you are attempting to accomplish for your E18. How do you structure governance effectively. And then customizing your content in your method. What is your organizational design model for success and what processes do you need to set up. The reason we wrote the leaders guide is because of a sad truth. Gardner will tell you that there has never been more spend on enterprise architecture than there is today. They'll also tell you that enterprise architecture teams have never lasted as short a period of time as they do today. So there is an absolute requirement for enterprise architecture. And most of the teams are stood up shut down stood up shut down stood up shut down because they're missing. That's what the guide is about is stop missing. People want good enterprise architecture help them get it because as a profession our struggle is we're very smart people. We have a lot of knowledge we have a lot of care we care deeply about our organizations. Why are we missing so if you're on a cut to how to pull this off. If you read the leaders guide it says right in the introduction stop reading the introduction and jump to chapter four. And then when you're done chapter four jump to chapter five. So if you're in a hurry just go right to chapter four and chapter five. Chapter four is all about the enterprise context. What is your company. What is your company trying to accomplish where do you live. What's your ecosystem that you live in chapter five. What does your company want from an architecture team. It will be very very different for different organizations. If you deliver the world's best architecture that they don't want it's an irrelevancy. The analogy we used when developing it it doesn't matter how good your filet mignon is if your company wants a hamburger. I spend about half my time helping people set up architecture teams. And I am constantly fascinated by people who do not architect their architecture capability. For me it's a credibility test. If you are winging your architecture capability what are you saying about your commitment to architecture. What are you saying about your understanding of how to design a capability that's fit for purpose. Why would I trust you. So when you think about this accidental organizations don't change the world. Accidental evolution takes bazillions of years your company doesn't have bazillions of years for you to evolve into the right structure. You've got to cut to deliberate design and the foundation leaders guide is two pieces. What does your organization want an architecture team to support them with. There's four basic patterns I won't come back to them but the four basic patterns are are you answering a question about strategy. Are you doing portfolio change are you doing project change are you doing solution change. Those are four very different models of who you serve and how you serve them. And when you line that up it's sweet when you missile line them. You're one of the groups that gets rebooted really blunt about that. It's what I spend half my time doing is helping teams who aren't getting there. So cautionary warning no one cares what you want to do. They care about what they want to receive from you. No one cares about what you could do if you only had a mandate if you only had the time. It's what they want and no one cares what another company does. Different organizations have different demands and that's the centerpiece of chapter four enterprise context. What is your company are you a startup. Are you one of the Fortune 500 is the boundary of your enterprise a part of your supply chain is the boundary of your enterprise and extended supply chain. So if you look at the definition of enterprise and tell gap it's very clear says the definition of an enterprise for the purpose of enterprise architecture is the boundary that you're architecting. It's not the legal decision of the organization. One simple example think about Apple. They don't make Apple stuff. My Mac book here somebody else does. They don't ship it somebody else does. If you're architecting the entire supply chain of Apple you are including third party manufacturers. You're including chip fabricators. You're including distribution. That's a radically different thing than if you are architecting Apple retail. And that could be your boundary. And the boundary again is what does your organization want architected. Where will you be valuable to understand your enterprise's mission and purpose. Do you understand your strategic position. Where do you live in your market. What are you trying to accomplish. Are you fitting into your market. Are you leading your market. Are you driving your market. Those are all radically different things. And the three hard questions. As a leader of an architecture team. Are you being stood up from scratch. Is your team being rebooted. Or are you improving it because you're successful. And if you're being rebooted it doesn't say it's strong enough in here and I'm really sorry we didn't put that in because they thought my team thought I was being too blunt. If you're being rebooted don't do what they did last time because it didn't work. Learn business objectives. Why do we do enterprise architecture. Guide effective change. Our organizations all want to get better. Help somebody get better enterprise architecture is good advice. What change is required. To reach your strategy what's the most effective change what's the most possible change what is the least. Risky change those are all the criteria that you'll use to guide change but that's your purpose as an enterprise architect enterprise architecture team. I talked earlier about the four common use cases why doesn't architecture team exist. Support strategy if you are supporting strategy what you will be doing is defining. Change initiatives and portfolios if you are not involved in that you are not supporting strategy support portfolio. Managing a portfolio of change what are you going to be involved in driving projects what are the definitions of projects what's the synergy of projects what's the sequencing of projects what's the sequencing of change. If you're not involved in that you're not supporting portfolio. If you are you're in front of decision you're not chasing the decision. Supporting project boundary of the project alignment how does project fit what are the synergies in the project what is the things that are in it how to the constraints you're going to pass down to a solution. Last one supporting solution how's the change going to be done. There's a lot of other use cases for enterprise architecture IT modernization digital transformation they're normally going to fit within one of these. And if you want to know where the sweet spot is where the most successful architecture teams are. Supporting portfolio helping an organization guide a portfolio of change that is the most common success model with the lowest reboot rate. Supporting solution because the architect show up after the decisions are made an argue. And if you're showing up after the decisions have been made you are not guiding effective change you are interfering with effective change which leads you to be rebooted because you're a barrier to success. And when I've been a VP and driven an organization I know what I do to barriers to change. Use a bulldozer push them off the path and move on because I'm in a hurry and I want to know what to do that's right. This then comes back to architecture governance governance section that's in the leaders guide says there's two things you need to govern. First is the creation of your architecture does your architecture actually represent the change that company wants to do. Did your stakeholders approve your architecture. That's pretty blunt. It says if your stakeholders didn't approve your architecture you don't have an architecture you have an opinion. And what is the difference between your opinion and a portfolio leaders opinion. One of you has power in a budget and the other has an opinion. Guide somebody who's driving change. What will your order look like. What are the approved changes. Once you've got your architecture now what are you governing execution. Fundamentals of governance you're giving somebody a performance expectation you're saying go do this change and follow these constraints. Constraints architecture specifications. What are the rules of the change. You will use the open footprint data model full stop don't talk about it moving on. It's not an argument because that's what we're doing because that's efficiency for us and then you'll be controls what reporting back where the directions followed where the constraints adhered to and if they weren't what are you doing to fix that because those constraints exist for a reason. In this country we all drive on the wrong side of the road in my country we all drive on the right side of the road arbitrary rule both work I can drive here I can drive in Canada. I can't drive on the wrong side of the road here because I'm not conforming to traffic I'm not following it and there's a control often there's multiple sets of controls for that. Now customizing configuring what is it that you're going to customize and configure leaders guide says it's really really really clear you're going to customize your deliverable documents and your information that's it. Are you going to customize the ADM no because the ADM is an information model and if you don't have the information necessary to succeed you're going to fail guaranteed it's all about knowledge it's all about creating an engineering knowledge. The process that you go through you're going to customize and you're going to have to engage with business processes. And those business processes depend on where you are but the critical customization is what information do you capture and what how do you deliver it. If you want a really cool example togaf says that you come out of phase A with an architecture vision document. If you ever work at the government of Canada on transformative change you're going to see a really cool thing called a cabinet briefing document. Cabinet briefing documents were first done in 1868 and essentially are unchanged and they look like an architecture vision. What are the parameters of change what are we trying to achieve what are the goals what are the constraints and it is a document that then cabinet says yeah we'll fund. What's the purpose of architecture vision your stakeholders going yeah we'll fund. Then you get down to phase EG EF and you're building a roadmap and a plan what are they doing there. Your stakeholders are moving past yeah we'll fund to you go do fit in those processes are immutable. Now the processes are tied to your org model and I routinely run into things off we didn't work for the CIO if we only worked for this guy. It's all crap doesn't matter where you work for doesn't matter who your boss is it matters who you serve and are you successfully serving that individual. I've got architecture teams we've worked with for decades who are misaligned in terms of organization and successfully doing it because they serve the right people. You don't have to work for the right person makes it a little easier sometimes you don't have as much conflict with your boss. But what do you need to do. Organize for what your purpose is. Organize your team for your work product. Organize for how you manage and who's on your team. An architecture team that talks in the book about building a team or building a capability and it very deliberately is structured to be the leaders guide the leader being the person who leads the capability not the boss or chief architect. Because you're trying to accomplish that. And you got enterprise processes I mentioned those a few times that you're going to have to connect to your company has existing processes for planning and execution. Do you plug into them or do you show up late. Plug in so a lot more fun decision making processes execution strategy development governance processes. Really common if you're working in portfolio you have to tie into the budget process think about when your budgets are decided. If you're working on a calendar basis it's probably sometime in October. What does that tell you as an architect when do you need to show up. It's May. You need to feed into that process not the end of it because you're providing effective guidance. And all of this. All of our organizations want to change all of our organizations want to be better whether we're incrementally improving whether we are radically transforming it doesn't really matter we want to be better and our leaders want good advice. I have never met a successful senior leader who wasn't open to good advice about how to lead how to drive a change that was more effective. So everything you need to do if you're building your architecture team build a capability model build yourself out identify what capability what ability what people what processes what information do you need to succeed. All that 110 pages. It's all in there remember started chapter four then jumped to chapter five line up to what your business wants and you'll have phenomenal success. And then we're over to Chris who's going to talk about OK. Thanks for that for Dave and I just wanted to do a few housekeeping things which I sort of forgot to start. What we are going to do is to have a Q&A panel at the end so but there is a way if this thing was to click on in a minute to take questions remotely. So if you if you don't want to ask your question but you want to feed it in to the system you can go to slido.com key in the hashtag o g long and then select to go for use a group meeting so you can actually submit questions that way electronically if you don't want to ask them in the session later or if you or if you remotely we are actually I should have said we are being joined on it we are doing a live stream from here on to LinkedIn I believe at the moment and like to introduce our next speaker now it's Chris Frost. Who's a principal enterprise architect at Fujitsu Global Services Business Group so Chris is going to be talking about enabling enterprise agility and which is one of our specific new Toga series guides over to you Chris. So thank you very much Andrew just give me a moment here while I do the obligatory laptop and projector dance. Okay good so yeah thank you very much Andrew thank you Dave and as Andrew said my name's Chris Frost and I'm with Fujitsu Services I'm a principal enterprise architect but of relevance to what we're talking about here this morning. I'm also the lead author for what was called the enabling enterprise agility guide so what I'm going to tell you in the next 20 25 minutes or so is essentially what's in that box what's in that guide and how to use it. So here it is first up Toga series guide goes on to the snappily title code of G20F I mentioned that because that's actually the quickest way if you look trying to find it in the in the library because if you just put that code G20F in the search of the library that's probably the quickest way to actually find this guide and it's called enabling enterprise agility. And if I wanted to just put in one sentence what's this all about it's describing how to apply the Toga standard when you're working in an agile enterprise and I guess at least I would hope that's some that's a situation that applies probably to a lot of you here today. So I'm just going to do a quick tour of what's what's in this. So chapter one of the guide there's five chapters chapter one is just short introduction chapter two gives you some definitions useful things but then it's in chapter three where we start to get into the sort of real meat of it. Chapter three is talking about the the architecture development method the ADM and just giving a brief introduction to how does that fit into agile projects. Chapter four essentially starts to go into that in a little bit more detail what are the various techniques guidance for how you use the ADM in agile projects. And then chapter five which is called enterprise architecture in an agile environment is sort of taking a reverse point of view sort of looking at the kinds of things that you commonly find in agile framework. So things like the safes and the less and all of these frameworks some of the things that you commonly find in those frameworks and how do they fit in with Toga. So it's sort of taking almost like the reverse point of view. So just take a bit of a canter through through those chapters and obviously might go through the introduction and the definitions. That's just something to read there if you need it but chapter three which is just introducing the ADM and how does that fit into an agile delivery environment. I guess the one key point that this is making is that the Toga framework is not a waterfall thing. I hear quite a lot. Toga FADM is waterfall and sort of people cite the fact that you've got the ADM that sort of talks about phase A, phase B, phase C and so on. Well that's obviously waterfall isn't it? No, no, not at all. Yet the order of the starts and finishes matter of course. You have to start phase A before you can go into B before you can go into C and so on. And the order of the finishes matter and that you sort of finish A before you can say you finish B and before you finish C. And that's kind of just an inevitable logical flow because if you think about it how could I possibly be telling you that I've finished my technology architecture when actually somebody is still working on the business architecture. Obviously that doesn't make sense and you have a flip side of that. How could I confidently say yeah I'm starting to work on the application architecture when actually I haven't really finished working on, I haven't even started working on the vision so I haven't even really established the scope of what I'm doing. So there's a certain inevitability to the fact that I have to start things in this order and that I have to finish them in that order. But of course within that things can overlap and iterate between the different phases and in reality they usually do because even before the sort of term of agile working became popular. In reality as a practicing architect did you ever completely work through your business architecture start to finish uninterrupted, do the whole thing, finish it and then never come back to it again while you then worked on the application architecture. In reality you probably always did overlap these things a little bit, it's just that now that's just a little bit more explicit and indeed positively encouraged to do this sort of iterative development. Chapter 4 is then sort of looking at some of this stuff in a little bit more detail and there'll be some very familiar messages in there if you are familiar with agile working. So it talks about things like doing the architecture iteratively and again really if you think about it it's a common sense stuff isn't it. It's talking about doing a little bit of work, doing your testing, your validation however that might be stakeholder reviews and then going on to the next steps based on that feedback. It's talking about doing a little bit of architecture up front necessarily if you like the intentional architectures it's called in most of the frameworks before you sort of get into any of the construction because there are some, there are almost always some aspects of ground work, some sort of setting of foundations that you need to do before you can meaningfully start any construction. So do a little bit of the architecture up front but get to that first capability level as it's described in Toga, that lowest level of architecture, the one that you then actually turn into implementable designs. Get to that as soon as possible so that you can get as soon as possible then into actually starting to construct the solution, getting something running then you can start to gather live feedback from the use of whatever it is you're building and then feed that back into the later cycle. So do a little bit up front the intentional architecture but get to the point as soon as possible that you're actually starting to build some parts of the running solution. Another point it touches on is governance and from practical experience this for me is one of the things that is quite a significant change in our job of working because previously and again certainly from my own experience governance is something we tended to do in sort of big stage gate review types of things. You know you maybe have some major stage end review at the end of a design phase or something like that where you do some big review exercise, days of work possibly even more as you went through documents and sort of marked up how work and possibly sent things back for rework. But it all happened in that sort of stage end phase. Here we're talking about doing things much more continuously working as governance architects or as governance reviewers with the teams doing the development work so it becomes much more of a sort of a consultative and advisory type of engagement rather than a policing type of engagement. Don't be that policeman that just sort of turns up once every three or four months and sort of goes on and go and redo this bit. Be the helpful advisor who turns up perhaps every week and says yeah okay I'll see what you're doing there but you know a really successful way we did that over here was perhaps a little bit different and have you considered maybe that or yeah okay that's good but I still can't see. Where you're covering this part of the requirements so you know probably good on it again have a closer look at that part of your work so much more sort of consultative and advisory type of approach rather than the policeman like I said turning up every three months or whatever it might be. And as you're creating your architecture you've always got to be thinking about this continuous delivery aspect because again you know one of the fundamental mantras of agile working is this notion of continuous delivery delivering in small increments of work and that just won't happen by magic you know that has to be sort of deliberately and intentionally done. So as an architect you may be thinking of how do I organise my tool chain to and my operational systems to allow me to do those incremental batches of work and put them right from the beginning of the architecture work all the way through the various processes until it eventually ends up in the running system. So you know think about how that whole development and operational system will work so that you can do these little bits of incremental delivery. And then of course the operational system itself the running system itself that too you want to be agile and responsive and so that will mean things like if you're wanting to enable these small rapid releases. That's great but of course sometimes releases go wrong don't they sometimes you need to back things out and especially if you're doing a high release cadence and you want to sort of have the minimum barriers possible to having these rapid incremental releases you also need to have pretty efficient mechanisms in order to back it out when it goes wrong because things will go wrong. Even when you've got the best experts in the world working on things things still sometimes go wrong. So that can often come down to just simple things like having software switches through your system so that you can turn bits of it on and off again and thinking about planning in advance how you would roll back a change if it went wrong and that kind of thing. So these are all the things to think about when you're wanting to create that architecture for continuous delivery. And then another thing that's in this chapter might seem a little odd because this is a guide about working in an agile way but of course as we know that is not the only way. Yes it's the way that this guide talks about but occasionally for example it is appropriate to work in a more waterfall style for example if you're working in highly regulated safety critical environments where very comprehensive design reviews have to be done for some regulator requirement then you will have to take a more of a waterfall approach to create all of those specifications or whatever it might be in order to fit into that environment and as an architect if you're the architect leading the work and you need to think about actually yes what is the appropriate delivery style and sometimes at the end of the scale you may be working in an environment where you've got to do something extremely quickly it's almost like a one shot process through we've just got we have to get something completed in a very short period of time and so you might take a very rapid approach as it's called so actually in the chapter it looks at the three different possible delivery styles which it calls the rapid, the agile and the robust and actually the author of that section is actually sitting right here at the front my can is so I can defer any questions on that part of it to Mike here so thanks for Mike for that particular section. And then moving on to chapter five like so this is a one where it starts to take sort of almost the reverse point of view and say okay so some of the things that's commonly talked about in agile frameworks how does this fit in with Togaf so it sort of looks a little bit about the project to product shift and what does that mean in terms of an architect working with Togaf that now you're taking a more sort of product whole product view of what you're working on rather than a project view it talks a little bit about how techniques like design thinking fit in design thinking is actually covered in many places within Togaf and indeed other open group standards but here it's talking about how for example would that fit into Togaf it talks about using things like the business model canvas because a lot of agile approaches use something very similar to this is a good way to get that initial overview of very high level just what are my business objectives here what is my cost structure my revenue structure what is my value proposition here you know all of those early visioning type of visioning and scoping type of things that you need to do and that can be a very good approach for doing that and it talks a little bit about the need for using agile artifacts often meaning things like templates because these things set a tone if it makes me smile sometimes perhaps smile is the wrong thing but if we're asking our architects to work in agile ways but then the next thing we do is give them 100 page template to fill in that's a bit of a conflict isn't it it's quite hard to work in a rapid iterative sort of way at the same time as asking somebody to fill out 100 page template so if it's your job to be defining templates then think about how you could make them a little bit shorter a little bit more minimalistic to encourage that sort of iterative working so that's taken a quick sort of canter through the major contents of the guide and some of the things that are in it now if you're thinking about agile architecture and how I do that then of course there's the guide I've just described the enabling enterprise agility guide I don't know if we've got any copies of that down here but certainly I've seen some downstairs but the good news is from the open group there's also a number of other things that I would encourage you to look at as well if you're an architect working in agile ways there's another guide happens to be G210 again that code document code good way to actually find them in the open group library applying the togaf ADM in agile sprints and what that guide does is it kind of zooms into the very particular part of the problem of how do I how do I adapt the ADM to fit into the sort of typical two week or so sprint cycles that common methods like scrum for example talk about so you know it really sort of zooms into that part of the problem which the enabling enterprise agility guide also looks at but takes a sort of view on some of the other aspects as well that I've been describing and then also I'd encourage you to look at the open agile architecture work known as the OAA to its friends that's that's another product of the architecture forum which of course is a forum in the open group that owns togaf it covers oh yes and I should give a shout out to the chair of the OAA work over there so Steve Nicol over there so I'd encourage you to look at that too that gives a whole collection of tools and techniques and guidance and building blocks as they're called in the OAA for helping you with agile working and some of the some of the same techniques for example I think the OAA also covers a little bit on design thinking if I'm not mistaken so again another source of advice and guidance on agile working so to wrap up and summarise I would honestly say that enterprise architecture is improved by using agile delivery frameworks and vice versa and the main reason I say that is not some sort of religious doctrine it's that by adopting that iterative do a little bit of work test it is it good carry on is there a problem adjust move forward again and possibly even if it's appropriate completely pivot going a different direction taking that approach is I think in most cases genuinely beneficial to that let's show we said the older waterfall approach where you had very rare opportunities through the life cycle to actually take the opportunity to pause check am I on the right path and sadly some of the project failures that some of the older people in the audience may have seen through their careers you know we maybe realise just a little bit too late that we were on the wrong path so that the sooner you can do that and correct the better and I say vice versa as well because if you're working on some of the larger problems in developing systems or developing digital solutions then there are a lot of problems that you can solve in these emerging ways and you'll hear people saying things like no the the best architectures spontaneously emerge from the development teams and yes that that's true to a point but I would honestly say when you're working on the room on the on the larger scale projects then if there isn't some in that intentional architecture up front laying down some some of the foundation some of the principles some of the guard rails these types of things then you know it's very easy for a purely emergent architecture to sadly start to go off in a in a slightly strange direction and if you want an illustration of that just think of natural human evolution that human evolution that's essentially been an emergent process and mostly you know this it's quite a good biological machine isn't it it works but then there's some there are some slightly crazy things like you know where we breathe through and where we eat through is crazily mixed up I mean who thought if you were designing that who thought that was a good idea you know that the tube that you put your food through is also the same as the tube that you breathe through because there's some obvious problems with that isn't there if you think about that from a sensible design point of view but hey that's emergent architecture mostly good but you can find yourself kind of going developing in a wrong direction so EA is improved by using our delivery frameworks and vice versa it does mean some change of ways of working if you've not done this before now I should think talking about this now most of us will have experienced this so we'll be familiar with the fact that yes it does mean a change to the ways of working with incremental development and the continuous governance but you know there's nothing really so hard about that there's nothing so fundamentally difficult about that it is an adjustment that if you've not already made it I'm sure we can all do it and finally I would say and I hope they've made the point clear on the previous slide there is a lot of help available from the open group there's the enabling enterprise agility guide the sprinting the ADM guide the OA material there's a lot of really good material there that's available from the open group to help you as architects work out what you need to do working in an agile delivery environment so thank you very much that's a brief canter through the guide and I encourage you to go and take a look at it thank you next up is Dave again and Dave's going to tell us about the ADM practitioners guide so it's another guide that Dave has led the team working on I left my dongle so that the laser thing works so this is about the practitioners guide and one of the things I want to highlight when we're thinking about the guides is if you flip to about here there's a section on how to do agile it goes on for an outstanding two paragraphs and says it's really really important to get it right or you can get Chris's guide which goes on into a little bit more detail one of the design characteristics of Togaf and the guides is to allow us to do that I have a generalist guide on how to do enterprise architecture how to do it to support the four basic patterns strategy portfolio practitioner we then have more advanced guidance on very specific use cases there's the seven guide guides around business architecture here says business architecture is really important do it right so what we're talking about here in the practitioners guide is the transitioning to delivery developing and delivering an architecture that guides change putting the ADM in practice and inventing creating knowledge knowledge that can be used to guide and constrain change what the architecture landscape is and what to find in a good architecture repository so in practice Chris talked about the ADM being an incremental approach with some logical constraints what you're doing when you're architecting as you are creating knowledge you are creating an understanding of what your world looks like today what your world where it fails practitioners guide talks about deficiencies your organization isn't happy it has a shortfall and shortfall and agility a shortfall and capability a shortfall and something your target addresses that shortfall what does it take to make that target change that's knowledge what is the best place to address that change how are you moving forward because what you need to know is exactly where your enterprise fails where does it fall short that's the fix if you're not focused on where the shortfall is you're not focused on something that's particularly useful and that's the core piece in developing the ADM what is it that will make your stakeholders happier what is it that will allow your organization to meet its objectives and goals and strategy what work will close the gap and that's when you look at the structure of the ADM and you think about governance phase A phase B phase C phase D are all about figuring out what is the work that will fill the deficiency phase E and F are all about agreeing to do the work without an agreement to execute you don't have a change that's going to happen and you're not going to get a well thought out guided change without understanding what the deficiency is and what needs to fill it is it software development is it organizational redesign is it standing up an architecture an agile team depending on where you're working in enterprise architecture you may be doing very different things and that's one of the important things that's in practitioners is highlight who you are serving and the questions you are answering may be very very different all of this is about creating knowledge knowledge engineering creation of knowledge and the irony is in the practitioners guide deliberately you do not get a copy of the crop circle ADM wasn't put in we left it out in fact when you go through this what you're going to discover flipping through this this one guide has not one fundamental diagram in it because it's talking about how to put those into practice how to take those fundamental constructs and execute them instead we need something actually radical project plan in a gant chart on how to develop an ADM for strategy and what you'll see is exactly what Chris said you don't go A then B then C then D if you are creating the knowledge of your business architecture you're executing phase B you're probably going to start developing your business architecture simultaneously with your application architecture simultaneously with your technology architecture simultaneously with your roadmap why because they all play together that's what iteration is in practice it's not going from A and bouncing back to B it's having your business architect actually talk to application a few years ago there was this really cool thing invented ATMs the little things in the wall hole in the wall do you think a single bank thought that was a good idea and said business architecture we're going to completely change retail banking yep that's what we're going to do and we're going to go and ask for some technology to be invented or do you think some jerk showed up with the concept of an ATM and radically re-changed banking was a ladder you don't get to do technology and application architecture after you've made your business decisions because the technology capabilities the application capabilities change what you can do in your business architecture that's how you do it in practice you tie them together so that you can move forward here's a couple of plans architecture for project architecture for portfolio what are the big steps of work you're going to do if you're working in architecture for project one things are you have to accept the fact that your portfolio your big change have already been decided no one asking you to invent the change portfolio of change there flip side is if you're working in portfolio you're going to be worrying about viability and opportunity not so much about execution the questions you ask are very different the ADM you use is identical who you're serving and the questions you're asking are the differences so think about those plans for whom you are serving that's what the big section that's in here there's a whole giant section as the Gantt chart walking through and that was highlighted to what does it mean for ADM and execution that you've got these start and finish dependencies because you can only create your knowledge by tying it together don't follow don't don't think of the ADM as a waterfall work plan the architecture landscape simplification of reality breath level of detail when you are working as an architect to deliver an architecture you're not architecting the entire enterprise top to bottom across all domains across all scopes of it time someone is asking you to address the deficiency you're going to be constrained conceivably by superior architecture architecture that's already been decided we are a retail bank that's already been decided what's your focus stop banging that promise you build formal models how much work do you do enough for confidence for the question that you're being asked Chris's guide G20F and by the way he is right that is the fastest way to find it says don't do big giant up front architecture practitioners guide doesn't tells you the same thing do enough to guide the change for the question you're asking and that may be I'm feeding a constraint into my agile project you will use this data model don't care what how you develop it don't care about your UI don't care about a long list of things why am I caring about the data thing because I know this app needs to integrate with this one I need you to do the equivalent of drive on the right side of the road because it would be a lot more convenient if we let every agile team every driver in the UK decide speed limit with the vehicle and what side of the road to drive on that's what a lot of bottom up software emergent architecture delivers then you spend a thing called you develop technical debt if it matters to you in your architecture put a spec in and build appropriate models you're going to have many many models Chris showed an example of the value business model canvas using a business model canvas is a model kind it tells you things I use business model canvases all the time not at a product level I use them at an enterprise level because all of those resources that you need on the left oh my god it's just a walking capability model right there what is it that I need who are my resources who are my partners it's all on the left one model won't show you why your enterprise isn't agile one model won't show you how you have to protect your data one model won't show you all of your application integration and one model won't show you your supply chain weaknesses if those are your problems you're going to have to put different models together to find the gap you're going to have to create the knowledge as you work your way through which gets to your hard bit working with your stakeholders your stakeholders own the architecture the technical thing on governance in here is dead clear it says your stakeholders own all decisions about the architecture it also says your implementers own all decisions about implementation by inference who owns what does an enterprise architect own in terms of decision nothing it's not a decision making job it's an advisory job your stakeholders own the architecture what do you have to do then work with them so that they can understand the trade off do they understand the implications of their choice wherever their choice is and when an implementer makes a choice do they do your stakeholders understand the implications of that choice if it is not following the architecture what is it that you do all through this on the price fundamental nature of enterprise architecture is getting it done so that you can actually help your company do the valuable bit which is change my practice we have a joke time to latte because you know an architect has delivered value when they can sit at a cafe and sip a latte because the longer they spend architecting the bigger the delays they're putting in in the organization executing the change architectures about creating the knowledge to guide effective change value is created in togaf space G when the changes executed and value is only realized after the change is successful so if you're an architect time to latte guide effective change what needs to be fixed what's the fix what is the work that your organization will fund and pay for general guide in the guidance as Chris said there's lots of other material that's available specific guidance around business architecture capabilities specific guidance around working in an agile framework G210F and G220F specific guidance as Celine's going to talk about doing things around sustainability the reason for all that specific guidance all of us have different companies and different problems and we use a common framework the fundamentals don't change thank you very much thanks Dave as Dave mentioned Celine is up next Celine's just coming to join us for those who don't know Celine Celine is a lead architect at AXA I guess you'll tell us a little bit more why you're Celine do you need any of these dongles yes hello so I'm a woman and I'm a French person so sorry for my sorry for my English maybe to start I would like to know who is a member of the architecture forum and who is not in the room so a few a few ones right there and yeah quite a lot okay now because I'm going to speak about a guide that is under company review so if you want to take part to the review of that guide if you are a member of the open group you can do so and if you are not yet a member maybe you can become one with your company so maybe you have noticed that the topic of the forum is enterprise architecture for sustainability and this is a proposal of a series guide to provide some guidance to enterprise architect to address the digital sustainability topic so it's very focused on digital sustainability how but technologies IT can can really support sustainable word and how we should proceed to reach that that objective yes a few words by myself I've been taking part to this event in the open group first as a representative of Aris Mawry used to be the French office of the open group so I've met Andrew for instance quite a while I remember a lot of time ago when I first came in this place to attend the meeting I've been a TOGAF trainer also and at the moment I'm an enterprise architect in an insurance company which is AXA so I take part to the enterprise architecture governance and I'm also leading for AXA's digital sustainability program maybe a few words about myself also in 2018 I have so there have been different studies that have been published in France and also in the world about you know what the carbon footprint and ICT carbon footprint and when I have understood that I have thought it was very important to leverage what I knew enterprise architecture which is a systemic transformation approach to address that so what we try to do with that guide is if we consider our skills as enterprise architect how can we use them to address that topic so it was really what we try to do it is a result not of so I'm representing today but I'm not the single one who have worked on that there has been several companies involved I would say the railway SNCF company so AXA of course people of Société Générale people from Thales in France have also contributed and we were able to leverage some of the enterprise architect community we have in France to do that so it's a result of a collective work that was done in the context of a French NGO the shift project that is dedicated to low carbon economy and that is now transmitted to the open group for a more international benefit yeah I'm doing a call for participation because yeah I didn't say it yet but I am co-chair of the architecture forum and I have a patient in life it is writing papers to international standards and I would be very happy to have many other people who have that same patient because I think we can have more definitely to read the paper that are proposed to propose some paper and in my architecture practice this is something that has brought me as architect because it is a way to step back and stepping back when we are engaged in organization with short term request is something that you don't do in a natural manner so coming back to the open group writing paper either way for me like teaching like presenting today to step back which is a fundamental value I think in my enterprise architecture practice so Daniel with over there send the company review request for this guide and this guide is not finished so it is kind of preview also to give you a flavor of what is in and to encourage you to take part to the review because the more people take part to the review the more universal the content becomes and also if you take part to the review this guide becomes a little bit yours so it's changing your relationship with it and you will have a different attitude when it will come on the market and maybe like a book that Andrew may distribute what if this happens so yeah so I told you you have here the summary because I think it's very important to keep the lineage of knowledge you know where things are born so I told you as I started with a shift project delivery so you can find some documentation there it's available in English and it's free so it's very easy to access so in September 2022 we have delivered the first version of this guide it was well presented at Indienburg APC because we were started the architecture forum review so we had some review so I want to give a special thanks to last person listen Linda Tate, Chris Fort and Robert Baseman who made some feedback on that then we had the editor review with your team and now we are starting the company review and it will last until end of May so it's plenty of time to make some feedback so I'm presenting here the table of content because I think it's important for you to get the global idea of what is there it's starting with an intradiction on the environmental impact of ICT because it's something well I don't know about you but in France it's something that was not very much taught at university or in an ingenious school so it's something on which we have to work so there are many tools that we have to use that no exist in France and the guide is proposing a review on that I will have a short slide about it after but this is a main topic I spoke in Indienburg and then so we have a chapter that is explicitly the relationship to existing standards of the open group because the idea is to make things consistent and then we describe the capability so the purpose of the digital sustainability capability and how to deploy your sustainable information system policy so we will go through that and then what we propose is a reference model so a business function reference model where you have the description of the different activities you need to have in an organization that would like to move toward a sustainable information system that is compatible with a different environmental challenge we have at the moment so I'm going to deep dive on that so then we try to provide high level representation as you can see here and detailed level representation and also some comments on each box so the idea of the framework is to provide different level of representation and of course each organization like anything in Togaf needs to customize it, it is a guidance leveraging best practice that I am personally applying in a well that have been developed in the AXA context so it's also concrete experience but also from other organization so all is not true for all organization and you have to find and maybe you will have to add some elements for your specific organization to compare to that we are finished with the last chapter so for those who have had at the beginning of the week there have been many discussion about how to measure environmental impact and clearly to drive enterprise architecture in the right direction so there is the open footprint standard that is also developed in the open group but we need much more standard about how to measure environmental impact and guidance for that so we describe in this chapter also what we think we need in that domain so Dave knows that maybe Paul also have a kind of working on sustainability makes dynamic system maybe some of you know about dynamic system and if yes I am interested to be connected with you but system dynamics is very important when you think about sustainability and here it is a diagram that is kind of representing where the pollutions come from so I have put it in a red square on the right side and the fact that you have different causal effects so the more usage you have the more infrastructure you need and the more infrastructure you need the more usage you will develop so this creates kind of positive feedback loops that makes the current IT sector generating a lot of equipment consuming a lot of electricity that leads to a kind of pollution normally when this happens you have a balancing feedback loop that you see at the bottom with the cost because when you have more infrastructure the cost is increasing but in the case of IT cost efficiency has increased a lot so the cost has not increased which explains why we could develop a lot of digital without exploding the cost of the capability and this produces something that is a little bit contradictory you may think that optimization is something that is good for sustainability but optimization alone is not good because you have a rebound effect like you can see on this diagram and the volumes keeps on increasing so you need to define some rules to keep the volume under control so that your global pollution impact or energy impact is put under control so I'm not I could spend hours on that diagram it's a causal loop diagram inspired from system dynamics and it's main strength is to show causal link and also reinforcing feedback loop or balancing one which are the one which we have to play in system dynamics so you have here the reference I want to tell you also that OECD is proposing also some method around that I think it's very interesting to see that OECD is developing that and it's important also to understand rebound effects so why does it make sense for enterprise architecture? Enterprise architecture is a systemic transformation approach for the organization so it makes perfectly sense to dedicate it for that so when you will go through the guide you will see different artifacts we have a first one that is representing the information system life cycle management and what is a bit different compared to what we do usually is that it is looking at the full supply chain from the extract of material and natural resources until the waste so you have to consider the full life cycle of your IT equipments when you think of digital sustainability and in that life cycle in the middle of it you have to build the machines so this is usually what HP is doing well bigger providers and then you are building an information system so you are connecting them together to deliver some services and then you have so this is where usually us as architect we work and then you have to use and maintain it and at the end like for the data because a lot of data you have to think on how you are going to manage the waste or the recycle what is very important also in that ecosystem is that there are the manufacturer, how they were trained, what are the skills they have and us as well as IS professionals what is our knowledge background and what are our practice and at the top of it you have other actors that are in the ecosystem very important the ones that regulate the sector so here it's the government I would put more or less the open group in that area it's not a regulator but proposing standard is a way also to regulate the worldwide ecosystem and then you have NGO and also I would say educational system with universities that share the knowledge on that that is very important so it's at the moment we observe a kind of burst in that area in France I don't know about other countries but really it's significantly improving so it's to explain that then you have the reference model that we have proposed we try to take care to use also archimates so it is archimates business function that we represent there and also a global capability to deploy a sustainable information system policy and the reference model is organized like that at the top you are first and I think you know that perfectly as enterprise architect but you need a sponsor in your organization you need to stop management to ask you for the transformation and if not you are just preparing your land but you are not executing the transformation so it's very important to get the sponsorship especially on the sustainability topic that is a new topic that many organizations tries to find their way on that and we need to invent the past because we don't know yet exactly where we need to go so the sponsorship is something very important at the bottom you can see the governance that is the operational I would say day to day check that the strategy is well executed and in the case of digital sustainability you can have a specific CSR so corporate and social responsibility governance but the approach that I have followed and that I see a followed is more to add the sustainability criteria in existing governance rather than to add a new governance because we already have a lot in your organization and at the end the point is to have the sustainability criteria embedded in any decision that is made so the idea is more to leverage the existing governance and to use them and by the way it's working quite well it's also quite funny you know sometimes you may have internal control or audits coming on the topic sometimes well it's very useful but everybody's not totally happy to do that but on digital sustainability topic people find a lot of sense at doing audits or internal control on that and there is kind of synergies that is created in the organization and new interest for all different magazine to address that so I think it's very motivating and it's generating really good work so that's at the bottom at the kernel you have the design and build sustainable information system here it is about how we manage data how we develop how we do data science how we do architecture so I am working in this sector since 1996 so it's quite a while now and I think since the beginning of my career IT is cheaper and cheaper and each time I say oh guys you have to take care of your data volumes they just answer me but yes let's say in the data storage is costing nothing now so I'm fed up with your control I don't want to do it anymore and there is a major change we have to do in your organization we add this winter an energy crisis in Europe so we were fearing in France to have shortage in term of electricity it's the first time I leave it since I am born hopefully the weather has been nice and we managed to get enough gas and so on but I think it's a huge running we have developed IT in an environment where energy was really abundant and we have to consider that this is going to change so the energy cost of the solution we deploy is going to be instrumental to secure our digital because if there is no more electricity there is no more IT we had to work on zero IT plan to see how we can operate in France if we have no more electricity and I think it's a kind of paradigm change for IT professionals and we need really to think of that so it will mean training people it will mean changing the practice so this is what is in building of course in operating we will have to repair a lot more the equipment culture is about the training how we do innovation and so on and so this is what you have at the middle which is very important because if you don't understand that we have a problem with the environment you don't understand why you should change your IT practice on the right hand side we have put the measure so there has been a lot of conference on that we can speak three hours two days about the measure of ICT environmental impact I'm not doing it now but this is very important and like requirement is in the kernel of TOGAF the measure of CO2 electricity consumption is at the kernel of any decision around sustainability so it's very aligned I think with our value but it is science based approach we have to check that the decisions that are made provide quantitative result because there is a kind of emergency also to act efficiency on that and then there is what I do today it is the ecosystem we all work with a lot of providers they are making progress on that probably still have to do some and also we need to put in common so this is the idea with sharing with the open group the best practices so that we can be fast in their deployment in the world so in the guide we do also mapping with the ADM which is quite natural I'm not going to detail it now because I think I'm almost at the end here you have also some guidance about the measure what you should measure and a few steps proposed to go there and to do it yeah and we also worked on when we work with providers what are the data we need from them so of course you need totals how much CO2 for instance when you use I don't know the staff services from a provider or any cloud provider you will need data so you need the totals how much CO2 this is emitting mynd i ddweud i'r lleidio cyfnodd, a byddai fyddai yn oed yn gweithio'r ddau yn ffant yw'r pethau o'r dweud y gweithio arall sy'n ddau ymwneud. If you want to act on that, you need to know to have more details. This is also a proposal of what we would need in terms of measures. Felly, mae'r farchitech sy'n cymryd i'r prinsibol cyfrant digital sy'n ddweud, Eli Always has a look at it, on the spirit of the Top Gaff principle. Try to work on that. Some of them are reinforcing architecture principles. I'm thinking architecture principles, I tell you it's better to double-ster the data and stuff like that. Try to say that you should have one solution to do one thing, But IZ is not a one thing and many things like that. A reduction of complexity makes total sense with digital sustainability. All what concerns cost efficiency in terms of energy or in terms of equipment also makes a sense. But probably, and I am going to make a link with the first conference introducing this open group even with Ron Toledo. It'n cael ei ffordd. I think his presentation was less for less. And I think as architects we will have sometimes and probably more often to say no for digital deployments that don't bring so much value compared to the pollution they generate. So saying no is never easy. I think you know that as architect it's always better, easier to say what? You can go on, but I think it's something we need to prepare and do it. I think I'm finished for today, so Andrew, I don't know, I'll give you my pleasure. Okay. Is it just on there? Good. Okay, yes, so we're going to do a panel now. What I'll do is I will walk around with the mic. Shall I, and just if anybody's got a question, I can bring the mic to you. Okay, so Chris, you're going to join the panel. So anyway, who'd like to kick us off with a question, put your hand up? Nobody? Questions for our panel? Oh, Michael's going to start us off with one, good. Thank you. Are you on the panel as well, Andrew? Yes, good. So it sort of applies to you and the panel. And it's really to do with the restructuring that we've done in 10. So we have the foundation and we have the series guides. The foundation is 60 years worth of basic understanding, running through enterprise architecture, through IVM business systems planning, through Zachman, et cetera. We end up with the ADM and the content metamodel. Those are two foundational models for organising what we do. The series guides are examples of people saying how we could apply it. But they're just opinions. And often a contradictory with the foundation. So when we teach it, we look at sections in the foundation, sections in the series guide. They say different things. And that's fine because the series guides are people taking stuff. Here's how we've applied it in certain situations. So does that represent some reality in the difference between the two? That's the first. Well, if you're asking that to me, I think if you look at the series guides, they usually make it pretty clear when they are making, I guess, what you might call an interpretation of the standard. They're making it very clear that the standard may say that a stakeholder is X, Y and Z. But in practice, in the series, in practice, based on their experience, they treat it this other way. No issue with that rule. Except there may be 100 different experiences of doing it differently, which may all be equally valid. So the issue is the series guides are not the way we do it. They are a way that's been proved to be useful in certain circumstances. So when we teach it, we would like to go across all of those different alternatives and say, here's how we've got to apply it. This series guide says this, this series guide says that. Here's the examples. And we can then take it back to the experience of the people who are actually sitting there to what happens in their business, which may be very different to how some of the series guides have worked. So what I'm really getting at is that in the way that we're now structuring it, we've said the two are together in the standard. So the foundation and the series guides are now the standard. I would say that personally I don't believe that to be true. I think that's a problem. I think what's in the series guides is extremely useful, but is particular opinion. They're two very different things and I'm not sure we're clear on that. And then also we'll talk later in other sessions about how that affects the training, a lot of the feedback that a lot of the trainers have given around this. So the question is, the series guides are really useful example experience of how to apply it in certain circumstances. I don't think anyone disagrees with that. Is there a fundamental difference between the foundation section and the series guides? And how do we make that clear to people or is that a misunderstanding of what we've got? So it's about that fundamental structure. I would argue that that's a fundamental misunderstanding. If you look at the TOGAF library, the TOGAF library goes through three stages. One is fundamentals. Here is a framework. Then there are two sets of guidance material. One is the TOGAF series guide and one are the white papers. The design structure of the series guides versus a white paper. White paper unquestionably opinion. When we do it really well, and I will happily admit we don't always do it really well, is ensure that the series guide goes through the appropriate levels of review so that the best practice is that it exists as paper, a guide, and goes through multiple reviews before it becomes a TOGAF series guide and part of the standard. The other aspect is being very clear about the context and applicability of the series guide, which can either be very general business capabilities or can be very specific. Business capabilities in an environmentally sustainable way for ICT, which is a very, very specific guide. The other aspect that we've got, the limitations of the contradictions inside. My advice then is go on the bug tracker and put a comment in. Until that is done, nothing is going to change. I agree with that in the sense that what we don't have is a controlling mind yet. There are some aspects of trying to get the controlling mind in place, which says if we said A and B equals this, is that true? Have we got two different Bs? That's not really been done over the last few years. Most of the reviews have been done by relatively small numbers of people because that's the number of people that get involved in doing it. We only need ten agreements to get a document passed. What I'm making is the observation that the series guides and the foundation have different histories and different content. We've put them together and said they're sort of on parallel. I think this is not to say the series guides aren't useful. I think they're extremely useful. But I don't think they have the status of the foundation. I think also when you teach it, the foundation allows you to then go out and talk about all these things in context really, really well. I think we're taking a slightly different view on it this time. We were actually addressing it. We looked at the standard and it's very broad now. We're not saying let's teach everybody everything. We've gone in and we've focused on it. We're actually drawing on the experience of the architects who put themselves forward to write these guides. What you're doing is, this is members of the architecture forum have come to the open group. They have contributed their work. What we want to do with the teaching is actually to give that experience, to make that experience available to our students. So they can look and it's more like, what would that enterprise architect do in that situation given the guidance that is there? You can put yourself in there. But as Dave pointed out very clearly, it's not necessarily prescriptive. Some of it will be in specific cases. Some of it won't be. Again, I think there actually needs to be an adjustment for the training community to take on board the approach that we're giving now. So it is different. I get that. We've got enterprise architect, business architect, agile specialist, digital specialist, EA leader. We've done that purposely. We've broken the link between calling it Togaf 9-something and Togaf 10-something to focus specifically on skill sets and competencies. I understand what you've done. Getting people into the thinking mode, I sometimes think maybe this is being unfair that the trainers want a very black and white thing. We're usually trained by taking clients' examples and go across hundreds of different things. There's nothing to stop you doing that. What I'm saying is not the stuff's not useful. Not that it's not providing a perspective. It absolutely is. It's been put together at the same level and I think it's a different level. And I think that's what's causing some of the issues. Because also the people that we try and get to use the standard are working at many levels from companies with hundreds of thousands of people to people with small companies, different environments, and we would apply these in very different ways. So the comment is there's a whole discussion to have on that which I'll put upon the side. It's that the structural change intent may have caused a number of other people, I think, to have a problem in the way we can apply it and explain it. The other thing, and I'll do first thing, just quickly say get involved with the forum. Obviously come and talk with the forum. We've got the chairs of the architecture forum here and in the room. So these are the people to come and get involved with and talk about it. I don't expect other people to follow what I've done as the answer. I expect them to follow it as something to consider. And that's the flavour. I think there's more consideration in the series Guides and the Foundation. That's how we always looked at teaching in the past. I think that gives you the space to make it real for people and to pull out particularly in examples where the series guides are absolutely spot on giving you the real answer to this question. I think it's two different types of information. We've had at least one contradiction point to that and we've got some wording improvements in GitLab. Obviously we need the architecture forum to progress some of those changes. Selenia, we're going to say something. No, I wanted to... No, because I am asking... You know when your author, Toghaff, gave his guide you tried to ask yourself what is in your practice relevant to put in the Toghaff. So I think the exercise for me is very interesting. There is one thing I was saying was teaching that standards are never finished and people when they come to a course they would like to have the perfect standard. But standard are never finished and this is why I call for participation to review and authoring because I think we could be more dynamic on that and when you seek contradiction I think it's very important that you send it because we can improve the standard. Then when you say it is a specific opinion yes, no, it's not the same level of the foundation of Toghaff and I think the split between the foundation and the series guide is on purpose. I mean it's not the same documents but it represents it has gone through all the process of the open group and the people who are trying to reach a kind of universal consensus position on the topic, the number of people contributing. So this is also always an attempt to reach that but it's never perfect and can be improved. So I don't totally agree with you when you see it's just personal views. It's more than that. It's not as universal as the core standard but the aim is to provide a kind of standard guidance specific to pick for instance on metadata management like the one we did with the information architect from. No, no, but I think your feedback is very... No, but it's very fair and I think there is a lot of content that was added which I think is great but all this needs to be digest and maybe improved a little to reach a more comfortable level to teach. Hello. Hi there. My name is Devine. I'm an independent consultant. I come from the Washington, D.C. area. What actually made me come to this summit is the EA for sustainability. Now I once in a while, not once in a while, the kind of work I do, I'm called in both in the private and public sectors to come in and address a business need as an architect and sometimes that involve the entire enterprise. Sometimes it must just be part of the enterprise. Now what I want to understand is I have two questions actually for you, Miss Ellen and everybody. Anyone else that can help? How do you kick off a conversation on how this business needs that I want to address are going to affect the environment and how do you get a buy-in from the customer? The customer thinks they have a problem and they need someone to come and address a problem a need or many problems or needs and you come in and you start bringing conversations about the environment and sustainability. Also, do we have some kind of tools that if you are planning to actually deliver or implement a solution, do you have any kind of tools that you can qualify or quantify the environmental impact of the entire implementation or delivery? Those are my two questions. Okay, maybe the first one I'm going to try to answer short and maybe we can discuss afterwards. So I think Dave said something during his presentation is that you have to understand so if you are an independent you take part to different enterprise and it's very important to understand in which enterprise you land is it a small one, a big one, a medium one and what is a business model? Depending on the business model of that organisation, sustainability will not have the same flavour. So I'm working for an insurance company. Insurance company job is a risk is to protect people, society, cooperation and addressing the environmental topic is quite natural in that context because the more natural catastrophes you have the more costly will be your insurance. If you are working in an energy company I think it's totally different. So you will have to find out in the business model of the company you work for what, how is it it by the environmental risk and how it will be it by the environmental regulations that will come in the future. And then you will find so there was also very good presentation where people were explaining how you can get some value also business value out of that. So I think it's many ideas for that. And I think the other question. Can you repeat your last question? I had it in mind but I... The second question was about how you qualify if there are any tools. All the software provider at the moment are proposing some tooling for that. So yes there are many tools too and they are around measuring carbon footprint so there are a lot of them. I think there was a presentation just before where all the logo of the company proposing tooling was displayed and there are a lot of them. So yes tooling comes but again like all the time we have tools but we miss data but that's... So when you're looking at tooling there's a couple of places you could easily start. One get an advance copy of Celine's paper and read the system dynamic model of ICT cost. Second is look at scope one, two and three and simply break scope one, two and three down into the constituent parts and apply those constituent parts to your business model. Whether you're an energy company or a transportation company or an insurance company you are going to have energy uses that you are in direct control of or indirect control of. Those are costs in your organization. Then when you're looking for gathering the information and comparing it open footprint is great because it is providing a fundamental data model that says here's a way to talk about it. Are you talking about megatons of carbon or grams of carbon the number four has a huge difference. Do we have any more? Do we have any more questions? This guy looks like you'll ask a hard question. This is an easy one. I'm fairly straightforward. First of all, my name is David George. I work with the insurance company. Going to digital sustainability what do we think this is probably mostly for small to medium size enterprises where CTOs basically looking at their energy bills and as a solution basically moving from in-house data centres to infrastructure as a service or platform as a service with public cloud companies. Do we see that as a viable solution because given say the main public cloud companies we know what their energy sources may be or is that just simply moving the problem? So if you're looking at the advantage that you're going to have if you're trying to deal with your energy footprint by going to an external provider is they're going to do all the math for you and when you do your purchasing decisions if you're paying attention to both their unit cost and their intensity measures you're going to drive them as a customer into being more and more efficient and you'll see that with the large providers now switching their energy sources over to renewables as fast as they can in as many places as they can to deal with that. But that's only part of your equation part of your value and where you choose to spend because if it really matters to you you are probably going to be able to build an on-prem footprint that is more energy effective than a shared environment but you're then going to have to take the accountability to get everything right and if you're not prepared to do that work going to a common provider who is by market driven to be effective enough will save you time. Did I misstate anything for you? No, it's good. Thanks for... So maybe you have part of the answer on the diagram I show because the hyperscale data center are more efficient than the on-prem one but if your volume is exploding I mean if the fact it's a lot easier or at the beginning only cheaper because you will see your... I mean the question of the cost I think with the raise of energy cost is going to appear also in that area from my point of view I think it's already appearing in some area but so you have to take care of your volumes at the end if your volume are in an exponential growth your pollution will grow also and sometimes so it is a change in practice from your on-prem to the cloud the way to monitor the volume and the consequence for you are a bit different so you need to adapt on that and there is a risk because it's easy to activate that your volume really increase so that's the point and the other point is that it's quite easy to measure on what you operate because you have the electricity bill we miss some transparency and some indicators from the hyperscaler and so it's today effectively difficult to really compare strictly the things so we need to improve transparency but this is the purpose of open footprint and so on so I think the market is organizing itself to go in that direction so it's not a yes, no, it's a, you know so we will probably start to see the differences based on scale so possibly the smaller enterprises might sort of benefit from just moving over to that service rather than trying to sort of invest or take on the expense of being more sustainable it gets to how critically important it is and your levers of control if it really matters to your business then you being on you select an on-prem that's appropriate you select an on-prem power source that is appropriate you design your on-prem infrastructure to be as energy efficient as possible you design your environment so that you have no wasted systems but that's all work you're going to choose to do if that work isn't worth it for you if there's not enough return either in cost savings or in market opportunity and I'm going to be really clear don't always look at this as a cost because you may be choosing to do it for market positioning there was an excellent presentation I don't know Sammy's last name Sammy Lansmanam yesterday I think it was even in this room he did a fascinating presentation on how you can use your sustainability approach for generating additional value so it's not always a cost you can increase the market share value point of your product if your customers care I guess if this is sustainability values are more pervasive than just the digital aspect of the business if it's ingrained throughout the entire enterprise and the priority is quite high for sustainability that's where you would sort of and recognize where look at scope123 look at where your sources of consumption are if you're flying people all over the earth your data centers probably not at the top of the list thank you I think of that one personally because years ago when carbon sources were brand new my young son he's no longer young at the time they were doing a chart of carbon footprint and at the time I lived in western Canada and I was commuting to Brazil for work so they put up this bar chart on the wall about everybody's family's carbon footprint and then there was this one giant Florida bottom black it went across a couple of panels so you had a problem with your son well no, he separated me from our family okay, thank you I think we'll call it an end there because we need to break the lunch and there are other sessions starting at 2 o'clock so I'd like to thank Dave, Celine, Chris and Andrew if you could show your appreciation and the quickest way to lunch is down those stairs and most of the user guides are actually on one of the tables downstairs if you haven't grabbed them already please go and get them thank you