 My name is Stige Agstander, I work as an enterprise architect at Sikuhuspartnerd.hf. We'll come back to a little bit more what it is. And my colleague wandering aimlessly around in the room is called Jan Stobbe. He's also an enterprise architect within Sikuhuspartnerd. So this is the agenda. We're going to give you some background, some introduction to our company and where we come from. We're going to have a little discussion about what the service actually is. Talk a little bit about architecture, artifacts, and models. Lifecycle management, IT for IT, enterprise solution architecture, Togaf, IT for IT, and some lessons learned on the QA. And Rob, are you timing us? Yeah, good. 40 minutes. 40 minutes? Ah! Because we did a trial run of this presentation. And I think we talked for over an hour, so we sort of have to cut down a little bit. Background and introduction. This is where we come from. It's a Southeast Regional Health Authority in Norway. It's the blue thing down there. And we have 11 county health care trusts. We support about 25 hospitals. We have 100 psychiatric, somatic, out-care centers, ambulances, pharmacies, whatever. About 77 employees. And by far Norway's largest IT environment. Our company, Secret's partner at HoF, is an independent subsidiary of this regional health authority. And we're a shared service provider for ICT HR logistics into this entire region. About 1400 employees. One of the largest IT suppliers in the Nordic countries. Just a quick. This is today's operating rooms, which is sort of where the end customers is. The physicians and the patients. And this is what it actually looks like today. And we're kind of thinking that in 10 years, the ambulance will come and pick you up, take you to the hospital and put you into this room. The ambulance will actually bring this to your living room. So it's quite exciting what's happening out there. As part of a transition project within the company, there was done a lot of work defining a new strategy for the company. And where's the pointer? What we're going to talk about today is pretty much what's down here. The service orientation as a traversing principle. Put it quite plainly, we had problems delivering to our customers needs. So it was started a huge transition project to sort of align us more and to be better able to deliver services to the customers. Huge reorganization. The entire company has been turned upside down and inside out and reorganized. So we now have four business units. One to the left for you is customers and services. That's supposed to be the business units where you are closest to the customer. You capture the customer's needs. You start planning on how to deliver what the customer wants and needs. Then we have resource planning and scheduling, which is pretty much what it says. Are we sure we have enough people? Are we sure we have the resources available to start building those services? Then we have service development, which is a business unit, which actually do the service development. They run projects, programs, stuff like that. And operations at the end. So this entire organization was built on the plan, build, run paradigm. And these guys you will see a lot of in the presentation. So we tried to relate both enterprise architecture and service delivery, the mode of operation to sort of support this through the plan, build, run paradigm. And now it's Jan's turn. One part of the reorganization of Sukish partner was that we decided to look for an external partner that will run our infrastructure and will provide end user computing services, network hosting and telecom to us. And by basically giving away all everything you can touch, we were aware of that we can't continue to work before. Basically, you could either call it agile or you could call it firefighting. So we had to define what we actually do. And so we started building a functional modem for SIAM service integration management and basically tried to find everything we do, all the functions we need to have to run our business. And we clustered them in service integration governance and in service integration management, so the daily operation, the daily management of the services and the service delivery that is delivered either through this partner or through internal delivery organizations or actually by the hospitals themselves. And well, we got pretty far finding all these functions, but we couldn't really explain how they interact, how they end to operate and how the value chain looks like, what's the value add in each function. So then we found the IT480 reference architecture, the IT480 standard. At that time it wasn't a standard yet, but it looked very promising. So we took the status it had then and we found, okay, we have a value chain where we have all these activities, all these functions and the IT480 reference architecture, they put them in order and it defines the relations. And the other thing is that we do a lot of things and we found that the value streams, the IT480 reference architecture defines help us to actually grasp what we're doing better and when we go into certain organizational change initiatives, we could look at only one value stream and say, okay, now we're doing something in the operations area which is that detector correct or now we're actually working with planning services and we're only focusing on this value stream and we're saying, okay, this is a handover to the next value stream, we do not worry about that now. And we tried to understand, okay, this is actually what we're doing here as architecture and how do these things work together and how do we, again, how do we actually produce value to our customers and how we deliver it. And the part we like most about the infrastructure, about the reference architecture is actually not all the blue boxes. They're also pretty cool but what's best is the backbone and we found out that we don't have one. We have 3,000 applications that we're managing and delivering and that people call but we can't have a dialogue with our customers about 3,000 applications because not even the IT department of the hospitals know that they have them. And so we started to think of how can we use the concept of the service backbone to end up with 3,000 services, 3,000 which are actually applications in operations and reduce them to minimum 15 or maximum 25 services that we actually can have a dialogue with our customers about and those services are functional and that's not a service that's DPS which is our provider of EHR, the patient record system but that may be patient record system or patient records actually and then we go into those 3,000 applications and we have 15 different applications for patient records and we can have a dialogue about these applications. Yep, just take a quick step back to this one again because IT4IT starts up here with the enterprise architecture component. Where does that come from? Nobody's going to deliver it to you. It's not something that's just out there. This is where you have to start. And one of the interesting things is when you start talking about service orientation you certainly find out that there is now clear unified definition of what a service actually is. Everyone's got their own definition or they don't have one at all. So we have a Secures partners definition, we have IT4IT definition of what a service is, Togaf really doesn't have a definition of what a service is. It talks about application services, technology services. Satman doesn't mention services at all. Cobit, Gardner, ITL, Oasis, Open Group, Micro Services. They all have different definitions of what a service is. So we spent the first 6 months discussing service orientation and then we suddenly discovered we're not talking about the same thing here. Everybody has their own definition of what a service is. And that makes it kind of hard actually to get anything sensible done. So we started thinking is there another perspective on how to look at this that can help us create an architecture because creating an architecture based on these definitions is not trivial to put it mildly. So we took a look at what are we actually doing. And this is an example from the laboratory services in hospital where the question is basically what is the lab service for the clinicians. Well, for them it's pretty simple. They take a blood sample, tissue sample, they requisition a test and they want their answers back. That's the physicians and clinicians definition of a lab service. What's the lab service for the people who are actually working on the lab? Well, to them it's quite important that these stuff works. So they want their analysis equipment to work, their laboratory information management systems to work. That's their perception of a lab service. Then we have the ICT department. What's their definition? What's their perception of the lab service? Well, network storage service applications and everything that sort of builds up the lab service in the infrastructure, that's their perception of what a lab service actually is. So when we're talking about a service, it actually all depends on who the customer is. Your deliveries will change according to the customer. And all of this is jumbled together in something called the lab service. And if you don't know this, if you don't take into account who the customer actually is, you will not be able to build the services that your customer needs. So we've come up with yet another definition of a service and it's quite simply a service is what the customer consumes. Very simplistic, simple to understand, but there are some major points in here. Well, it's not a service until you have a customer because you're actually delivering something of value to someone and if you don't have a customer, you don't deliver anything. The service is defined by the customer. The customer is a consumer of what you provide. You have to know what the customer wants. So you actually have to try to figure out what the customer wants. Another important part is that the customer doesn't own specific costs and risks when you are developing the service. They're consuming a service, building, developing a service. That's our responsibility. We take the risks. We have to budget for the development. That doesn't mean the customer doesn't pay for it in the end. They do. It's an outside in and not an inside out approach to the design process because there's no point in building services the customer doesn't want. So you have to reach out to the customer. You have to understand the customer's needs, the requirements to actually start developing some sensible services for them. And a huge point at the bottom, this is actually quite easy to architect. You know what the customer consumes or you should know. If you don't know, figure it out pretty fast. So architecture, artifacts and models. So this is how we view the architecture development world with Togaf and IT for IT wrong button. So we're doing enterprise architecture and this is the plan phase. So when we as enterprise architects in Sykes partner are involved with developing a service, we are always in the plan phase. We do not do implementation, but we do it in the plan phase. And then we hand this over to the solution architect and then the guys is actually building it. They do all the service changes. They are part of projects. They are part of programs. They are the people that actually delivers the service, builds it and implements it. And at the bottom, on the run phase or operations, there's a realized service. It is the service as it is realized in your infrastructure at any given time. The point with these guys is that when you have done a service change, the service actually changes down here. And that has to be a feedback into the enterprise architecture when you start planning your next run of service development. And this is some architectural artifacts that we use. What I'm going to show you now is a very, very simplistic and simple reference architecture for services. This is not the answer to the big question about life of the universe and everything, which is 42, but it's a very simple reference architecture on how you can start building your enterprise architecture in a simple and easy way. So these are the three artifacts that we need. Which is the smallest configurable managed element. And for those of you who know ITIL, it's a configuration item. It's a CI. Very simple. It's either a person organization, it's a process, technology, it can be a service. Technology can be anything from a thumb drive to a hospital to an ambulance or helicopter, whatever. But these are the smallest components, sort of the physical entities that you can touch and the smallest components that you actually do management on. And we have the capabilities. And it's a Togas definition. An ability that an organization person or system possesses. And it must have all the love. It has to have a person component, a process component, and a technology component. Because it's about somebody doing something on something for someone. So you need all these three. And then at the end, we have the service, which is what the customers consumes. That's pretty much where the money is. And this is how the model looks. It doesn't have to be much more complicated than this to get started. And it will grow and expand over time. And this is from the planning perspective. And when we're talking about planning here, we are what is, in our case, it's the clinical capabilities that our customers possesses. That they're capabilities that we need to build services to support. So an example of clinical capabilities, if this works, is this one. This is a capability map from Ireland, which pretty much lists up more or less all the different clinical capabilities you need to run a healthcare system. So this is kind of the level we are talking about here. We have your core EHR over here. We have oncology. We have pharmacy systems. We have mental health records. All of these are capabilities that the healthcare system has and that we actually need to build services to support. So the question is, you have all these capabilities. And then the question is, okay, which services do we need, ICT services, do we need to build to support or to enable those capabilities? Simple question. So, and how do we build services? Yeah, well, we have these components down there. They're ABBs and SBBs. And it's a bit like building Lego. You have a box of components and you take the pieces that you actually need, put them together and then hopefully suddenly you have a service in here. So now we're kind of turning it upside down because now we're talking about the delivery perspective. How do we actually deliver this service? Well, at the bottom we still have the components. All those building blocks, we have put them together to create services and we have created the services to support our customers' capabilities or the customer-facing service. Well, added a couple of attributes down there that has to do with money because there's always a discussion about how much does the service cost to produce, how much does it cost to deliver that service. And management is very interested in this. They're pretty much all about the money. You can split or you can figure out how much this costs because when you are building something, you are doing a service transition, you are developing a service, you are actually building components. You're not building a service. You are building the components necessary to aggregate or orchestrate the services. So your cost of investment will always be on the component layer. And then you come to the cost of operation, which is on this layer because this is where sort of all these components join together and they run in your IT environment, then you need cost of operations. You need servers, you need cooling, you need staff, you need management, monitoring and all that stuff that costs money. So you can add that on the service layer. When you come to the top where you have the customer-facing service where you actually have a customer, then you have to start doing governance. You have to start keeping the systems updated. You have to proactively hopefully detect and correct errors and all that stuff. But the point is you actually don't have governance costs before you have a customer. So the total cost of service is the investments cost on your component layer, the operation cost on your services layer, and the governance cost of your customer-facing service layer, all regulated by service level agreements. So as I said, very simple model. It's not the answer to everything, but it's a place to start. And it's sort of a place to get some kind of structure into it. Laboratory revisited. I mentioned the example from the laboratory service and I see I have to speak a little bit faster. Because if you have the planning perspective, these are capabilities. So you have the laboratory capability, which consists of the pathology, microbiology, genetics, immunology capabilities. Some other capabilities are down here. And then you have your components at the bottom. From your delivery perspective, still components, but now they're services. Much simpler. So why this? One of the reasons why this is better is that when you build services, you kind of build them monolithic. You start with the service. If you're going to build a pathology service, you establish the pathology capability, you build services, you build components in their own silo. With this, you don't have to. With this, if a customer comes along and says, well, we don't have genetics, you don't need it. Then you sort of just disconnect them from the network. You update your service level agreement and then you're done. What if it's the opposite way around? We don't have genetics, but we need it. Start planning on the genetics capability. What more capabilities do we need? Which components do we need? And after some planning, you actually figure out we have most of the components. We only have to build this one to aggregate and orchestrate these services. So it gives you much more flexibility on how to deliver services to your customers. And it also gives you much better control over your environment when you're actually developing those services. Because down here, you now know which components that you have to adjust or do development on. And you also have the dependencies to other services. And be careful not to do too much like that. And your turn. So when we look at developing services and planning services, we had to find out that this is not iterations. We don't plan a service change and we go into production with the service change and we look at what happens and we do it again. Actually, we found out that the services we have exist in several different states at any given time. So we might have a vision for a service in our plan phase where, of course, we architects are sitting. And then you have a couple of initiatives that are in planning, maybe a couple of proposals that are out at the hospitals and they haven't answered on them yet. And you actually have a few projects that are going on and then you have some projects, the hospitals run without us and at some point of time maybe tell us about. And, of course, you have the services in production. And we needed to find a way or we need to find a way. We haven't done it yet. We need to find a way how to keep track of all these different states. And we think that that has to happen in the plan phase, right? In the beginning of the value chain. And we look at it as a roadmap of a service. So everything that's planned, everything that's in projects and everything that's in operations has its place in the roadmap. And whenever there's a new order, when there's a functional request from our customers, then basically the roadmap gets updated. And we think that the blueprint, the conceptual service blueprint and the reference architecture is that what represents the roadmap for us. Whereas the service architecture that's built in the enterprise architecture functional component is the overall target state of the whole of the entire portfolio of services. And so this is basically trying to put this in the picture that we have this... How we think to do is we're trying to use the service cop and the community of practice concept where we have an enterprise architect together with something you could call a product manager for the service. They team up and they basically build the core of the service cop and they involve everyone inside our organization and maybe even outside our organization that adds value to the service or that does something with the service. Basically that everybody's on the same page and everybody knows what's happening. You could call it situational awareness. And by that we can keep track of all the functional requirements. We can have a constant dialogue with our customers and how they want. And when they ask us or when they want us to reprioritize, then we can actually go and look at the roadmap together with them and say, okay, we can delay this delivery and do this delivery first and we can actually analyze and manage the portfolio. We think to build up one of those cops for each of the 15 to 25 services. And now I would like to go into the enterprise architecture function where we are and I think they're the reference architecture as we interpret it a little differently. And in the reference architecture, the enterprise architecture components up here kind of isolate it and actually the only thing it's responsible for is the service, the overall service architecture. And for us, in our organization, the enterprise architecture component is the same function as the service portfolio component. So the architects are also the ones that plan the portfolio. And then we have more architects that do the service design and then in the new organization we have actually decided to split the architecture community in two parts. One doing enterprise architecture that is planning and the other half doing solution architecture and working together with design teams to actually build the solutions. And we didn't like the idea, the notion of splitting people because you work how you organize yourself and we thought it was very important to keep the architects together so that everybody is friends and we are on the same page doing things. But we just had to find out that the rest of the organization would not regard these guys as enterprise architects that do planning, that focus on the function, that focus on the clinical processes as long as they're sitting in the same office as these guys. So we did an organizational split now and we're just going to have to find out how we want to work together with these guys in order to, that they basically produce the architecture, the solution architectures that we have depicted in the enterprise architecture. So for us, architecture is all about strategy portfolio. It's not only the enterprise architecture component, we think that the entire strategy portfolio value stream is about architecture because you need the target architectures, the end state of the architecture as of today. You need to have policies for architecture, you have to have the guidelines in place for the solution architects. You have to contribute to the proposal management because sometimes we have to help prioritizing the task and we have to find out what we have to do next and you have to sit on the portfolio, the moncommoner because the architects are often those that actually produce the demand or actually describe the demand and as I've depicted, we are also involved in managing the portfolio of services. And we're kind of lucky that we had, everyone attended the presentation right before us. Basically, we're continuing that presentation with one little difference. We're thinking that you run the ADM in each value stream and you run it completely, you take a whole circle. So we think when we do plan for one service or all service, we have to create the vision, we have to create the architecture in a certain granularity. We have to decide actually together with the clinicians the right solutions. We have to plan the solutions. We have to basically task our solution architects to build the solution. We have to follow up that they do it and then at the end of the day, we have to update the roadmap of what they did and then we have to start to cycle again. So we think that in strategy portfolio we run the entire circle and what happens in the next phase in R2D and R2F, the wheel spins again several times for each initiative, for each idea, for everything they do and it spins and it spins and it spins and it gets detailed and detailed and every spin could actually create one or more spin-offs, new spins of the ADM and whenever one spin is done, basically the parent spin can go one step further. So just looking at the clock, we do a little one slide on how we do tooling for the portfolio management. A long time ago we bought a solution that's called TRU. It's a portfolio management tool. We found out for ourselves that it's not so suitable for actually architecture development but it's an extremely powerful tool for portfolio management. So when we analyze the portfolio and try to find out and catch the requirements then we try to use TRU and when you actually develop architecture that's what our solution teams do and then we use Sparks Enterprise Architect for modeling and we have our resource planning happens in CI Clarity and when the service is in operations we do it in HP. But that's, of course, not the truth. We do a lot of other work too and so we try to map our tooling landscape on the IT4-IT reference architecture which is actually the purpose of the reference architecture. So we found out that we have a lot of applications that we use and we also found out that we have functional components where we don't have applications where we maybe use a word processing or actually we use paper and we're trying to find out why do these people not work together properly and why do we have to recreate data because all these systems are not interoperable or we just didn't activate the integration. So now we're starting to plan our tooling landscape for the entire service management organization according to the IT4-IT reference architecture and so far we have had great success with it. It is kind of hard to get consultants and the vendor companies to talk the same language, especially those guys here, they're not necessarily better than the others even if they came up with the reference architecture but we find out once we actually require them to do it and they ring their people that actually know about it or they read the standard, then everybody is glad that we actually have a common language to speak tooling and to speak data integration. So for the IT4-IT we have identified a few lessons. We haven't gone so far to call lessons learned because we actually haven't learned from them yet and we see in 4IT4-IT we see a value add as that the value streams help us focus on one area at a time and we can produce values faster when we just focus on one area. It's really congenial to understand tooling, the flow of information and the need for integration and actually to find the gaps you have in your tooling landscape and you can actually use the IT4-IT to develop a tooling strategy. The next thing comes actually as a surprise it might be little strange for the tool vendors but using the functional components actually paves the way for real best-of-breed tooling strategy because you can look at each functional component and find out what is the best tool for this functional component and then you look at the information architecture of the reference actor and say how do we integrate these components with the others and you can define requirements to the tool vendors when you're big enough of an organization they will develop it and you can have a dialogue on what integrations you need to have and it's very promising to do an actual benchmark of your tooling and we started initiative in such initiative right now where we actually went out to our benchmarking organization and said okay go come into our house and look at our old tooling and tell us according to IT4-IT what we're missing and where our blind spots are. There are a few challenges with the IT4-IT reference architecture for once it's just as Eitel and Togov looked at as another IT thing and it's actually not even if it's if the at least we don't want to look at it as a pure IT thing I think we can actually use it for organizational development as well as we can do it for tooling and then the insight. So that led to as it was ignored during organizational change so the organizational model based on planned old run was not they didn't come up on it because they looked at the IT4-IT reference architecture and quite understand the whole concept around deliver. It turns out that the parallel use of the IT4-IT reference architecture on Eitel can be a challenge every once in a while. You have this highlander problem that there can only be one and that works pretty fine as long as you have an incident component and incident management process but once you have a process that doesn't quite match on one component then you have a gap and it's kind of hard to find the right balance. We made the mistake in the beginning and trying to implement the entire reference architecture and we just had to find out that we have to go one by one. Two minutes left. This is lessons learned, not lessons identified. Make sure everybody are in agreement of what a service is and talks about the same things in the same way and it's actually quite important that you start that early. So when you start talking about service orientation make sure everybody have agreed on what the definition of a service is and follow up a little bit about point from young with the organization do not underestimate the need for organizational changes when adopting IT4-IT. IT4-IT is a reference architecture for how to manage IT as a business but what you're actually doing, you are imposing a set of processes on your entire organization and people really don't like to change so make absolutely sure that you sort of address that problem sufficiently. I have this kind of rhetorical question what do you think is the easiest to change 30 application or 3,000 doctors you go for the applications trust me. So when you're doing stuff like this never underestimate the sort of organizational strain you're actually putting into your company and that is also the last point get executive sponsorship because this will impact the entire organization if you don't have management with you in this process it will fail. Very simple. You need for this to work you need to get the people on board to get people on board somebody in management has to say this is actually how we're going to do it this is not just something that the IT guys have come up with yet another IT thing this is actually how we are going to improve our deliveries of services to customers. Thank you for your attention.