 We'll move straight into into Ben's session, which is about applying the togaf standard to agile development at Shell So it's a pleasure to introduce Ben Heidefeldt in his second year of returning to Shell where he earlier set up enterprise architecture for the exploration and production Areas between 2007 and 2008 So without further ado a warm welcome from the open group pleased to Ben Heidefeldt Welcome Ben over to you. Welcome everybody I'm actually in the master of science and not a doctor I studied theoretical physics in its right in the Netherlands But as so many people immediately after studying I went into IT. So I started in IT in 97 and I had multiple engagements So That the as I was introduced this is about how to use the open group architecture framework in the situation where your development is dominated by agile development because we all know that Togaf has been conceived as a waterfall approach to creating architecture And so let me start with that right off the bat You can develop architecture in a waterfall approach and then insert that Architecture that you developed in a waterfall approach into an agile Project, but that of course is suboptimal. I also happen to know that The open group is working on an agile version of togaf Expect that to come out over next year somewhere Okay, let me start to tell you a little bit about Shell Shell is a large IT shop They're running about 10,000 applications and even more deployments of applications because some applications are only deployed once and others multiple times There are 400 architects few over 400 architects worldwide in the US London Amsterdam the Hague And also in Bangalore and That's a huge practice actually the most architects we have are working out of Bangalore Our development is a combination of waterfall and agile DevOps with the trend being that Agile is is quickly winning out Not only for developments of new applications basically bespoke software development, but also for Let's see. Let's say your Classical SAP configuration implementation. That's also more and more done in an agile way So we are divided according to togaf terms in segments segments have a certain interest from line of business We have oil and gas but many more things and Shell is diversifying strongly into Renewable energy Already some years ago. We chose togaf as our architecture framework And we are already working according to togaf for some years now We have just over this year changed our architecture modeling tool to Archimates Coming out of system architects by IBM so We have a cloud and less policy, so we prefer cloud deployment And also market standard and less so we use commercial off-the-shelf applications like SAP and Salesforce and Create a lot of applications using those platforms however, we also have many niches including high-performance computing because in the oil and gas business you basically cause earth tremors by explosions either in the water or on the land and Those give reflections from the various Layers of earth. It's called seismic and that's basically the way that The oil and gas industry is trying to look what is on the ground Trying to see certain structures that are strong indicators for finding hydrocarbons oil and gas We have strongly value-driven architecture So we don't want the best architecture, but we basically want an architecture that take us over the lifespan of the application So that takes us all the way starting from requirements Gathering to decommissioning of applications, which also happens all the time as you can probably imagine with so many applications running Going into agile now I've been in agile software developments in from the beginning from the 90s and I was part of the start of DSDM a Dynamic system development methods and off-cap Gemini's iterative application development. So I'm basically there from the get-go and Agile software development is a way to solve the problem to basically Make sure that You solve the problem that it's hard to specify for the business what kind of system they need because specification is hard and by doing sessions with These customers you can basically find out exactly what you need to build So agile is not primarily in architecture development methods Because it is a software development method And it uses architecture to basically realize what it needs to do. There's methods like safe Scalable architecture framework and But shell already chose togaf and because togaf is also going into agile We will stay with togaf and this presentation basically is about how to use togaf In an agile way and We basically Find that it is possible to do just enough architecture just in time So this is of course Unreadably slow, but this is basically mapping all of the togaf deliverables That are in an architecture contract Over the run period of your project and this is a waterfall project here at the stage gate number two But let me go to the next slide where it is a little bit more zoomed in At the stage gate two is normally where we deliver the architecture and the developers take over however Also for a waterfall project. We are now mandating that architects stay involved from the beginning to the end But in a waterfall project you see that the architecture Deliverables are much more developed Then we will see in agile. So a red Means that this architecture deliverable The application migration diagram is just being sketched Before you basically start development Others other deliverables are totally made final like the strategy capability matrix or The organization decomposition diagram or for application development The application function matrix or the application user location diagram, etc. It's all here. You can read it for yourself so that means that the architecture deliverables are much farther along by the time you hit Development and you will still have to mature some Deliverables like for instance software engineering, but many deliverables are already ready to go or As you can see here because this in the right here only lists The deliverables that are not yet finalized because the green ones that are green here are finalized in this phase And they are not mentioned anymore here So this is just the deliverables that are not finalized here And they are then finalized during the design stage with a few exceptions of further deployment So this is what we had what we have been doing Using tog after deliverables already for let's say the last three years at Shell And now we need to cater to agile because more and more development is happening in agile mode So Let me take you through the next slide so We see that the business need is basically being framed The technology stack however must still be chosen and that is important. We You basically have to start Delivering your architecture before the team comes on board because the architect needs to select the software development stack and Only after you've chosen the software development stack like are you going to do bespoke Development in Java or are you going to run? an SAP application that requires a lot of knowledge About how to configure SAP that will require totally different people so Let me take you into the agile project mapping What we do here is basically starting out the same way we start all of the deliverables and In the face before the team comes on board we finalize some but as you Can perhaps see the other deliverables I'm much less finalized many are Only sketched Or they are in draft Or they are a bit further on that they are already reviewable That's especially a case for the segment architects that has let's say 10 solution architects working for him Covering a whole segment. So those deliverables are already in a reviewable state but not mature yet and other deliverables as Soon as you go through the initial architecture development phase Can be taken all the way to the point that they are mature that does not mean they are final but they are certainly mature they are beyond The states that they have been reviewed however Most of the deliverables the toga of standard deliverables are still immature They are in sketch draft Sketch or draft So then After choosing the technology stack. So, okay, we have determined. We're going to develop this bespoke as a bespoke application development using Java developers a team of Java experienced agile developers in Java will be onboarded and then basically you start to socialize your architecture and Bringing these toga of Deliverables into a more mature state helps you also to get buy-in from the agile team That is that basically is expecting to work more independently than during a waterfall Project so you basically need to entice their attention. You need to involve them in the architecture decisions and to basically ripen the architecture deliverables with them and As you can see Certain deliverables can be in the first sprints be finalized or to make mature Like the application and data matrix and the data dissemination diagram But the logical diagram will only be finalized for the first modules that are being deployed Because we're doing execute sprints execute of sprints and we are doing deploying in agile Every two weeks or every four weeks. We try to get to a deployment and Demonstrate that to the business and get the feedback from the business. So that is basically the core of this presentation So Do not develop all your deliverables in your architecture already to the hilt that they are basically fixed Take take a More sketchy development of your deliverable into the design when the team is onboarded and The Advantage the advantages are huge you get much more buy-in and actually You become one of the team. You are not one of the developers But you basically touch base with the team on a weekly basis on their There the sprint reviews of course, but also When when they are poker ring Doing the sprint planning and also when you basically do a deep dive on a certain technology issue And basically you want to be with you want to explain something they will explain something back to you And you will change your architecture deliverables for especially the software engineering diagram will strongly change Module by module as they are being delivered. So I I Basically what I wanted to say this is what I what I wanted to say We we want to give enough architecture guidance that the team will not lose Site of the guardrails of architecture, however, we don't want to crush their creativity and Actually, I find that an agile development team Focuses mostly on what they need to build what functionality and they feel greatly helped when the architecture is already There that they don't need to worry about the architecture that there's somebody working with their team to basically explain how functionality is to be built and that make sure that all of the formalities and and and and the permits are being taken care that you also are basically a snow scoop that is Making sure that they can just develop functionality and with that I would like to open the Q&A Thank you, Ben. Thank you. That that that was great. And it's It's great to start off as such a such a clear message that you can use To get in in agile way. It's something we've been saying but It's sometimes takes a while for that message to get through but it's it's nice to see you Actually with some charts that help us Help us demonstrate that so fantastic. Thank you So we have some questions. I know you're you're you're up again and then but Tell me tell me Okay Let me get to these there's sort of grouping of of questions I Guess that which is around the the use of architects in agile teams so if I if I group two together what is your allocation of architects to agile teams and Do you have layered architects with some acting at the solution level and some overseeing the enterprise architecture? Yeah, let me start with the second part Shell has many architects. We have the segment architects that overview all applications support So I think we just I think we just lost Ben While I wait to see if it if Ben comes back we've got a number of a Number of questions coming in which are on this occasion all to do with Yes, the person who asked that question that he was just starting to answer is is Feeling feeling poor timing for Ben dropping off, but I think what we've what what we're seeing in is this this this big topic of or regular topic of of enterprise architecture Different architecture domains agile How do they all relate to each other and there are different approaches to doing that and you heard earlier before the the break in the first session about About one of those which is our OAA or open agile architecture standard which is Which is a great addition to the to effectively to the to the toolkit of the toolbox Whatever you want to call it of the of the architect and of course, we've got the the call it more traditional approaches of architecture very widely used such as the toga framework so what Ben noted at the beginning of his talk was that we are The the architecture forum of the open group, which is the group that that evolves and Maintains the standard They have been working hard on Some agile content for a Future version of the standard so We're going to the goal is to be able to give architects Lots of different choices on the approaches that they take the frameworks that they use The standards they use the tools they use Along the way so that depending on the environment that they're in they they can use those Which make most sense so and Ben talked about Shell switching to using Archimate as its Modeling language, that's another many of you will know this but Archimate is another standard from the open group a modeling language standard, which is great for doing enterprise architecture It works very very nicely a complementary to anyone who's using the toga standard to a lot of their Terminology is very similar and increasingly Increasingly so over the years So there are there are as I as I would say and you can see this on the open group website. There are a lot of a Lot essentially a lot of tools in the toolkit for enterprise architects to use so Do take a look at them it looks unfortunately as though we just lost Ben at the at the crucial moment of answering questions