 So welcome back everybody and hope you got what you needed during that during the break. Now we're going to deal with questions for our speakers so far today so if I could. If I could ask you all Richard V shall then to rejoin me. Put your videos on if you can or if bandwidth supports and added to that list as I said just before the break. It's a pleasure to welcome my colleague Sonia Gonzalez who's the toga standard product manager for the open group known to many of you previously for her work in the architecture and argument forums inside the open group and. A long career as an enterprise enterprise architect herself in various industries so welcome Sonia. We have a great panel and we have a lot of questions so please. Do your best to answer them but be as succinct as you can I'm going to try and get through as many as possible and the ones we don't get to. Then I will. We will we will do our best to answer them remotely so first off without any further ado. Question how does the toga standard work with safe. Richard you touched on this in your presentation specifically and right question that we get asked a lot. Yeah, so you want me to be succinct about this one. Okay, prepared for a 20 minute conversation here right so it actually can work very well there specifically. If you know safe it works on the concept of. We have we call program increments right and so that after every 10 weeks you basically do is you define your architecture. You create your vision in the program you do your estimates you create your backlog. And then you do your spurts right and every 10 weeks you do another program increment. Well, that fits very well with toga where we're use toga very much in the. We help define us what we're going to be doing during the program increments right the vision. We're trying to do the architecture. Now what the very key thing is that we also use the other phases during the actual sprints. The architecture works with during the implementation side. We work together with the implementers. With the other developers are we are part of the team. And we help so we create what we call our intentional architecture in the beginning. And as through the various sprints we are architecture involves as we start to learn things because in the beginning, we really don't know what the heck we're doing. So, as we start learning information, as we started accumulating it and we work together, we have an emergent architecture starts to evolve. That that's as succinct as it's going to get with that kind of question. Does anyone anyone else want to add to to that. Yes, actually, Steve. Hi, everyone. I would like to add that besides the briefing that Richard just gave. Also, so you've recognized the new having enterprise architect at the higher level of the lean portfolio management level. She will see and they're like enterprise architect is key for the strategic planning, the epics, the strategic teams and having the portfolio vision in which architect is paramount. And also architecture. It's very important to define the different epics and go rails that will at the end be helpful to govern the rest of of the developments whenever you would you reach the, the level of their delivery pipeline and the and the I really strain having this guidance from architecture. It's quite important and save recognize that in the framework. So that's the way that they can be used together as well. Right. Right. And it flashed up on my screen quickly, but I didn't get a chance to use it, but I know Chris Frost has put a comment in the chat around around that too. So do look in there. We will move on. In terms of agile and its relation to the toga standard. Do you feel one always dictates the other or or does it depend on the scenario. And should one dictate the other. So, can I answer that one? Yeah, there is no standard for agile. All right, so toga toga is a framework. Agile is a process because there are, there are very, there are a lot of different frameworks are for agile. It's kind of a broad statement. Right. So, yes, it's definitely works. So, works with toga toga remember is focusing more on strategic. It's the enterprise architecture side that we do there. A lot of times we look at the agile side is from the development side. So it's a layer within the toga it's it's enabling how does the architects enterprise architecture work with developers and solution architects together. So it's a combination of the both. I weren't stressed that because we say agile system. It's just a broad statement. Yes, I will add to that that also, you know, we have, I will say that he has a practice and the standard are meant to be adapted to a specific needs and the culture and at the end agile is much more than just development is a way of working being an agile enterprise. So I think it's, it's bigger than just development, even though it's key and important in that site. So it's not that one mandates the other is the fact that your practice and not only enterprise architecture, every practice that you have in your organization should be adapted to this new agile way of working in general. Right. I think it's an important point on you because it's, you know, often I can trip over the, the difference between agile software development methods and agile enterprises and that, you know, they're really, really quite, quite different. But that's, that's good. We'll move on. Steve, Steve, I would like to say something. Please do then. Yes. In Shell, we see, we basically use scrum. So there is a standard, because the various ceremonies are standardized the process is much standardized the tools are becoming more standardized. So we work in sprints, etc. So it is not that that basically agile is is is not an organized process it is. The question you have to ask yourself is. If agile is about developing functionality in projects. Is it really interfering that much with the creation of architecture? Because let me say 95% of the it that gets developed at Shell can be developed inside the ring fences of the existing architecture. The technology gets basically a refund every two years, because a lot of technology is coming out, especially in cloud. So you need to keep current, otherwise you're dropping behind and people don't know anymore what you're talking about because everybody has moved on. However, when it turns out that you really need a new piece of architecture that didn't that doesn't exist. So you cannot just bring it into the agile team. I went through this because we had a SQL server database that was running on the largest node that was in existence. So, and we still needed to scale by a factor of 10. So we needed a different technology database that scans horizontally basically that you can have over multiple nodes, which doesn't work with SQL server. That's why we had to move to no SQL to MongoDB. So in an agile way with with sprints, we developed in collaboration with a vendor of MongoDB. We flashed out what the specific MongoDB layout had to look like and we were talking about 50 servers and MongoDB living on 50 servers. So that this is a piece of architecture. And so there was agile architecture developments in this project, but that is rare. That is not the normal case. Architecture is about non-functionals and agile teams 95% of the time are interested in creating the functionality that the business needs and they care a little bit less about the architecture that they have to work in. They are coding, they are testing, they are running, they are deploying, they have tools for that. Architecture, it just needs to be there and they won't go into discussion as long as it's performant enough and scalable. Thank you. Okay, we'll move to next question, maybe one for you Vishal. In fact, specifically for you this one, could you provide more clarity on your mention of value streams being mapped to capabilities? So can you give an example of how that happens or how that's done? So there are two series guides already from Togaf from the open group, one on value streams on one on business capability with examples. I would like to reiterate one of my favorite example which is there. So let's assume a hiring process wherein there are certain process involved which are known as value stages. For example, advertising the job specifications, then assessing and inviting the application, then conducting the interviews and finally selecting and by agreements and everything happening. So these are let's say the four stages involved in a hiring process which is known as value streams. Business capability for each of these value streams are then noted down. For example, when it's advertising, the business capability is around how the enterprise is advertising, how effective it is. When it comes to hiring, it's more about the hiring and the interview process, the HR management business capability. When it comes to agreement and everything, there is a finance capability coming into the picture. So that's how the capabilities are mapped to each of these value streams. And then when we have this clear picture across the process with the value stages and the capabilities, we assess which business capability is performing how good it is and where is the lagging areas. And once we have identified those lagging areas and we can always present it in a dashboard of a heat map kind of structure that these are in red, which means these are the areas where a candidate is suffering or is not liking the process. And once we strengthen those areas, probably our value streams are all green and self-sufficient. And it's giving a good experience to the end user, which is the candidate in this case. Thank you. Thank you. Question here, maybe one for you, Sonia, probably in the best position to answer this. Is there a collaboration or relationship between the TOGAP standard and the open architecture standard from the open group? Yes, actually it was especially at the beginning since when the OAA was released and we were in the process into the open group of releasing it into the market, it was participation from the architect to form. It mostly has experts and it has been also discussion in the TOGAP and IEL working group that Richard mentioned also when Chris Frost was previously leading the F4. And therefore we recognize that more needs to be done. We need to work more because the both of them work nicely together. So the next step we should take is to provide more guidance on the how and actually perhaps at the end of the panel, we can take a couple of minutes to go over the results of the polls, which are interesting because they reflect in a way that people need more guidance on the how. So that's the response is that, yes, it was some work in the past and we are looking forward to engage more with that working group. Okay, thank you. Talking of guidance, the next question. Any guidance that you can give on keeping the documentation aspect up to date so it doesn't get in the way of project delivery. Let me couple this, let me couple this with a with a more general question, I guess, not specific to documentation but have you ever had feedback from agile teams that the architecture processes slow things down and if so, how do you deal with that. One specific invitation and one generally on that agile teams may be thinking that architecture processes slow things down any, any volunteers for that one. Yeah, I can handle both of them. So one of the key things is that we've when we do our project is that the architects are components of the team. They're part of the scrum team. They are not the everybody has a voice in the team there so even the lead developer works with the architects and helping to find the architects. Docputation is a challenge, no matter whether it's from the development side or it's from the architecture side tends to put a focus a lot in the beginning but when things start to go into panic mode. People get sloppy they're working late, late nights and everything. And there's a lot of changes doing being done and those are not always capture. The only way that we can do things is we try to automate as much as possible the capturing of the information. Keep it as lean as possible. We use a lot of wikis to capture the information at the same time. Right. We're not. And because we get away from this gated process there. It's, it's not you don't spend all the time making fancy PowerPoints. You're trying to really just capture this information and trying again to capture the data. That's another thing I wanted to focus on, which hopefully we will take a look at an enterprise architecture. There's now been a movement of automated tools to help capture information to even automatically generate models of the initial systems there. So automation. Same thing that happened for DevOps has to happen for enterprise architecture. Okay. Over here. So thanks Richard for bringing out the automation perspective, because there are lots of auxiliary documents also needs to be prepared like weekly status report and monthly status report how the enter how the work is going on for that rather than putting the entire document it's always better to have some of the tools which are available open source tools because it's more like drag and drop and then a snippet of that automated tool always works and it saves lots of time in those auxiliary documentation. In reality. One of the major one things when it's discussed about that. One of the major challenges. At the end of the project needs to do a cleanup of the things because you just, you got to look at reality man you just have when projects start to basically. You start finding all the things you miss. You go to the testing issues performance issues there. You're so overwhelmed. You're actually doing, you know, 8% of the work in the last 20% of the time. You need to have some time to fix up the documentation right there's you just have to live in the real world. The problem though is by the time it comes there they've reallocated you to another project. You don't get that time. So yes, that's an open source point that there is no magical answer. If I can ask you a question. We see the same pattern. However, the documentation of systems that are created in an agile way deal with the architecture of the application, which is basically software. Engineering, which often fails in adequate documentation and people yelling the code is the documentation. That is not so much at Shell, but we are concerned with when we talk about the solution architecture. We are much more concerned with the architecture between systems. What interfaces exist to other systems. How what technologies do the do they use and this is a pretty rigorous at Shell. You don't get to go live. When when basically the inter system architecture is not bolted down because otherwise you jeopardize the whole operation if you have a rogue application. So, I totally recognize what you say at the level of software engineering and software architecture, but I do not recognize it in our practice as far as architects work. I do. I am very happy with the fact that you have embedded architects. That is, that is essential. I just finished a major project with the pipeline, right, where we had the interfaces well defined, but then they changed the controllers at the last minute with new software. So, let me tell you about the resource industry. Yeah. You know, you always get surprises. Okay, we need to hear what you say. We need to be our interesting, interesting perspectives there. So, would your approach. What would your approach look like or would it change if a part of the business architecture needed to be developed along the way to. What's the, you know, what's the, what's the role or what's the approach for where you need to develop business architecture to. Okay, all I can do for my own experience is that the budget structure always involves because we, first we have the, the 1st. We determine what is the target architecture and then we create the backlog. Right. And so we have the business process and value chain that apps and development change. Then we start doing our sprints and we find all the things we were wrong. All the assumptions. So the business process has to be re-evolved again. Right. And then we also have to try to, let's say I did a QDC type of thing there. Well, guess what? We get the feedback from the product managers. We don't necessarily always get it from the field. We put it out to the field. The guys say, you don't really remember that this really changed or this isn't working or I'm not comfortable with this because I've been used to this thing for the last 20 years. Right. So there's always this input that evolves. So yes, the business architecture continues to evolve and drives then the development solution. Okay, we're going to ask 1 more question and then we're going to hear the survey results from, from Sonia. And apologies if I, if I didn't quite get to your question. It regards the decision around the technology stack. Who decides on the technology stack in your experience or who should or who do you think should decide on the technology stack? I mentioned the technology stack. Yeah. And to a large extent, this is the decision of the solution architect. Of course, you need to. You need to choose a technology stack that is supported by the IT organization. Obviously, but basically it is 1 of the pivotal decisions and it is taken at a moment that the team hasn't been convened yet. Now there is a lot of peer review happening at Shell and you need to defend your choice for the development stack because it determines so much. And even in sometimes you can, you can be in a situation that is very hard to get adequately trained Java programmers and you, you are forced to try and develop this in C sharp. And basically dot net. That can even happen, but that is rare. So most of the time it's a decision. Are we in a, are we in a buy or or make scenario. So you get SAP consultants when it's an SAP project, et cetera, et cetera. But yeah, you can you can actually get even into a discussion on architecture. Are we going to have an event. An event centric software architecture that will lead to having different people on board than a more relational database centric development. So I agree, but what do you should realize to get a little bit practicality for large projects to it can be very political. Right. There have been many times that for instance, a CIO has been signed this big deal with Oracle. Right. So he's defined, you have to use these Oracle products same thing with IBM to you have to use the entire IBM suite. You may not be the best fit for the particular solution, but very often or sometimes unfortunately, you either inherited some type of decisions. Yeah, yeah. Yes, constraints that we that we have to deal with along the way. Absolutely. Okay. Thank you all panelists before before you leave us. Sonya, you'd like to share the survey results, I think. Oh, yes, actually, I don't know if it would be possible to put them on the on the screen so everybody can see them. If not, I will, I will read it so because I have it in there. I think it's quite set of interesting responses for the first one is the Togov standard really, really aim to support the digital enterprise. I think we got around 28% of people saying that actually it supports the digital enterprise. And we have 33 saying that it doesn't. But we have 40% of people that didn't deliver an answer, which is it gives us an idea that we need to work more and give it that guidance which is precisely another of the working efforts that are around into the architect to foreign you know there's a lot of discussion about what digital enterprise is and what is a digital transformation. If you ask that question you will receive probably 20 different answers. So therefore that will motivate us more to work more in that space. The other one which is also connected with this which is also around EA Togov and digital, the questions where if EA is key or crucial for digital transformation and also the Togov standard is also important and it could be adapted to support the digital enterprise. You can see around 15, 20% people saying something in the responses and 30, 34 saying that all of the above so they say that EA is important and also Togov standard is important and is the Togov standard can be applied to do that. And similar trend we have around 49% of people that didn't respond to the poll. So again that is like in a way related with the previous response people is not quite certain about what to do with digital transformation. So therefore there's a lot of room for us to deliver value into the market in this space. And finally about the agile question also interesting responses EA key to support agile developments. We received 13% of responses. EA can be delivered an agile way more people 33% to anyone important for enterprise agility which is interesting like supporting the fact that we say before that EA should be used for the agile enterprise and adapted to the digital enterprise. So in relation with the Togov standard adapted to support agile delivery and adapted to support agile developments around 20% each of the responses and 34 people saying that all of the above applies to that. And similar trends around 40% of the people that didn't deliver an answer. And so we hope that after this virtual event people is more clear now after the excellent presentation that we also before from richer visual and then of our agile and EA and Togov. But again, I think this is something that will show color attention and they need to deliver more guidance into the market and this is suspect. So interesting responses. Thank you for taking this early. Yes, thanks everyone for your for your input on that and it does help guide what what we do inside the open group and and where we take things so we'll move on. Thank you again, Richard, Ben, Vishal and Sonya for your for your thoughts and warm virtual round of applause from from the attendees for you. Take care. Thank you. Thank you.