 Welcome everybody warm warm welcome from the open group. Thank you for joining us today. We have people joining us from all over the world, which is always great to hear. So the chats already started of where you are. I encourage that to get going. Let's see if we can beat the number of countries that we've had in the last two days. But we know there are people coming from 85 different countries. But let's tell us where you are and and anything else you want to share with your fellow attendees in the chat channel. And as John said, any questions for any of the speakers, please put them in the Q&A. I'll be sharing question duties with my colleague Dave Lansbury over the over the course of today. But it's helpful to us if they're all in the Q&A and we'll take them in the panel. We have a really great day lined up is an expression that I grew up with, which was a quart in a pint pot. And we really have that today. We've got a lot of content and great speakers and and they're going to really bring bring this topic to life. So we're here to talk about it's digital professionals day and we're here to talk about how open digital standards can can help you in your day to day and in your digital transformation journeys. And I can't think of a better way to start off than with our first speaker, who it's always a pleasure to to introduce Mr. Mr. Charlie Betts. Welcome Charlie. Charlie is a principal analyst with Forrester and he serves the infrastructure and operation operations professionals as his responsibility there. He covers DevOps, enterprise service management and next generation IT operating models, which is really what he's going to focus on today. This includes topic areas such as product team thinking, continuous delivery, enterprise service management, automation, change management, incident management, service catalog, IT asset management, application discovery and dependency mapping, configuration management and CMDB, as well as industry frameworks like ITIL, IT for IT, DPBot and COVID. So in an increasingly volatile world, digitally transforming organizations are aggressively scaling their agile and DevOps capabilities. Numerous lessons are emerging at the leading edge, the trend towards product teams, the emergence of infrastructure platform teams and ensuring coordination without gridlock between these new organizational units and to guide us through the labyrinth that that that is for all of us. A warm welcome from the open, a welcome back from the open group for Charlie Betts. Welcome Charlie, great to see you again. Great and thank you so much Steve. So let me just share my content here and if somebody can confirm for me that the, I have to swap the presenter view as the presentation appear correct. Excellent. Okay. Now without further ado, thanks again to the open group for such a warm welcome. Today's topic is the new operating model is upon us. This represents research, research stream that I've been working with now for about a year and a half looking at the impact of product thinking, digital transformation on the broader questions of how do we organize and operate the IT organization and increasingly VUCA times. VUCA is a acronym that has gotten a lot of traction recently standing for volatile, uncertain, complex and ambiguous. I think we would all agree that this is not a bad shorthand to characterize the times we're in. And the certainly immediate expression of this, not the only expression, has been the massive impact on the global workforce up to a billion people impact that I've heard by the pandemic. And this has had day to day impacts that sometimes are not as obvious to us. For example, informal knowledge exchange in the modern organization is diminished. You no longer can walk down to the fifth floor and talk to the receptionist at the HR department. You have definitely a greater reliance on mediated communication channels and more formalized knowledge sharing, which has resulted in some market trends that have been clear to us as well as others that have resulted in further acceleration of digital transformation and in general, a what you could call a pivot. I went looking for a big pivot. I see that there are some conference attendees from the Netherlands who will recognize the very large seawalls that they have in place to protect the low countries. I can't think of a bigger pivot than this. And it certainly is a good symbol for the kinds of transformation that companies around the world have found themselves making as five year strategic plans were unceremoniously recycled as the new outlines of the outlines of the new reality became more and more apparent in the words of Sacha Nadella. And he said this, I think in April of late April of last year. So just between March 1st and April 30th of the year 2020, this was how Sacha Nadella summed it up two years worth of digital transformation in two months. And we certainly saw this at Forester as well with the accelerating interest in enterprise service management. We saw companies who were expecting actually to not do well, do much better than they had projected. Maybe their business plans were fulfilled in different ways. Big deals fell through, but then were more than made up with by organic growth and just the ongoing demand for greater coverage on certain digital platforms. But all in all, it's been a time of change. And keeping up with the speed of change is not a new topic and not a topic that emerged in 2020. It only accelerated even further in 2020. It was already a topic for years. And the response to keeping up with the speed of change in the digital world was, of course, DevOps. And DevOps is, I think, a very important trend. It is one of these technical trends like distributed computing that you can pretty clearly point to and say, yes, there's a before, there's an after, and the after is clearly different than the before. Other technical trends, a bit more market driven, a bit more shiny object, it's not as easy to say that. But I think that DevOps definitely has earned its rightful place in history as one of the transformative moments, one of the watersheds in computing and applied computing and information management. And it was all about ultimately speeding the feedback loop, which is why I view DevOps ultimately as inspirational, not only for computing centric domains, but for all of business because it integrates and it emphasizes the need for fast feedback between your ideation capabilities of marketing, R&D, product management, your implementation capabilities, in this case, largely digital, your sales and service capabilities and your operational capabilities. It used to be that there were long, it was long latency, you know, to get that feedback back from sales back into marketing and R&D. It was a notorious problem for decades in business, let alone feedback from the shop floor. How can we design this better for manufacturing? DevOps forces a tighter and tighter integration of these concerns. And again, I'm fairly deliberately expressing this in business terms, not necessarily in technical terms, because I think that the lessons are broadly applicable across business. We're seeing a trend, for example, in many corners of business to product towards product teams. We're seeing a decline in project teams. We're hearing right and left of PMOs being shut down, or at least dramatically re-chartered. There still is a need for some kind of investment authority. There still is a need for accountability. But the demand I think is going down, at least in terms of the cutting edge digital capabilities. Functional specialization is transforming. It is easy to say that product teams are multi-skilled and therefore less about functional specialization. But we also see the rise of platform teams, which I think give new life to necessary functional specialization. I'll talk more about this. In terms of the actual data, we see product teams on the rise. I ran this survey. We saw that 27 percent of organizations were saying that they were orienting primarily to a product team operating model. And my belief is that if I'd run this years ago, that would have been much less. And we ran the same question for another survey, which I'm not able to publish the results, but I can say verbally, we ran the exact same question on another survey, and product teams was closer to 40 percent. And so we definitely see a growing interest. I mean, to say that, you know, product teams are becoming the primary preferred operating model. I mean, yeah, there's actual data supporting that statement. And the benefits, there's actual data supporting the benefits. We see that they're correlated with faster release frequencies, faster agility, and agile DevOps transformation as a whole, which is not surprising because one of the things that an agile transformation will look at is the overall structure of the work and structure of the organization. You build it, you run it is a common rallying cry in digitally transforming organizations. Our data shows that when product teams move to a build run model, the business as a whole is more likely to report it has exceeded expectations for business objectives. Correlation, not causation, of course, but nevertheless interesting. I've talked about product teams, but what are they? I use the epoch double a model. Product teams are empathetic, which means that they care about the customer. They engage in tech specific techniques, such as understanding customer personas, understanding customer journeys, analyzing the jobs to be done of the product. They're persistent, which means that they're not simply reformulated every arbitrarily every 12 to 18 month with another turn of the big project management crank. They instead retain their identity for as long as there's a business need. They are outcome focused, which means that instead of being just fixated on deliverables and activities, they take concern for overall business outcomes. This is maybe the biggest challenge that your traditional project management mindset is faced with, where the tradition there has been, well, I make my iron triangle deliverables of scope and budget and time, and the business outcomes are the business sponsors problem. Product management integrates those two. I think that's probably the single most important aspect of a product management transformation. The collaborative means that they prefer face-to-face, higher touch interactions, as opposed to shipping work over high silo walls via tickets or work orders. They're heterogeneous and multi-skilled. They tend to prefer automation. If you can't have a high touch collaboration, then you want automation with an API, and they are relatively autonomous. It doesn't mean that this is an anarchy. They're still held accountable to the overall objectives of the value stream. But again, the autonomy is there for the team to determine its ways of working, and the accountability is to the what, not the how. This may seem obvious, but we've come from decades of industrial engineering practice where industrial engineers would come in as a specific independent organizational capability, would map out the workflows and present them to the operational teams in three-ring binders, and then auditors would come in and audit that the teams were complying with those workflows. That is not an autonomous team. That is not a team that has autonomy to define its own ways of working. This is a change. It is an evolution in work practice to give the product team more control over how it works in the interest of being accountable to and achieving those outcomes that it is charted with. We also see that product teams have both an external and an internal as well as an external guys. External product teams have been around a long time. Obviously, that's the whole basis of marketing and product management as it's taught in the business school. But the idea that internal teams also market a product to an internal market is a newer idea that is gaining traction with leading thinkers like Jeff Gothel, who has actually said, yes, HR and finance and legal have products. The core concerns of product management, and I won't go through all these bullet points in the interest of time, the core concerns, however, don't change whether you're internal or external. You still need the epoch model. You still need the outcome orientation. But what are the impacts that this is having on the traditional IT organization? The infrastructure and operations capability, it's interesting even to say, I know, it just kind of rolls off the tongue. But it takes some unpacking. If I say infrastructure, I'm actually implying a stack where I counterpose infrastructure versus application. If I say operations, I'm really proposing a lifecycle I develop, then I operate. And so it's a four box. And yes, I'm an analyst. We love our four boxes. But this one makes sense and has been sticky and has had traction over the years that I've been working on it. For one thing, it actually explains the frequently heard lament. We spend 75% of the IT dollar just to keep the lights on. And this is why I thought it was always a little unfair to say infrastructure engineering is just keeping the lights on, but it is further from the customer. And so it gets lumped in with operations is also your infrastructure choices are tremendously important as to the day two operability of your system. But now everything's changing. We see with infrastructure is code, for example, that an application development team can write a chef recipe or a terraform template and the cloud hyperskyler says, Well, we don't care who writes it. And so it narrows the domain of action for the traditional infrastructure engineer. Similarly, and not what I did there, it's no longer application development, it's product teams, it's digital product management and product teams encroach, not all the way to the right, but they certainly encroach on your traditional tier two with the U build that you run at mindset. And in the tier one, while we're trying to turn tier one into tier zero and make itself serve an autonomous and automate it as much as possible. And so you see a narrowing of the traditional day two conversation as well, and an endgame where it's no longer 75% to keep the lights on, but more like a 50 50, maybe even a 60 40. I do think, however, that you need the remainder of the I and O world because there's still a platform problem. And there is also a skills problem. This skeptical, this is my generic skeptical dude, photo, and skeptical dude here is standing in for about half a dozen senior vice presidents of infrastructure and operations that I've had inquiries with lately, and they all say the same thing, literally in the same words, Charlie, I don't have enough DBAs to go around because they're what the and what does that mean? Well, they're responding to the idea that the product teams are heterogeneous and have all the skills they need to meet to get the job done. And the reality is, is that there are specialist skills. And there aren't enough DBAs or network engineers or security engineers or architects, so that every product team can have one. And how we solve this problem, I think, is right at the bleeding edge of the DevOps and digital transformation problem. Because ultimately, we can say that product teams are autonomous, but nobody is truly autonomous. This young individual here, where did their clothes come from? Where did the lantern come from? You know, they may appear to be autonomous, perhaps they're on a outtending the flocks or just camping. But ultimately, you have to have a supporting infrastructure, which leads us to a second iteration of the DevOps figure eight here, where we are at pains to point out that the enterprise shared services support the DevOps team in its continual journey of discovery. And then notice also the nuance that there is a small figure eight there on every one of those green boxes. Now, this is a nuanced conversation. The velocities of discovery, the variability of the problem is not the same. No, legal is not writing a lot of software and pumping it through a DevOps pipeline, although they may need some software written on their behalf. The broader point is, is that everybody is engaged in a continuous improvement effort. Everybody is managing, if they're truly managing their offering as a product, they are constantly looking for ways to optimize it. And folks, this is not a new radical conversation. This goes all the way back to Deming. And of course, the great thinkers like Deming were highly influential on the thought leaders who really were driving DevOps back in the day. If you look at the intellectual influences that some of the DevOps thought leaders were referring to when they started pushing hard for DevOps. So, you know, there really is nothing new under the sun here. And yet it is a difference of focus in the operating model. Ultimately, and I don't have time to go into a lot of depth on this diagram, we see the self organizing DevOps teams in the center, we see them held accountable to a set of capabilities up top of value stream management and so forth. We see them supported by platforms on the bottom. Cloud should appear there. I need to get cloud in there in the next version of the diagram. It's conspicuous by its absence. And then we have a set of coordination services that are framed as with a bit more optionality than in previous operating models because we know that at some levels of the teams when they're just in an experimental emergent phase, they don't need major incident management. They're not important enough that they think goes wrong. It's a major incident. They might not even need change management because they're still experimenting. They're still iterating. But at a certain point a scale those coordination services on the right become essential. You have to have some way to discover services, whether at the human to human level with a service catalog or at the machine to machine level with an API catalog, I view it as kind of the same problem. And you need to have, you know, some ability to route work and make and ensure coordination. A critically important aspect of this is the concept of the platform team. The platform team is the future of the infrastructure and operations organization. You still need teams that are there to reduce the cognitive load on more business focused teams. And it doesn't mean that the platform team is necessarily running its own compute infrastructure. But you have to have somebody who is curating and putting in recommended standards and practices for what bits of Amazon and Azure do you want to use? You know, there are dozens of variations on compute and storage. And, you know, you look at the overall panoply of offerings from a cloud hyperscaler, you're bewildered. And if you allow every team to simply choose what seems best to them, you're going to run into staffing and security and attack surface issues very quickly. So there is still plenty to do for platform teams, even if the data center is no longer yours. And in fact, Amazon makes it easy to actually plug their catalog into a commercial service catalog framework like ServiceNow. There have been, you know, there's ongoing interaction between those two players in part because of this problem, because of the need to manage those services within the enterprise. Ultimately, though, I do want to emphasize that transforming your infrastructure team to platform team, beware of platform washing. You simply you don't take those six DBAs or six CIS admins and say, hey, you're a platform team now. There is an implication of automation. There's an implication of product thinking that has historically been unfamiliar to your infrastructure organization, which is one of the reasons that people tend to dread being told they need to use a shared service, whether we call it a platform service or something else. It's because we have fallen into what I call the default service model. I characterize it as first come, first served, media, sit down, shut up, take a number, wait your turn, unless you get your boss to yell at my boss. That's a, you know, first come, first serve mediated by escalation, and at least to gridlock. And it's a terrible service approach. We need to start moving beyond that default operating model because it still results, even when you've got, you know, internal or external cloud, we still hear stories of it takes six months to get a server because it's not about the technology. It's never been about the technology. It's been about the process. And so how do we start enabling these shared services teams to actually rise to the occasion of digital and agile transformation and move away from the traditional service manager mindset. Now there are leading thinkers in service management who have always emphasized the customer focus, the customer outcome, but the reality of service management in the majority of enterprises has become ticketing centric. It revolves around that ticket and some of the learned helplessness on both sides, you know, surrounding the ticketed workflow. And ticketing is never going to go away, but from the point of view of a service manager, we need to expand the thinking of the service manager into a true sense of product ownership, understanding that they have options ranging from APIs to managing a bench of expertise to in some cases saying my service is not the right answer for you. You do need to onboard your own DBA or security engineer or network engineer because you've got a business case to do that. But that's not the only option we have here for getting people the expertise they need. This slide, it's in particular unpacked basically into a whole research stream, it will unpack into its own presentation. So I regret not being able to go through and speak to every one of these examples here, but we are limited for time. I do want to emphasize that from a service as product owner perspective, you manage two cues. You manage the day to day business as usual, people present you with the inputs that you need, you provide the outputs that they're expecting. But there's another critically important cue that is not as well understood. It's the continuous improvement cue. It's the suggestion box. It's never, it's not a new idea, but it's an idea that we really need to elevate in our thinking about modern digital operating models. We need to think in terms of a continuous improvement, Cata, you know, and many of you are familiar with PDCA, Plan to Check Act or PDSA or Damaic. I prefer the Toyota Cata, but it's the same conversation that's been around since the 40s and before of continuous iteration to the desired condition and this doesn't change. This is what the service owner needs. I don't often use slides from specific vendors, but this one is excited me. It's made it into my standard deck now for a while. It shows the kind of analytics that are enabled when we bring services together into a common platform, a common infrastructure. We can start to identify the service hotspots, just the same way a hardware engineer might look at the hotspots on a storage array or in a networking or in a cache, the cache hits in a content delivery networking architecture or the hotspots in a routing tables. All of those hotspots are well-known technical concepts. Well, now we have the requirement to start managing the hotspots in the human to human work because we start to have consolidated workflow. It's no longer buried in shared email boxes and distributed workflows like Lotus Notes Domino and SharePoint. We start to centralize it and we can start to see where the human to human interactions are running hot. I think that this is absolutely a requirement for modern service professionals in a digitally transforming organization because that gives you the ability to watch for the queuing issues, to decide whether you're going to left shift your service as a product or right shift it into higher touch or both, or apply some of your classic lean solutions, making work visible, streamlining, better prioritization algorithms. All of these imply that there is some improvement, some demand for improvement. If you don't do at least one of these things, that's a de facto consensus to accept the cost and risk of delay. But at least it's a conscious decision instead of simply saying, well, the sys admins, the DBAs are just overloaded and it's just too bad. We've got to move beyond this if we're going to keep the overall IT operating model in sync with the demands of digital and IT transformation, which is where we're looking ahead to. We're looking ahead to greater power and strength of analytics to enable the digitally transforming organizations and keep those shared services responsive and performant and agile in their own support. I think all in all, it's a fascinating time to watch these industry dynamics and watch the actions of companies as they continue to evolve along these lines. With that, I think I have time just for one or two questions, but I'm scheduled to five after. It's one after. John, not sure, Steve, not sure about the moderation here. Is it back to Steve? Right, Charlie. It is. We're actually going to keep right on track. We've got a lot to get through. Thank you for being right on time. We're going to save that time and deal with the questions in the panel, which Dave is moderating. In the meantime, as ever, you've given us much to think about, Charlie. Thank you for being here today and sharing your thoughts. We'll see you on the panel. A warm round of applause for Charlie Betts, please. You have to imagine it, though, Charlie. It's all right. I'm hearing it in my mind. It feels good. That's great. Well, thank you very much. Okay, we'll see you on the panel.