 But we're going to try to look at this a little differently during this last portion about where the most strength is, where some of the deficits are as a way of patting out and understanding what needs to be done. So a bit of a more practical, pragmatic approach to getting this more mature as fast as possible and make it most usable and applicable and beneficial to enterprises. So with that, you're familiar with the panel, but I'll go through them anyway just for the sake of for anyone that may have come in late. We're joined by Michael Fulton, he's principal architect at CC&C Solutions, Philippe Genest and a partner in Accenture, Sue Desiderio, the director of Price Warhouse, a director at Price Warhouse Coopers, Dwight David, enterprise architect, Hewlett Packard Enterprise, and Rob Akershoek, solution architect, IT for IT at Shell, IT International. So let me start with our panel and just go down the line. Philippe, tell me where you think the most progress has been made in terms of making this a mature reference architecture and where you think the most work is needed, at least from your slice and view on these. Most, okay, greatest level of maturity I think, that's a tough one. I think I like all the two innovations that we have in the IT for IT reference architecture, the service backbone and the R2F. I think we keep hammering on this message, but I think it's important for people to understand that these are the two greatest novelties of the reference architecture. Are they mature? I think they are mature enough, they'll probably evolve in their level of maturity. There are a number of areas that are maturing and some that we have in design. The IT financial management, for instance, is one that, again, I'm working on a little bit and the service costing within that, which I think will get a chance to get ready by version 2.1 and the idea is to have it as guidance into version 2.1. The value streams by themselves I think are also mature and almost complete. There are a number of improvements we can make to all of them, but I think overall the reference architecture is usable today, has an architecture to start with. Not quite for vendor certification, although that's upcoming. There are a number of good things and a number of implementations that would benefit from using the current IT for IT reference architecture version 2.0. Sue, also where do you see the most traction and growth and what would you like to see improved? I would say that I would agree with Philippe's statements. I would say, and also even picking up on what Lars had said earlier this morning, I do think it is an easier entry point to start with to detect a correct, which is often where we see it because it's maybe one of the value streams that's a little bit more known and understood, and so that's an easier point of entry for the whole IT for IT value chain compared to some of the other value streams. I think the service model is definitely, as we've stated all along, the backbone to the whole IT value chain, and although I think it is well formed in a good mature state, I think there's still plenty of work to do to really make that consumable to the IT organizations to really understand all the different phases of the life cycle, all the different data objects that make up the service backbone, and so that is something that we are currently working on for the 2.1 version so that we have better examples we can really show how it applies in a real IT organization and it's not just what's in the documentation today. And same to you, positive and negative? Well, I don't think it's about positive and negative in this case, but it's like some areas where we need to work on specifically is like the service broker role that you see in the IT organization, so interfacing with your suppliers. So we have identified a number of areas where we have touch point with the vendors, like if you have your catalog, you need to synchronize catalog information with the external vendors and aggregate the net in your own catalog, but also the fulfillment API of how do you communicate a request to your suppliers or different technology stacks and getting the consumption and cost data in. So that's an area that I think we define that, but we need to go lower level of detail is how do we actually integrate with the vendors and our service providers, I must say. So there's on many different levels, it's on the catalog level and the request fulfillment that you'd actually do provision seem to be the cost to consumption data and those kind of level. And another topic I think is still the linking into security and identity access management. It's an area where we still need to clearly identify, you have an identity or IT organization that has a subscription to a service. So the linking to that access management which is part of the subscription and of course the fulfillment. We didn't identify as a separate functional component. And to why were you most optimistic and where would you put more emphasis? Oh, I'll start with the latter. I think more emphasis needs to be really our approach to specifically to detect correct. Oftentimes I see people thinking about detect the correct as really in the traditional mode of being reactive as really as opposed to really understanding that this model can be applied even to the new change in user friendly type of economy and within the hybrid type of IT. So I think really a change in thinking in the application of the value streams really would also help us. I think many of us have a lot of gray hairs including myself. So we revert to the old way of thinking as opposed to the way we should be moving forward. So that's really I think the area that we can do the most. What I think is really good though is that a lot of people understand, detect the correct. So it's an easy adoption in terms of understanding the reference architecture. It's a good entry point to the IT for IT reference architecture. So that's where I see the actual benefit and I would also again encourage us to actually make it useful, use it, try it. The most benefit happens then. And Michael, same room for optimism and room for improvement. Yeah, I want to build on Dwight's point around trying it by sharing the one thing I'm most excited about, particularly this week and that's the management guide. And particularly very specifically chapter five of the management guide. I hope all of you got a chance to grab your copy of that. If you haven't, I recommend downloading it from the upper group website. That chapter is just absolutely rich in content about how to actually implement IT for IT. And I tip my hat to Rob who did a great piece of work along with several other people but it's just if you want to pick up this standard and use it, start there. Start with chapter five of the management guide and you may not need to go much further because that's just great content to work with. So I'm very excited about that. From a standpoint of where we need to continue to evolve and grow as a standard, we've referenced some of the individual pieces but at a higher level, I think the supporting activities in general really all still need to evolve and get to the level of detail that we have with the value streams. So that's a key area for me and then the next area that I would highlight and I know we're actively starting work on this is really around getting down to that level of detail where we can do data interoperability. Where we can start to outline the specifics that are needed to define APIs between the functional components in such a way that we can ultimately really bring us back to that open group vision of boundaryless information flow. And picking up on that when we finished our main panel in the plenary this morning just before lunch, one of the last points made was how do we bridge the divide between a cloud provider or a series of providers and have IT in a brokering role within the organization. But as the broker, they're going to be held responsible for the performance regardless of where those services originate and how they interoperate or not. So what do we see as needed in order to make that boundarylessness extend to this idea of a brokered IT organization, a hybrid organization, but still able to produce a common approach to support and quality of service across IT in that particular organization. So again, let's start on one end of the panel and work our way along. How do we get to that hybrid vision, Philippe? I think we'll get there step by step. I think there's a practical step that's implementable already today. My suggestion would be that every customer company that selects an outsourcer, that selects a cloud vendor, that selects a product, uses the IT for IT reference architecture in the RFP, putting a strong emphasis on the integration. We see a lot of RFPs that are silo-based still, which one is the best product for project and portfolio management, which one is the best service management tool. But it's not very frequent that we see the integration as being the top notch value measured in the RFP. So that would be one point, the discussions with vendors, again cloud vendors or outsourcers or consulting firms, should start from this, use it as an integration architecture, and tell us how you would do things based on these standardized concepts. So today that's a practical step that can be used or employed. I think in a second step, when we go forward or further into the vendor specification, there are vendors today or again when you analyze the products and the cloud offerings that are closer to the concepts we have in the reference architecture. Maybe not certified, maybe not the same terminology, but the concepts are there, or the way to the concepts is closer. And then ultimately, step three and three and a half will be product vendor certified, cloud service offering certified, and hopefully so full integration according to the RA, and eventually even plug and play. Maybe I'm dreaming a little bit about plug and play, but at least integration. And what sort of timeframe would you put on those steps? Is this a two-year process, a four-year process, too soon to tell? That's a tough one. I suppose the vendors should be responding to this one, but no, I think for the cloud service providers, it's a little bit trickier, but for the consulting firm, for the service providers, it should be what it takes to get the workforce trained and to get the concepts spread inside the organization. So I would say within six to 12 months, the critical mass should be there in these organizations. It's possible, stuff, but project by project, customer by customer, it's achievable. Vendors, I know some are on the way, and we've seen several vendors talk about IT for IT in this venue, in this conference. So I'm pretty sure that those have, you know, I know that those have significant efforts on the way and are preparing for vendor certification, and it will be probably a multi-year process to get the full suite of product certified because there's quite a lot to change in the underlying software, but progressively we should get there. So having first levels of certification within, I don't know, one to two years, possibly even sooner, and be interested in knowing what the vendor responses will be. Mm-hmm. Sue, along the same lines, what do you see needed in order to make the IT department able to exercise the responsibility of delivering IT across multiple players and multiple boundaries? Yeah, again, I think it's starting with the awareness and the open communication about IT for IT and on a specific instance, where does that fit in? So depending on the services we're getting from vendors, from whether it be even internal services that we're getting or across, really, where do they fit into the whole IT for IT framework? What functions are we getting? What are those key components within that? And, you know, kind of where our interface points are and really have those conversations up front in the contract conversations and whatnot. So that it's, you know, everyone's aware of what we're really trying to accomplish and that we really are trying to seek that seamless integration between, you know, ourselves and those suppliers. Mm-hmm. Rob, this would appear to be a buyer's market in terms of their ability to exercise some influence. If they go seeking RFPs, if there are a fewer cloud providers and there were general vendors in a traditional IT environment, they should be able to dictate this, don't you think? You mean who dictates it? I would, in the cloud world, I would say the consumer would not dictate at all. See, that's the traditional way that we dictate how an operator should provide us data. And so that's the problem with the cloud. We want a consumer standard service. So in that sense, we cannot tell the cloud vendor, you sent me your cost data in this format, right? That will not work because we don't want the cloud vendor to make something proprietary for us. So that's the first challenge. The cloud vendors are out there and we don't want to dictate. We're going to assume a standard service. So if they set up a catalog in their way, we have to adopt that. If they do the billing on their way, we have to adopt it or select another cloud vendor. So that's the only option you have. Select another vendor or adopt the management practices of the cloud vendor because otherwise we will continuously update, I have to update it according to our policy. So that's a key challenge. So that's why managing your cloud vendors is really about the entire value change. So you start with strategy to portfolio, thinking about what cloud services do I put in my offerings or my portfolio, I must say. So defining, let's say for past platforms, we use vendor A and for infrastructure service, vendor B. So that's where it starts. Which vendors do I engage with? And then going down to the request to fulfill, it's more like, okay, what are the products that we're allowed to order and how do we provision those? And unfortunately, the cloud vendors, they don't have IT for IT yet. Meaning we have to do some work, let's say, the same, how IT for IT defines it. Let's say we want to provision a cloud environment. We make sure that all the cloud resources we provision are linked to that subscription, linked to that service. So at least we know the components that the cloud vendor is managing, where it belongs to and which service is consuming that. So I'm gonna jump in on Dwight, I apologize Dwight. But to Rob's point, I think Rob has got a key point here around the expectations being different around cloud vendors. And that's why I think IT for IT is actually so powerful. A cloud vendor is not going to customize their interfaces for every single individual company. But we can hold cloud vendors accountable to an open industry standard like IT for IT, if we've detailed out the right levels of interoperability. And so to me, that's the way that this thing comes together long term, is through this open standard. And then through that RFP process, hold customer organizations holding their vendors accountable to delivering against that open standard. And I think in the world of cloud, I think that's actually to the benefit of the cloud providers as well. Yeah, I think that's a key point you make there, indeed. And even just to piggyback on what you're saying, it goes back to the value proposition. Why am I doing this, right? And if we have something that's an open standard, it enables velocity, you can identify costs much easier, it's simpler, so really it goes back again to the value proposition and showing really these cloud vendors that because of a standard, I am able to consume more of your service, I'm able to consume your service easier. And here, I'm guaranteed based on, because it's a standard, to get my value. So again, back to the value proposition, which the open standard offers. Great. A couple of other threads that we heard earlier today were the idea that this standard makes more sense at least now for large organizations and say startups or SMBs. And that automation is essential and that manual processes are a bug. How do you react to that? Is that wisdom and truth for you that automation is king and that this is designed for large, complex organizations? Again, we'll start on one side with Philippe. If it will be, sorry, it will be a lot, it will take more work for a large organization to deploy the full RA that it will be for a smaller organization. I think those organizations that today use a lot of dev ops practices, agile practices that are close to the concepts that we have service catalog, service backbone, should be able to get it straight very quickly as a matter of fact, including with vendor products and things that aren't necessarily fully certified, but at least for which the concepts are quite close to what we're recommending here. So the large organizations will have a different set of challenges, which is that there is a massive legacy that we need to transform along the concepts. So it's possible and we heard recommendation. Start with D2C or do it one way or another. But I would say that the smaller organizations can get it right by simplifying some of the implementations, getting the right tools that can move faster on two new tools. And I view it as two different challenges, but not necessarily in adapted for the smaller organizations. It's a set of very good practices that are implementable and the description is in the books, basically, that have just been published. The ones for which I see an extra challenge perhaps, or at least that I see today in the industry is the big outsourcers. You know, those long-term contracts, data center outsourcing, five years, networks, so on and so forth. Companies that use those should plan before their contract renegotiation, exactly what I said for the RFPs for vendor products. When you are planning a year ahead, two years ahead, even three years ahead to renegotiate your outsourcing contracts, again, introduce the reference architecture, use it as a bit of a benchmark for who you're gonna contract with. And if you know that you're gonna renegotiate with the same vendor, try and influence them enough that they can, you know, you can have these concepts and these architectures in place. Sue, how about this issue of automation? Is it essential to be largely automated to realize the full benefits of IT for IT, or is that more of a nice to have or a goal? How what's the relationship between a high degree of automation in your IT organization for the support of these activities and the standard reference architecture? Yeah, I definitely am a believer that automation is key, so we definitely have to get automation throughout the whole end-to-end value chain, no matter what, that's really part of the whole transformation going into this new model. So yeah, I think you see that actually throughout the whole value chain. I mean, we talked about it, I think, individually on the different value streams and how it comes back. I also wanna touch back on, you know, what's the right size company or firm to actually pick up the IT for IT? And I do agree with where Philip was coming from, is that I think your smaller shops can actually pick it up and start leveraging it more quickly because they don't have that legacy and all that historical legacy IT that was done, you know, where it's very, you know, not built on composite services and things, but everything, you know, on a system is, you know, pinpointing direct servers and direct networks and all this instead of the building it on services like a hosting service and a monitoring response service. So for your larger IT organizations, you know, there's a lot more change, but it's critical for us to really survive and actually be viable in the future for those IT shops, the larger ones and larger organizations to really start adopting and moving forward. And it's not a big bang. We on a larger IT shop are gonna be running in a mixed mode for a long time to come. So it's really looking at where do you start really seeing that business value and as you look at new initiatives and things within your organization, how do you start moving into the new model with the new things? How do you start transitioning your legacy systems and whatnot into more of the new way of thinking and really looking at that consumption model and what we're really trying to do which is focus on that business outcome. So it's much harder for the larger IT shops, I would say, but I do think the concepts apply to all sizes. Rob, the subject of the moment is size and automation. I think the principle would just discuss automation is, we automate always, it's a good principle, but if you look at the legacy as you mentioned, so you're not gonna automate your legacy unless you have a real good business case for that, so you need to standardize your services on many different layers and that's what you see in the clouds, cloud vendors are standardizing extremely, say these are my standard components and you have to do the same, you say these are our standard services and we're gonna automate those and the rest, the legacy ones is you cannot automate or you probably don't want to automate those. So it's more standardization, more standard configurations and then you can automate and that valid for detector as well if you have a very complex configurations that changes all the time without any standard. So and even if you're small, let's say you deploy to the cloud there because typically if you're small and you probably consume more from the cloud, there you still use their automation tools, right? And it can be done initially through a web portal to it could be Amazon or Azure, but you could also have them to standardize like infrastructure code there, so as a developer you're gonna do that. So it doesn't have to be small or a large organization, it's even for small environments you can do that and you probably should to make it repeatable, yeah. Yes, so small organizations don't want to remain small all the time. They actually want to grow. So it starts really, growth starts with a mindset, a thinking mindset. By applying the reference architecture, even though you don't apply every single point to my one man or two man shop, it then helps me, it positions me, it gives me the frame of reference, the thinking to enable growth and so it grows organically so you don't end up with the legacy baggage that most of the large companies have and small companies may get acquired, right? At least they have good discipline or they may acquire others as they grow. So I think the application of the reference architecture, IT for IT is just not for large companies. It's also for small companies and I'm saying that as a small business owner myself. Can I add to that, that if you are starting now as a cloud, deploy to the cloud, maybe the best way is to start with automation at the first, or at least design for automation because if once you have a few thousand servers running in the cloud and you didn't start with that concept to start off, then you already have legacy after a few years running in the cloud. So you should start thinking about automation from the start and not with your legacy of course but if you're now moving to the cloud, design that and build that immediately on the control, let's say. Yeah, on this topic of size, you may, if you were with us yesterday, you might have participated in a maturity model conversation if you were here this morning for Ryan's plenary speech, he referenced an emergence model. We have just started work within the forum on this topic and I think there's at a minimum a few of us and I think potentially one of the directions we're heading is to figure out this very issue. What of the reference architecture applies at what size and evolution in a company's growth? And I think that as I mentioned, I think I made this comment earlier, I actually think that the entire reference architecture applies from day one for companies of any size. It's just a question of whether it is explicit or implicit. If it's implicit, it's in the head of the founder, you're still doing the elements or you can be still doing the elements of the reference architecture in your mindset and your thought process and your thinking but there are pieces you need to make explicit even when you're in, as Charlie likes to say, two people in a garage. On the cloud piece, I think, I'm sorry, the automation piece, the key thing I would say that has been happening throughout our industry related to automation has been, at least this is my perspective, when we've been automating, we've been automating within functional components and I think what the IT for IT reference architecture and its vision of value streams allows us to do is rethink automation along the lines of value streams, across functional components and that's where I think it starts to really add considerable value, especially when we can start to put together interoperability between tooling on some of these things. I think that's where we're gonna see automation really take us to that next level as IT organizations. Okay, one more question for me before we'll take some questions from the audience and this goes a little bit into the future, a little bit of the hypothetical but as IT for IT matures and becomes adopted and serves both consumers and providers of services, it seems to me that there'll be a similar track with digital business of how you run your business which is gonna be more a brokering activity at a business level, that a business is really a constituency of different providers across the supply chain and increasingly across service providers. Is there a dual track for IT for IT in the IT side and business for business management of services through portal, through dashboard, something that your business analyst and on up would be involved with? Should we let them happen separately? How can we make them more aligned and even perhaps highly integrated and synergistic? I hope you understand where I'm getting at. Again, we'll start on the panel end with Philippe. All right, well, I'm looking at your question as we have such best practices in IT for IT that the businesses themselves can replicate that and use that for themselves basically. So if I'm, well, I suppose certain companies do that a little bit today. If you take the Ubers and some of the RBMBs and have these disintermediation connecting with, well, private individuals a lot of the time but have some of these service oriented concepts today effectively even though they don't use IT for IT. But I think that just as much as we see today we have cases where businesses for their help desks or for their request management basically turn to the likes of HPE for service management software to help them with their business help desk. We are likely effectively to see that those best practices in terms of individualization and specification of individual conceptual service, service catalog, subscription mechanisms, you're right, the concepts could very easily apply to businesses. How technically that would turn out, we need to do a little bit more thinking but I think from a good concepts point it surely should be useful. Sue? Yeah, I mean, again, I think we really are trying to move ourselves up the stack to really be helping the businesses in the services that they are providing. And so it's very relevant as we're looking at IT for IT and how we're managing the IT services. It's also those business services. I think it's concurrent. I mean, I think it's really evolving and really make training and making the business aware of where we're trying to go and how can they leverage that in their own services that they're providing outward. And I mean, when you look at adopting this even you go back down to your IT in your organization where you have your different typical organizational teams and things like that, it's, you know, there's a challenge for each IT team to really look at what are the services they're providing and how do they start looking at what they do in terms of services instead of just the functions. And so I mean, that goes all the way up the stack including the business and the business services and IT's job and really where we start talking about transformation is really being, you know, next to and aligned with the business so we really understand their business processes and the services that they're really trying to serve and then how are we truly that business enabler. Great, thank you. Yeah, I interpret your question like we discussed, I think this morning about shadow IT that there is no shadow IT then the IT is part of the or performed some management activities performed by the business. And I think you mentioned it as well, then they can apply IT for IT there as well. So as soon as IT activities are done by the business like they have their own SaaS application that do it all themselves. They even configure it themselves. The business is doing the configuration. They maybe even do end user support to do end user support. Then those activities fit in the IT for IT reference architecture model as well. Dwight, we have a business scorecard. We have an IT scorecard. Why shouldn't they be the same scorecard? Yeah, I'm always reminded that IT is in place to help the business, right? The business is the function. IT should be an invisible enabler of business success. So I think in really IT for ITs, I would classify it as catching up really to business today. So could some of the principles that we apply in IT be used for the business? Yeah, it can be, but I see more of the other way around, right? If you look at our whole value chain, that really came from the business perspective being applied to IT. So I still see that the business driving, but really IT becoming more seamless in enabling the business to achieve their particular goals. Michael? I think that the whole concept of digital business is actually a complete misnomer. I hate it. I think it's wrong. And the reason why I think it is wrong is because it's all about the application of information technology. I think in the context of what we typically talk about with IT for IT, we're talking about the application of information technology to the management of the IT departments. But we also talk about the application of information technology to the transformation of business processes, most of the time that happens inside companies and we're using the principles of IT for IT to do that. When we talk about digital business, usually we're talking about the application of information technology into the transformation of business models of companies. And again, it's still all about applying information technology to make the company work in a different way. And for me, the IT for IT principles, the reference architecture, the value streams, I'll still hold for all of that. Well, great. We have time for one or two questions from our audience and let's start with the gentleman right there in the black shirt. So I heard that you could start with detective correct as an entry point. A comment was made that you could start with detective correct has an entry point into the value chain. And then I also heard you don't have to implement all the functional components. Does that imply that you can do just some of the value streams and not all and people can kind of pick and choose what they think will help their organization the most? I'll say the starting point can be detected correct. But I think as Sue mentioned earlier, it's where in your business is that pain point? Evaluate the entire value chain, look at all the value streams, map that to your business activity, identify where you have exactly one of your main pain points and start there. Certainly, if you go to detective correct and maybe your shop doesn't have a problem type of practice, there are certainly options that you could maybe leave out problem if that's not a particular pain point for you. Again, the size of the company, the level of maturity will determine where you actually start and what you use. But what we do have in the reference architecture, it will help any size of company across the breadth of that particular organization to use and apply the architecture. So yeah, my opinion is that you don't start with a specific value stream because otherwise you focus too much on a single value stream, so you still look at the overall picture first. So even if you're gonna optimize detective correct, it doesn't make sense if you don't have requirements to deploy very well or you even don't have your service portfolio in order. So in that sense, you should not try to optimize a value stream by itself. And I guess most organizations have something in place and then you could say, yeah, I have my portfolio, my service portfolio. So if you don't have anything, you probably start with strategy to portfolio. What services do we start to offer, right? You don't have suddenly so many services running out there. So that's best, there's always to start there. But of course, we're not in a green field. So you hope that you have some portfolio management capabilities in place. If not, maybe that's, at least you need to start there because otherwise you seem to be, you cannot link your CIs to services have no concept of that. So I think it's still, you look at the entire value chain you select the things that you try to mature. What great one suggestion on this, I think, which we're testing at the moment with a couple of clients is the start with a pass, start with a platform as a service thing. So to train your IT workforce first, they need to understand all these concepts before they move it to the business. And IT will source its own services. My development environment, my test, I'm sorry, my development service, my test service and so on. And once you've piloted that, then move on to everything that you develop in the, what we call the new. All of those digital solutions are solutions for the digital business, which typically are newer based on these metaphors and have tools that are easier to make work along those concepts. And then progressively, as these will not work in isolation, they will need to work with some of your legacy, some of the data you have in your existing data sources and so on. You can bring those on as designing them as services as standardized APIs and progressively bring in the more and more business services in that fashion and sort of try and take over the legacy of the IT progressively like this. I'm not afraid we've gone over our time a bit, so I think we'll have to leave it there, but how about a big hand for our panel, thank you.