 Welcome back everyone. Thanks for being here and thanks for sticking with us. We've had a great turnout today and some great participation. Thank you very much. So we're continuing with the topic of basically standards in the digital world and how we can use those to create great things. We've just heard about the work going on on the security reference model between two of our forums, the IT for IT forum and the security forum. We're going to have another double act presentation now on the reference, introducing a reference model for digital. And to do that, we have Justin Mann and Jan Stoby. So Justin is managing partner at Digital Business Consulting and he's an implementation consultant and educator recognized for his work in IT transformation and technology value management. While at Cisco, he developed the framework for an author of the associated book on operating IT as a service organization. He's continued to involve the solution aligning it with agile practice principles such as digital product line management as one of the world's leading experience based frameworks and training product centric technology management across a digital business. Justin works closely with industry standards bodies, including the open group and the Technology Business Management Council. Leverages a strong technology background and is committed to understanding his clients industry verticals. And here's something about putting your heart and soul into it. He even went as far as to complete sea survival and helicopter underwater extraction training in support of petroleum industry clients. So welcome, Jason. And sorry, this is just it on this one. Yes, I just realized that John, sorry, I was getting ahead of myself today. Okay, no, this is just Justin, but he's going to talk again about the introducing a reference. Operating model for digital. So sorry about that, Justin, but a warm welcome. You don't need anybody else. We've got you. Sounds good. Thank you so much, Steve. So we've been really excited about this opportunity seems to have locked up here. All right, so we've been really excited for this opportunity. It's both a chance to provide a preview of an upcoming white paper from the open group. We're about 2 to 3 months out from release. And it's also an opportunity to follow up on a presentation that we did last year at another open group conference. And in that presentation, we described a product centric kernel for a digital operating model. So independent of the broader elements of an operating model, we went into detail on what that core could look like and even more importantly, in real world practical terms, what a product centric kernel would change it, how it changed our approach to cloud, how it changed our approach to managed services providers. So we got a lot of interest and feedback from that. And based on that, we fired up this team. To look at, could we define an end in reference operating model that was product centric. And again, we're about 2 to 3 months away from releasing that white paper. And actually the agenda that you see on your screen there roughly maps to the table of contents for that upcoming paper. So I'll start with the background and approach of team followed. One of the first things we wanted to start with was a few guiding principles for the effort. The first thing we agreed to was that we wanted to move past redefining the challenges and considerations that I think we've all seen plenty of and really focus on solutions and prescribing some recommendations and solutions. So almost coming out with more of a prescriptive technical paper than just redefining those challenges that we've all seen plenty of articles on. The next thing we wanted to do, at least as an early exercise, was to set aside everything we knew today about how technology management has been done. And just start in terms with what do we know now about the circumstances for digital and business requirements. And if we could do it from the ground up, what would we do? Finally, we wanted to make sure we prescribe a holistic system. I think we've all seen plenty of great articles that look at the challenges facing, for example, funding models and then propose some good ideas for that. But when you start carrying those recommendations out to your organizational models and other elements of an operating model, they start to conflict. So we wanted to make sure we were building up a holistic system. Now, the very next thing we wanted to do was agree on a mission statement. And surprisingly, we did this very quickly. We wanted the goal of the operating model to be to achieve holistic management of the value and risk of every digital product in the business at all times. We didn't want to shoot too high, but we did want to go with something that was pretty bold. And I'm going to circle back to this mission statement at the end of the presentation. And I think we're all going to agree we've managed to do it. We've managed to lay out a practical approach to accomplishing just this, no matter how bold the mission statement may be. Now, the key is we knew early on that to accomplish this, we needed to start with that product-centric kernel. So the next few slides are going to go into some details on that kernel. But one other bit of background I wanted to share with the team was this debate we had early on, on whether to emphasize product-centricity or customer-centricity, because we've seen both out there in the industry. And what we agreed to at the end was that if you lay out the values and principles that most associate with customer-centric, product-centricity does not exclude those principles. So we're not leaving any of those behind by being product-centric. In fact, a lot of us felt the value and principles that we associate with customer-centricity were really implicit. But I think more broadly the concern for us or the big decision factor was that we're trying to align everybody to a common goal. And when you think in terms of customers versus a delivery team, we get that there's customers out there and that's ultimately what we're trying to serve. But the reality is for certain delivery team members, the idea of a customer is somewhat abstract. It's multiple levels removed, and it's unlikely they're ever going to interface directly with a customer. But on the other hand, a product, a digital product, that's something they can envision. That's something they can get behind and start to envision how their actions day to day can impact how they are creating value for a consumer through these digital products. So if we start to think about that product-centric kernel, what is it trying to do differently than all of the operating models that we've defined traditionally? And the very first thing we wanted to do was to move the focus to the products themselves that we are delivering. We wanted that to represent the central nervous system for the operating model, not the traditional silos that we've been organized around. Number two, we wanted to make sure to prioritize holistic value management, not just operational requirements. This is much bigger than requirements you would pass from a development team to an operations and support team. It's bigger than just understanding your cost. We wanted to move the bar all the way up to holistic value management and get our arms around any and all elements that might involve for a given product. And number three, we wanted to make sure we did that throughout the entire product lifecycle. We have a ton of methodologies out there to help us understand how to deliver value in the development phase. But how you build something to be able to create value is different than how you operate that thing over time to continue to create value. What we see is a lot of enterprise businesses are continuing to operate these digital products over time, and you start to see a ton of value degradation and increased risk. So to minimize that, we need to manage value throughout the entire lifecycle. And finally, we need to figure out a way to do that at scale across all of the products in our digital business, not just a few premier products. So how we accomplish that in the kernel at a high level is to think about how we define the digital product. And it's this final unit of delivery from the technology team to the consumer. So if you want to get your arms around how you create value for a consumer, all of the elements that the customer experience, the total cost of ownership, that's where you do it at. Now what we've done is we've taken a slightly broader definition to encompass everything from not just a software package, but it could represent a technical capability in the end customer device like a laptop or tablet, or even an outcome that's delivered. The goal here is to use digital product as a unifying concept to get everyone on the same page about, we need to understand the things we deliver and get our heads around how we create value through those things we deliver, not get into terminology wars. Next, once we've applied this broader definition, we're obviously going to have dozens, hundreds of products identified across the business. So we're going to use digital product lines to help us scale. It's very simple. It's a logically related group of digital products. In some cases, a digital product line may involve only two to four products that are complex and kind of these premier products we think of being consumed by our lines of business. In other cases, it's okay to make sense to group a dozen or even upward of 20 digital products into a single product line. So long as you can get the right level of management around those. And finally, we want to rethink how we manage our portfolios, and it's going to be a lot easier going forward to organize by the type of consumer. We have external consumers for those digital products like connected vehicles or smart appliances that are consumed external. Internal, speak for itself. But I think we found there's a lot of value in thinking the difference between digital products delivered directly to employees like laptops, desktops, collaboration and productivity capabilities. And those digital products that are actually consumed by a line of business to transform how they operate because they represent fundamentally different approaches to investment, innovation and how you want to manage those things. So there's a lot of value potential to at least thinking in those two different terms. And finally, we've got those enabling and foundational products. So these are your infrastructure development capabilities, things like that, that make up the technology supply chains for a lot of the top level digital products. Now with those in place, the question now is, how do we effectively scale that across a full digital business? So we're talking through the basic principles for digital product line management, that we are going to designate products end to end grouping by these digital product lines. And the real key here is that the expectation when you designate a digital product line, we're going to manage that thing like a semi-autonomous micro-enterprise. That is a big difference than just thinking of it as a typical delivery team. For most businesses, small enterprises, 15, maybe 20 on the high side in terms of the digital product lines, larger enterprises, upward of 60. If you designate too many of these digital product lines, you're going to be creating a ton of effort in terms of management, reporting, and you're not going to get a lot of value. On the other hand, if you go too low, you're probably missing out on a lot of value optimization opportunities. So follow those best practices, you'll be in a good starting point. Number two, we are going to decentralize the accountability for value and risk management to digital product line managers. Now this more than anything is the key to success. These are not product owners. These are not organizational managers. What I'm looking for in these roles is that general manager mindset, which I agree a lot of times to three key principles. We're looking for an extreme sense of ownership. Number two, we're looking for high performance decision engines and strong delegation skills. So I regularly see a lot of new information and ideas around how we can shape that digital product line manager role, but a lot of them are still kind of leveraging and moving outward from product owners and design thinking and things like that. Those are all valuable roles to have out there, but at some point we need that more business minded general manager mindset if we're going to make this successful. And finally, we need to leverage a common strategy for value management across all of our product lines. And we do this for the same reason we have a common way to report publicly traded companies. If every publicly traded company was reporting its performance in a completely different way, we would have no idea how to analyze and make investment decisions. So we need to have a common approach that still allows a lot of flexibility for the specific product lines. So if you want to hear more information on these ideas and again, going through what it means, what it looks like in practice, there's a link right there that will take you to a 20 minute video that takes you through more details on these practices. But now that we've got that product center kernel, the question shifts to what are the best strategies and functions the operating model needs to support that kernel. So I want to be clear, we're not trying to be overly descriptive on differentiating between a strategy and a function loosely. If it represents ideas and responsibilities that are carried out by teams across the business, it's a strategy. If it can largely be captured and executed on by a dedicated central team, then we think of that as a function. Now, it should be no surprise given the mission of our operating model that one of the top ones is digital value management. So this represents both a strategy and a function for us. We talked about the need to have that business wide strategy, but it's going to be really valuable to also designate a central function that can help us drive the governance, build standards and processes, even drive training, driving training and awareness for a lot of that is going to be a big value add for that team. And also make sure we've got templates and the different tools and platforms out there to help us perform value management. There's a lot of elements that could represent value management. So if you look down there just at the total cost of ownership, there's going to need to be processes and standards and hopefully templates and tools that help us report that. Even within that, we see a lot of focus emerging for financial ops or fin ops, which is dedicated to helping you right size your spend in the common public and private clouds. So you can see right there the value potential for having dedicated resources who really know these areas incredibly well and they can help drive training standards and awareness. Now, technically risk is absolutely part of the value management strategy. You make tradeoffs and the other elements of value to increase or decrease risk. We see risk management is three distinct pillars. So if we start with that digital security function, this team is responsible for driving business wide governance and architectures. So if you're rolling out a zero trust architecture, this is the team that's responsible for that. What this team is not responsible for is the actual digital security of the products themselves across the business. That accountability, again, lies with our digital product line managers. So they will be leveraging the digital security team as an advisory function to help them figure out the best way to do digital security relative to a product. And that in itself represents only one element of a much broader risk management strategy that those digital product line managers are accountable for. Now, the final piece of this is we are recommending that we pull out a function for controls and audit. So if we need to identify the controls and perform audits on zero trust architecture, we want that done by a different team reporting to a different leadership. And another area of opportunity here is that when this control and audit team gets their heads around these digital product lines, there's always a moment where they start to realize the whole new set of opportunities that the digital products and digital product lines represent for identifying control and audit points that are a lot more directly associated with business performance and business conformance requirements. Now, I'll talk to these next two all in the same page. The first two are kind of creative thinking, I would say, but we know that change is going to be constant in a digital business. So we've seen a lot of value with leveraging dedicated change leadership functions. And I want to be clear, I'm not talking about traditional IT change management. I'm talking about the formal practices and body of knowledge around actual change leadership. So you might be leveraging a change leadership function that already exists in the business and trying to identify some resources within that team that has background in the digital space, or you may be training up a few leaders within the digital practitioner space and helping them to pick up some of the skill sets from that digital change leadership. But the goal here is to make sure that we are smoothing out all of the change that's happening. Next, another creative call is this digital talent resourcing. We're going to keep going back to this as we go through some of the organizational structures and resourcing challenges later in the next few slides. But loosely right now I'm just going to say that talent resourcing for digital is very quickly becoming a point where it represents a unique set of challenges and considerations that is different than traditional talent resourcing. And having a small team that's dedicated to understanding this business really well can very quickly be a competitive advantage to really help be efficient and drive better levels of value. These last two are functions we're all familiar with. Enterprise architecture has always been and will remain a critical function. We just need to make sure we evolve it to make sure it's lean and agile. And the biggest thing I want to stress about EA going forward is that it is an advisory function. The final decisions on whether or not to invest, what level of tolerance for risk to accept, or even to accept some degree of duplication from what other teams are doing, those decisions rest with the business and with the product teams. EA is a critical advisory function and not this central final authority on those decisions. For data and information, the key thing, and I really can't stress this enough, this rest on we are decentralizing accountability and we are broadly democratizing greater levels of authority and autonomy. What the data information strategy has to prioritize is making sure information is now available where the decisions are being made. So hopefully it's running in parallel to this designation of the digital product lines and the product line managers. At the same time, you want to make sure you're prepared to intake all of the new information that's going to be generated by those digital product lines and making sure it's available anywhere else in the business. It can be a value without making it available in a way that increases risks. And finally, always keep in mind, I think we all agree, big value potential add always comes down to AI, ML, things like that. And data and information are critical to unlocking those. Now, when we've got these strategies and functions now down, I think the next question turns to where do these things live? Who is responsible? Who owns it? So we want to start thinking about how we repurpose the central IT organization. And when I say repurpose, I just mean that the goal is no longer for the central technology organization to be the sole owner and administrator for all technology in the business. That's not the case. We have to acknowledge technology and technologists are going to exist everywhere. So to be really clear, we are all violently in agreement that the goal is not to decentralize what was the central IT organization. The better question is what do we leave in and where is it valuable to move something out to the product teams or into the lines of business? And the best way to figure that out is start rethinking the new priorities for IT organizations going forward. And we align on four of these. The first one is that digital governments should be pretty explanatory, but you can imagine the value with having the central organization defining best practices for secure coding, API code library storages, and helping drive the platforms that help you be successful in that function. So digital governments is a key. Another one I think we forget about is that this organization will still be a large scale product delivery team. So they're still going to have product teams. And what they're doing is they're applying that product thinking to the things we deliver, whether it's infrastructure, cloud and infrastructure capabilities, or even those productivity and collaboration capabilities. So the other thing here is as digital products recent inflection point that may be embedded with the lines of business and we're ready to scale that across the board, it may make sense to shift that product team into this technology organization to help with the scaling. And you want these guys to be an innovation partner. When we think in terms of innovation, we always put so much focus on the products that are out there embedded with our lines of business are delivered to external consumers. But in reality, if we drive innovation in this space, we're improving if we drive improvement for something that's part of the technology supply chain, we just increased the value potential of dozens and perhaps hundreds of digital products. So keeping the pedal to the metal on innovation is another important area for the IT organization. And lastly, I think it's the one on everybody's mind, which is being that big digital delivery partner. So we're trying to figure out how do we deliver efficiently when we have the need for these very elastic organizations. It's very highly unpredictable levels of demand. So the way that we do that efficiently going forward is going to be to move away from the idea of traditional delivery teams. So you have smaller teams, five, maybe 15 people. It was largely fixed in size within this very strict hierarchical structure. Resources were either full time or maybe contractor. And you only had a chance once per year to kind of reevaluate the demand you had the previous year, the upcoming year approved projects and fight for increased headcount. And these things also kind of reinforce that silo oriented operations and cultures. What we want to move to instead for delivery is coordinated centers of excellence. So there's not going to be a fixed structure. This is more about larger teams of loosely organized resources and we're coordinating between them. They could be upward of several dozen, even 40, 50, 60 resources that you're coordinating between here. They are intended to be elastic and to shift in size with demand to be really effective. We want to start using a larger range of resource types. We could be using offsite, near shoring and even gig worker mentality is something that we'll come back to. And you're continuously assessing your ability to support the incoming demand. And another key thing is you want to drive that product thinking from the top. So at the top level, we are still treating these just like all of our other digital product lines. So the question still is, I still need an organizational structure in some way. So what do those look like? And the reality is, when you think through the challenges we're facing, there's no single solution for an organizational structure that can answer everything. But what we can do is view it into single planes. So we have a top plane that is dedicated to product and value management. So these are smaller teams. It's the digital product line manager, a handful of product owners, maybe some solution to architects. And it's simple, flat organizations, but they are broad all across the business. In some cases where it makes sense, we can embed some delivery resources here, typically data scientists, developers. Underneath that is where we do digital delivery. And that's where our centers of excellence are coordinated. The bigger thing I think is to look at how this looks in practice. So at the top level, we've got our small, simple product value management teams. In some cases, there's some dedicated delivery. But in the centers of excellence, you are looking to a much bigger group of people, different types of resources, and that's how you're going to, I think, approach a lot of this. So the bigger question now is, okay, the product and value teams, that is a simple organizational structure. How do I structure my delivery teams? And I think one of the near solutions we started to see is something called Helix organizations. So to make sense of this, it's important to think back. When we look at organizational structures traditionally, we had a single line that encompassed both the work assignment and work prioritization, and it also covered the performance evaluation, career support, and administrative support for that resource. It was all a single line. So Helix organizations break that out into two distinct lines. So you've got one manager that's assigning workloads, prioritizing work for the resource, and another that's doing the performance evaluation career progression. So I had read about these organizations a while back. I thought they were interesting, but I really didn't see the value potential until I started to view it a little bit differently. So all I've done here in this visual is to kind of detangle the Helix. So you can imagine a case where there's an infrastructure COE manager. They've got a resource who's recently passed a new AWS engineering certification and worked alongside some senior engineers. And he says, okay, you are now clear to pick up senior level work requests from product teams. And as happens, we've got a product team who needs an AWS engineer. But here's where this gets interesting and creates an opportunity for us. Over time, this resource sees that its commitments are only a couple of hours a week for that product team. So he's got more time on his hands. So he can now sign up to do cloud engineering work for multiple other product teams. So this is where we start to move to a lot more dynamic work assignment and work engagement rather than trying to filter it through a single team and resource. But there's an even better opportunity here. Imagine for a second that this resource also got interested in Python development. So he started working with the development COE and got cleared to do level one Python development. So now he can also pick up work from product teams for that work stream. What this does is it lets us not only foster but take advantage of multi-discipline resources. And I cannot stress enough how big of a value potential that is for letting us move to a lot more dynamic resource organizations. Now a couple of call outs on this. Number one, you can imagine where maybe we have a business internal app. And now these delivery resources can engage almost like gig workers throughout the week where they can sign up for different product to work for different product teams. You could even carry that analogy out and have reviews from the product teams similar to how we give Uber drivers. Hey, I'm a five star Python developer. You know, keep me on your list. This will require that the resources are capable of higher levels of self management, self prioritization. And we'll eventually need some platforms to help us manage these, whether it's app based or whatever it is. We need a way to start handling that increased complexity that comes with that. Now last topic for us, cost and funding. Every element of the operating model is ultimately enabled through funding. So if you're not funding it correctly, you're inhibiting its value potential in some way. Where this gets challenging is we know we need to be more agile in our funding and investment. But how do we do that without sacrificing some top level governance and setting some limits somewhere. And we hear about continuous product funding, but then it's the real world issue we hit is how does that work when a big part of the technology supply chain for this digital product is still using projects and operational budgets. And we also know there's a challenge where because we're architecting things in the cloud and other ways we're actually bypassing our traditional approval processes where we had capital review and approval. Now the good news is when you move to these models for end to end product thinking, it completely changes the options that are available to you. So when everybody, when everything is managed as a digital product line, now you actually can do continuous product funding where if it's funded, it's funded. If it's discontinued, then you can cut off the funding. The question becomes more, how do we manage those over time, manage those costs over time. And I've got a good tool I'm going to show you in just one second. But the other thing to be aware of is when we're driving the expectation that everything is managed for value, then it changes the context of the conversations from projects and outcomes to true value management. And you have to remember we're driving accountability for continuous cost optimization. Now as a part of that, we're also encouraging those digital product line managers to make sure to consider the broader technology supply chain. So they're thinking ahead to say, if we scale this digital product to this point, there's going to be a spike because we have to grow the private data center at some point. So these product line managers have to keep their arms around. There's other costs involved to keep up with the scaling delivery and the risk of these products. Now, for years, I spent coaching service owners and we use block charts showing the quarterly. And those were okay, but the problem we always had was the service owners never paid attention into the quarter and then there were surprises here. As we move to continuous product funding, these sliding windows for product funding become a lot more valuable to us. We can think of it as being fixed in time and we can even link it to sprints or ethics and we can start driving that accountability. And this gives us our mechanism for setting some sort of expectations for what the allowance for spend is. So if these are commodity based products, your tablets, laptops, PCs, you can set the height of your window fairly low. In fact, just above the trend for continuous delivery over the past six months. But if it's a premier product where you want to incentivize a lot of investment, you can set the height of that window a lot higher and allow for a lot more continuous improvement investment. So these are great tools for us going forward. Finally, when we've got the elements for the operating model, it can sound good at practice at a high level, but the day to day tools and processes is what will make this work. So if all of our processes are still non product centric, it's going to inhibit our operating model. So I think like a lot of people have been keeping my eyes on different standards and methodologies and I wasn't really impressed with the initial product shift. But now I am completely excited about the open groups it for it standard version three that will act as a great reference architecture. So it's going to help us go through with a fine tooth comb, look at the processes like change that incident problem event management and just rethink those from the product perspective. At the end of the day, it may be only minor changes, but man, those nuances can have huge impacts. So we have to take this time to rethink processes from the product perspective. And finally, we're going to have a new set of priorities for tools. We need platforms that can help us do digital management. We need platforms that are going to help us do this dynamic work management and resource management that we talked about. And if we are using a single source of truth, it needs to be product centric or at least have a roadmap to becoming product centric. So in wrap up, if you think back to our mission statement that we wanted to somehow manage the value and the risk of every product at all times, set aside all of the solutions that we've talked about for the past few minutes. How we are actually accomplishing this is we are doing a we are aligning everybody to a common goal. Number two, we are decentralizing accountability. We are democratizing greater and greater levels of authority. And we are increasing the levels of autonomy. And I understand that that can give some heartache and concern to a lot of traditional business and tech leaders. It really is the only way we're going to accomplish this. It relies heavily on our people because we're asking our typical managers to step up and now be almost general managers of a mini business. Even our delivery resources, we're asking to step up and exert higher levels of self management and self prioritization. Overall, I'm not worried about this because I'm convinced when we empower the right people, great things start to happen. And they keep happening. So this is a bit of a bold move and this operating model is leaning into it more boldly than anything else I've seen. But I truly believe it is something we can accomplish and that these principles right here are the way to do that. So get excited. It's a great time to be in this industry and there's a lot more to come. We're about two months away from releasing the paper and with that, I probably overshot my time just a bit. But let me know if you've got time for a few quick Q&A. Justin, great stuff. Thank you. Yeah, it is an exciting time and we're very much looking forward to the version three of the IT for IT reference. Thanks, Steve. We've got some, we do questions. I'm conscious. So one now and I'll come back to the others in the panel session. Perfect. But one specific, when you talked about the data and information part of the organization, the question is could that be a data mesh where data stewards are responsible but there is a central governance and control. I like that. Short answers. Yes, I like that. I think, yes, I would encourage, you know, reach out, see if we can collaborate on that and maybe get some updates into the paper before it's released. Thumbs up. Okay, great. That question was from Matthew Clark. So, um, Matthew, maybe you and Justin can hook up and we can help that. So I'll take the rest of the questions in the, in the panel, Justin, but thank you once again for that great overview and see you in a few minutes, 30 minutes on the panel. Thank you. Good. Thanks, Steve.