 And Dave, I'm going to hand over to you to moderate the panel and I'll be back with some closing comments later. Thank you. So I just wanted to thank all our panelists for going coming back to our slide from from the market to NIST and really we're here to actually talk about how the specific standards of the open groups forums are here to actually ease some of these transformations we've heard about. And give you a framework for actually developing your workforces, managing your technology delivery and architecting the necessary components of that transformation. So hopefully by the end of this session, you'll at least have a guide to the standards that will make sure that you're not one of the people who is confused about digital transformation. And so I've talked about this earlier we've got some themes that are clearly emerging and you heard them time and time again in the, in the presentations earlier about the need to change a little bit how you do business and that you reorient both your workforce and how your enterprise approaches its products and move to an agile digital first delivery in order to compete in today's market. And if you use the standards you're about to hear about that will accelerate your journey to digital competence. Again, I've mentioned these before but we do have a set of standards that you're about to hear about I'm going to move quickly past these slides. So you actually hear from the people who are making it happen. And I think our first first person is Mark Bodman Mark has been well introduced by Steve but I do want to recognize that he's been one of the real thought leaders in the it for it group and helps make this, you know, our standards transition happens so we can help make your digital transition happen. So if we can give the ball to Mark and let you flip the slides. All right, just testing my audio. Can you hear me okay. Yeah, here you find. Excellent. Excellent. Okay, I wanted to kind of talk a little bit about what digital products are I think they're everywhere already and I wanted to use my example is a digital oven. A few years ago, we put in a new house and it came with all these new appliances. And one of the appliances that we got was an oven, which was digital. So, and it has these features which you wouldn't have expected I didn't ask for a digital oven. This is just the default oven that came with the house. But it was digital that had code running in it. And it had these features to help with programming the oven and interacting with it digitally. And it's interesting where you can actually scan the barcode for for food of your food, whatever you're going to be cooking frozen food or whatnot. That would in turn, go look up the instructions for programming the oven. And then those instructions would appear on the oven itself and tell you how to prepare and what to do next and everything. It's really cool and and then I about six months ago I got a watch an Apple watch, and it even started hooking into my watch to tell me when the food was done so even if I wasn't around the oven whatsoever, when the timer went off right as the watch alerted me and had me go back and make sure that you know my food wasn't burning. And so this digital experiences everywhere it's profound it's changing how you do almost anything. And just for this feature at all in the oven is just how things are done. So digital products are everywhere and that means that you need to understand it. What I worry about now in my house is I expect to have this oven around for 20 years. I don't want to reach changes like as fast as I change my iPhone or the Apple watch so I expect this thing to last and I'm worried that people that make ovens. I don't know how to manage it. Do they know how to alert me when the back end systems are down so this experience changes. So I just wanted to use this because I think if you look around, these are different digital products actually that are all linked together. And the ecosystem will continue to evolve as these additional features and opportunities for digital become more apparent. And I figured that we were representing of course is the IT for IT standard which you heard a bit from Lars earlier, but the current architecture is changing. So it's really built on this service model backbone we call it to more of a digital product backbone. And you can learn more about what the standard is today by accessing the URL in the bottom to some of the material that was presented by Sasha and Lars and others was a little bit more forward thinking around this digital product shift. And some of the things that you're seeing in the industry are things like this project to product shift which is about being able to invest and manage those products as Lars kind of pointed out with a product management acumen to understand exactly what the product is doing for my customers. Who are my customers? What are those dependencies that I have and what is dependent on my product. So we're evolving this DevOps concept into more of a end to end view of what it means to manage digital products from an IT perspective but also for those things like digital ovens which have IT embedded and IT dependencies which we're seeing everywhere cars ovens you name it. Now that this definition that we've characterizing in the white paper we're coming out with soon is that the additional product is running on code highly dependent on IT. It provides one or more service. This is for we embed the service management acumen. The idea of being able to monitor and manage the service your customers outcomes are embedded in IT for IT but when we get to a product management perspective it's even more profound because these are your customers and you're interacting with them in a digital manner. So it changes the nature of what a customer is in the digital world versus a physical you know if it were just an oven that didn't have any digital components it's a very different experience. And you have to manage the life cycle. We talk about the system life cycle but also the offer and the usage. So what that looks like we'll get to in a minute. This is the old definition of IT service model used in IT for IT 2.1. There's a white paper on this and we're rewriting this paper to transform it to digital product which is on this one. The big difference is on the integration where the machine machine or machine-to-human interaction is the measured integration. It provides the outcome. The systems are the what we manage and we call things systems today but we don't have a definition of system per se in the IT for IT specs. So this basically is generic enough but key to that system definition is the code and the compute which makes digital product digital. It's the difference between old you know non-digital products and what we call digital product. And the similar life cycles you've got to manage the system itself for in perpetuity. As long as that thing is running that system is running we need to be able to measure and manage the consumption of it which is requestable fill. That's the value stream that defines that interaction and manages that subscription over the life of the use of this digital product. And the more elaborate definition of digital product you'll be seeing this come out in the digital product white paper that we'll be publishing soon probably within the next month and a half, two months with the most is a blend between management of products which is the top part here. You're seeing here but also the management of IT. It's understanding how folks are consuming IT and what kind of systems are being run to be able to provide that consumption experience. And then not only that but in a IT setting you have a lot of shared resources. You have people that support your product. You have CICD pipelines that you build to be able to update your product and sometimes those reach over the wire to the house itself. So my oven gets up that periodically is through cars now in your phone. So all of these things have to be built into the product and thought about and IT for IT defines much of what you need to manage digital products based on this definition and how IT has sort of evolved to becoming part and parcel to the product. That you use. So with that I wanted to hand it over to my next speaker Jim Dawes. Hello, thank you Mark. As Steve said, my name is Jim Dawes and I'm the co-chair of the open groups digital practitioners working group. And just here to talk to you today about what the DPWG has done and what it's doing organizations providing a digital customer experience. Jim, we are appearing not to be able to hear you at the moment. There seems to be some problems with your audio. Sorry, there was just some delay in my navigation toggling. Sorry about that. Can you hear me okay? I can hear you fine. Thank you. Great. So I hope everyone has had the chance to redesign for digital. So the industry is changing and looking beyond how to simply apply path architecture and program management strategies to the problem of reorienting organizations to focus on value delivery through technology. So there's a growing recognition that new skills and capabilities are needed. So members of the open group are aligned with this new perspective and we're developing new open standards to meet this need. So on the principle deliverable to date of the DPWG is the DP box standard. There are a few things that make this DP box unique. So why is this different than any other standard? Well, the DP box has its foundation and lean agile and DevOps and is comprehensive in the sense that it covers all phases of the enterprise and we'll talk a bit more about that in the next slide. It's also an open standards of viable non commercial open governance open source standard. All people can now use that open standard free of charge for their internal use or academic use. So that's one of the things that makes a DP box standard unique, but we've also adopted a unique approach of how we organize our content. So in contrast to life cycle approaches, the digital practitioner body of knowledge is pioneers and new scaling structure from startup to enterprise and call it the emergence model. And it's one of the box key differentiators. The emergence model aims to address many needs at once. And the first is that it provides organization size specific lean full life cycle digital product management guidance. So this means that organizations of any size can mature their digital practices without having to abstract practices from competing or like mostly life cycle based box, which due to their organizing principles generally do not provide such scale specific guidance for all practices. So, just at the founder level the founder context here at the bottom for example if I would extend mark story about the digital oven. If Mark and I were founders of a company creating a digital oven or another digital product, we would be concerned with a bare minimum requirements of delivering digital value as founders only two person team after all. But what are the minimal essential minimal essential concerns that we must address to develop and sustain a product in a digital environment. Well, at the founder's level we start out with the digital interface on the face of the oven for user interaction at the startup stage we typically have little or no concern for process or method. Right approaches and practices their opportunities, opportunistic, their tactical, they're driven by technical choices such as programming language delivery pipeline and target execution platform from an architectural perspective, automation requirements are minimal but they're present. The ability to track the state from a digital product or service across the rudimentary build one pipeline is essential from our earliest efforts. So while we were successful and we had to hire a few people and now we're a teams we're up in the team context and at the team level we've added the digital product. We've added the digital product that brings into use of mobile phone scanner to get the cooking instructions to the oven so things are getting more complex. So we have a single mission and a cohesive identity but we still don't need a lot of overhead to get the job done. But even with a few new people comes the need to more clearly established product direction so people are building the right thing the team is typically on the same location and can still communicate and formally, but there's enough going on that needs a more organized approach to getting work done. Still, things are getting larger and more complex. The product has a significant user base and its founders Mark and I are increasingly out meeting with users, customers and investors. As a result, we aren't the room when the product team with the product team as much anymore. In fact, we just named someone to be product owner. From an architectural perspective, further automation is required at the team context as product management is formalized and operational work, such as provisioning and monitoring emerges. And then the team of team context is our team based company grew a recent crisis point in scaling the digital product. One team could no longer cope as a single unit and with the increasing complexity and the operational demands involved. The organization is now a team of teams at a size where space to face communication is increasingly supplemented by other forms of communication and coordination. The team may get results, but in different ways, the organization needs some level of coordination. And not everyone is readily accessible for immediate communication. People are no longer collated co located and there are different schedules involved. Furthermore, the organization now has multiple products as we scaled up. We must now split our products into features and components and the organization moved from our first product to adding more further to adding more and further organizational evolution is required. So tension between various terms is starting to emerge. Specialization organization is increasing along with the tendency of specialists to identify more with their field. And with the needs of customers, there's an increasing desire among stakeholders and executives to control predictability resources are limited and they're always in contention. Advisors and consultants suggest various frameworks for managing the organization as the organization scales. Its leaders need to remember that the highest value is found in moving in a fast moving committed multi skilled teams. The losing site of that value is a common problem for growing organization. From an architectural perspective as the organization scales to multiple products and teams, new components are required for coordinating and managing investment at provisioning multiple services and handling operational issues when product to team cardinality is no longer one to one. Formal ITFM Q based processes of incident change and problem management emerge here as mechanisms for communicating executing and assessing risk across team boundaries. As we move up the enduring enterprise Mark and I are now running one of the larger and more complex operations with an annual budget of hundreds of millions or billions of dollars. There are thousands of employees with a wide variety of responsibility. Digital is central to our market facing products and in our back office operation. In fact, it's sometimes hard to distinguish the boundaries as our company transforms into a digital business. Agile techniques remain important, but things are getting complex and we're testing the boundaries of what is possible. How can we operate at the scale and still be agile. Decisions made long ago come back to haunt us security threats are increasing and at the scale. There is no escaping the auditors organization has scaled up to a relatively large size. However, what may be less obvious is that scaling up in size also means scaling out in terms of timeframe concerns for the past and the future extend further and further in each direction. Organizational history is an increasing factory and the need to manage this knowledge base can't be ignored or organization is fulfilling responsibilities. Set in place by those by some no longer present in his building products and signing service contracts to be fulfilled by those who will come after hence the qualifier enduring is applied to the enduring enterprise context. From an architectural perspective as the organization grows to the largest scale and the longest time horizons. Forward and backwards a digital, excuse me, a digital additional components are required to architecture governance policy assurance portfolio management service brokering supplier integration and managements I am and advanced financial management. So there are four contexts of the DP box and each of those contexts have four competence areas and those competencies are placed in the context with it within which formalization of those practices. And to occur, just give you a quick minute to look at that. Those are the 12 conference areas. So of course the open group is always back at standards with the certification program and training ecosystem. So you can now get trained and certified as a digital practitioner with the DP box foundation certification. So, so what is getting certified with the DP box tell your employer well it demonstrates an understanding that you have an understanding of digital context for business. It gives you professional credibility of the digital practitioner and it gives you competitive advantage in a job search. And if you look there at the bottom there there's a link for a lot more information. So in the past few months, we've published additional material based on the standard to help drive adoption and certification you can take a look at those there we got our practitioners pocket of digital practitioners pocket guide. There's a new digital practitioner foundation study guide, and there's DP box standard reference cards so all of those are great options for self study for those who might not have the time or the money to get into a more face to face or a live class. And we've also coordinated the development of the guide of the principles for open standards at the open group so the review period for this is already begun. So this review is is is now open for members who want to get and review that we invite any members to just review that and submit your change request. So before what's going on this year as we go forward so we're, we are working very hard to get an update BK box version one dot one we hope to have that out by the end of the year. We're working on digital standards alignment. And we're looking to enable open car contribution from the community. And the big announcement for today is that as of today, the DP box community edition is open for contribution and there's the link right there. There's always the open group is always pride itself that it standards are made freely available to all. And as a result, we're establishing a community repository for the DP box standard we're open to pull request and we hope that everybody listening will get involved. Great, well thank you Jim, let's hand over our presenter to Andy and as I see has already happened so Andy, please help us understand the digital view of architecture. All right, thanks very much. The first thing that I want to say is that enterprise from open groups definition does not talk about size whether you are three people working in a garage or 300,000 people working around the room around the world. You're an enterprise and architecture and all the business process associated with running a business exist whether you're three people or 300,000 people. And the practice of it might not be quite as evolved if you're three people but it is still there and everything you do is is an architectural decision or has some architectural impact. It does come back to haunches is Jim said earlier. I want to talk a little bit about architecture and there are a lot of people say there's a there's a big difference between architecture and the process which is very artifact heavy and DevOps which is very lightweight and and runs without an awful lot of upfront planning and that those two are not compatible or collaborative and I I want to talk about an example where it is it has shown that they are actually collaborative compatible and very collaborative. I have a friend of mine that leads disaster response. For a large height, high tech company based in Seattle, Washington. And with disaster response. I called him up and I said, What are your top three things on your mind. And is there anything I can do to help and he said Australia, Peru, and coven 19. If you've never heard of disaster response and thought about it. When they're from an IT perspective, people are always looking. The first responders that go in and they provide medical attention and survival support with food and water and shelter for people. There's also an IT component that goes in there they're looking for their loved ones and they've got to have a way to do that. And the infrastructure that is local might have fallen apart. And so IT companies high tech companies they typically go in they drop in technology whether that's a portable data center or connectivity to the cloud or or some kind of wireless capability to to help stand up and people will Well, a lot of times put finding their loved ones before they put finding a place to rest or getting some food. And once they've got that and they want to make sure that the people around the world that they know know that they're okay and that they survived. And then very quickly after that, they start worrying about recovery and that is what am I going to do about my home what am I going to do about my business. How am I going to put in for aid and support, etc. And with that, the IT capability has got to be customized to each disaster that the company goes in with. And when I asked him if I could help, he said, no. He said, we still have all of our regulatory requirements with GDP, HL seven HIPAA, etc. All the regulatory pieces are in place. Same with all the compliance with our internal legal internal security internal data structures. And we have reference architectures and reference designs that you don't have access to and you don't have access to our experts on the different on the different sort of regulatory and compliance pieces. So he said, while you might want to help, you'd be a burden. You wouldn't help. And when you're operating in that type of an environment where it's disaster response, number one priority is to get a solution out and get it out very quickly. And then it's got to be compliant and to everything that the organization works with, and it's got to be scalable and reliable so that when people need to use it, it actually works. And what they found in these high tech companies is that architecture has all of the resources, all of the artifacts and all of the connections across the entire organization so that they can feed these DevOps teams that are working. And they can help them with data design and with being compliant with the regulatory pieces and with security reviews and they can connect them with other DevOps teams that have already built similar capabilities and perhaps find test harnesses that are already developed and they can use with minor modification and that really accelerates their delivery and delivery in a digital enterprise and in a digital marketplace is this paramount. It is the number one thing people worry about is how quickly they can get it out. So architecture in a digital enterprise and in a DevOps environment, absolutely. We're working on a Togaf series guide, which is a form of white paper that describes how you can use the tools and the techniques that are in Togaf and OAF in order to inform the DevOps practice. You saw the, and we're also providing EA practitioners who may not know an awful lot about the digital space with the tools that they need to be able to work in a DevOps in a digital environment. So the common points of interest between Togaf, OAF and DPBock, Togaf is adaptable to digital enterprises, has a lot of the tools and the templates, techniques that DPBock competencies identify both their outward view, product centric and customer centric and those are critical pieces. Now the goal of the paper that we're working on is to support the digital practitioners that may not know about the Togaf tools and techniques and could benefit from their use. And we point directly to the tools and the techniques that are relevant at the different levels of business function that the DPBock defines in their context. And for enterprise architecture practitioners, EA practitioners, we are helping them with digital transformation. If they're not familiar with it, we're providing guidance on some of the gotchas and how you can use these tools to move forward in a digital environment. So their approach we're using is we're going to cover both Togaf and DPBock. We're going to make sure that the terminology, we clarify that where there might be confusion. And we're going to describe how the Togaf standards address the digital age and then how they're going to be applied in the different areas of the DPBock. And looking side by side to give an example of it, this is an eye chart, not for reading, but you can look at it and you can see the four contexts and you can see the 12 competencies. And if you look at one, for instance, operations management, you can look and the Togaf framework has guidance around that. So it does OAaf. And so what we do is we provide the information in context with each of those areas. And the way we're doing that is we've organized a small team and we are currently working on that paper and four members of the open group. If you want to be a part of that and if you want to help us with that definition and provide feedback on it, then there's the link to do it. And those are the keys that I had. Dave, take over. Great. Well, thank you, Andy. I think we've covered all of the key points here going the wrong direction. So I just want to wind up by talking about where you can get to some of these standards. You can always find our standards at the open group library and information on how to get certified and contribute to our new open DVBoc community. So there have been a lot of questions coming in. I think we've got about 15 minutes for Q&A. So let's start with some of these. Of course, people are reminded to put your questions in the Q&A box and we'll try to get those answered. We have a way of saving all the questions. We can try to get people to follow up if we don't get to all of them. So I'll ask the first one and I think we'll ask this of everybody because we've all got a piece of this. How can a big organization with a complex landscape go into transformation into a digital enterprise? And how does this can be handled incrementally to avoid risk exposure? And I guess I'd ask, you know, how do you see each of the standards we've talked about applying to help guide that process? So let's see. I'll have to go first. I'll be happy to take that one. So what we've, sorry, Jim Doss here, so what we find is that, you know, a lot of organizations, yes, they struggle to, organizations tend to group that size and scale and they struggle to go to the next level. But when they do, they're there. Larger organizations at the team of teams or the enduring enterprise level. Sometimes they have trouble acting like a small nimble organization. Well, not sometimes very often. So what you're finding in the, you know, this digital landscape that we're performing in today is that organizations are experimenting with downscale digital piloting. So they'll set up some digital initiatives. They'll try to sandbox or cordon, just cordon off that those digital initiatives from the big lumbering bureaucratic enterprise, if you will. And so they won't be subject to some, you know, some governance, many governance concerns or many architecture concerns that are more appropriate for the higher levels of the bigger parts of the organization. The experiment with these downscaled digital pilots, they'll act, they'll have small team, they'll have teams that begin almost like startups within the company, you know, entrepreneurship. And they'll, they'll, they'll experiment digitally with various initiatives and products and features. And of course, bring that feedback in very, very quickly. They'll amplify what works well. And they will dampen what doesn't and they will scale it and they will try to bring that back up to their, to the size of their organization. So, if it doesn't work at dampening what doesn't work, you know, the sort of scaling and growing what does. Sorry, amplifying what does work dampening what doesn't work scaling then to bring it back up to something that that meets their large, you know, user customer base. So that's, you see a lot of that going on with, I think digital there's there's other sort of digital ways to kick off and start digital but that's a very common thing that we see. And of course, I think that's what we were hearing in, in Mike Fulton's earlier presentation, we was talking about innovation inside a large organization. So Mark or Andy, any, any further comments on that question. Andy, let's go ahead. All right. Yes, that's the approach I've seen that works very well for getting started is having an IT team that is allowed to work outside of the bounds of the typical business process for developing product. They're given freedom to work in a more innovative way. They do proof of concept by delivering a real product and show the value and the speed that they can to deliver. And then once they do that, then it starts organically growing across the entire organization. And there are a couple of crisis points where leadership has got to evolve the culture of the organization in order to facilitate that move to a more agile process. Yeah, I'll just add on to that. One of the things that we're doing in the next version of it for it is incorporating different value streams and one of them is called explore. The idea here is to allow for better understanding of how do you explore new opportunities. And very much if you're familiar with Shark Tank, it's a popular television show about investors investing in ideas is we want to be able to quickly invest in ideas, try them out in the market and then invest further if those assumptions are true about what you are developing for your market. This changes how it is funded. It changes the culture as mentioned before, but it also allows you to accelerate new ideas in the market, which many it shops have been seen as blockers and and a lot of businesses have gone out and done their own thing. So, I would say traditional it shops need to learn to be more agile and there's a lot of changes that need to be made culturally financial models tracking these product owners and and working as teams that are cross functional versus having too much bureaucracy between teams. These are all shifts that we're trying to incorporate in the it Friday version three efforts that we're also putting. If I could just add one last comment on my earlier one so you know there's a statistic show that companies that just try to bring in digital technologies without bringing in the new digital ways of working and retrained workforce. There's a lot of digital buzzwords out there but frankly and I'm finding this is my consultancy a lot of people don't know what they really need. They've heard agile lean DevOps. They've heard product management, centricity, and they may have read a white paper to and they think they have digital and I'm working with them. It's anything but I find a lot of digital buzzwords being applied to old ways of working and templating on either waterfall, or delivering what I call delivering done mentalities right so I'm really, really finding in my own consultancy and I think the literature supporting this is that you know these new digital. I'm so excited about the DP box because I use I'm using it all the time in my own consultancy, really getting people to understand the digital ways of working which are absolutely required with these new injections of digital technology. Okay, thank you Jim. To that point, you know we've heard a lot about that, that culture of starting small and bringing it back into a larger enterprise. The importance of experimentation in innovation and exploring what is possible in digital product launches. You know, what do we think about how we can overcome the culture of waterfall thinking stage dating in order to get that iterative rapid iterative experimentation. And how do we get to the, you know, we minimum viable architecture to enable that rapid experimentation. Everyone for you to start Andy. My opinion, and what I what I've seen work in other places is that leadership is has got to be shifting over to more service leadership, which is something that is described in DP box. And in that case, what they do is they define the strategy and the business objectives that organization is trying to achieve. Once they've they've done that, then they turn it over to the line of business owners that drive each one of those lines of business. And the line of business owners tell the dev teams, these are the objectives that we've got, got to meet and they let the dev teams manage themselves in order to prioritize and to figure out how they're going to deliver that and and the leadership is more service oriented where they say, tell me what you need to remove your blockers, and I'll do that and tell me who you need to connect with and I'll provide that. And it becomes driven by the development teams that are very closely connected to the end users and that's, that's why I've seen a structure work and and it takes a cultural shift in order to do that. To put that in place to to move from being a leader that says this is what you're going to do. And you're going to report back to me every week or two and tell me how you're doing to saying, this is the objective we're trying to achieve. Tell me when you're going to get it done and show me iterative releases that are moving towards that. You're losing control as a leader and you're really not you're putting the ball in the hands of the best people that can deliver. Thank you. Mark, Mark or Jim any immediate reactions. No, I'm just, I'm just finding that there are, there's constant need for digital awareness and training. I'm seeing it everywhere so we're right I'm writing a strategy right now for a very large organization. Actually rewriting it it was it come out a while back but it needs some tweaks it wasn't as digital as it needs to be. This is so there's and this is a major undertaking at a big organization, and we're, we're challenged because we're putting in some, some, some, some words about agile lean DevOps product management centricity integrated product teams which want to run across functional areas not just very within a silo that's not an integrated product team. Right, so it's, we're finding that we can put digital words in but they don't know what they mean so there's, you can have digital strategies but if people don't understand what how to do those concepts with you know the DP box and and with it for it and and so on, they're really going to be challenged. They're really going to be challenged to actually do that in practice and you find there's a lot of conflict but I'm seeing a cultural clash right now in ways of working. The irony is, the more people have been working in the last 23 years and I see in the plan build operate mode left to right. Some of those people can be the hardest to get think from outside in right to left. So that's the huge challenge that I'm continuing addressing where I'm having the most success when I do address it successfully. And what I think is going to be a continue thing for the next few years. Yeah, I would say that there's two problems and they're coming together. One is digital native companies that grew up with a digital product in mind. They typically are especially newer techniques, agile techniques are used. They're struggling to become, you know, quote unquote mature IT organizations because they put a product out and they have they have to evolve. They have to do it properly because you're now dealing with scale and complexities from a regulation point of view and all kinds of other moving parts that larger more established companies already know. And then the second problem is really for traditional IT organizations to become more product-centric. We're kind of grounded in legacy and the way we do things, the tools, the processes that we've established over many, many years. And so they're struggling to kind of shift into that product and be agile. And I think that what we're trying to do as an industry is to bridge these two so they coexist. It's not one or the other, but it's a bit of both. And I think there's some concepts that help organizations understand that and how to apply, you know, both both levels of thinking in the same organization without breaking one of the other. Well, if I can if I can just add to that mark what we're finding as well is that you have to understand when some old ways of working are negating some of your digital sort of efforts. So again, I just give you an example of this hat we had. We have a, we have an organization who wants to use integrated product teams so they grabbed onto the buzzword but they're using it like a project team and it's very stage gated. And so there's an engineering IPP. There's a design IPP. There's an operation IPP and they're different. They're not a one persistent team. So I think an organization also has to understand where old ways of thinking can run counter to and really understand that dynamic and understand where they're they're old ways of thinking they're bringing in some digital concepts but they're not using them properly. So that's, that's something is so yes, where they can both coexist. They're not going to get rid of project management overnight that is certainly not going to happen quickly, but you find product and project management and service management, looking a lot more like product management today when you're looking at the latest releases and so on so it's I think it's an interesting time, but an understanding where those can be counter to one another is very very important. It's kind of like it's, you have the digital terminology but you're still living the digital anti patterns. And adding on to that it is that's absolutely correct. You've got the notions but you haven't modified the business process in order to implement those and make sure that they're going to work and and so the, the ideas there but tactically how you do it in the step by step doesn't get implemented. Great. Thank you. Our speakers were all so concise we've got a fair amount of time for questions so please keep them coming. I want to leave one from the question stream because I think we've covered this has been a lot of discussion and question stream about product versus service and I think you guys have addressed it very nicely. You know, obviously, to some extent, you know, your, you will have products delivered digitally, but those are actually also going to be to some extent backed by the service that you provide for your customers to allow them to interact with your product delivery team. So, yeah, I would just like to add to that one. I think the main difference from a product team perspective is that code is running somewhere to deliver the outcome. So if you think about digital products being different in that way, then I think you can make that transition and your customers can be internal or external or partners right you might be part of a larger ecosystem. So really having a product centric mindset when you think about the full life cycle and also understanding your customer and evolving those products over time because nothing stands still you always have to keep the code coming if you will, so that you can incorporate new features and, you know, kill bugs as they're identified. I think somewhat related to that the question in the case of organizations from the manufacturing sector that deliver physical products into the market. How can they make the shift to becoming digital. I'll take an initial stab at that one. What we're finding and you saw that in Mark and Jim's, their opening scenario where the oven becomes connected to a smartphone and watches and devices. Those are ways to do that in the in the IT teams that are working around a product they they're the best to envision and to provide that innovation to say boy, I sure wish that I could do blah, and then they can define and evolve that a little bit and push it out there. And one of the challenges that that I was going to speak to is what happens if you have a digital oven that gets hacked and somebody burned your house down. So there are compliance and regulatory pieces that come up and Jim Mark and I had a fun little discussion about that and how those things do need to be looked at and and where architecture and where all the compliance and governance needs to come in. Yeah, I think, well, I think that's a, I think that's a great question. It's almost like a microcosm of the whole. So you see like, you know, this goes back to the turn of the last century with, you know, mass production production line. And just all that reduction is sort of approach you optimize supply chains you minimize your, your costs you maximize your profit and you're really about getting, you know, it's reducing variant like a six sigma approach with the kind of the, you know, the, the height of this right reducing variance on your on your product quality right so that you have standard of quality for everything that comes off the line. And, and so we're seeing this kind of different thing but when, when an oven manufacturer or a car manufacturer gets into a digital space. As, as Mark and Andy said, you know, I want to know, know that they're in a different space that they know how to manage it. Mark tells me that there wasn't a stove and solve in his house as well but it got recalled because it actually did get and it could be turned on. So, you know, they didn't have to put more time to stove than the end in the code in the, in the, you know, the actual digital aspects of it so they're in a very so you find that people that are manufacturing physical products if it didn't start out as a digital product with, you know, the physical component of it too. They're, they're in a new space and they might not understand that. And that's, that's really, really all the rest of this conversation sort of floods in here. Yeah, I am. Yeah, go ahead. Go ahead. So I'm just going to add, you know, the thing for a product manager that's my day job as a product manager here at service now and I'm always thinking about better ways of making my product work without having to invest in the ground up idea like to link in other products or you know, extend into my ecosystem or leverage technologies that weren't available in my product recently or just, you know, recent other generations of the product or even my competitors. So I think the opportunity to leverage compute interfacing real time connections, social data, right, media, be able to leverage other folks data as a service like in the oven. I worry about, you know, the foods 20 years from now. Well, those foods still work because there's going to be different barcodes and different cooking instructions needed. So the ecosystem just expands, but also the opportunity if you're clever and you think outside the box. Of course the regulations are the tricky thing you don't want to go so outside the box that you're leaving your company for a reliable situation with whatever product you're coming out with but I think there's for technologists that are, you know, that are aware as a product manager in today's age you can do a lot with just a very little knowledge these days, embedding computers or RFIDs or, you know, technologies in ways that just nobody had thought about. You know, Mark, I think that you're, you're up to a very important idea there. And I think part of the, the change we're seeing is this, these digital concepts are forcing these traditional, you know, you know, hardware product oriented manufacturers, physical product oriented manufacturers to re-envision what a product actually means to them. I think there's a really good case study that's fairly easy to find about GE where they completely reoriented from, oh, here's an engine, here's a jet engine for your plane to, here's how we're going to maintain this jet engine, no matter where is in the world, no matter what parts you need, they track the life cycle. And the life cycle management of their product was the service and not just the delivery of the product. So I think that's, that's you see here, these leading ideas and I keep growing out of people who have purely digital delivery, the people that have physical delivery starting to re-reshape the way they actually model their business. So we've probably got time for one more question. I think there's a take it back to the standards view of the world. And I'm going to generalize a question I got here. We originally got a question, Ken, you touch on, you know, why there's both the OAAF and TOG-AFF standards, but I think the question I'm going to ask is a little bit more general. We've got standards that are each innovating in their own space, BP, Bach, OAAF, you know, TOG-AFF and IT for IT. You're all leaders in this. How do you see them coming together? Do you see that happening smoothly? Do you see rough spots? Where do you need help? I guess I'll go first. You know, from an IT for IT perspective, we started out with really the service focus and then we transformed to digital products. And what we're finding is that we can integrate ideas from each other, from the different forums and the other activities and shared concepts or shared ideas. One of the things I like about this whole thing we're doing in this forum now is we're coming up with a shared set of principles. So we all operate and kind of fill in the gaps wherever those principles apply to the standards work we're doing. I think that's really critical. So we're all on the same page at least, but each forum is kind of out to solve a different type of problem. And I think that's important too. We still need to be able to solve the problems that we were set out to, but then at least coexist and integrate wherever possible so that we're not doing this in different directions. We're kind of aligning our decisions and our terminologies. And those are the kind of, that's the kind of help I think I would say to kind of answer your question, Dave, is folks that kind of live in different worlds. If you're doing IT for IT and architecture, can you help with evolving how that comes together? Or DP Bach, if you don't have DP Bach now and you want to start using it and you're an architect, you can bring that into your place of work and be a champion. And I, and I think what's going on with these digital standards, which are notable digital standards, right, they reflect what's going on with the industry. And I see what's going on with the open groups digital standards portfolios exact same thing that's going on right now up in the industry. You are seeing an amazing time, a lot of new paradigms new paradigm shifts, these paradigms all informing and influencing each other. It's a very, very, very exciting time to be an IT it's a very exciting time to be in digital. It's a very exciting time to be in business and increasingly no separation between those two is being seen by business going forward so it's been very exciting here at the open group. But I would just say it's reflective of exactly what's going on and it's been fun and there's lots of great conversations and ideas flowing back and forth. It's a great time to be involved honestly and working with the digital standards at the open group. And to add on onto that the terminology I think is is critical the way that we communicate is extremely important and when I started my part of this discussion. I qualified what an enterprise is based on the definition the open group uses and we have so many terms that we've got to do that with all of the new digital language can be confusing to an awful lot of people and everyone has their own vision. That they have with that the same with architecture and the same with platform. Dare I say it everyone you use those words and they're very polarizing people see them for what they think that they are and from their background and I think that providing a common terminology and then providing the relationship between these different frameworks is is a critical piece and and that's why I'm involved in the glue part of it. Well that's a great place to end you know to hear Jim's reflection that we're really here right at the cutting edge of where industry isn't that our standards are are following you know following that along as close as we can. And Andy had a good reminder that it is hard work but it's what the open group does we bring people together to hammer these things out. Sometimes it will painfully but we do hammer them out eventually and know that we can actually produce that standard those standards for everybody to use. So we are up on our time I want to thank my panelists. Mark Bobman from service now Jim Doss from IT management and governance and Andy moves from sustainable evolution.