 Welcome to this IT for IT track, which is all about managing the business of IT So we're going to talk about or zoom into IT management. My name is Rob Akershoek I'm the chair of the IT for IT forum and Since the introduction of the IT for IT reference architecture We see a lot of interest in it and and that's not surprising Considering all the challenges that most IT organizations are facing today Just think about it. We have to deliver faster and reduce the cost eliminate risks and at the same time Improved transparency and traceability in the IT function But more important gift the business control over the outcome on IT and at the same time if you heard this morning We have to create implement new ways of working such as continuous delivery Agile development DevOps just to mention a few now most IT organizations realize that they need to fundamentally change the way They run and manage their IT and that they need to transform to enable the digital enterprise and now The good news is that IT for IT the IT for IT reference architecture provides you the guidance to to implement that journey and to modernize your IT function This afternoon we will have three presentations on IT for IT, but we start over the panel discussion So I'm very glad that we have all the keynote speakers from this morning available on the panel It's a little bit hot here, but I guess we will survive So I would like to welcome you. So it's very nice being here. So Charles Betts Active member of the IT for IT forum got Jean Kim. Well, we don't need to further introduction. We all have the book lying around here Bernard Golden and David Weebel and David Cannon. Thank you for being here. It's a pleasure But we also got some additional IT for IT specialist in the room that potentially if the if the debate allows We will have some further discussion so Mike Fulton from nation night our Vice president of the IT for IT forum of vice chair. I must say and we got also Lars is Lars in the room It's not there Mark Butler from service now potentially also we will ask some questions and zoom into that Okay Now the format for this afternoon is we have identified the number of themes we'd like to discuss and we have organized some questions around that and So one of the key topics is an a start with that is automation of the IT organization so that's one of the topics and the role of architecture within the IT organization specifically IT management architecture We're going to talk about DevOps and what does that mean for your IT operations IT function the way we organize things and Potentially if the times allows we have some relationships with transforming the IT organization getting the business IT more together That's also one of the topics of this morning's presentation now the format is we will ask some of the questions and At the end of each theme we have the possibility for you to ask additional questions So just raise your hand and I will give you a microphone We have to looking at the number of people on the stage. We have to look at the timing as well So let's see if how much interaction with the audience we can get but feel free to After his item to jump in. Okay. Thanks So let me start with the first theme. That's about automation. So Now I understand DevOps is all about culture and People but I still want to talk about tools as if I was okay with you because we still see that automation of IT activities is a key activity within the IT function and But if you look at how done IT is managed today, so you see a lot of manual activities still and a lot of spreadsheets. So what we interested in is If you how important this for you gene specifically how important do you think is Automating your IT activities across the value stream and the different value chains How important is automation because you mentioned in your presentation as well if you don't automate for example test Maybe also deployment monitoring you're building legacy from the start So would like to get your opinion on automation and importance in the value streams Yeah, I think what the study show is you know quite conclusive. I mean, there's really three Factors needed to get these amazing outcomes now that we talked about one is architecture, right enable loosely a couple You know something something sufficiently lucid couple to enable Small teams to independently develop test and deploy value to the customer. That's one number two is technical practices, right? So that's broadly speaking now would probably include automation whether it's testing deployment environment creation and so forth and then third is cultural norms and You know it is like a After top my head the top seven things that predict performance our version control Automated testing high-test cultural norms production monitoring Something else right deployment automation require automation to some degree. So it's extremely important, but certainly not It's necessary, but not sufficient, right? And maybe related to that there is a some organizations They say our strategy is to automate everything as maybe for Benar for you because Organizations that move to the cloud typically have the ability to do that from the start So how do you see is there is a good strategy to say we automate everything from the from day one? Well day one if you introduce a new application in the cloud for example, I think for sure If you say oh, yeah, I'm going to use that was bang cloud provider And I'm going to use the same kind of processes. I've had a long you're probably not going to have optimal outcomes and You may have actually I have worse outcomes because as I mentioned my presentation You know Amazon's number one rule is everything fails all the time So the assumption is the underlying infrastructure is not as is is not resilient You have to figure out how to put that into your application Not assume it from the infrastructure, which is the traditional Assumptions been I put in a server and it runs forever and anytime it breaks down It's like well that was an exception to the thing rather than the rule So if you say I've got to figure out how to put resilience into the application that means I'm going to be repeatedly doing things I've got to automate it so I think you have to do that if you want to get the value otherwise you just sort of You know you've bought you've started to use something That's really great But shoved it in that you know It's like buying a brand-new huge engine and putting it into an old beat-up jalopy and then going how come I can't run The Nuremberg ring as fast as BMW does well Because you haven't got the whole car Okay, thank you, and then Charlie related to it. How do you think it for IT can help you enabling what was just discussed the Automation across the value stream. How important is it for IT for that? Well, let me just Briefly address what was pre some of the previous as well. I think one of the most interesting Works on automating all the things is the Google site reliability engineering work. There's a book by a Riley An O'Reilly book at a Betsy Byer edited it and they go into details on what Google thinks should be automated and should not be They've got a whole set of criteria as to when they choose to automate And so there's actually a taxonomy and a whole decision processing to go through in general high variability work that is performed And frequently not a great candidate for automation You have to think about it in terms of those kinds of you know Spectrum issues. Can you just share one story that I just thought was so provocative So, you know the chaos monkey is very sexy, right? It's like oh my gosh They're randomly rebooting servers at one of the most interesting stories I got from one of the reviewers was this problem they have right the biggest problem They have is they can't patch servers because they're afraid that it will never come back up again So what they did was now they basically emailed everybody and said I'm going to reboot your servers sometime this week You know in about a month get ready Right, and they had to show the meantime to finish rebooting went from days to hours to minutes Just by announcing that we're gonna reboot servers sometime right and suddenly our ability to patch You know our confidence to do that went through the roof and I just love it because it's so pedestrian It's so fundamental and yet You know we still love the servers that haven't been rebooted for eight years, right? Yeah, that's exactly behavior. We don't want in mission critical refinery say right Forced them to think about these kind of things up front right Yeah but to your question so Automation is an interesting concept and Part of the problem is is that a lot of the automation that we've been talking about especially like with Bernard and so on is Kind of I consider it kind of under the line of it for it You're getting down into you know API level things and it for it. He doesn't really play there I T for it is more about human to machine human to human automation as opposed to machine to machine automation And I could probably go down a rabbit hole that I don't think we want to go down right now on that one Yeah, but for example, you mean to enter and trace ability if there's a new thing in backlog Some people modify the code is bill test deployed to enter and change you can bring the data together across the value streams Yeah, not necessary only automation is more providing the inside and getting the data link to each other Yeah, and I think right he kind of operates at a metal level with some of the R2F stuff It just says you should have an API you should have a process But boy to specify all those will be be starting with what Bernard showed for the Amazon services and blowing that out I mean, that's not it for it's intent So Dave cannon for you you talked about business strategy and IT strategy Have you seen a place where on the board where you talk about strategy also it management strategy is discussed So for example, typically the CIOs or you see executive level They're not interested in the tools or the automation we use do you see that as a topic if automation is important Would that be something that you will discuss more strategically as well? I don't know that I've seen that many discussions on the board around this Quite frankly, I think most boards don't really care how you do it They really care that you're doing it as cost effectively and as consistently as possible And then to that end obviously automation is something that a CIO would be Wanting to get behind the the question though is to automate something you really have to understand it and That's that's one of the issues not only do you have to understand it But it has to be so repeatable and so frequent within the organization exactly Yeah, that means maybe you need to rethink the way you organize your work, right? And so I don't see the legacy process be automated those discussions around managing IT Don't tend to happen at board level. I I'll give you a kind of example that I find very inspiring Richard Fairbanks the CEO of capital one has gone on record saying numerous times now in order for us to win in the marketplace We are building a world-class technology organization All right, the CEO of ING Bank same thing and so you know these are organizations have 8,000 10,000 I'll come engineers dev test off security people. And so I think that's a declaration, right? You would imagine indeed if the business says our strategy is that IT is part of our business They they need to think about how they manage that right the underlying way of working and and then it is a question Is there a need to standardize that way of working before we can automate? But do you see that practice happening? Well, we see it happening more on the front end You were to ask our boards discussing how they can automate Interactions with customers absolutely Are they discussing? What do we do in the back office to make our IT more cost efficient? I'm not sure. Yeah But it is at the front end Suddenly you need to manage that as a business capability potentially Meaning you need to think about how you manage IT across the life cycle So potentially then the IT management discussion will come back in the strategy This may seem like a minor thing But you know when we came out with the Phoenix project, we actually changed one word It was a in fact, I've know I've changed my talk titles I've changed all references IT to technology It's almost like IT is like MIS and it's like how I get my new laptops But you know, it's like you say it's about world-class technology organizations I mean it's a has a different context about you know how quickly can I get my laptop from the help desk Maybe a question for you David. Sorry. Sorry. Yeah, I want you raised something you said help desk So that raised raised something for me in terms of technology Everyone knows I told people yeah, we'll never give up the help desk. That's all I care about We've known each other for a long time What's interesting about help desk is exactly what you're saying the trend in help desk now is to is to move from break fix to being more of business support and So for example When when a user calls you and says I need something from you technology Used to be I need you to fix this Increasingly, it's you know, I'm trying to use this to do that Am I doing it the best way? Do you know of some app or some technology that can do it better? And this really started to come to the fore when we started talking about genius bars and concierge bars Something that most organizations were not prepared for they thought it would be a walk-in break fix Instead it became a tech advisory center And I that's a really good example of where Where the technologists are getting engaged in the front lines of business Now again, it doesn't necessarily translate into what I automated in the back office So But it's partly maybe self-service self-help to do business And then if they really have a question that is rooted not to a service desk But rooted to the person against answer that question immediately. We're right This is what you're doing through automation what you're doing is you're taking the routine activities You're taking the things that are easy to handle the things that are well understood. You're commoditizing them Automating them so that your technical staff can focus on the really high value activities of What it takes to make this business competitive and and run better than anything No question for David David people So one of the challenges we see with a lot of art IT organization. They're going to source IT services to a number of vendors So we have a multi vendor ecosystem each using their own processes their own tools their own terminology and the own way of working So what do you see as an opportunity to have better interoperability between all these vendors by having a standard such as it for it Such as defining how you can integrate and interoperate with multiple vendors across the value chain So how do you see that? No, it's relevant from us every organization. I talked to at the moment They've gone from the stage of just using internal services now to integrating internal and external services as Architects has also become more granular with microservices You're actually getting the situation where you want those individual teams to use the best tools Available to manage the product that they are responsible for So there has to be an integration layer now What that means in terms of some of the tools and some of the interactions we're going from Effectively build time complexity to run time complexity Therefore how you understand what is happening live in the production environment with all the interactions and integrations becomes important so standards and common language Then allow you to be able to effectively and efficiently to be that run time integrator of all these Disperate services you're going to consume, but I wouldn't say it's just multi supplier It's actually treating the internal IT in the same way So if you have a product team that's responsible for a particular set of microservices Then they are treated in the same way as the external vendor Right, but you could see that currently if you consume market services each vendor and there's a probably a question for you Benar is that each of the vendors like Amazon and Azure they Provide management tools with them and management APIs and management capabilities But in a sense their propriety because they're linked to their capabilities Do how do you see that in the future is there a more need to that I can consume market services using standards Or will you always have the each vendor competing with their own APIs to deliver that specific service day? Well So there's it's not that there's a sense that they're proprietary. They are proprietary There's no question and they tune those to deliver as much value as they can for their particular center services Which are you know unique to them? Well, let me ask you your question in a different way. I was Approached by a company that said we would like you to come join us and help define a standard for APIs and management of these of cloud providers And we want you to work with the cloud providers to put this together And so that we can deliver value to you know end users and all that I said well That's fine, but that would be like pushing on a rope because While you might like it the cloud providers. There's there's nothing You know there maybe there's a sort of a patriotic kind of yeah, that would be great to do But there's no practical value for them and if anything they see it as sort of interfering with their ability to innovate so You know thank my reaction was thanks, but no thanks I don't want to I don't want a job where basically I knock on doors people saying get out of here, so I Think it's quite challenging and I've been at two companies that that was basically our value process We're gonna figure out a way to you know provide a homogenous layer across heterogeneous stuff to make it better for it And the the thing that we kept breaking our pick on was We were not able to expose enough of the Functionality that those providers offered and we ended up with the lowest common denominator You get order a virtual machine in a database right that's everybody has that but then you can build up on top of that Or you really leverage their serverless computing, which is different for I think that's you know a dilemma that there is no convenient solution for Unfortunately Closing down the topic of automation. Is there any additional question from the audience or maybe Mike additional comments on this? Science I think he wrote a book on it It's a really interesting So I'm familiar I wouldn't say that I've studied the disciplines But I'm actually familiar with the question and it's been preoccupying my mind for the last ten years or so It and digital is primarily R&D software is thought that's straight from Alistair Coburn And so as thought it is an R&D process and when you try to mix too much Production engineering thinking into it you get into dead ends like the capability maturity model Which was based on the premise of statistical process control for software development And I think has been resoundingly rejected by history So that's not to say we can't learn don't shoot Yeah, I'm sorry, you know On the other hand are the things we can learn from production thinking and production engineering that absolutely has come into the digital movement Via lean and DevOps via the work for example The gene is done bringing in the perspectives of Eli Goldrat into the DevOps production pipeline But you have to be very very clear on your variability domains When you go looking at the high variability development and R&D processes Well, Don Reinertson He loves to tell the story of the Lean Six Sigma engineers in there pestering the research and development engineers Saying oh well the problem that your R&D program has is that your engineers are putting their staplers in Inconsistent places on their desktops And so we're going to solve the R&D problems by putting tape around where they should put their stapler to story it happened So 50% increase in productivity And then there was the guy who wanted a banana on his desk for half the day and that took a week to resolve You know, so I'm sorry if that you know, it's a really interesting conversation Yeah, what I love about it was I mean you made a very I would say almost like an isomorphic mapping between Bill of materials and routings and loadings and you know lead times and I just I remember being just dazzled by that in terms of You know, how would you run? Part of the value stream in that kind of mechanistic world, and I think testing and operations is very much that it is But I mean there's a value for like how do you go from if you measure lead time by how quickly can you go from a requirement? To a feature to what there's so much value to be gained there, right? Just because even where there is variability, but it's a variable process and at the risk of and I'll shut up And you can like not call me for a little bit But one of the seminal moments in the creation of scrum and there's a story there a lot of people know about Sutherland Getting getting involved with no knocker and the lean product paradigm people will say that's where scrum came from But the other half of it was Ken Schwabber's experience as a depart Where he came in as a consultant with I think it was Ernst and Young or Deloitte One of those and yet they had the big methodology like at Accenture We had the business integration methodology and he ran into some real process control engineers Including a guy named Boba Tunde Oganeki who wrote one of the definitive texts in the field you're talking about and What what Schwabber said the quote is epic rarely have I provided a group with so much hilarity Because he came in with this flowchart of how they were going to do software development and these real process control engineers said you are engaged in pseudoscience You know there is no way that you can apply our techniques of process control to such a variable process The only process control mechanism that will work is empirical process control And so that's the great historical narrative CMM trying statistical process control scrum ultimately triumphing in the market with empirical process control That's where we are historically I'll be quiet and you can not call on me now for that Yeah, let's do that. I changed microphone here We want to talk about architecture so that the next topic specifically IT management architecture Now let me set the scene most larger IT organizations. They don't have a vision or a strategy for IT management, right? They have different tool tools in place for the same function or they let development people select their own development tools and Operations operations tools and you can imagine. There's a whole set of processes tools Repository spreadsheets custom-built solution and so on now one of the key challenges that we face is how do we do it one? Do we want to standardize that and how do you create that standardization of process and tools within the IT organization? So I want to start with David we've all about this specifically you mentioned service architecture So what is your idea and opinion that and how can we leverage that? architecture for IT management. I think it's an area that needs more development. That's certainly there I suppose it's difficult to say one of the challenges I have a lot of IT management software at the moment is Fundamentally, it's fairly basic to be honest There's been automation done in lots of ways, but we don't actually exploit the technology we use for business into IT management So taking the favorite service desk help desk ticketing system It really hasn't moved much on for you on the paper system It really is about moving bits of paper around if it ever goes wrong You could fundamentally replace it with paper and it'll be slower, but that's all so one of the challenges I think for this sort of new world as we get more complex architectures and we have these much greater digital interactions is actually understanding the better ways of managing and governing and operating the software that we are deploying and actually starting to use Those technologies that are coming out now that allows to do that better So using AI using the changes in some of the other technologies that we can actually build out So a lot more understanding of the environment built-in a lot more causality actions and so on so using machine learning to To pick up patterns. That's where I think the that has to go And we have to start really thinking that there is a value in that management IT Yeah, so I think people recognize the value but there's further question for Jean about this But how do you do you think how important is IT management architecture for the IT function? Or do you leave each development or agile team select their own source code system tests? Oh God help us. No The room for improvement is so so vast Maybe just to characterize it as much as I love making fun of architects and I would aspire to be an architect in a different life It's been such an overly delegated function, right? I mean like one of the key learnings for me what I was trying to get across in the Etsy example with that Sprouter is that like how can you make organizational design decisions without first incorporating the architectural? Implications and for me I just think about like there's certain industries like hospitality where they still routinely outsourced development to one group Outsource tests to another outsource ops to another group and then information security to it to you another one Right that the theory is you know, they all keep each other accountable and so forth But I mean you talk about in a world where speed matters more than cost, right? I you cannot come up with a worse configuration to get anything done, right and so, you know anything we can do to arm Executives and IT management was like, you know, here's how we organize and think about flow in this new world you know Who's gonna help them if not the architects Yeah, so so you can't mention that you basically need an IT manager to guide that value-stream implementation process and tools but Can I tell a funny story just I mean this is tragic, but hopefully you'll see the Comedy in it. Yeah, yeah a friend of mine. He's like an IT director in a large hotel chain and You know, there's three in this hotel like this There are three Wi-Fi networks is the guest Wi-Fi events Wi-Fi and then there's probably corporate Wi-Fi, right? where all the back office systems are and Some bean counter said you know what we have three network switches Let's put them all in one right, you know better accountability, you know better cost control better support contracts Whatever what they didn't realize was each one of those three network switches had three different outsources on it So they put them all in one switch and within days They were locking each other out of the accounts to one day like the link between the point-of-sale systems in the restaurants And the ERP systems broke and no one would accept responsibility for it It went out for four weeks went to the CEO of a multi-billion-dollar hotel organization for CEOs multi-billion outsourcers And you know no one admitted failure for that But I just we took a simple working system where there was no interaction and for whatever reason Management and architects, you know, we allowed ourselves again those situations where now you had everything that was talked about can need to communicate coordinate prioritize whatever and and you know do a denial service on everybody it's just Does anyone think that's a little bit funny? I mean like terrible. I mean Does that resonate with any stories in your own history? I think I stayed in that hotel. Yeah, right. I Find that so mad news like we can help management make better decisions But in a way, I'm sorry In a way, isn't that sort of the appraisee of The entire DevOps continuous integration continuous one in that you take stuff that formerly could be done in a very asynchronous You know disconnected thing you say no now It's all got to be integrated and and aligned and that means groups that used to be able to go I don't know anything about those guys, but I do my own thing I do it really well, and I'm you know, I'm proud of what I do and also you say no now you have to coordinate with that other group you used to never have to talk to except the Christmas party and There all of a sudden your your stuff And even more challenging is that you go and by the way, you're gonna be mutually measured So that's sort of in a way the But the I won't say about the hotel But the value of doing that is manifest in that you go from months to do something to weeks or days Which has tremendous outcomes, but it requires a lot more Coordination and I love it just because in my mind if we took something that was simple and working and we turned it complex Right and tightly coupled so we tried to optimize for cost and we got not cost and not speed We got everything want to work bad, right? So I Will be happy when an architect should would have smited, you know, everyone who came up with that idea a Question for David cannon so you talked about portfolio and you managing your service portfolio You can imagine if we move to the cloud people can say I want a mongo database or Everybody can select their own services And I would like to think about a similar thing as it management people can say I need this automation tool Or I need this test tool for my capability. How would you be able to because? Ownership and investing in that you manage tools challenge who takes the decision who pays for it So how do you think you would manage the portfolio of it management solutions in the company like Why would it management tools be in a portfolio Separate from every other activity that we as technical professionals do Yeah, it should be in the same portfolio. Yeah, it's a solution. I don't see them as being a separate entity in a portfolio I see them as being a component of what of a capability that enables us to provide certain activities that Deliver value to the company. That's how I would see it And most organizations don't manage it management tooling as a portfolio So they have different ownerships in the in the company So it's very difficult to take decisions on for example, somebody said we need to automate appointment Right, so let me go let me go back to the let me go back to your initial question Which is who should architect the role of the IT manager and the management activities? The day that we in this room agree what an IT manager is Maybe we can start architecting that Right now we do not have an industry agreement of what a technical management Professional is and what they do and how they do it We have a lot of theories. We have a lot of frameworks. Some of them official. Some of them not Some of them proprietary some of them not and we as an industry do not agree on what those are And so Difficult to architect something when there's so much disagreement amongst the practitioners of that something That's my first statement and then to come back to where in the portfolio Do we put IT management tools? Where would you put your assembly line Shop floor operation shop floor operations. Yeah, I mean it's the same kind of question It's an internal capability that we have that somebody needs to manage Somehow we don't plan for this Yeah, it's I Don't know a problem putting in my portfolio. I managed that portfolio You know and there was a marketing portfolio And there was a retail banking portfolio and a wholesale banking portfolio and there was a smaller portfolios for legal and communications and HR They all have their lead architects and then there was a business of IT architect and I think that shell Carl I think you were that guy at shell, you know, it's not that unusual It's it's at scale the digital management systems are a non-trivial batch of functionality and investment It's just arbitrary. I mean dividing up a portfolio is kind of an arbitrary thing, you know This is probably obvious to everybody but me but I was shadowing the folks that rally now They're not part of CA and I got to the goal was I was gonna watch them do a deployment and I remember asking true and ready. He was a VP of R&D and VP of operations at the time And I asked, you know, do you use a ticketing system? Which ticketing system do you use and I said, oh, we don't have a ticketing system, you know coming from an Offsback, I'm like, well, she don't have a ticketing system. It was like, you know, write anything down and and it's I was part of that It took me days to realize. Oh No, no, no, they have a ticketing system But if they're using the same backlog management ticketing as development, right and You know, I guess in that moment. It was just dazzling to me. It's like, oh, they have a single backlog of work They have one place you can prioritize, you know, they can actually when they have live site incidents, you know all all active work goes into, you know Not work, right? So everybody could work on the issue. And so I think One of the common denominators of many of the organizations coming on DevOps Enterprise Summit is, you know This notion of like, how do we agree on a single intake of work, right? And I thought that was They said it was probably so important, especially when you Have to balance the technical debt reduction, you have to see all the failure demand And it has to be in a way that development is going to digest Standardize at least on the way you manage work like backlogs could be an instant problem There are stories where you have a single backlog where all the teams can work on And the failure is visible to everybody in the value stream, right? I'm still a little puzzled by your question as to why you would need an IT management tool portfolio. Well, let me explain If you look at a larger IT organization I was working for Shell, the investment in IT management and security is a lot is large, right? And typically there was not a single owner for IT management tooling and processes So what every team does they select their own tools or build and share one side to manage backlog So before you know it, there is a sort of everybody does it their own way with their own set of tools with their own set of processes These challenges, how do you standardize the way of working standardize your tools without your ownership in the IT organization and manage that as a portfolio. Oh Can I add it to the previous story? So actually there's a gentleman from HPE. His name is Tomer Gershone. He's responsible for security for all of the HPE online services Including fortify and all that stuff and he said, you know The biggest change that we've made over the last couple years is you know We used to put everything in a GRC tool, right security phone a security tool, right? And he said, you know, we realized, you know, it might as well go to die there, right? It will no one will act on it has to be in Jira or something where the developers are looking at if it's not in there It will never get fixed and I thought that was just a in my mind It's another sort of radical reorientation of where our work systems are. Yeah I mean right now and you've illustrated this so well in Phoenix project project gene Work arrives at the poor hapless individual in the standard old-school IT organization at least three different channels Fractional allocation to projects you're gonna be 20% on this 15% how I've spent 15% of my time in anything I don't know and then you got a ticketing system and Then you got stuff like John's massive 500 row 500 page Excel spreadsheet showing up via email Now to bring back to the operations question I mean you see a drill press or a CNC lathe on a shop floor Do you have people lining up at it from three different directions and then some expediter Resolving the conflicts right there at the point of production. No, they know how work is arriving to that to that work station And sure there are we need to be cautious about, you know manufacturing analogies But right now as you so well said IT has a lot to learn from classic manufacturing It's we're not ahead at all not when the demand is so fragmented and that is one of the outcomes of having fragmented tool portfolios There's no overall architecture no understanding of demand therefore too much work in process no flow Yeah We got we all got the t-shirt on that Conversation starts to go So my question for you is in the presentation this morning David and David you talked about the the need to differentiate between value creation for Those who are consuming things versus those who are producing things as We think about it for IT and we think about, you know some of the conversations. We just had you know And the standard and how we're going about looking at this problem Are we focusing on this too much from the producer's perspective as We look at optimizing an IT for IT tool portfolio Process should we be looking at optimizing it for the end-user for the consumers of these services not for the people who are producing them Yeah, and I think this was this was my my question earlier about what kind of portfolio trying to build You're trying to solve the problem of we have too many people using too many different tools It's a management issue that is not a value creation issue and So you want to map value creation and how that value is realized and returned It's a very different flow the very different analysis then we have 50 different groups using 50 different tools We need to get them all on the same page They're both part of that portfolio process, but I think they do different things They're both necessary and so if you look at the digital business Cycle you have two cycles one is how do we create more value? How do we create more features? Positive emotions good customer experiences and at the bottom end. How do we be more efficient? How do we deliver more quality? They're both very important But I agree with you. I think you have to start to the top one Which is what are we trying to what are we trying to deliver into the market? What makes us unique? What brings value and then go to the bottom and say how do we do it? It's a different question Yeah, I mean just following up on that if we look at what if we take a digital business scenario for there You don't start the traditional way, which is what business we in what products do we have what services you start more? So I saying what are we good at what can we expose as digital touch points? What ecosystems do we take part in what relationships do we have it? We can exploit in those ecosystems and you start designing that value for those sort of connections and those Ecosystems not for products and services and I did sort of hold back this morning with lots of conversation still very very product service focused and message We're trying to get across is now thinking of how the customer how the User of that actually incorporates that into an ecosystem and how they generate value by using that ecosystem But we're also talking about we cannot just deliver features for the customer We also make it manageable and make it so maybe 50% or maybe less is built features for the business or even experience or outcome The rest is making sure that we can run and maintain their services, right? So it's a balance we can focus on building outcome to the business But eventually those features we also need to build in monitoring need to build in resilience That's also work right management typically not a business value directly But if I take it again, one of the things you still see end-to-end service management where the Concepts is you own the end-to-end value chain and you can monitor it and you can measure it Again, what we're trying to say here is that you don't own the end-to-end value chain You don't actually know how the customer is constructing to get their outcome So therefore your your role in there is as much as getting the resilience of your component But you have to consider what the interactions are in the wider which you may not control anymore So the big change in mentality for for IT departments is for you know It's basically removing this boundary You don't have a wall around everything you control and in fact, you're not in control of it the customer is So how do you actually change your approach to recognize that including the management including the governance Including the operation where you don't where you're going to effectively hand over that control They're looking at the time with one minute left So I want to do a sort of closure here Imagine it's 13 years from now and you would look back at one of the things you would laugh about that how they manage IT today What will be different in? 2030 like what we did key new capabilities. What do you see different? So let me start with Charles. I Think having an understanding of the overall work. We will have a much better understanding of the work overall Being imposed on the or being being a directed to the IT capability as a whole and Jean I would guess I mean just Two to three order of improvement order of magnitude improvement in our productivity You know, how are we to find it in terms of our ability to go from idea to actually creating value for the customer? I? Think we'll be sitting there going I can't believe that we used to think that humans were gonna Design and run this as opposed to some AI system that basically keeps track of all this and gives us an optimized plan and executes it and We'll all sit around drinking my ties going one. That was that was that was a big waste of time that we used to do So I think the biggest change from us is just the Increased diversity of of these the technology so if we look at cloud now where it's going We're still at the only the first step. It's still relatively new We're only taking really the first steps if you start continuing to abstract What the concepts are and going further and further away as the functional type of architectures go? You're gonna see lots and lots more capability and as AI gets out there as internet of things You're just gonna see technology embedded in everything So when I look back and thinking now is is we really thought cloud was the next best thing Well, that's that was just the little step out the data center That's 13 years. Hmm. I think we're gonna see so much innovation But I think some of the things are still gonna be the same. I think you're still always gonna have technology people Focused on managing technology whatever form that takes and I think Things can be a different technology But there'll still be a lot of a technology focus in some groups Challenge will still be how do we overcome that the techno-centric view in favor of a bigger picture? I think it's 13 years. We're still not gonna have solved that one. And we'll still be using Visio Visio from my cold fingers Just a final question for you. What we're just thinking of what if the Phoenix project had IT for IT as a reference Architect how to run a modern IT function without help them in their journey Yeah, no, I think Is Charlie so astutely points out I mean so much of it was about work and take and to be able to normalize it against a common language Right say independent of what the work is for you know It's gonna flow through these work centers and you know needs to get prioritized scheduled executable So I mean that it would be a tremendous help troubles. It'd be a much smaller book Thank you very much for being a panel here