 Wow, Jean, thanks so much for coming out to San Francisco for the open group event. And we've been talking to each other now for how long? Twelve years, I think. We met in 2004 at the ITS MEPH conference in Washington, D.C. Yeah. And it's funny how many of those themes about work intake, work prioritization, queuing, you know, how does IT show up in IT for IT? And I've been an admirer of your work for many, many years. In fact, your book, The Cobbers... Yeah. The Cobbers' Children, yeah. About architects, you know, in architecture. I think it was just a seminal book, and I'm so delighted to see so many of the concepts that you were proposing back then, now really being adopted and stew-wide in IT for IT. Yeah, oh, thank you. It's been an interesting journey, certainly. So what made, if you don't know what I'm asking, what made IT for IT, what caught your interest, and what made it seem so promising to you? What was the earliest indication for you? Well, they were clearly going down a similar route, and I'd actually had some indirect influence on it that I did not realize. It's a long story, but the people who were working on IT for IT were also aware of my work and had the book about how to use tools like value streams, value stream mapping in understanding digital delivery, but certainly when I looked at what they'd done and I looked at the value stream approach, I thought it was more compelling than what I had done. I mean, I still believe that, I mean, I had taken a value stream approach with law and life cycles. I said, well, we've got an asset life cycle, a tech product life cycle, a service life cycle. And I still think there's merit in thinking about it that way. But when I saw what Lars Ronson and team had done with strategy portfolio, requirement to deploy, request to fulfill the technical record, I said, well, that's also an orthogonal and very compelling way of understanding the different domains of practice we have. And it makes sense and it's held up. I mean, I'm very critical. I look at stuff like that. I'm like, okay, can I disprove that? You know, because that's all it takes is one point of disproof. I've not yet seen the point of disproof on those value streams. One of the Zen paradoxes for me, if I can use that word, in doing IT for IT and also being very interested in tracking the agile and related DevOps progress over the years, has been the ideas of standards, frameworks, bodies of knowledge. They're not that well regarded in certain segments of the agile community. And, you know, I kind of just deal with that contradiction on a daily basis. And I look at, you know, things like skilled agile framework and some of the controversies that have swirled around it. And so I find it exciting. And it was totally, I guess, it's interesting to me that there's so many people from the ITIL and CSRS-Mantlin community as part of this effort. And, you know, what a better group of people to be able to say, all right, here's a larger world to operate in than sort of classical IT service management. Yeah, and I guess, you know, to maybe directly answer your question about like, you know, there are certain segments, you know, in DevOps, in the agile that are, I think, very hostile towards training, certification standards. They came to the world of rational, unified process and all that. I guess I think they're a minority and I think the rest are, you know, as mentioned really today, it's like they have more than one job left to go, right? They have sometimes deep feelings about what do I need to do to stay relevant and they have a vague feeling that automation and DevOps and agile have something to do with it. Boy, any place where we can be much more explicit about your guidance, your stuff to learn, that's hugely valuable. You know, what excites me about being here today is, you know, you and I have shared or, you know, have told our share of architect jokes. And I've long believed that, you know, architecture has been over-delegated and that, you know, some of the biggest sins of how we manage technologies to happen because, you know, we've totally ignored the architectural function and I guess one of my biggest learnings is, I'm actually a little rough-lord. He was a CIO for HP, later HPE, a Fortune 20 company, and, you know, he said, you know, what we need is buoys, not boundaries, right? So it's kind of using the river channel metaphor. So the days of like mandatory practices, mandatory processes, mandatory tools, I think those days are over that it's really about an internal marketplace of ideas. But on the other hand, the goal is, how do you maximize developer productivity by giving them these very safe channels to go down and also give them permission to strap sounds outside the channel and, you know, even saying, you know, you understand the business objective better than anybody if that's what you need to do it. And that might be the next source of innovation that we have to integrate into our enterprise architecture. Yeah, no, that makes perfect sense. I think that architecture, it will not go away. You know, there's still a need for it. As you say, it's Chief Architects who are coming to the DevOps Enterprise Summit, which was one of the really surprising findings. I mean, I think there's actually hope here. Yeah, probably just to clarify this, I talk to these people that, I mean, so what are the, in my mind, the words that come to my mind when I think of Chief Architects? They're global thinkers, not local thinkers, right? They tend to be more abstract than concrete. And I actually tend to be global abstract. So these are, so no wonder they're seeing kind of a need for these problems that are absolutely intended problems. So I think you have to say, well, what is architecture trying to do and, you know, what are the value drivers? How do you quantify it better? I've been putting some thoughts together and I think it still is a challenge for the architecture community. You saw a little bit today on how I look at quantifying the value of just limiting the technology portfolio, which is only one small part of what architects do. But yet, you know, vendor diversity, platform diversity, that's a problem, that's a cost. One of the things you also have observed is that developers are compensated financially and in terms of the experience you give them. You can call a resume padding, and I used that term earlier today, but the thing is it's legitimate because at the end of the day, you kind of be able to hire top-tier talent if all you're running is cobalt and you have to pay an economic cost for making decisions like that. Yeah, I'd love that presentation from earlier today from the Simple Learn. The CEO of AT&T saying, you know, we need every engineer to spend five to ten hours a week learning new skills and I thought that was actually, you know, that seemed compelling on so many different reasons, right? You have to stay relevant, you have to accept that we are all lifelong learners. So yeah, I think many people would agree including the CEO of AT&T is like, if you want to stay in the game, that's the amount of time you need to invest. Well, Gene, as always, it's been a real pleasure, great to spend time with you and hopefully we'll do something like this again sooner than later. Absolutely, and again, I learned a lot today and thanks for having me and look forward to working with you here. Yeah, thank you.