 Mi je Luka Žešnjevski, je arhitekturecenter v tem tem, zato sem izgleda, če je začala prezentacija. Zdaj smo počkali nekaj preliminarne vorki, kaj smo počkali, kako počkali Togaf in I.T. for I.T. počkali. Sve včasno nekaj bil izgleda vse hodnje, ki bo všeč neko spustnočna z evoščenih. In prvi predet. Zato poživaj, nekaj prijevčenih arhitek neče vsegao seštje obrhu idej, da se vsegao service in nekaj ne bo neče dobro zvodnje rečenih. Svegao je nekaj poživaj, nekaj ne bo poživaj, Here we can use the TOGF to implement IT for IT to establish this capability driven by IT for IT within the enterprise. So, there is a agenda of our presentations. So first we will give some brief introduction to the TOGF and IT for IT. Then we will discuss the touch points of these two standards, so how we can connect So what are the points of connection? Then we will show how to use the TOGaf NIT4IT to transform business capabilities within enterprise. Then we will tell a few words about some concept that we would like to work on, like architecture, development and operations, so how to make the enterprise architecture more agile and how to create architecture-driven development and operations. And then last part will be about how we can establish this new IT that is driven by IT4IT standard as some reference architecture for IT and TOGaf approach together. OK, so the brief review of TOGaf. So I would like to ask the question, who have a deep knowledge about the TOGaf? Yeah? OK, so I see the most of the audience, so we will. And about the IT4IT, I see most of the member of the poll. How many of you? No, IT4IT. Yeah, OK, so let me give some brief introduction for this who are new in this TOGaf world. So TOGaf is Open Group Architecture Framework, so it's a framework. We can tell that this is one of the world-recognized framework now about how to create and establish enterprise architecture within organization. It supports the usage of other open standards, and it's also helped to improve our organization to better achieve the business outcomes. This is a TOGaf structure. So TOGaf is a sum, you probably saw this big book, 70 pages, 700 pages. And it's divided to some specific parts, so it's modular, so it has one first part that is part seven about the architecture capability, so it tells how to establish the architecture capability in the organization, so how to hire the team of experienced architects, how to define the processes, how to tailor this to entire enterprise environment. Then we have the development method, so part two is the main process, process that tells us how to establish enterprise architecture. This process is supported by the content from part three, so it's about the guidelines and technique that are useful to execute the architecture development process. We have a full model of the content, of the deliverables of the architecture building blocks in architecture content framework in the next part. And we have also the continuum and tools, so it's part that discuss how to classify different architectural assets and how to put it to the repository, architecture repository. Also, what is the main purpose of TOGaf is to transform the, as you can see on this scheme, transform the business vision and drivers to some working business capabilities, so going from vision and goals of our stakeholders using TOGaf, we deliver some specific business capabilities. And this is the main concept of the capabilities that is behind the TOGaf, so we plan the capability to increment some people process and material dimensions. And then through architecture process, we're describing how this capability is built, so we're describing the business architecture part, information architecture part, application and technology. And thanks to this description, we can go from the current state that is defined to the target states that we would like to deliver. We're doing gap analysis between this. We have some series of transition architecture. Everything is based on the requirements and some organizational constraints. So here we have the methods, so it's a process how to deliver the architecture from preliminar phase when we're preparing to use TOGaf, then we're going through the vision when we're defining what should be the end states, we're defining the vision and how we achieve this vision, then we're going through the phases BC and D, so we're going through all architectural domains when we're describing this architecture, performing gap analysis, then we're defining the opportunities and solutions, so what solution will implement the architectures, then it's a migration planning in phase F, in phase G we overseer the implementation, so we're checking that the implementation is aligned with the architecture and in phase change and then we provide some sort of the continuous improvement for the architecture and we're monitoring changes. Of course the process is driven by requirements, so as you can see in the center we have the requirements management process that assure that everything what we do is based on the business requirements. Then we have the architecture capability framework, so this is part of this element from this part seven, when we discussing how to establish governance, what skills people need and other resources that are needed to do the architectural practice. We have model for the repository that defines how the repository should look like. Enterprise continuum, so it's some classification method, we produce many different assets, it's that are reusable, we can adapt also something for some models from the industry, so this help us to understand this entire continuum of architectural assets. Okay, so let me give the stage to Sylvain, he will give the introduction to IT for IT, please. Thank you. So introducing IT for IT, I will try to be brief because probably most of you have heard, this today a lot of an IT for IT. So just to remind that IT for IT is a new operating model to run the business of IT. And so it's based on two main components, one is the IT value chain, which you can see here, with this four value stream strategy portfolio requirement to deploy, request to fulfill and detect to correct, so which means we want to do a plan, build, deliver and run, and we have supporting activities which are generally not specific to the IT functions, but who will help the value stream to operate efficiently. And so the other part of the other element of IT for IT is this reference architecture that will build and implement the functionalities that are necessary to run IT. So one of the core concepts that we, this part of the IT for IT is the service lifecycle concept. So IT for IT is really based and built upon the service lifecycle concept and the service lifecycle will streamline the development from strategy to portfolio, from the concept of the service to the reality of the service, going through three main stages. First one is the status is a conceptual service model. Once we are going to design the service and to deploy the service, we are in the logical service model and finally the one which is implemented into the production environment is the realized service model. So the goal of IT for IT is to maintain the relationship and to maintain the trustability going down from conceptual to realized service and also backwards from what is in the production environment to be able to get all the metrics and to link these metrics to the conceptual service. So this shows the reference architecture. So this is a global view of the reference architecture. We call it the level one. And what you can see here is the goal unless in traditional IT where we are built around process and built around the product that we run the process here, what we design is functional components and data objects which are independent from processes and from product. Even if afterwards these functional components will lead to a product. But we want that this architecture be completely independent. This is one of the main deliverable of the IT for IT reference architecture is service. So we are service centric, it's a service centric framework. And what you can see here is this blue circle as the data object, as the data object which allows us to precisely identify the different states of the service through it lifecycle. So you can see we have seven different objects with relationship between these objects that allows us to very precisely follow the service lifecycle. So what is our intention in this presentation? What we wanted is to show you, it's our vision. It's not the open group. It's our vision of how we can use both standard together. So the goal is not to fuse the standard, but really to show you, because we know that there are some differences. We will see there are some differences in terminology. But really we think that you may use, enterprise can efficiently use the two standard together. And this is what we are going to show now. So first, looking at the touch point. So the good news is both have the word architecture in the name. So we, IT for IT is a reference architecture. The GAF is an enterprise architecture framework. Of course, the ultimate goal of these two standards is to have services into a production environment. So services that are in an operation mode and that will help the enterprise to do its job. The difference are that in Togaf, the scope of Togaf is enterprise wide. So we are designing architecture for the whole enterprise. IT for IT is dedicated to the IT function, to the IT function. So the reference architecture is really dedicated to the IT function in the enterprise. In terms of deliverable also, Togaf, the deliverable of Togaf is to enable business capability. So we want to transform business capabilities in order to support and enable the business strategy. In IT for IT, what I said, the main delivery, what we want to deliver is IT services and IT services that will enable business operations. So in terms of conceptual models, yesterday I was speaking with a guy from Modelio, and he says yes, Modelio, we support Archimage, we support BPMN, we support UML, and he says now we will have to support IT for IT. And I said no, the good news is IT for IT is not a new meta model. IT for IT is just a new architecture that is described using mainly Archimate. So it's not a new meta model. We speak in IT for IT, we speak about class model which could be confusing, but we will see that it's not a new meta model. Togaf provide a core content meta models with extensions and I will show you that we use part of this meta model concept. Of course, there are some difference in entities, so the way, mainly in terminology, the way we named the concept between Archimate, we speak about, for example, building blocks in architecture, we speak about functional component in IT for IT, so there are some differences, there are also some differences in how we describe the relationship between the concept and to facilitate the use of both standard will probably benefit from aligning the terminology together and this is something that the organization can do as when they implement IT for IT or when they implement Togaf. So this is just to show you the core content meta model of Togaf and just to show you, in IT for IT, we mainly use as three of these objects, mainly data in TT and application components and in some way also business service is the thing that we are using from the Togaf core content meta model. So I could explain also the same concept that we use from Archimate which are exactly the same concept we use in Archimate. On the other hand, in IT for IT, we speak about level of class model. So we have three levels of class model that are part of the IT for IT standard, I would say normative part and we are two other levels, four and five, which are specific to the vendor and the tool vendor. So in the three first level, level one and level two and level three, for Togaf people that manipulate the concept of views is just views describing different architecture. So we have three levels of architecture that are defined. The first one is a global view. The level two is a more detailed view that will focus on value stream and the third level is many views that are defined in Archimate language that will concentrate sometimes on data objects, sometimes on functional components, sometimes on the relationship between all these components together. So as Lukas said, so we have two ways to look at how we can use IT for IT and Togaf together. So one way is in transforming business capabilities, what will be the interactions between IT for IT and Togaf. The other way that Lukas will present afterwards is if I want to use Togaf and the ADM methods to transform an IT capability, what will be, how will I use the IT for IT reference architecture. So this first one, just a reminder, sorry, but for the people who knows Togaf and the ADM, so remember that in order to transform an IT, a business capability, we will go through the ADM cycle, begin with the phase defining the vision, the initial requirements. Phase BCD that you can see here will be focused on developing the architecture, the BCD at different level, the business level at this information system level and technology levels. Phase E will be where we define the solution, so we choose a solution and we define the roadmap for the transformation and phase F, this is where we'll identify the project and that will deliver, and that will really conduct the transformation. Phase G is a phase where we will oversee the implementation phase, so trying to ensure that the implementation project will be in line with what we design as an enterprise architect and phase H will ensure that the architecture that we produce is still valid in time. So it's a sort of maintenance part of the cycle. So what we try to do is to try to understand during this ADM cycle what will be the relationship with what we found in the IT for IT. So I said that IT for IT is focused on services, delivering services, and Togaf is focused on delivering an architecture, even if the ultimate goal for both standard is to deliver, of course, a real architecture that provides services in a real environment. But in an intermediate phase, what Togaf will produce is a description of the architecture and what IT for IT will produce is starting from a service portfolio for identification of a certain number of services, implement these services into a production environment. So what we wanted to show here is that it sees in the phase B, C and D where we are going to identify building blocks that can be candidates to become services. So the business architecture will probably allow us to identify business services, information system architecture will allow us to identify IT services, and technology architecture will allow us to identify infrastructure services. And afterwards, this will be part of the service portfolio and the service portfolio for those who know IT for IT is in the strategy to portfolio. This is the starting point of the service lifecycle. The next phase of the ADM cycle so will help us to identify solutions and define the solution run maps and finally the project portfolio that will run the transformation. So if we try now to understand the interactions that we can have between the value stream, the four value stream and the ADM, so, of course, we will find the same interactions between phase B, C and D, you can see here, and the strategy to portfolio value stream. So this here, this is where we want the older services that are identified to be part of our service portfolio. When we are in phase E and F, this is probably more linked, it's not a one-to-one link, of course, it's not a one-to-one interactions, but in the requirement to deploy, this is where we are going to have the project, the initiative of the project, the requirements, detailed requirements, the design of the service, the identification of solutions, and this is why this requirement to deploy is linked to phase E, where we choose a solution, phase F, where we identify the project, and phase G, where we design the service in detail. Phase G is also a link to the request to fulfill, why, because the request to fulfill is the value stream that will implement, that will deploy most of service component into the production environment. The last one, detect to correct is, in some way, detect to correct is the maintenance of the service, and as I said, phase H is also the phase, this is the maintenance of the architecture, so we'll have a dialogue, probably between the people from the architecture and the people from the detect to correct phase. If I go a little more into details, so here I am at the functional component level, and here you can see that the main component that is involved in the ADM interaction, as you can imagine, is called the enterprise architecture component. So the enterprise architecture component will have a role of taking the information from the phase BCD, as I said, and to populate the service portfolio. The service portfolio component will be part of being relationship with phase AE to identify solutions and define the roadmap, and afterwards will have the service design, the proposal component, which identifies the project and also the project component, of course, because the phase G is mainly realized through project. So as you can see, most of the relations between ADM phases and the functional components are in the strategy to portfolio, little in the requirement to deploy, but mainly in the strategy to portfolio value stream, which is normal. Of course, phase G, as it is implementation, all the rest of the IT for IT, I mean all the request to deployment, the request to fulfill and detect to correct will be mainly in phase G and H. So if we want to look a little more carefully at this enterprise architecture component, so the enterprise architecture component will make the link between the business strategy and the service portfolio, as I said, and you can see here the main functions of this component, which is to develop target state business, information application technology. So this is quite what we can find in the ADM phase BCD, and to develop the IT road maps based on the business road map. Okay, so I will... Thank you, Sylvain. It's a link to the... Okay, so as Sylvain show in previous slides, we define some concept that we can use this standard together because there is a lot of discussion about how to improve enterprise architecture approach, how to move to the agile way, yeah, and our idea is that connection, integration of these two standards and show people how to use it together. I don't talk about putting it to the one standard, but to use this as a two in our organization. Can assure something that we call the architecture development and operations, or architecture devops, or continuous architecture delivery. So we're showing that using the Togaf and IT for IT together, we can continuously deliver architecture and drive the development in iteration in some structured, architectured way, and this is also a really big chance to improve the practice of enterprise architecture. Now I will move to the next topic. So it's a different point of view on the using Togaf and IT for IT. So how to use the Togaf and IT for IT to transform the IT capability within the enterprise. So how we can improve our IT capability, so this IT area in enterprise using these two standards. So as I said before, the Togaf transform the vision to the some working capability. So we have from one side the IT for IT as some reference architecture. We tell that is a reference business architecture for IT. And from other side we have IT business capability. So we would like to use the IT for IT in this case as some reference model, how the modern IT should look like in all the enterprises. And we here map the IT for IT to the Togaf structure. So first we reflecting the use of IT for IT as some part of the architecture capability. So we need for example, some specific principles that reflect IT for IT, specific people with specific skill set based on Togaf and IT for IT. We also reflecting the ADM, so architecture development method as a way how to establish organization, IT organization that is aligned with IT for IT reference model. Then we have some guideline, we using Togaf guideline to support this implementation. Then we reflecting the IT for IT as a part of the architecture content. There is a reference model, we can use reference model to create our architecture. Then we also reflecting this as a part of the continuum, we putting some architectural asset based on IT for IT to our architecture repository. And it's here, we have the concept of continuum that shows the different level of the enterprises. So here we decide to define that IT for IT is some sort of common system architecture. So common reference model that we can use to establish any IT capability within any enterprise. And also in IT for IT we have level four and five. So this vendor specific architecture that are not part of the standard but they could be defined in alignment with this standard level one and three. So the solutions that support the IT for IT reference architecture and the vendor specific solution that we can use to implement this architecture building block that are designed in this level one and three vendor agnostic reference architecture. Then we reflecting the IT for IT in the architecture repository. So we using in the reference library, the IT for IT as a set of reference models that is a good example, how the architecture for IT capability should look like. Then we reflecting in the landscape, set of architecture building blocks that are designed based on IT for IT. So like for example, some functional components and data object that we have in the IT for IT. And also in solution repository, we will put the old solution that are aligned with IT for IT. I know that the open group IT for IT forum works on the some certification, accreditation program for the solutions that are based on IT for IT. Okay, and finally the process. So how to use the ADM to implement IT for IT. So first of all, we reflecting the IT for IT as a part of the architecture capability. So for example, we can define the principle in the part preliminary, phase preliminary like IT is a service broker that is also promoted by IT for IT. We defining the vision in phase A, how the IT should look like. Then in phases BCND, we using the IT for IT as a reference architectural model to design our architecture. In phase E, we will be selecting the specific solution that are aligned with the level four and five of IT for IT to implement the architecture building blocks. In F, we will detail plan the migration, how to migrate our current IT states to this future that is aligned with IT for IT. In phase G, during the implementation governance of the architecture, we will use IT for IT to provide the compliance of the architecture. And then in edge, we will be monitoring what we can still improve, what we can change to work better. Okay, and some sort of the summary. So from one side, we have the TOGA framework that is currently leading enterprise architecture framework. The IT for IT architecture provides the guidance how to structure the elements to strengthen the IT service delivery. And we think that these two standards have the aspiration to improve the agility and effectiveness of each enterprise. So we think that when we ensure that the standard can work together in the best way, we can help many organization to improve their IT operations, to achieve their goals. And also we will help to improve the practice about the enterprise architecture to give the agile way to this, the agile way to this practice, yeah? So thank you very much. That's it.