 The session will discuss the digital practitioners body of knowledge and how it's relevant to innovation practice building out new digital products at nationwide gentlemen welcome. So I'll kick off hopefully everybody can hear me. Bill give me a thumbs up making sure perfect. Alright so I welcome everybody to tomorrow's tech today is we like to call it nationwide we run an internal podcast where we talk about different things going on in the innovation space and the emerging technology space. Because of that we run a little bit different format than maybe what you're used to. It's more of a conversational format we'll have a deck that is presented Michael walk through that and Phil, but during the presentation will kind of just jump in almost interview style as Phil is talking through things to give a little, you know, makes a little more So today we'll be, you know, discussing our scaling digital products by leveraging the PB box. And first like to introduce myself Paul Gilmore my co host Mike Bolton, Mike and I lead the technology innovation team here at nationwide. And, and today we're really focusing on a new kind of digital product. And we're going to have Phil jump in here in a little bit here to discuss kind of his journey on the new digital bringing a new digital product to life at nationwide is a lot different process and procedure than we've done in the past. And I think I think it really kind of keep good conversation going really you. It's a great lead in on the previous conversation was a great lead into this somehow we how we build these. With that, I'm going to jump over to Mike, let Mike kind of kick off a little bit of context setting, and then Phil will go into a little bit of detail about the product we built called nimble. Yeah, thanks. Thanks Paul. I am looking to someone from the open group to help me with the slides here and not seeing a way to navigate through this actually there I found it. So as Paul was mentioning, we are going to be talking a little bit today about our journey with nimble. Nationwide digital product that was launched in December, but to give you a little bit of context setting Paul asked me to just talk about some of the basic concepts that we're going to be leveraging in the conversation today. You may if you've been with us for the morning or afternoon as it may be or evening depending on where you are in the world. You may have seen a little bit about some of these different concepts already, but we know that people are coming in and out and some of the folks are joining just for this conversation. So we want to make sure that we give you all a little bit of information to set the stage. So the first thing we want to talk about that's an important concept for our journey today is IT for IT and this particular picture. This particular picture is a level one reference architecture view basically as you think about your IT tool chain and all of the different systems that you might need to run an IT function. We view this as a blueprint. It's a blueprint for your IT function. It's a blueprint for supporting the digital enterprise and for standing up the digital product. When we go through the conversation today, we'll be leveraging IT for IT. So again, the slide that we're talking about is that level one reference architecture for the IT function and this will be the basis of our conversation today. We're also going to talk a little bit about the digital practitioners body of knowledge and specifically the emergence model. If you're here in our last presentation, Dave talked a little bit about digital practitioners and he talked a little bit about this concept of emergence. How the body of knowledge is structured into these competency areas that start with the founder level emerge into what you need to know to work in a team. Then expand out to what you need to know to manage a team of teams and then how do you really leverage the body of knowledge across an enduring enterprise. And so we're going to take you on that journey today with Nimble and how we leveraged this construct for our digital product that we built within Nationwide. And what you'll see as we go through the discussion is there's a clear mapping between that digital enterprise blueprint, the IT for IT level one reference architecture, and each of those stages of emergence from digital practitioners. This blueprint mapping and the emergence of our IT tool chain is what we're specifically going to be talking about today. But I don't want to give away all the stories so let's keep going on and transition is over to Phil, who's going to talk a little bit about Nimble story. Thanks Mike. Hopefully you guys can hear me okay. Give me a thumbs up. Great, thank you. Well, thanks. I'm excited to be here and talk a little bit about Nimble tell the Nimble story. So, this is the high level organizational context with how we approach innovation at Nationwide and we do so from three different lenses. We talk about the desirability lens, the feasibility lens and the viability lens. And primarily you start in the nationwide way with a design thinking approach focused on desirability. The thought there is that if you don't have a strong unmet need in the marketplace, then sort of the feasibility can we solve it and the viability can be built a business behind this just doesn't matter. So, early in the innovation process we start with the lens of customer desirability. The other thing to note very quickly here many on this call will be familiar with the minimum viable product. You know, we do implement agile and scrum as a big part of that. We've modified that a little bit to make it a minimally awesome product. The thought is that we want to deliver things quickly, but we want to inject a little bit of customer delight. So, our goal is to create products that customers didn't know they needed but once they have them they can't live without them. And that quickly is with minimally awesome products instead of minimally viable products. All right. This is a high level view of the, well actually this is a slightly less high level than the last slide but this is still relatively high level for our corporate innovation process in nationwide. How we think about launching ideas from the ground up and scaling to an actual business that's generating revenue at scale. Our goal is to do this a lot of different times with a lot of different concepts. And I, you know, I don't think it's appropriate for the conversation here for me to go through this and any kind of excruciating detail and many of you will be happy with that. But to relate this back to the digital practitioner body of knowledge and the it for it framework. That's kind of why we bring this here. When we talk about what I just described as desirability viability and feasibility. And I don't know, can people see my cursor here. No, we can't. Okay, it's all right. So, down the left side of this library see team stage phase duration and pod size. I'm going to be talking to the phase row there. So, we start out trying to find unmet needs in the market with explore, we move into conceptual design and then detailed design. The idea there is that we aren't yet writing code for launching. We are creating high fidelity working prototypes. And we're doing so using sort of minimum technology required to answer questions so that we can learn. And that's really where the founder context comes into play for us. So, we have, we are writing code so some of the, some of the basics of the founder context infrastructure configuration management, etc, is required. But beyond that, these are largely again working prototypes that are intended to be, you know, answer a question test hypothesis and then potentially be thrown out. The other thing to say here is that in Nimble's case, we had worked for probably six months, just exploring unmet needs in market with customers, trying to do ethnographic research and understand what people needed and what people didn't have in their life. And that's really, we did that with low fidelity prototypes, click through prototypes using images and sketch, etc, before we wrote one line of code. So, that's, that's really, I guess the takeaway here is that founder context for us was applicable for just working prototypes and code that was largely going to be testing hypotheses and then cost out when we were done. So, once we So, what you're saying there is that you, you were actually potentially throwing this code away. Is that right. Yeah, and in a lot of cases, you know, the process of exploring and understanding needs that aren't well understood. People, unfortunately, didn't make our jobs easier, but people can't just tell you here all the needs I have in my life that I don't that aren't filled and if you could find a way to fill them that would be great. The, what we would do is often put prototypes in front of people and assess how how much they either light up or don't. When you see those prototypes and the assessment of that need is directly related and in many cases to how much the person seems to enjoy that prototype and talk about, oh man, I would love this thing or I'd be willing to even pay for this. Then you know you've found a stronger need. But yeah, again, it's it's testing to learn not testing to actually build something. So to your point, yeah, those assets are often just thrown away. And that seems a little counterintuitive doesn't it, Paul, to how we typically build systems at Nationwide. I mean, throwing away code. Absolutely it does. But what we found here is it really a lot of a lot of the code, some of them are POC's if we have to certain API's and stuff that we may reuse, but a lot of it is throw away, but the value we get is we really help develop a tighter set of requirements. So even though the throw some of the code may be throw away the learnings that we get and the requirements that we pull from it can help accelerate the build in the next phase. Great. Thanks. Absolutely. The other thing the other benefit to these working prototypes that are often thrown away is it just it indicates the speed with which it can run when we aren't being constrained I'll say by some of the necessary components that you bring to bear when you're launching enterprise systems. So I think that's an interesting that's been an interesting takeaway for, you know, for my business partners within for our business partners within the innovation space. And real quick, Phil, also realize we're talking, you know, in some cases, days and some cases, you know, a couple weeks this isn't, you know, big, big project work, big development work. Right. So, as you proceed in our innovation process, you bundle up all of these learnings and then we present them. You can kind of see it to the right of the founder bubble and something called an innovation case to a funding body that basically, if you think of it as a shark tank like presentation, here are the things that we've learned in market when we've traversed through our exploring design phase. Now we would love to have some funding. We would love to go and try to build this thing and see if we can actually create a business to to launch and market. And so with that, we really start having to organize more deliberately in this team context. In the case of Nimble, we chose to bring this to market in partnership with a couple of different teams that are geographically dispersed. So we had some complexity there in terms of managing the actual delivery on a day-to-day basis and remote collaboration. We did use Agile, of course, I know there's an assumption of Agile here. We did execute with Agile and Scrum. Nationwide has been using Agile for many years. And so yeah, this is really where we start to bring in some of the key principles of sort of traditional software development. This code is not intended to be thrown away. A lot of the infrastructure we're standing up is going to be intended to be used in production once we launch. And in our case with Nimble is a very, very, very tight timeline where we were hoping to launch in less than six months or so. A digital product from concepts to live and market. So that's pretty, it felt pretty aggressive from a nationwide perspective, but with the kind of work we were doing, I think it's aggressive in lots of different contexts. And one thing on this in the team concept real quick, Phil, we try to keep these teams lightweight. We have process and we have to follow process, but in certain cases we try to keep those things as lightweight as possible. We don't want to overspend and overbuild on something that once we get into what we call the incubate phase here we may determine that, you know what, maybe this isn't going to cut it, we got to throw it away. And we worry about adding, you know, some more heft in the scale section. Sorry, Phil, go ahead. Yeah, that's absolutely right. Appreciate that Paul. And so as we, as we scale our development team to try to launch this thing on time, then team of teams contacts becomes even more applicable for us. And the one thing I would say is that throughout this process, I was not familiar with the digital practitioner body of knowledge. It's only in retrospect that we look back and sort of sought to overlay founder team and team of teams. But I'll tell you what this has done for us is it gives us an interesting capability mapping that we can use to talk about the work we're doing in a way that puts some of our enterprise partners at ease. There are a lot of folks in nationwide that know how well to deliver digital products, maybe in different ways than what we're trying to accomplish here in innovation. But there's plenty of knowledge and experience and digital product delivery at nationwide and I to organization of, you know, more than 7000 people. So, when somebody comes to the table and says, Well, what are you approaching defect management or how are you doing this or that. You know, again, retrospectively, it would have been nice for us to be able to have this founder team and team of teams capability mappings that it for it provides and be able to sort of walk people through. Yeah, we know that's a thing. That's not a thing right now for us. So something that will definitely take forward in our innovation efforts. Great. So we've been talking a little bit about nimble. I'd love to take just a moment to introduce it to you. Nimble is a digital product. The first of its kind for nationwide that is direct to consumer and was launched in December of this past year. I would love for my friends on this call to download this application, either from Google Play or the Apple iTunes app store. And if you love it, talk about that in the app store. If you don't love it so much, feel free to give us an email. But the idea here is that nimble is built around the strong unmet need of helping our users get out of debt and stay out of debt with some course correction along the way and spend guidance. Really the big unmet need we had here was people understand the conventional knowledge that I should spend within my means right people know that people know that they should have a budget. These things aren't particularly helpful for people that are struggling with that day to day. What they really what we found that they really needed in talking with more than 100 people in field, as well as through several quantitative research rounds was a personalized plan that helps somebody understand where to start. Where do I start now what's the next step I take in my getting out of that journey. I can get this thing out of the way and achieve some life goals that I have that starting a family or buying a house etc. So again nimble gives you a personalized plan and then it helps you with some spend guidance along the way. So that as things change throughout your month throughout your execution, you know, the application and change with you and keep you on track and help you ultimately accomplish that goal of getting out of debt. So just just a quick note since we do have an international audience. Phil I do know that nationwide as a general rule we're fortune 75 so we're a really large company but we do business in the US we currently do not do business outside of the US is nimble a product that is available outside of the US or is it a US only product at this point. Nimble is available for us only at this time. Great. Apologies to all the international folks but perhaps down the road will make this available in your country as well. That's right. Absolutely. Yeah, so spoke about this earlier, but the the overlay here with the circle at right, you can see the actual it for it capability mapping here on the left. Really, when you think about the founder context where you've either got a couple of founders or a high autonomy. R&D team that's really what we were, we're a higher and send me R&D team trying to put concepts in front of people that met the need of, you know, in the case of a financial application. There's a lot of complexity associated with these numbers, and we felt that we needed to put some of us own numbers in front of them to really test the learnings, which requires working software. You can't do that with a sketch low fidelity prototype, but the minimum amount of technology we needed to bring to bear was, you know, what you see here highlighted in these in the founder context capability mapping. Configuration management bottom right, we got that free from the cloud. I didn't have to spend a lot of time there and then just writing these prototypes you can see in the first control build and build packaging components being relevant for us in this context. Yeah, I think one point that's important to mention here, Phil, as we look at a picture like this is that from a perspective of this being the blueprint of our digital enterprise, the way I think about these boxes, which are the components of the IT tool chain, or the circles, which is the data flowing between the different steps. Everything on this chart is still relevant, even in the prototyping stage, but the difference really is whether you are using tools and formalizing these things, or whether maybe you're doing these things in an informal way, maybe you're doing them in your head, or by swiveling your chair around and talking to the other folks on the team. So I always like to use the enterprise architecture component as an example here, even in the smallest digital product, you have an architecture component that you have to think through. You're just thinking through it in your head, you don't have to write it down because your team is small, you're able to articulate neck and conversations. Whereas when it comes to managing your source control, you got to have systems to do that even at the earliest stages is that kind of you see it as well though. Yeah, absolutely. Another great example right above source control is requirement component. I think it's built without requirements, right? So your point that, you know, very small, you know, autonomous team working through requirements in person together, right? Co-located with the development staff and handing them requirements, but we just didn't have a system with the requirements capability operationalized, you know, with, you know, one of the common systems that we use today. So that's a great clarifying point. So how did that start to change as you got your innovation case approved and you moved into the next stage, Phil? Well, the real key there for us was, and I'll go ahead and go to that, we had to get a lot more systematic about managing our requirements and managing our quality and start in doing some test automation. Fulfillment execution component, that becomes critically important for us so that we can actually start testing our digital products on Android and iOS handsets. The way we do that is through Google Play or Apple iTunes from a film and execution perspective. You can't do those things without making them systematized or, you know, engaging with these in a more deliberate way. So, yeah, again, from a retrospective perspective, I think these are the sort of the minimum things that we would have needed to consider going into the actual develop and launch post-innovation case. And it really would have helped us focus our efforts in these different domains had we had this when we were going through it. Great. So, then how about as you moved on to the next stage? Yeah, so, again, as we traverse through our development and got closer to launch in December, things just, you know, continue to increase in complexity. You have to get a lot more deliberate about actually managing the effort, project management and program management fundamentals. For us, since this was a brand new company or brand new experience for nationwide, we didn't have the business operational side in play. We didn't have bank partnerships for the digital product that we were building in Nimble. There are bank partnerships required. We didn't have any of the business deployed. So, there really was a program with multiple work streams to manage. You can't do that with hallway conversations. There's a growth marketing capability. A lot of that, you know, program and project management and portfolio demand component come into play. Yeah. And then obviously, you want to make sure that as you're delivering a beta to the market, you've got the problem and incident components ready to start addressing issues as they present themselves with your users. And so, team of teams, especially in our geographically dispersed situation that we have is a nice way to think about executing and managing on that. Yeah, when we launch a new company like this Nimble, you know, it says by nationwide that's kind of in small print. One of the big, you know, when people are going to get involved in an application like this from a company, they may or may not, especially from a company they don't know, or doesn't carry a big brand. Talk a little bit about trust and some of the cyber security type protocols we put in place. Sure. Yeah. So, Nimble, I didn't mention this piece of it, but for those of you who do try it, you'll be asked early in the setup process to connect your bank accounts. And we know from live in market feedback as well as our qualitative and quantitative tests. We know that people will hesitate to do that because they feel as though that's highly sensitive information. And so to just give that to application ABC, that's something that they're going to hesitate to do. We also know that nationwide is one of the most trusted brands in the US with global recognition. And that brand, that co-brand being there suggests that we can be trusted. I will tell you we can be trusted, trust me. When it comes to the actual security in place, we use bank level encryption. All of our, you know, we're looking at encrypting all of our data at rest, all of our data in motion is all encrypted. So, yeah, you know, we are a very, we are critically focused on security because we know our users demand it. And we talk a lot about that throughout the experience. We also were able to partner with the nationwide, it's ever security team to perform an attack and penetration test prior to launch scale attack and penetration test. I will tell you that one of the things that came out of that was a very excited fintech partner that we were working with who called us one day and said, Hey, so we're seeing a lot of really strange looking activity coming from nationwide. And so what had happened is the attack and penetration test started hammering one of our partners because it was exposed in the app. And it was, it was a useful full output of that A&P test because what seemed like it shouldn't have been a huge amount of traffic was actually impacting their production system. So that was, that was nice to, that was nice to get that feedback and say, Hey guys, maybe, maybe it might be a good idea to update your system so that we can scale a little bit more effectively. Sure. Yeah, the enterprise context will be one that's very familiar and comfortable to nationwide but something that we aren't implementing yet for Nimble. We are bringing some of the contexts in the enterprise context. Yeah. So it's the next slide there. So, you know, this is really where some of the risk management and other enterprise architecture and other, you know, other other these capabilities come into play. Again, nationwide business units that are going concerned business units implement these today. And a lot of people that come and ask, Well, how is Nimble doing this or that they really are relevant here. And when we are finished executing our learning plan for Nimble, which our learning plan is, this is this thing that we built actually solve the needs that we thought it would, can we make money at this thing. And can we actually require, can, excuse me, can we acquire customers viably. So that is the focus of our learning plan today. Once that learning plan is finished, once we're done answering those questions, we'll make a decision on whether or not we want to sort of move out of this Dev and launch early launch stage and into more of an incubate and scale phase. So far, things are going well for him for Nimble. We still have a few things that we haven't learned that we need to learn around the business viability, but you know, this is what I would assume will be coming our way in the next, you know, six to 12 months for Nimble. Great. Now, before we switch over to key learnings, I did want to throw out a couple of questions we got from the audience today for our podcast. So the there's one from Samir talking about POCs. Is there a POC between the stages of exploring design and develop and launch. I think you kind of addressed that you made. How do you handle POCs. Yeah. So, our POCs again are primarily created in order to test with small groups of participants in field research. In the case of Nimble, and I'll be careful that I don't go too long on this one because I could say a lot, but in the case of Nimble. We continued our detailed design user research work until about June or July of 2019 and Dev and our Dev and launch phase have started in April. So the way in our case, the way we use proof of concepts or POCs is we put these concepts in front of consumers. We say, if we had a thing like this, how, how would this help you or would it help you. And we use that we use learnings from showing POCs to users like that to make our product even better. And Mike real quick on some of the other vision has startups that we're doing at nationwide. We do do proof of concepts, especially on companies that we're looking at partnering or integrating with the validate technology. Yeah, one more, one more quick thing on the POCs for Nimble. When people are dealing with finances. A lot of folks, especially folks who have big debt situations have learned again this is something we've learned through research. People have learned to sort of not want to get into the details on the numbers. And when we show numbers to them that are sort of example numbers are made up in a low fidelity prototype to kind of glaze over and any learnings you could have gotten are sort of out the door. And that's where we had a strong need to put people's own numbers in front of them. So that's another point on the POC side where it was particularly important for nimble be able to show people their own numbers. Yeah, absolutely. And one more question I'm going to hit really quickly. Before we transition over the learning slide, there's a question around the first phase of pods and the second phase of teams. And maybe I'll address it really quickly in exploring design. We do call our teams pods there. Those pods stay together across multiple innovation initiatives. Once we hit innovation case, we fund a specific innovation initiative going forward, and then we stand up and call those teams. And so there is a little bit of nomenclature difference and it is intentional as we kind of think about how we navigate the organization. With that, I know we're running quickly out of time so maybe we can hit on a couple of key learnings though. And then we'll hit the rest of questions in Q&A afterwards with Dave. Sure. I think I've spoken to a lot of these, but we've talked about prototypes in the founder context, especially in a company besides the nationwide. It's a nice way to do some low fidelity testing in market with the fidelity required, I guess. Yeah, we definitely felt the second one where we use the nationwide brand, we talked about that, which required us to pull some legal and compliance and other particular brand management topics forward from context three and four earlier in the process. Yeah, and again, we had more folks in nationwide trying to pull us directly to enterprise because that's the world that we execute in most days. And so having, again, this is where I talked about having this blueprint, the IT for IT blueprint to refer back to becomes a valuable tool just to help manage those conversations and when people are actually pulling you in one direction or another. And yeah, that last point sort of is obvious, but I really would have appreciated being able to map our work to these, the IT for IT, as well as the emergence model had we had it when we started. Yeah, we kind of picked it up in the middle and used it both going forward in the launch and accelerate phase, but then we looked at it retrospectively and saw it fit really well with the experience that we had, right? Absolutely. So the one other learning that we didn't mention, but you mentioned here in your presentation today, Phil, that I do think it's worth reiterating and highlighting, right? This is a different way of doing development, right, from what we have historically done. The way I like to think about it is in this new digital world, we're doing R&D, not engineering, right? And we need a different set of processes, a different approach, a different way of thinking that's much more experiential or experimental to developing products and determining and finding out requirements. And so I think this is a very, very different way of building in, building out an IT product. And I think the digital world is, it's increasingly relevant to be able to do things like this. Yep, absolutely. Totally agree. Well, with that, I think we are out of time. So I'll turn it back over to our friends over at the open group. Thanks everyone for joining us on our podcast today. Paul, any last comments as my co-host? No, thanks. Great job as always. And we appreciate everyone taking their time today to kind of listen a little bit about our journey. Back to you, Steve. Thank you, gentlemen. Thanks, Phil, Mike, and Paul for that. We have a lot of questions that have come in. I know you've tackled a couple of them, but it's great to hear the use of some of our standards for real in an organization like nationwide. So really, really great to hear. So a number of questions. Now, you talked about your map versus your MVP, but the first question relates to that, which is, MVP is mandatory but not sufficient. The open group, agile architecture framework, and also Gartner recommend also using MVA, minimum value architecture. How are you addressing this point? For example, a single MVA and multiple MVPs sharing the same architecture? That's a good question. I think the way we, so I guess I'll answer this in a roundabout fashion that may not be satisfactory to the person who answered the question, but when we think about MVP versus MAP, the focus is less on the architecture. That's a solid foundation for multiple MVPs, which I think is what the question is getting to, and it's more around, you know, something that just satisfies a need without any points of delight. It's more of a user focused, do something in addition to serving the need to delight the user and make them want to return to your product. Now, from an architectural perspective, we've certainly built this in a automated way using serverless architecture so that we believe that we've built this with an MVA, I think is the term that you use, that is extensible and we can deliver additional capabilities and products using this architecture. But in the MVP to MAP pivot that our Chief Innovation Officer Scott Sanchez encourages us to use, it's less about the technology architecture underpinning the solution and more about the way we solve the need, if that makes sense. So maybe Paul, you can talk just a little bit about the innovation platform that you're working on, because I think that really kind of fits this concept of MVA and how we're planning on addressing architecture across multiple products. Yeah, so first thing we want to do is I know there was a question or somewhere around our kind of our enterprise architecture from an innovation standpoint, we don't want to stifle innovation by too many rules of our girls. So, at Nationwide, like I said, we're a great company and in our cloud platforms and our other various architectures throughout, we have pretty strict-ish guidelines on where we have to be within these guardrails. We're creating a platform that allows us to go outside those bounds so we can try things we don't want to be slowed down or hindered by those. Now, we do have, we still have to go through our security protocols and we have a sect dev ops team that goes through, make sure we're not reaching any data privacy, attack of penetration, things like that. Outside of that, we leave a lot of freedom. So what we're doing is essentially basically using the cloud-native platform, kind of outside the nation, we're using AWS in this case, but outside of the nationwide AWS until our own, it's kind of really pretty open, like a startup might do. And then layering in common components that we use, like a billing component or something like this, that's not an internal nationwide billing component, so we can move fast. And also, so there's security, there's also a lot of MarTech tools that we look at a little bit differently nationwide as we're trying to introduce something new to the market and learn, see if it's a viable business. The last thing we want to do is over-invest on an application to make sure it can scale to Azulian users if it's something that we're going to test in the market and then end up throwing away. So, in this, you know, we do want to, if we're going to fail, we want to fail fast and fail as cheaply, you know, within a reasonable amount of dollars as well. Well, on that point, Paul, and another question that came in, in your concept of explore, is that some form of analysis which drives design, because many companies that fail fast, the failings often because they don't do the analysis and they try to transform a story right to code with no analysis and little design. So, could you speak to that a bit? Sure, it depends on the complexity of the technology in the solution we're building. So Nembol wasn't a super, you know, there wasn't a lot of technically complex role, deep components there, you know, some of the algorithms and stuff are, but the actual information of the technology wasn't. So things where we do have, it could be a little trickier, whether that's a really detailed machine learning, learning components, AI components, or if we're going to integrate with other start-ups or other companies, is that we have to validate how their application, will their application meet our needs, the integrations, and how does it work? We do do design work in front of that. Are there open APIs? Can we access those APIs? Do they have proper security protocols in place on their site if we're going to share data? So we do get into that on those types. Right, and I know one of you mentioned design thinking as the start. I think it was Mike probably as the start of things, but so. There's probably six to 12 months worth of analysis that happens, leveraging design thinking to your point, Steve. Right. Up front before we ever write a single line of code. So yes, we do a tremendous amount of analysis and understanding up front. So, interesting question came in. What if the, let me read this to get it right, right? What if the nimble solution approach is in conflict with an enterprise architecture thinking before the enterprise phase is started? Yeah, it's an interesting question, go ahead. I actually think it's pretty easy, right? So Paul and Phil have done a great job of engaging architecture in the journey, even prior to that integration with the broad enterprise stage. So I think it's, that's a really key piece of it, right? Even if you are not in that enduring enterprise stage, you have to, we talked about it, in a company like nationwide, you have to talk to the architects. You have to talk to the security folks. You have to give a little free thought to how you're going to have this thing come together. Even if you don't invest in all of the tooling, that might go into it behind that. Right. Yeah, because we have to, we have to put dollars to when you get to point to the enterprise phase or what we're calling scale where now it's a real asset. We need to make sure the decisions we're making, we understand some of the cost implications that if you want to bring in later what it will cost, if those numbers get really high, we may choose different decisions earlier in our phases. But we do look at that, especially on standardized software that we may use the company that we don't want to use on something like this and what would that take if we're going to bring this in house to switch it over? Right. And I think this is a really important nuance for folks to understand. When you think about leveraging DP Bach and the emergence model in the context of an existing enterprise, a big company like a nationwide, the way that you leverage it is thinking about your new products as digital products and then thinking about it as you integrate with the broader enterprise. And so each of those products needs their own tool chain, their own way of thinking about it and going through this progression as it grows. That's very different than if you're starting a company all on its own as a startup, right? If you're starting a company as a startup following that DP Bach progression, you can do that almost pretty pure, right? But in an enterprise, you have to have some other constructs to consider and take advantage of. Right. Steve, if I can add on to that a little bit, one of the things that's being done a lot of consideration in the architecture group is in fact that kind of mapping that you saw for IT for IT applying to architecture. Because as Michael just pointed out, you know, everybody needs some architecture, whether it's the thing you do on your whiteboard with the guy you're sitting next to or something that's more complex that you've inherited from your organization. You do need to have it and particularly people shouldn't confuse the scaling model of, you know, I only need to do what's necessary at my own scale. It's got to help you with your transition to the next, the next level as well. And that's where architecture really kicks in is that that planning for what happens when you succeed. How do you move up in the world? Right. Okay. All right, gentlemen, we are out of time. I just Dave now, as you're speaking. I know you answered this in the, in the Q&A chat, but there was interest around how are we rolling out Togaf training and certification? Can you just say a few short words on that? Well, I think, you know, we've got plenty of material on Togaf training and certification. I think for DP Bach, we do have a training and certification program also, as we do for all of our standards. And so I put the link in the, in the Q&A, I think it's the best thing go to that page. We do have a presenter, excuse me, a training ecosystem. We've got a couple of trainers are actively doing it and those are growing and looking at how to do more online because of course people, you know, can't get face to face and attend training session. So our certification team is looking at that. And I believe we've got some university training going on. This is guy named Mike Fulton who's got a really good course that he talks about a lot on LinkedIn. So we're looking for more of that as well. Okay, great. Yeah, nice plug there. So another presentation for another day. Yeah, exactly.