A warm virtual welcome to all of our all of our speakers and question panelists, and I'm going to hand over to Mick and Paul. Paul seems to have balls, so I'll back out to have a new gentleman. So, thank you, Steve, from a rather rainy north of England in the UK. So I'm just going to take a few minutes to sort of set up first question I'm going to pose, just take it for a couple of minutes is, you know, the challenge of is architecture still necessary? I guess most people on this particular conference will argue quite strongly against that, and I will as well. But basically it is a constant challenge that we see. Do you still need architecture in the age of design thinking and agile? So, the way the kind of position that is, I like to think that essentially enterprise architecture has been through a number of different winters. And I'll explain what I mean by that in a minute and agile in particular is just the latest and perhaps a particularly deep winter. And the architecture itself over the years has had these kind of challenges and has emerged from them. So what does that mean for the for the latest? And why do what do I mean by winter? Well, this is a hand drawn image that I've presented a few times and I want to sort of do it the first time a few people stopped me going away and getting it done professionally because they kind of like the fact it was hand drawn because it kind of illustrated the thinking and the flow. So I've kept it like that. So hopefully it still makes sense. But you can see it is literally just a one or two. But I'm old enough and have been around in IT long enough that if you start on the top left hand side, people created bespoke solutions where I first started work within an aerospace company. And I worked on a spares provisioning system and it was completely different to the inventory system. And again, it was completely separate and different to the finance system. They weren't joined up at that point whatsoever. And of course what that did is created a bunch of siloed systems. And from that, not from my particular organization, but from that, that pattern happening around the world enterprise architecture was born. You know, trying to join it all back up and support that great thing that underpins the whole of the open group interoperability. So, you know, that happened for a short while, but then sort of big ERP packages came along and other packages. And for a while again, people were saying, well, why do you need to worry about architecture when your process models and your data models are given to you wall to wall. Well, we soon found out through that winter that actually all the different packages, whether they were ERP packages, whether they were PLM packages, CRM packages, lots and lots of acronyms. They didn't actually necessarily join up as neatly as we wanted them to. There were a few gaps and overlaps and we still needed to bring these things together so they could interoperate. And so EA came out of that winter, realizing it had a role to play. Not long after that we got into service buses and integrated solutions. And again, you can see another sort of criticism that sort of challenged towards do we need to have architecture when all we've got to do is plug and play. Well, guess what? Again, we went through that winter and we came out and EA was still needed for that interoperability. So why do I kind of keep going through these? Well, these series of winters, I think the latest ones where we've had multiple cloud provision, lots of solutions being built up in agile way, proof of concepts have basically shown that actually we've gone through this winter. But what we're tending to find and what I've seen a lot of is a lot of small projects which are highly successful, really fast, very, very popular in the business, don't necessarily scale. They don't have all the security in them they need and the assurance. And they certainly don't all necessarily talk to one another. And that's just if you look within an organization. These are two days and certainly this is very true. The need to work across ecosystems and interoperate with many others and collaborate actually forces the need to be able to underpin that interoperability. And hence, we moved to something that I would refer to as an agile version of EA. That's EA for both agile businesses, agile software development, as well as making enterprise architecture more agile itself. So, so that's what I meant by an architecture winter. And where I'm just going to kind of summarize out to them is what what that means for us is, you know, large organizations, especially that have got brand big reputations and brands to match or complex. I've got lots of legacy. There's a lot of things that they need to worry about still. And we're seeing that being able to worry about that being able to worry about how you manage your portfolio of lots of proof of concepts so that it interweaves into that environment. It is still a big challenge for those organizations. In addition, people and the the actual make the way we kind of look at the demand for architects still seems to be going up right every measure we have shows more and more people. The figures change that Andrew took you through some of those. But other things like safe and, you know, various technology credentials are growing and growing all the time. So what does that really mean? Well, we need to ensure that our basic architectural principles and understanding is still there, but that they are held within the context of an agile world. So what have we been doing? What we've been doing is actually will be covered in in the backlog in the portfolio areas that we're going through. And I think Michael is going to pick up on that. So like, like Paul was explaining architecture that has been over a series of stages because winter, which is a very interesting concept. And we're going to explain how we are facing this into the open group architecture portfolio, which is, even though the standard is the main product, we have other products as well. But also, but it will sit to complement this and to learn us understand better how he should fit those new challenges in talking about challenges. There's different ways in which you can face a crisis. Some people whenever something dangerous will take some shelter to the protector, but some mothers, even though being cautious, they will see also things as an opportunity to grow and become rich. And I guess that's something that they're all always should apply in the different disciplines being, of course, architecture one of those disciplines. So what we're doing is the open group architecture portfolio is having this balance of transform, evolve and optimize business. So we are always focusing EA to drive in value to organizations, having this shifting mind to have a more outside in view, being more flexible to new changes, being more agile and digital to optimize the resources that we have at the enterprise and to have this constant evolution. It was some question in the previous session about how we are considered all these into the standard. So what we're doing right now as we're going to explain now and also Chris is going to explain the section corresponding to agile. We have a set of different working projects into the architecture for which is a portfolio of activities, each one of them is taking a different area of knowledge. Some trends that need to be addressing the standard we call that the talk of bucklow and this talk of bucklow include things like digital agile, being able to adopt the new trends how architecture can support the decision making of new technologies like advanced adoption, microservice architecture, cloud, all these activities all together into this architecture portfolio, the view that we have into this. And we also have been searching over the concept of having a sustainable EA. Sustainable is something that can make good use of the resources and can allow the resources to be reused again in a world that optimize them, keeping the organization growing. So applying this to EA, EA has always been about maximizing synergies, having this holistic view of the organization but now we are combining that into having a lean agile approach, delivering value faster, keeping at the same time the high level of distribution, the governance and the risk assessment that we need to have in architecture, having more an outside in thinking, being more customer and product focus, even though we still can handle the concept of a project and architecture project. At the end of the day, what we need to do is to deliver value in the form of products and services. So we are doing also that assessment on how to provide guidance on that particular aspect, and also to be able to provide a rapid response and be flexible to changes. And in that, there's also a shift in what the role of the architect should be. Actually, you can go over the open group blogs and you will see some interesting blogs in there about the role of the new architect. It's a very interesting blog, so I invite you to take a look on that. It's basically to become a consultant and internal consultation to precisely allow this sustainable EA concept. And actually, we'll present after this some concepts about stakeholder considerations for the EA profession. And what about the portfolio itself, like I said, besides the TOGAP standard, which is the factor standard for enterprise architecture. We also have other ones. We handle also the Archimee standard, which is a modeling notation. Some of you deliver a lot of questions about Archimee in the last session. Archimee is aimed to be used alone with the TOGAP standard to provide the architect or description support for that. There are a lot of very good tools available in the market. You can look at the list of certified tools in our site. And also like Andrew explained, there are also certification available for that. In terms of the work into the forum, we are working in the harmonization project between the TOGAP standard and the Archimee modeling notation. And it's going to be a very interesting guide that is aimed to provide guidance on how the two standard can be used together. There are also other guidance that is work in progress. One of them is how the TOGAP standard can be used to support the digital enterprise. Some of you that were in the Digital Management Day on the one day may have a representation about this. We are delivering guidance on how the TOGAP standard can support the different contexts that we have in the DP book and how architecture can leverage the digital profession. And we also have the Azure Architecture Framework. Also, some people have been asking questions about that. It's another group standard that is right now work in progress. And it's going to also be guidance about how the TOGAP standard and the Azure Architecture Framework are aimed to be used together. The Azure Architecture Framework has a more specific view. It's going into Azure architecture and it's providing a lot of very interesting guidance in that aspect. How do you know TOGAP has a wider scope in that? It's not only addressing Azure, Azure LEA has a new architecture style, but it has also been in all of those winters that Paul explained. So it's covering much more than that. So it can be used in the more, using this work, traditional ways, for example, a big organization that needs more governance and risk assessment. And also another organization that is more and more into the Azure digital or another one that is using both approaches. So that standard can be used to support all that. And also another work in progress. We also need to have a more coherence view of the different set of public group standards. So there are a lot of work in progress in the architecture portfolio about harmonization, like I just mentioned with the DP book. We also have a harmonization with Archimage. We have another harmonization work with the IT for IT standard. And we're working with the SOA working group around microservice architecture and cloud. And we also have another very interesting project with the Security Forum about serotrust architecture, the building of reference models for that. And also we have a delivering a set of very interesting guys in different aspects, like this architecture, some of you are familiar with those and also information architecture. So like you will see, we're working into the architecture forum to evolve this portfolio to keep the core foundation of the practice, but at the same time to evolve and transform to cover also a new trends and the new technologies that are right now available. Now we're going to talk, we're going to have Mick talking about the stakeholders and their impact on the EA. So Simon, could you please make me present so he can go over presentation. Oh, thank you. Okay, yeah, well, I'm very pleased to be with you all today. I'm going from the UK. I've got a bit of sunshine outside. I hope your weather is pleasant. You're all safe first and foremost. What I'd like to do, just over the next five or 10 minutes is to focus on the architecture demand drivers that are playing and the different types of architecture work that are evaluating from that demand. Obviously, you know, there's a set of probably like generic drivers that have been in play now for the last 12 months or so that I'll come to shortly on the slide. I want to talk to, but before I do that, I do want to get into the major driver for organizations, be it public sector or private sector today. And that is the response to COVID-19, which is certainly generating a lot of activity in the marketplace that is now rippling down into the sphere of architecture. So what I'd like to do is just take you through the top three areas of work that COVID-19 is focusing organizations minds on in terms of areas where architecture can help out. The first area is people and, you know, the impact of COVID-19 on basically virtual working and what that means for the workforce, the public sector and private sector organizations are having to deal with a new way of working. And that's going to have some massive downstream connotations going forward. Architecturally, those organizations that have, you know, written down operating models in terms of their organization and the capabilities that they are using are in far better shape to respond to what they want to configure their organizations to or the new working environment. And there's two real kind of areas that our architects are looking at currently in this people space. The first one is profiling and skills. Have we got the right level of expertise in-house or external to do the work that we need for the future? So there's an opportunity there of retraining, re-skilling, channel-shifting work that is being looked at. And that's closely coupled with, you know, the different ways of working and how that will impact infrastructure organizations and in terms of real estate, for example, and also in terms of technology. That's the first one for COVID-19. So the second one is finance, where, you know, architects are looking at basically value chains within organizations to ensure that cash flow is well understood and any mitigations can be put in place. So we've got people, finance. And thirdly, what I'd like to draw your attention to is the supply chain in which organizations invariably sit. And architects are now being employed to look at principally counter-party risks with regards, you know, supply of goods or services to actually fulfill their own value proposition to the market. So we've got a real focus now from for architects from an EAM solution perspective to address those three category areas that are being like driven out by, you know, the advent of COVID-19 people, finance and their supply chain. Now, we'll get into the more generic drivers that are at play. And if Sonya could kind of just flip to the next slide. Yeah, these are the main groups that are interested from a demand creation perspective with architecture. The first broad group is the executive board level and they are still remain to be, you know, the paymasters for a lot of architecture work within organizations. And they're principally interested in, you know, how to transition organizational states to effect strategy. So what are our options from an organizational perspective in terms of change that can give us a better outcome? And, you know, the response to that working with business and IT is to produce a cohesive operating model that's designed by principle that come from the board to effect those changes. The second area is we're seeing a lot of is in a risk and certainly the cyber space where cyber threats are increasingly being taken into account because they're actually impacting the underpinning insurance models for organizations. People have come down to the fact that, you know, a lot of damage can be done by cyber threats. Insurance companies are really trying to come up to speed with, you know, the varying risk threats that are at play and trying to update their products as quickly as possible to cater for that. So what that means for organizations is that they have got to have a fairly robust view with regards, you know, the information that's at play and the threat level associated with basically compromise of that asset. So architects are basically being employed to create information centric architectures to cascade the associated risk profiles from the third area is in the area really of technology innovation. And we're seeing a lot of activity where companies have a steady state IT model and they're using basically architecture patterns to evaluate new products and technologies that are coming over the horizon for them to create business advantage. So that stakeholder group there, CTO, maybe CIO type organization is being increasingly forced to look at innovation that may also come out of the business organization in the form of a chief digital officer type set up. Regardless, the bottom line is the use of technology reference models married up to your clear IT strategy is what a lot of organizations are doing to actually create architectural advantage. The fourth stakeholder group where I'm currently heavily involved in a very large government department, which is undergoing a transformation is to use basically architecture reference models to produce baseline costings. So that procurement based conversations can be had with the market in order to do that, you know, the current common currency of the architect, which is, you know, actors, service descriptions and service, et cetera, are all bought into play to actually create a model that eventuates in a baseline cost model that can be used in a commercial negotiation. And certainly, you know, we're seeing a lot of activity in the cloud space where, you know, there's basically hybrid models of cloud in play with their organizations and the applications have been provisioned in such type of environments. You know, the driver to get a handle on, you know, the best bang for book, does it work with regard service provision is really paramount. And we're seeing combinations of toga and language like argument being used for that. So I hope that gives you a feel for, you know, what's going on out there in industry in the broader sense with regard to demand drivers and responses. I'd now like to just hand back to Sonia, whoever the driver is of this system to continue the presentation. Thanks for your time. Okay. Thank you for that. All next presentation now is for Chris Frost. He's going to talk about agile and how we are talking and working to form around agile and toga and EA. So Chris, stop to you. Okay. Thank you very much, Sonia. Just move us straight on to opening slide here. So hello everybody. My name is Chris Frost and I'm from Fujitsu. I'm going to be talking about one of the pieces of work that was mentioned a little earlier on that's going on inside the architecture forum and that's to produce some guidance about how toga works in an agile delivery environment. So I'd like to start by thinking really why one of the reasons why we're doing this. And one of the reasons there's some myths that are commonly heard in the marketplace myths like toga standard is waterfall toga is big design up front. If you accept those things that would basically mean toga standard isn't agile, but I would say very strongly I believe that is that is not the case. To go through these few slides here, explain more about why that is absolutely not the case. But why should these myths emerge? Why should it be that toga is perceived perhaps as a waterfall method? Perhaps it's just simply because the crop circle diagram that we're all very familiar with shows the phases separately with the little interconnecting areas between them. And perhaps it's because in the standard descriptions of it in all the reference cards and other materials that we get shows the phases laid out in sort of lists and tables and perhaps all of that together gives that impression that it's a very serial thing. Phase A then phase B and phase C and so on. And also maybe it's because historically it's true that enterprise architecture projects used to be delivered in that way. I reflect myself on some of the things that I was involved in back in the 1990s, even early 2000s. Then it's true that indeed was a common approach to this sort of project. But we mustn't forget, and actually Paul touched on this point earlier on, architecture is vital, remains vital for any large scale project. The need for that architecture doesn't somehow disappear just because the project is being delivered in two weeks sprints. If you want some supporting evidence of that, just look at some of the industry leading frameworks for doing agile at scale. And some of these frameworks, some of these frameworks for agile at scale explicitly recognize need for architecture and for architects. Another thing, a great little illustration of why that is, is the Leaning Tower of Pisa here on the slides. Architecture is necessary to give guidance when you've got large groups of people all working together that need to produce some sort of single coherent integrated output. And also it's necessary to identify those things that really need to be thought through and designed out a little bit up front. And a great example is buildings where it's necessary to put down those foundations first and make sure those foundations are fit for the building that's going to be put on top of it. And that's sadly what our friends in Pisa got slightly wrong. The foundations were not deep enough or not strong enough and the tower leaned. That's interesting to reflect of course about this particular example that had the tower being built straight and true as it was originally intended. And it probably wouldn't have been anything like the famous and anybody outside of northern Italy probably wouldn't have known anything about the Tower of Pisa. Probably wouldn't see millions of tourists flocking to see the straight and true Tower of Pisa. But I would say those guys got lucky. They got lucky that the tower didn't fall. And if anybody thinks it's a good idea to go into large scale projects without an architecture, then the paraphrase Clint Eastward, you've got to ask yourself, do you feel lucky? And I don't think trusting the luck is a very good and professional way to go about large scale projects. Now if we look at what's already available to Togaf practitioners, if you look in the Togaf library, you'll already find quite a number of things that give some guidance about Togaf and Agile. As far back as 2012, there was a white paper, World Class CA, the Agile Enterprise, happens to be document code W123. If you want to look it up in the Togaf in the open group library. And then more recently in 2018, there's a Togaf series guide about practitioners approach to the Togaf ADM. And you can see the details are on the slide. In section 12 of that, it talks a little bit about Togaf and Agile. And more recently, just last year, 2019, there's another white paper about using Agile practices in the Enterprise architecture. And then of course in the main Togaf core standard document, version 9.2, chapter 18 talks about applying iterations to the ADM, which isn't enough to be Agile by itself, but it's quite a major part of an Agile delivery style. So there is already some guidance available out there, but we decided more was needed in the open group. And in early 2012, this working group was started that I'm currently leading. A very simple statement, a purpose to produce a Togaf series guide on how Togaf standard can be adapted to Agile working. And like most open group working groups, it's filled with volunteer members, people like myself from member companies volunteering some of their time and effort to contribute this work. Currently 37 of us last time I did a count up and we are currently working on building some additional guidance for Togaf and Agile. And I'd like to give a few small examples from the draft guide that we're building at the moment. And a really important thing that it starts off with is this simple statement about the Togaf framework. Togaf framework does not mandate that the steps must be performed in the sequence shown, referring to the crop circle diagram. It does not mandate a waterfall method and it does not specify the duration of any phase or the cycle of architecture development. The Togaf framework does recommend that the ADM be adapted to meet the needs of the enterprise and Agility is just one such need. And if I take a very quick look at some of the topics that are covered within the guide, guide so far because it is work in progress, we're building this up. We're covering a number of things so far like how Togaf can be delivered in that Agile iterative style, the way that the architecture work can be carved up into various slices. For example, you might take a first slice at a very enterprise strategic level sort of looking at the graphic in the top left on the slide. Break that down into some segments and then into capabilities. So making multiple passes around the ADM cycle. And we get some guidance about how Togaf can fit in within these overarching Agile delivery frameworks. And most of those will describe ways of working, of having teams of teams looking at different aspects working in parallel on the overall endeavor. And so there's some guidance about how phases can be overlapped. So rather than treating that crop circle as something that says do phase A, finish phase A, then start phase B, do phase B, finish phase B and so on. So that's more a question of realizing that yes, that's the order in which you need to start things and also the order in which they need to finish but within that there's considerable scope for overlap. And there's also some guidance about how product delivery practices can be applied to the Togaf standard. That sort of very like whole life through life view that product delivery practices, teachers, they can be equally well applied to Togaf.  That fits very well with product delivery practices but nevertheless there's some useful disciplines in for example at the front end of that in the discovery phases. I'm thinking about things like design thinking that can be usefully applied in some of the early Togaf phases. So there's a variety of things that we're currently developing guidance on to help applying Togaf in agile delivery organizations. The work is continuing. We have group meetings every two weeks. Next one happens to be Thursday next week and we're the 7th. And we're using GitLab and ASCII Dark as the way to host and develop the document content. It gives a good environment for the sort of fine grained rapid collaborative working that you need to do with this sort of rapid and agile delivery style. Anybody who's ever tried to develop a large document in a product like Microsoft Word with a large team of people is very difficult. You have to slice out different sections from people whereas through GitLab and ASCII Dark it enables everybody to see the entire state of the document and to work on discrete little sections and even see what other edits people are making. So great tool for the job. So we're using agile tools to produce agile guidance and it is work in progress to say that again. So if you want to contribute I would welcome it if you have particularly if you have current experience of using Togaf in agile delivery particularly large scale agile delivery environments and I would welcome your thoughts and your contributions. See my email on the screen there. The only thing I would say is you do need to be a member signed up member of the architecture forum in order to get into this work and therefore get the necessary credentials to get into the GitLab repository and the Slack channels and all the other project machinery that's around that. If you're willing and able and got something to contribute I would welcome having you on board. And finally to close just to come back to a question I opened with why are we doing this another way to look at it. It's undeniable that agile is king in the marketplace at the moment. It's certainly from the sorts of things that I see in Fujitsu as we get customer requests. Most of them will talk about following an agile delivery style. And it's clear absolutely clear that agile at scale needs architecture to guide it to a successful delivery. And it's also evidence is clear that Togaf is the number one architecture framework. So all of those things put together in my view make a winning combination. So the real value I see coming from this guide that we're working on is that it will help us as Togaf skilled architects to apply those skills and experience and all of the knowledge that we've gained in projects over the world to guide these agile delivery efforts with appropriate architecture towards a successful delivery. And at the end of the day that is what we should be doing as professional architects. Okay that's a very quick run through the current Togaf and agile work. That's me done and I will hand back for the panel session. Thank you Chris. Thank you Sonya and Paul and Andrew before so we have hopefully all of you available to pitch in for some of these questions but appreciate your insights before we get that through those presentations so. Most of the questions are around the agile topic architecture and agile the general theme that are these, you know, are these concepts, fundamentally incompatible and what I would summarize from from what I've heard you say is. No they're not incompatible at all but can you speak to suggestions for those who are in organizations being told all enterprise architecture is old hat but don't need that anymore. It's all about agile. How do they help make the, the, how do they help explain the value of the in that scenario. Oliver goes first if that's all right. Please do for. It's been seen this question now for a few years. And I'm going to condition it slightly in that actually most of the times that we do enterprise architecture. We are talking of a reasonably sized enterprise. So, you know, a fair scope. And therefore when you're talking about agile delivery. So, how does enterprise architecture sit alongside agile solution delivery. You are still talking in the context of large endeavors. And if we take something and you know other frameworks available but if you take something like safe or disciplined agile or any of those sort of areas. You'll still see in there that enterprise architecture is identified as critical to the whole effort. It's just at the level. So if you look at safe and I'll pick safe as an example because it's quite widely used amongst a lot of people I work with. It identifies the need for enterprise architecture in sort of setting that. Identifying what the strategy is and are helping the epic and the epic enablers for the portfolios so that people know what it is that they fit within. Once you drop down into a smaller area, then it becomes leaner by definition. So that's that's in there and they're compatible because what it does it says it needs to do it. What you'll find in any of those methods or approaches is there's no information about how to so you can use toga to actually do the how and it fits the context of an agile solution delivery. The one other thing I'd add to it and this is quite key is you go right down and back to to agile sort of roots and the whole kind of lean and scrum sort of approaches. It's about you don't do something if it doesn't add value. I think that's the kind of one of the key mantras in agile, which raises the question how do you know you are adding value to your enterprise. There needs to be a context. So somebody somewhere has to explain and share that that context and ensure that people understand it correctly and that has always been something that we've been able to do as an architect. So it's all in there as part of an approach and still very compatible. I think it's about seeing the anti patterns and the myth that Chris referred to more than it is about actually going back and saying that that what was there isn't applicable. Absolutely. Yeah, I mean something that that that as you say we've been addressing this question for a number of years now and and I think, you know, that if we look at the crop circle Chris said, maybe it's because it looks like it's to be done in it, you know, in a waterfall world, but it's actually. It's actually, I mean, I'm talking to the experts here, but it was always intended to be an iterative approach. And there's nothing about that. The, about the architecture development method that means that you can't do that in an agile way. It's, it's one of those myths. Anyone else got anything to add about yeah, yeah, I think it's a scale thing and I think it's your choice and how you actually use togaff as well. So, I think, you know, togaff to me is an architecture framework you can be used for enterprise level endeavors as well as solution endeavors and depending on the type of the problem. The hand that you try to address with, with agile you invariably will get into, you know, architecture conversations, at least from a software engineering perspective, the value, the thinking that is in togaff. Those endeavors are scaled up. There is value in talking about enterprise architecture and how those patterns can be potentially be brought to bear to kind of accelerate agile work. So, I don't think it's an either or situation. I think just architecture needs to think about what's most deliberative, think about what's most appropriate for the challenge that's at hand. I would also like to add two very important things that are around this, which is interoperability and governance. Interoperability, because like Chris also was explaining with the example of the tower, I mean, you may have different several agile things delivering at the same time, but if they are not aligned to the single objective, then you are not really adding value. On the other hand, governance is very important because it will allow you to not only measure value, but to be sure that you're still keeping the compliance. The difference is the way that the governance can be applied on agile effort. It's not that doing enterprise architecture on governance in the vacuum, but also that the architect should be embedded into the agile teams like a consultant. That's why the shift of the role of the architect. So, for example, I can see an architect providing guidance to a product owner, trying to identify the product backlog and define different priorities, which is a very good way in which he can support an agile effort. Interoperability is another one. I mean, you may have different teams working, but it doesn't matter how well you have defined your user stories. It's always going to be some kind of interdependency between them. And that's why we can deliver a lot of value. And also, there are different dimensions in here. Actually, you see over one of the white papers that Chris referred to that paper is addressing a few of those topics. We can talk about, for example, EA supporting the agile enterprise, which is one aspect of that. In that regard, EA can support decision-taking, for example, like making clear your vision and your strategy and have you understand the context and the landscape that you have, providing governance and risk assessment and be sure you're reaching your goals. But also, EA can be used and delivered in an agile way, which is a different dimension that it's, by the way, one of the topics that we are covering in the guide that Chris explained, how we can partition the architect and provide different sprints using the ADM in an agile way. There is also another guide that is right now in review that is covering that specific point. So there are different angles in which you can see this. But overall, I guess, like we cannot have a very effective agile practice unless it is supported by enterprise architecture. Right. Thanks, Sonja. And on that point of the role of the architect, questions come in. Togeth makes the architect a central and important role, whereas agile scrum doesn't have a role for the architect specified. It's replaced by an engineer, a much more technical platform specialist. How do we bridge that gap? So I think you've talked about doing sprints in the ADM following those scrum type processes. Other ways to bridge that gap? Yeah, absolutely. Like I said, I see the architect, we see the architect as one of the key elements in those agile teams. So they can be from the very beginning, defining the ethics, defining the strategic objectives, finding and defining your product with the product owner, with the business analyst, defining priorities for your product backlog. And then whenever it comes into more detail with the architectural descriptions of those solutions, you can identify interdependencies. You can be sure that there's no technical depth in what you are delivering using architecture. You can handle your technology, diverse your technology landscape to address that, and then you are supporting also the engineers and the technical people that is in the different teams. If you're using scale, the safe framework or you're using scrum, it doesn't matter at the end of the day, you need to have a technical team that is building the solution. So the architect needs to be there to provide guidance, and also to be sure that there are, when you make your retrospective, you'll review that the architect is there to be sure that standards are being followed, that interoperability has been addressed, and that you are delivering value at the end. Yeah, I've got a slightly different slant on that in that, you know, the architect will invariably wear multiple hats for the different types of jobs that are at hand. So sometimes they are going to be an engineer. Sometimes they're going to be a business process reengineer. Sometimes they're going to be a data scientist. Sometimes they're going to be an application expert. Sometimes they're going to be an infrastructure cloud person. So, yeah, I think there may be a little bit of confusion with regards to what architects generally do. They do very often perform these very, very specific delivery roles, and the better architects are the ones that can easily swap their hats over as appropriate, the different types of conversations that are at play. Right. Okay. Before we leave the topic of agile, a number of questions come in saying any idea when this guide might be published. A lot of people keen to see it. And Chris is keen to finish it, I'm sure. Yeah, that's certainly very true, Steve. I mean, working, we're working through some draft content at the moment and within the working group. We certainly figure we've got another month or two of work to go to build the content to a level that we're comfortable with. And after that it will have to go through a number of review stages. There's plenty of people on the panel who know the review phase is much better than I do, but there's certainly a review process that it will need to go through. It's difficult to give an exact time scale. And Sonja, perhaps it would be better if I deferred to you because I think as part of what we've discussed around the general evolution of TOGAP, this is one of those components that's going into the forward evolution of TOGAP. And I don't know if there's anything else you can add at all about time scales on this. Okay, thank you, Chris. Just like Chris is saying we need to follow a process. Remember that one of the things that make our standards and publications stronger is the fact that we work based on different points of view and inconsensus. So whenever you see a publication of the open group, even if it is a white paper, a guy, a morphine standard, you can be sure that this is also following a best practice for different industries and regions. So that's why it takes a certain amount of time to count quality work into the market. So like Chris was saying, this guy is in the graph process right now, so we need to still follow the review process into the forum and into the open group, and then proceed with the publication. On the side of the evolution of the standard, the way that we are doing is it's also to give the TOGAP standard a more agile flavor. We made a survey a few years ago about what the market was asking for for the standard. And also whenever we have done these TOGAP user groups in a face-to-face event and now in a virtual event, we'll always gather in some feedback from the market because for us it's very important. And one of the things that the market is telling us is the standard should be more usable, easier to be used and consumed. That's why one of the strategies is to couple the standard in different volumes. Those volumes, some of them will be providing the foundation guidance for delivering EA and some others like this in this case, agile and also like digital and new technology trends are going to be guys. There will be also from a part of the standard supporting the standard. We are still working around that specific structure and so all of this is work in progress. Like Chris was saying, we cannot get explained or say, there is specific days because it will depend on the review process and the definition of the standard itself, but you can be sure that we are constantly working in the architecture forum through the architecture portfolio like I explained sooner to deliver all these values as long as possible because we are aware that the market is really needed to have that guidance. So keep in touch with the open follow us in the different channels, even if you're a member and non-member and you will be on track on that progress. Yes, and that was understandably we've had a couple of questions about when might we see an expression of tariff and, you know, it's work in progress and when we when we have it we can we can deliver it. So, thank you. So switch from agile.  So what gaps do you see EA filling? ERP packages come with their own. So as an architect, I work with the black box, white box approach.  Okay. And so it depends if, if you have and certainly when I used to work at the post office, if we had an external supplier providing and delivering an ERP package and within that, how it how the architecture was developed at all the levels.  That could be black box. What I was worried about was the stuff that crossed the boundary and came out because at the end of the day, an ERP, unless that's the only thing you've got in your organization of interest, it won't sit on its own. So, you know, I've never seen an ERP be truly wall to wall and have no integration or need to integrate with anything else. So, where EA definitely comes in on that point is, is how you get information in and out and how you work across that. I do a lot of work in nowadays in industrial plants and even those that have got large ERP traditional ERP solutions embedded for a long time. More and more, they are working with product lifecycle management systems. They're working with operational manufacturing execution systems. And the interoperability needs just keeps reemerging the ability to be able to control machines and robots and process lines on a shop floor needs data and exchange of data. And processes have to join up across the piece. So, so it's about focusing on the things that are important. To me, I always used to say, as from an enterprise architecture point of view, focus on the things that if you don't focus on them, we'll get forgotten. If you're already looking at the thing inside the ERP and you're paying them to do it, let them get on and worry about when it crosses the boundary. All right. Thank you, Paul. We'll move on to a different, a different topic. And it's been the topic of our conference so far this week digital. Are there plans to photograph to address digital and therefore be a useful tool for an organization to go to help it go through a digital transformation. And I'll take that Steve. And yeah, there was one suggest we are also working like we are working in this guide about the use of the total standard into the audio space. We are also working in another into another working activity into the forum about how the standard can be used to support the digital organization in alignment with the people. So for that, there's another working group like the one that Chris is leading into the forum. There are a lot of for active forum members engaged in that. And also we are working in combination with the digital practitioner working group, which are the ones that maintain the people because we need to provide alignment on that that guide is also work in progress. The roadmap, it's like the one that we are doing about agile is still in the drug process and the way that we are facing this is first how we can use the principles along with the principles to leverage each other. Alignment and liberation terminology. We have certain terms that are not in in the talk of standard that are related with digital. So we are also addressing that and the main component of that guide is going to be how EA and the top standard can leverage and be used in the four different contexts that we have in the DP book that for those of you that have been following the event since Monday. We have all the way from the individual, the team, the team of teams and the enduring enterprise, all those different levels have different needs. And therefore he should be supplying that and providing some some guidance and some input on all those different areas. Actually, if you go over the DP book, you will see certain related disciplines for the different contexts being, of course, enterprise architectural one of them. And then the rest of the guide is going to explain in more detail how the the architecture process can support the digital enterprise, how the which components of the architecture content will also support that. And the shift that we need to do into the capability itself for it to also become digital, because now there are certain shifts in the role of the architects in the tool that the architect is using. All of this is going into other architecture, for example, microservice architecture, the mind driven design and all that. So that's another piece of work. Very important also to mention that the work that we were doing around agile that please explain is also having alignment with the work around the the other sector framework that is also standard in progress. Some members of that team, the other sector framework are active in the talk of agile activity, and there are also active in the talk of digital activity. So, as you can see, we are trying to address these in a way that would be covering the different open group standards and to be sure that we are delivering a consistent message into the market and providing a consistent guidance as well. Okay, thank you, Sonia. Lots more questions are coming in and I see, Paul, you've answered a couple directly in the Q&A channel. A suggestion to come in, would it be appropriate to split architecture methodology between architecture domains, e.g. infrastructure technology, and those follow a waterfall methodology and for application and data domains to be governed by agile principles. Does that seem like a winning suggestion? Okay, go ahead, please. Yeah, thanks, Sonia. I'll come in with a view on that because it relates to something that actually we've been discussing within the talk of agile working group. Agile, of course, is one delivery style and it's a very common delivery style, very successful in certain environments, but it's not necessarily the right choice for everything that you do. And the example that was given there hints at some situations where perhaps agile might not be the most efficient sort of approach. For example, in some infrastructure architecture and design type tasks, don't say all, but possibly in some. And so the critical point here is that there's a decision to be made about what is the right delivery style to adopt for certain pieces of work. And something that we've been debating inside the agile working group is potentially putting some content into the guide. It's not there yet. It's something we're discussing and we've got some potential draft material about how to look at different possible delivery styles, which of course includes agile and make the decision as to which is appropriate. So I wouldn't necessarily say that you can make it as simple as if it's this sort of problem, then it's this delivery style that you can certainly kind of give some criteria that say if the type of problem you're trying to solve looks a bit like this or these criteria, these qualities, then this might be the appropriate delivery style because agile is not necessarily the answer to everything. And a quick glance through the chat channel on this event shows that there are some people with strong uses to weaknesses for agile and it's clearly not an answer to everything. Just a quick quarry to that one because it's an interesting idea to sort of split the methodology and look at architecture in two different ways and a lot of it is contextual, of course. So there is an argument for doing that in a certain phase. If we look at infrastructure, and I'm going to use the cloud word, right? So if we look at that and say, you know, initially when things went sort of cloud wise, you could actually make a good argument for separating those two out. One of the things certainly now as we move into later sort of uptake, more mature uptakes of sort of cloud and modern compute technologies is decisions that taken very early on around containerization and microservices. So actually the dependencies between what you might look at as your technology layers and your application development layer, certain cells out quite early. So it is a little bit dangerous to separate them out totally. Just a quick, an idea nowadays and whether people use cloud or not. It's a bit to me, like if we look back at the old space race in that, you know, back in the back in the day when when man went to the moon, lots of technologies were developed to get to get man there, right? You don't need to go to space to have benefited from it. Lots of things were created that helped that lots of technologies are available now around things like, you know, containerization and whatever. You don't have to determine the infrastructure you're going to to take advantage of them in the same way you don't need to go to space to benefit from those kinds of things because they give you a completely different way of options around ways of working. So actually you can separate it if you need to to minimize risk, but there's also lose on some of the benefits. Always love your analogies, Paul. Thank you. Okay, we are out of time people. I do want to have respect for people's for people's time. So I'm a big thank you to all our all our panelists Andrew a little earlier in the day and Sonia Paul, Mick and Chris. Thank you all for your contributions. And if you get the chance to answer to answer any answered questions that are in the Q&A channel, then please do. And I will I will conclude just by thanking all of all of the participants today. Hundreds of you have joined us today. It's been it's been great. And please, you'll get a survey about what you think about about this event and the topics that we might you might be interested in in future. So when you see that, please take the time to to give us the feedback we want to deliver the most value we can to you. It's been it's been a great a great few days. And if you have any questions about about our community or any of our open group standards then there's there's plenty of information provided today and links provided and I'll make a plug for the open group live. Web page which can see on the on our website and on it's linked to the conference site for this. There you will find out more about other things that go on in the open group and some context setting and just save a plug for the for the for the library lots of materials there. And of course for taking this opportunity that we now have for you to get certified from the safety and comfort of your own home. So thank you for joining us today. It really it's great to see the the level of interest and we're always interested in feedback on on what you love about to where the areas are you can that you would like to see improved.


There's the the reverse course field effect like when guys go on the road It's actually harder to hit because there's just constantly the changing is that something that's actively on your mind Like when you come up do you guys do hitters talk about that? Is there any is there anything that you do like differently or know about? Yeah, it's definitely it's real like it's hard when you spend the whole week or 10 days at home And you're seeing you know, you're an altitude the ball the ball just doesn't break as much You know you're facing you're seeing curve balls and they're not a sharp or the ball's not running as much So you swing at some pitches where you can still get to and you can still get a knock because the Outfield's so big and then you go on the road say to like San Fran or something and you swing at a breaking ball And it's bouncing in the dirt and you're like whoa like Because in Denver you're still able to get it because it hung up just a little bit So the ball just moves a lot more when you're on the road So the way we've been kind of towards the end of last year I think it was more it's like in DC or New York We started talking like really just trying to talk about it and Charlie Blackman actually came out had a great idea about Now we simulate the picture we're facing that night in the cage around the field pre game or something And we put the machine on and we simulate his fastball or his breaking ball a slider So we're getting pretty much like competitive bats in before we're even in the game So it's helping us kind of adjust quicker And I think when we started doing that a lot of guys really bought into it And their their road numbers definitely went up a lot more because it's I mean it's tough It's something we have to deal with and you know, it's part of it But we're doing whatever we can to figure out ways to to accelerate the prop that process and then try not to You know where it takes three days three games to get right you can did the machines can Simulate like certain pitchers stuff We'll get likes their spin rate and we'll simulate it like all the they know how to do all that I don't know how to do it You like you simulate Kershaw's curveball, and then you guys are just like a fuck that like less Simulated shirts or slider in the cage before we faced them and I went in there I got swung and missed it like almost everyone I'm like, maybe I just shouldn't swing at that pitch. Yeah, that's a good idea There's if you if you do that and you like crank these machines up and you try you're trying to simulate these guys pitches The machine is nastier than the actual pitch like the just something about like the timing like timing and stuff Yeah, you got putting the ball in the machine or like the red yellow green light Like you just can't synchronize your timing yet for it Like I was I think that is a really good drill to do but it will beat you down mentally You have to like say, okay, I'm probably not gonna hit these well, but I just need to see it Yeah, what I do is I usually you know I'll track like in my regular stance and I do a lot of work from I call it like your launch position Like the position you want to get to kind of and I just sit there on a machine I'll usually just kind of sit there be relaxed and just try to be quick from there Okay, it takes away my leg lift everything. It's not really at the time it up I can just work on being quick and I can still see the ball So I usually do a lot of like machine work just from like the launch position instead of you know, try that's good Yeah Once once you get dominated a lot by the machine Then you start thinking like man, man, is this making me better or worse or Start getting your head a little bit. So But we've kind of accepted that like I'd rather get dominated in the cage and go out get dominated for three straight games on the road Yeah, I'm thinking about Guys whose stuff isn't like nasty like if you have a landslun who throws three different fastballs You simulate that in the cage and just like have a day Then go out on the field like wait, how is he actually making this work though? Like Tanaka's another one of those guys where you know, he's just he he's just so good at the placement That's funny. I never you know, that was the thing You know guys with the spindly heaters will we'll simulate that too just to see how much like it's taken off and Because you know Bueller's a guy that's he's tough to hit especially in LA Hey, you're not talking about there's like not a machine that you can actually input spin rate into you're just kind of trying to I think are we have like analytic guys and stuff that have all the I don't think they type it into the machine But I think that like the spin radar like all that kind of stuff that they can set up and I guess that's that's right Yeah, some cameras or something they have it set up before we really even get there But you know it was something charlie really like he was tired of Us just him us we're just gonna be down on the road So we this is something like I think of our whole or their whole team buys in and really starts to do it I think our numbers would be a lot better on the road