 Jan's toolbox includes standards and practices such as IT for IT, ITILS, SAFE, Design Thinking, Agile, DevOps, and Continuous Delivery. And Jan is, thank you Jan, you are an active member of the OpenGrips IT for IT forum. In this session, Jan will present a case study for how Skyhoo's partner set out to modernize its operating model to better support digital product delivery. The initial phase of this operating model modernization initiative used the IT for IT reference architecture as a blueprint for a holistic capability model for the IT organization. So we've heard a few standards from the OpenGrips mentioned so far today and Jan's going to talk to more about another one, the IT for IT reference architecture. A warm virtual welcome from the OpenGrips, Jan Stobbe. Thank you, Steve. My name is Jan Stobbe. I'm working for Suga News Partner. I guess that's the most difficult thing of this presentation to pronounce the name of the company. Yes, it is. We are, actually, I've been working for a project in the last couple of months, almost over a year now. That is an operating model modernization project and that's basically the topic of my talk today. I will start off with a short introduction of Suga's partner and who we are and what we do. Then I will describe our modernization voyage and before I really dive deep into our operating model transformation, I will not be able to be talking about all of it but I want to look at two aspects that I think are especially interesting before we then go over to the Q&A. Suga's partner is a part of the Southeastern Norway Regional Health Authority or Norwegian heist service, Reginald Heist for that. We cover about 3 million citizens that it's over half of Norway. We are 11 local health trusts. I'll look at them as a federation but they're actually owned by Heist heist and a few private partners. Physically that's 25 hospitals, thousands of ambulances, pharmacies, labs, logistics and a lot of out-care centers. There are 80,000 employees in Heist service that means we have 80,000 users. In 2019 Heist service spent about 8 billion euros mostly for Heist. The last but not least, Heist service has the largest IT environment. There's where Suga's partner comes into play. We're one of those sort of health trusts and we are the shared service provider. Founded in 2003 basically by putting together all the IT organizations of those hospitals. We have grown to 1,550 employees and number of that is still growing but has become quite stable. Short about Suga's partner's motivation, modernization voyage. In 2015 we started for the first time to make a large modernization of the infrastructure estate that at the time had grown old and was very fragmented. The discussion phase ended up that we started basically sale and lease back outsourcer where a partner would take over responsibility for the infrastructure, modernize it and deliver it back to us on a lease basis. Weeks before we should go live the project was stopped due to security concerns and one year later was the contract with the outsourcing provider was cancelled. Then the same year we started a new program for the standardization and modernization of the IT infrastructure. The two programs have in common that they are mainly technology focused. But especially the newer one has actually a bigger focus on the operating model and actually acknowledges that when you modernize infrastructure you also have to look at your operating model. I mentioned that first program really because it is important to understand what such a project or program going wrong does to your employees. We are meeting a lot of resistance in that new project just because you guys failed the first time and everything went wrong the first time. So although everybody agrees that we need to do something we need to transform everybody still has that feels that pain from that first attempt on sale and that impacts the new work. Well why transform the operating model and why transform it now? We are seeing that we have a growing backlog of deliverables to our customers. We have an end of life issues in our technology state, everything grows old. Just as a reminder that since we attempt we wanted to source out the infrastructure not much has been done there in the last years. We have this modernization initiative ongoing in the region is building several new hospitals almost in one hospital per year. And we have that ever ongoing digital transformation throughout the healthcare region that just leads to an ever increasing demand for IT capacity and velocity. So our approach is that we have to automate what we can automate in order to make room and use our people to focus on what cannot be automated. And so we think that we need to adopt modern practices and behaviors. We have to go over from a waterfall throwing things over the fence approach to project delivery to establishing teams that maintains and has a much bigger ownership to the technology. We need to collaborate more and more efficiently. I think often we use the term co-creation instead of delivering. And like I said we need to seek automation to make capacity free for other stuff and also to reduce errors. So what are the ingredients for an operating model? The last six, seven years that I was with SuperSpark, now we've worked with service orientation and we basically started wrapping the applications that we maintain or deliver to the hospitals into service wrapping. So the other things that we thought should go into an operating model are design thinking and agile DevOps and Tweeting is delivery as the four cornerstones that we build everything on. And as I pointed out earlier, we think that a hierarchical organization that is very focused on the managers and the leaders is not efficient for what we need to do. We want to have more end-to-end accountable teams where throwing over the fence doesn't happen anymore but really where you have a team within accountability for what they deliver. At a previous open group event a couple years ago I picked up this book here and it's called The Operating Model Canvas. And what's nice about it is this picture, it's so self-expansory. So it divides up your operating model, tells you what are the domains that you have to look at when working with the operating model. And so defining an operating model, it's two things. It's how we deliver value to our customers and how we run ourselves. And that helps us to structure our approach in order to do what we do in this project. So what to do first? We figure this is so big and large projects you tend to fail because we tend to fix everything. So we need a map and a plan and scope is really the biggest issue that we've experienced all over the years since the bigger the project gets, the more likely it is to fail. So fix everything project part too large and they're difficult to manage and they will fail eventually. Small isolated initiatives have little or no business impact. So you have these little heroes that I have much respect for but they go and fix one process. And then you say, what's the business impact? Because what you do is right but it depends on other things happening in order to have an effect on the business. And that's where we struggle also with idle processes that we have established everywhere basically in operations at least. So if you want to improve one, you end up having so many dependencies that your project gets larger and you have to stop or scale down. Or you have to basically make the project larger and larger with all the difficulty that brings along. And then whenever we worked with process improvement we figured out we saw that there was the effect was so little and then we couldn't show for what we did. Internally everybody was like, oh cool, now we would have a change process improvement or you have request models. But it didn't really feel at the business end. And obviously, especially from the vendor market, I guess it says, okay, we need to build by a new tool set. We need to transition to another tools and everything will be perfect. And that's obviously not true either. So what are the main building blocks? And they're now going into the canvas and the P in the middle which stands for processes. We decided that we need to describe the enterprise at rest and the enterprise in motion. For rest, we use the capability object from the Archimade specification or standard. And capabilities provide high level view of the abilities of an organization. So what do we do? And then for us focusing on the IT part of the organization, okay, what are the IT capabilities? And on the other hand, enterprise in motion, how do we actually generate the value? And how? And we need to describe that on a high level and not to begin to long details and actually have to formulate something to a proposal that the business would buy into. And so we use the values to object in Archimade. So the first thing that we said we needed was a capability model. And here we were really compensating for our governance, for the lack of governance, I think. So I was, when I started in that project, I went to our governance people and said, okay, where's our capability model? We didn't have one, right? So we said, okay, let's use IT for IT, which is really reference architecture for tooling. But it has all the ingredients that you need for a capability model on the business level as well. And so at the time, version 2.1 was the current version, which still is, I think. You had those four value streams, stretch portfolio requirements to deploy requests to fulfill and detect to correct. And we made those capabilities. And that basically worked quite well together also with the discussions we are having in the IT for IT forum every Wednesday. And so we built this picture basically based on something I found in the forum. And we called it Super Spartan Value Network. And then we made all the value streams capabilities. And we tried to find stuff that are in those capabilities until we could basically have a hierarchy also in the capabilities. I have to mention that we got a lot of help from the market here. So that's not necessarily know how that we had in-house. Based on that capability model, we defined value streams. And those are, again, very similar to what you were going to experience in the next version of IT for IT, I think. So we will have this, the value stream explorer that basically is about making good plans. You have a value stream for integrating with this basically building good products. You have release, we are not calling it release, not publish. That basically is all about building that IKEA catalog that you can publish to your users and say, okay, this is what you can order. You have requests basically in where that describes what happens when someone orders. And deploy, obviously, what happens in systems and operators all about secure operation of things. Also, if you remember that big arrow from version 2.1, what's under the arrow has become those supporting capabilities. We really need those. They're not only supporting their part of the operating model. So if we move this around a little bit and move the strategy portfolio to the top, then you get this picture. And we tried this, we tested this, so I can say we're agile and we got quite good feedback. Also, this is one way of using those pictures we highlighted those that we focus on. So it's not that we don't have the other ones or we're just in our project we're actually working on with three of them. So, again, back to scope and we have adopted a model that we said, okay, we need to develop the values to maturity in stages or in plateaus if you want. And you can only integrate what you know, you can only automate or integrate what's integrated. So we really say on that, this is a communication effort that we're doing towards leadership and also inside the organization. We start simple. We need to understand and really write down how we do things. When we really have agreed here and we are 1500 people, so that agreement and Norway takes a long time. And so once we have those defined, we actually built and screwing together the systems and building the integrations between systems. Later on then, automated them. I think there are no shortcuts here. So you can hop over things. You can start with automation without being truthful to your stakeholders and say, okay, there's an automation unless we have this figured out. So what to do, we built, we call this a sunshine diagram, although the sun is green on this one. We have a stream basically, each value stream gets one of those sections in that diagram. We put all the efforts and all the initiatives that we plan, we put on this picture. And this worked out to be quite useful in communicating what we're attempting to do. And the other thing is we can actually say, okay, we're only going to focus on this box. And when we're finished with that box, we're going to take the next one and you can say stop. So we don't need funding for this whole picture. We need for this little box right here. And that reduces risk and actually increases the focus on the work at hand. Now I'm going over, we'll use the last few minutes to looking at organization or the organization dimension of the canvas. We have a current pattern that business teams and project talk directly to infrastructure teams. They do not speak the same language. There's a lot of misunderstanding. There's a lot of back and forth. There's a lot of misprioritization between operations and development of the state. And the worst thing is I think that you get a lot of undesired variation. So whenever we build something, a system, then basically infrastructure beneath gets set up especially for dedicated for that system. And so everything is different. There's no standard components. There's that language gap between the people. There's a lot of technology depth. And it's difficult to set up integrations between the system afterwards. Last but not least, you're getting really dependent upon your vendors for all those clinical systems. So what we are thinking is that we need to build up a framework for co-creation with business teams and the top infrastructure teams at the bottom as before, but we inject those platform teams in the middle that understand the business team language, but that can say, okay, here's your menu. Here's the stuff that you can consume to build your business services on. And that's standardization. And we have this ESM orchestration team and for service management, an orchestration team on the left that is creating, that is maintaining the framework. We are quite specific about in our communication internally that this team is not about controlling the deliveries and what happens between those teams, but basically to build the outbounds and the framework of communication between those teams. So that will narrow the language gap. We will have a decoupling that makes it easier to lifecycle the systems on the specific level also. In practice, this could look like you have a system, a portfolio of systems on the top of services or digital products or whatever you want to call this, that we can pick and choose on what platforms they run and the platforms themselves can pick and choose what infrastructure they are on. Picking and choosing is maybe not the right term, but there's a little more flexibility here. And also we are building up a structure that actually allows us to manage the variety of technologies on both the infrastructure and the platform. Those teams, we're looking at those two pizza team rules that shouldn't be too large and I also recommend Team Topologies, the book, which is very interesting and gives some hints about how to build those teams. I would like to close with some lessons that we have identified, but yet not solved. We find that value streams help to create folks on one area at a time, so that's really much more than processes. They're useful for understanding tooling, the flow of information and tooling integration gaps and to develop tooling strategies, but not only that. The IT reference, IT for IT reference architecture, we find is finally accepted as a standard in-house and we actually pitch it as a standard that we just have to basically comply to when we do things. We have a challenge that the things we do tend to be very academic. It's hard to get an approach for an EA approach that is not fighting fires. We need to compensate for a lot of stuff that's missing in governance. Like I said, the capability model is really not something that I personally think such a project should produce. I think being bold is also very difficult, especially when using terms as DevOps and those other pillars that I mentioned at the beginning create a lot of defensive reactions saying that we're not doing this kind of stuff. This is like 10 years in the future. What we've learned so far is a need to mention that we are now at the end of the concept phase so we're trying to get into planning and implementation phase afterwards is that you need to start, we need to gain momentum. We found out that by starting one of those initiatives that I had on that Sunshine app you instantly get the buy-in of that stakeholder and he will help you. He will carry this project into the next phase and then trust will build up. We need that iterative approach is very important but you still have to have a constant work on the plan that evolves over time. Especially in a project that is part of an infrastructure modernization program we need to be very specific about that. Operating model transformation is not technology transformation. It is organizational or mental organization. Those soft things are not so easy described as building a data center or replacing network switches. So it's more difficult to get buy-in for those. We have established a habit of insisting on the accountability of both other project and the line organization for what we do. When we're building catalogs, for example, and we're building processes then we're not starting before we don't have this crown prince in the organization that will own this afterwards. And last but not least, you need to make sure everybody understands what you're trying to do. In some phases, in some aspects of this project, honestly we couldn't explain it and that was due to the reason that we didn't understand it ourselves. But once you can explain it to everyone then I think it gets more obvious what you want to do and I think then you will succeed. Yes, I think this was it. Thank you for your attention and if there's time left we could do some questions. Absolutely. Thank you very much, Jan, for your presentation. We are extending people's participation here a little but a question came in that actually came in in a different context earlier around the Agile architecture sessions and that was with such a transformation like this that it's not just a technology thing it's affecting people, processes, culture, it's a big deal. How do you go about that whilst continuing to do business as usual to do the day job to deliver the services to clients as usual? I think there's two questions here. I think Ben gave one part of the answer by actually breaking it down and running your talk of ADM cycles incomplete, you could say. And the other one is, like I said, finding that crown prince in the organization solving actually a current pain point for someone and basically adding like pitting to it all the other small stuff that you really want to do. So for us standardization is that big issue and so the question is how can we standardize? How can we standardize? How can we reduce the variation? And then we said okay, do it this way. And I think that at least that's our approach and we're going quite well so far. Yeah, now absolutely and it's great to hear a story of how useful standards can be as well because obviously this is the open group and that's what we do. So thank you for sharing the experience. I'll have another goes. Suki, who's partner, is that better? That's nice, very good. Okay, well I can't. And I'm interested, maybe some other time offline but I'm interested, you made a comment about getting agreement in Norway takes longer. So maybe that's something about the Norwegian psyche that I never realized before but I've made a mental note about that one. Okay, well thank you very much, Jan. And thank you everyone for attending today. That brings us to the end of our sessions.