Open Source Tooling Chain Capability Map
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Thielscher, Jan
Openchain is a comprehensive set of requirements allowing to cope with the open source compliance challenge. Recently it even has been accepted as ISO standard. However, compliance in todays world is not possible without tool support. To get a grip on the different tools, understand what they can do and where their limitations are, the OC tooling workgroup decided to develop a capability model. This model outlines all required capabilities to cope with the open source challenge and allows to map the functionality of tools. Thus the model can be seen as a map through the djungle of tools. In this talk, Jan will introduce the model as well as briefly outline the most relevant capabilities. Links to further resources as well as first maps will be provided. Open Source Compliance (OSC) is not a might anymore. It is part of good manufacturing practise. Since manufacturing and software grow closer, the insight that not only the Software Bill of Materials (SBOMs) become essential for maintainability and security of software but also the legal documentation can't be seen as a once printed and never read paperwork anymore. The acceptance of CI/CD as development best practise and the ever growing amount of components used from open source stacks and their imminent dependencies prevent further manual delivery of compliance artefacts. But what is required to cope with that challenge? Where do you have to put your efforts in? Which tools are the right tools to check for your purpose? To help you answer these questions, the Capability model has been designed. This talk introduces the motivation as well as the basic aspects of the model without going into details. Guiding thoughts and ideas will be transported as well as links for further studies will be provided. Finally the talk will conclude with a few mapping samples and an outlook in which directions the work will proceed.
 Hello and welcome to the open source tooling chain capability map session. In this session we want to talk about what is required to automate the most of the open source compliance tasks. My name is Jan Thielscher. I am from EACG, a consulting company specializing in open source consulting. The creator of Trust Source, which is a software-solution service that is focusing on open source compliance. Actually open source compliance came to me quite a while ago. Naturally I studied business and computer science, but also did a degree in law, which then gives more or less directly into the direction of open source compliance, because this is a typical mixture of these fields. That's also one of the reasons why in 2015 when we had very large projects and we were delivering to our customers, where we used tons of open source that drove us into the consequences of the understanding of the need for something like Trust Source. However, I'm not here to talk about Trust Source. There are other talks. There's open source tooling available. A couple of links are shown there. But what I want to talk about is what is required to automate your open source compliance. To get towards that, it's good to have a clear vision of what your goal is. In the end, this is a picture from the open chain. The idea that you want to create an outbound artifact that accompanies your supplied software and describes what is in there. In an optimal world, everything that leaves the company has such a machine readable bill of materials attached so that everybody who is taking on the stuff can understand what he gets and what is in there. Unfortunately, we have to recognize that we are on our way to get there. Five years ago, there have been other difficulties that we face today. But still, some tasks have to be completed. We are not really done with this job. There is a lot of things to do. That's also why we have this tooling chain work group, which is actually addressing the automation requirements here. Try automation. Whoever is familiar with the open source compliance task sees that it's essential to have open source compliance relevant people that are looking for it. But even if you do it right, it's nothing where you can win good reputation. In the end, it's kind of a hygiene thing. It needs to be done, but you won't get an innovation award for it. It's something that is absolutely essential. I mean, one of our customers put it once saying when we were talking to the workers council to tell them why do we have to introduce now tools and measures and audit logs and so on. He said, well, guys, there is no opt-in or opt-out. It's just good manufacturing practice. You have to provide this material. And that's, I mean, you can't win anything if you do it, but you will lose or could lose a lot if you don't. And so that's why actually open source has to be understood as something that has to be there. And because nobody really wants to do it, because you can't gain good reputation in doing it well, it's something that you should automate. And there's also another couple of tasks that automation is required, because, I mean, you all know that continuous integration and development, continuous deployment are the coming things if they are not there already in your organization. And whenever you do software development, you will push it through immediately to either a repository or a test environment or probably even production. But you know that there is with all these package managers, there's always upgrades and things that go into the software and into the build that require a lot of attention. And if someone would sit there manually, the total CI CD idea would fail. So there is a huge demand for automation. And this is why it's so important to understand what all goes into the topic when you want to automate the thing. So it's like designing a system. I mean, five years ago, when we started thinking about this, we had a very rough understanding of what should be done. So all it was clear, there is something that should go on the outside. So there is a result and we want to have this documentation done. That's pretty clear. But the first thing that came up to our mind was, oh, we have to scan the things. That was first an understanding of scanning sources, because we need to know what's in there. Then there was a thinking of, oh, what about actually the parts? That we are not building by ourselves? Probably there's something else that we should look at and what is in there. The same applies later on. Since a couple of years now, we have the topic of containers. So containers come with a lot of stuff. There might also be something in. So it's all about scanning. But from the scanning to the outbound artifact, there's still a way to go. So we need to collect this stuff. We need to build a kind of a situation. It requires an understanding of what are we going to do with it? Is it actually relevant to build a kind of a compliance artifact? Is there something that we have to take into consideration when we are looking at the stuff? So we have to understand that we see, we have to assess the stuff that we are using, and then we have to put it into a kind of a situation project, module, whatever we call it. And this then someone should review in a kind of an approval saying, OK, that's good, or that's not good, please do again. So that we can be sure that it's correct. So we have a kind of a requirement for an approval. And whenever we talk about approvals, it's absolutely essential that we know who is doing what so that we need a kind of users. And we need probably to decide between those that are producing something and those that are giving the approval. So we have roles involved. And also essential, if you do an approval, it's relevant to audit that this approval has been has happened. So it doesn't make sense if you cannot follow up later on who has given the approval. So audit is absolutely essential as well. This gives already a couple of requirements for kind of a solution that you have to build. And then it happens that one project has a component, a second project has a component, and probably there are more projects using all the same components. So probably it's a good idea to have a kind of a package or data repository where you store data that you have once curated or identified and curated there. And so you do not need to do the same step over and over again. I think having such a repository is good. But the data that's arriving from the scan might not necessarily be complete. There is probably a declared license with something that is not essentially what is the one that is inside the repository. So how can this really resolve? You need more metadata. And what you can do to get more metadata is to use some kind of package crawlers, crawlers that are running around searching the Internet for additional information that can be added to this package data. Also it might be relevant that you have an option to look up for older versions. So it's a kind of a source archive that you probably should include into this kind of repository. So you can look up data or binaries or things that are probably older and then you can assess them in a separate approach to decode and understand what's in there. Following up this, it turns out that it's also a good idea if you once identified that there is something you don't want to use, for example a component that is out of license and therefore is not capable to be reused or doesn't give you the right to use it actually, then you do not want someone else to put it in his project again. So it makes sense to have kind of policy and rules capability that prevents people from doing things or pushing things into an approval flow just to hear that it's already denied by someone else. So this policy and rules thing is something that really might help you to get on and to improve the process. And whenever things are to be improved, a good base to understand how much it is improved is to have certain kind of reporting and analytics. So this should be something that is inside this kind of function as well. Now we start to get away from the basics into the luxury parts. Also cool to have would be something like a generator for all these kind of compliance artefacts because it's pretty, I mean when we have a list of 100, 200 or 1000 components, it's not really fun to assemble this all manually. So having a kind of compliance artefact generator is something that is pretty helpful or could be pretty helpful. To assemble the right things into this kind of compliance artefact it might also be relevant to have a kind of an understanding of what actually is required. There is one option to say, okay we do always everything and do the worst case scenario deployment. But there is also an option to say I want to take the circumstances and only provide as much as required. So I have a kind of a solver that is capable of understanding the licenses and the situational context and brings this together as the input for this kind of artefact generator so that it can create suitable stuff. And in addition to that we recognize and this is also why we put it as a new open source solution into the market. We saw that it's only few sources really have the information available or in a place put together that is required to cope with the challenges for publication. So the publication requirements, attribution requirements, it's often required to mention the copyright holder, required to put in license stuff and so on and so forth. But this is not necessarily exactly or simply to be derived from the package so sometimes it makes sense to have a more detailed view into a repository to understand what are the licenses and the copyrights attached. This is done by such a kind of a license and copyright scanner or could be done. It could also be done manually but having it automated might be a much better idea. When you already are doing all this for the open source world we've learned that there are some regulatory things that might want you to do in the coming off the shelf management for third party components in the same place because handling it a little bit different sort of components does not really make much of a difference anymore. Also nice to have is the snippet scanning. There is a real source code analysis for already used parts so that if a routine is taken from somewhere that this is flagged and it says, oh look, this is something that we know from these tools or probably this might be a copy and this might not be allowed or kind of modification. But we saw in our practice that it's pretty hard to get this into CI CD because the amount of false positives is so high and the base can be very narrow. It's hard to really put this into flow, keep it in time and so often the outputs then are there and if then else construct that is reused which is partly not too much to protect. However, given all this, if this is not all done by one tool, it might make sense to have something that's orchestrating it, keeping track of what's happening so that you can have a status over all of this. And now we're done. This is more or less the capability model that we have developed and that we were generating over the time of the last years and which is now as a kind of orientation map available. You can use this to focus on particular parts. For example, if you look into the outbound components, if you go back to our basic model and say, okay, this is outbound to be, for example, open chain compliant, I need to have this ordered log, I need to have the artifacts and if I want to automate it, I need to have this artifact generator. You can look on the inbound side and see, oh, there are different sorts of scanning types that I can execute, probably in my case, just the source is relevant. In other cases, it might be that there is just the container is relevant, whatever. Or someone wants to really make sure, he often wants to make sure that the packages used are really attributed correctly. So probably they want to do this kind of license and author scanning, which is a very different task from resolving transitive dependencies when you do the kind of package scanning. So there is a lot of different things and it's good to understand the differences between because they are easily mixed up and that's something that we really understood over the time when we were talking to customers that they get confused by these different tasks. And that's why we put this model out there. It's available. I will put on the links later on so that you can follow up and dive deeper and all these tasks that I have described, they are described there and laid out and you will find responsibilities and things broken down for this stuff. When we were talking about inbound, there's one thing that I really have to go about. I put it in an extra bucket because it's not, wherever we go, we find people just taking containers as they are, even if you take a component, a software component, it's difficult, it's dangerous. So please, whoever is going to reuse things, make sure that you understand what's inside, either by scanning or by just decomposing it manually, understand what you are using. It's so important. And these containers, there are so many other, they come with stuff, you won't never like it. But pay attention what's in there, it's absolutely essential. Same with the components, but for containers, it seems like, I don't know, people seem to believe that something is so ready to be reused that they don't need to spend the time on looking into it. I don't understand why it's that way. But it's absolutely dangerous. Then the next thing that we want to look at is the inner part. Here we see actually two important things. The first thing that, whatever you do, you should make sure that you resolve the obligations dynamically, because there is a context, it's your situation, it's your IP requirement, it is the business model that's behind it. There are different things that influence the interpretation, and you have to make sure that you really look for the effective licenses, not just the declared ones. There's a lot of stuff out there that is declaring licenses, but unfortunately, it's just a high level view, and deep down there are more licenses, you have to understand this, this is very toxic, or could be toxic. It's not necessarily, but it could be. And finally, when you implement such a process in an organization, you must ensure the accountability. It's so important. That's something that no tooling chain can do for you. This is something that you have to set up aside. It's make sure that people have to stay, for example, or keep their project green. There must be an indicator that saying, hey, approval is done, if not, people will go around. And this is something that no tooling chain can ever provide you with. You have to make sure that people are accountable for the results they are producing, and the tooling chain can be the mechanism to do, to comply, to serve this. But there must be an organizational barrier that's preventing these people from jumping around. There are a couple of uses for this capability model. So why are you taking care of this capability model? It is very helpful, and a couple of meanings. The first is, it gives you orientation when you want to develop your organization. So it can help to implement. This is, for example, these are the dimensions that we typically put into our change projects. There is a process. There is the policy itself. There is also the different tools or tool approaches that we have. There is an OSPORT that needs to be established, and there is the change project itself. And this should follow certain goals. And we typically have a kind of a mechanism that's saying something like, okay, let's put certain qualifications in Q1 so that we can ensure the basic move, and we enrich capabilities. We grow in maturity and professionality. And finally, we step up and increase quality and seriousness of the overall process. So you may want to use this to decide how you want to focus your rollout. This is typically pretty much demand driven. So if there is a business need to protect this or that or that, then you will have different icons put in there than if another need drives the compliance effort. So orientation is one thing that you can derive there. The second thing is kind of understanding of what a certain tool actually can provide you. Here you see a couple of samples. That's pretty simple ones because they're pretty much focused on one or two capabilities each. This is something where we want to get more into. We want to use the model to describe different solutions. And we want to offer this to give orientation on where you could use what kind of service. And especially in combination with the map that we've seen before, the planning, it gives you the orientation or understanding when to look for which tooling. And so growing steps. And this is then the map or the record that can help you on that. It's also good if you want to compare solutions. I mean, you can have now, if you say you want to do a setup and you get these kind of comparisons then you can map the tools and get the promises from probably the vendors saying, hey look, what are you serving and which competence. Here's an outline of the competencies. Are you coping with that? And then the vendor takes the boxes and you can see better understand which might be the right thing for your implementation plan. So these are actually more the benefits. This is also why in the next step we want to, based on this model, we want to grow further in that section. We want to map more tools. We want to build a kind of catalog with this. And I'm happy to get more information. All the one I help are invited to join us and to put in also efforts to close these materials. Probably also it's important to keep them up and running. I mean, if I judge something today, it might be different tomorrow. So it will be an effort to keep this in place. And also there is still some work to do. I mean, currently it's a reference architecture that we've put in there. It's a capability model, overview of things that need to be done. It's a functional view and it can be mapped into different technical architectures. And also there are still, when you look into the repositories, then you will find also an area of comments on each capability description. And these comments sometimes contain questions because there might be different capability to be achieved. Or we could probably do it in a different way or tailor it differently. And these questions, they should be finalized. They should be answered probably or put aside in a documented manner so that we say, okay, we can be sure that this will or will not be done. It will continue to mature the model and probably one day we come up with the reference architecture. Instead of having one that is a version number and going on, probably we can say, wow, this is the reference architecture. Finally there's also important these efforts that they have happened within the tooling work group over the last one and a half years. And there's also an approach to start from the data model side. So having all these components is nice and you saw this tool orchestrator in the background. The tool orchestrator needs to talk to these components, to initiate something, to push an event, to trigger or to receive messages. And so it's absolutely essential that we understand.
 Hello and welcome to the open source tooling chain capability map session.  In this session we want to talk about what is required to automate the most of the open  source compliance tasks.  My name is Jan Thielscher.  I am from EACG, a consulting company specializing in open source consulting.  The creator of Trust Source, which is a software-solution service that is focusing on open source compliance.  Actually open source compliance came to me quite a while ago.  Naturally I studied business and computer science, but also did a degree in law, which  then gives more or less directly into the direction of open source compliance, because  this is a typical mixture of these fields.  That's also one of the reasons why in 2015 when we had very large projects and we were  delivering to our customers, where we used tons of open source that drove us into the  consequences of the understanding of the need for something like Trust Source.  However, I'm not here to talk about Trust Source.  There are other talks.  There's open source tooling available.  A couple of links are shown there.  But what I want to talk about is what is required to automate your open source compliance.  To get towards that, it's good to have a clear vision of what your goal is.  In the end, this is a picture from the open chain.  The idea that you want to create an outbound artifact that accompanies your supplied software  and describes what is in there.  In an optimal world, everything that leaves the company has such a machine readable bill  of materials attached so that everybody who is taking on the stuff can understand what  he gets and what is in there.  Unfortunately, we have to recognize that we are on our way to get there.  Five years ago, there have been other difficulties that we face today.  But still, some tasks have to be completed.  We are not really done with this job.  There is a lot of things to do.  That's also why we have this tooling chain work group, which is actually addressing the  automation requirements here.  Try automation.  Whoever is familiar with the open source compliance task sees that it's essential to have open  source compliance relevant people that are looking for it.  But even if you do it right, it's nothing where you can win good reputation.  In the end, it's kind of a hygiene thing.  It needs to be done, but you won't get an innovation award for it.  It's something that is absolutely essential.  I mean, one of our customers put it once saying when we were talking to the workers council  to tell them why do we have to introduce now tools and measures and audit logs and so on.  He said, well, guys, there is no opt-in or opt-out.  It's just good manufacturing practice.  You have to provide this material.  And that's, I mean, you can't win anything if you do it, but you will lose or could lose  a lot if you don't.  And so that's why actually open source has to be understood as something that has to  be there.  And because nobody really wants to do it, because you can't gain good reputation in  doing it well, it's something that you should automate.  And there's also another couple of tasks that automation is required, because, I mean, you  all know that continuous integration and development, continuous deployment are the  coming things if they are not there already in your organization.  And whenever you do software development, you will push it through immediately to either  a repository or a test environment or probably even production.  But you know that there is with all these package managers, there's always upgrades  and things that go into the software and into the build that require a lot of attention.  And if someone would sit there manually, the total CI CD idea would fail.  So there is a huge demand for automation.  And this is why it's so important to understand what all goes into the topic when you want  to automate the thing.  So it's like designing a system.  I mean, five years ago, when we started thinking about this, we had a very rough understanding  of what should be done.  So all it was clear, there is something that should go on the outside.  So there is a result and we want to have this documentation done.  That's pretty clear.  But the first thing that came up to our mind was, oh, we have to scan the things.  That was first an understanding of scanning sources, because we need to know what's in  there.  Then there was a thinking of, oh, what about actually the parts?  That we are not building by ourselves?  Probably there's something else that we should look at and what is in there.  The same applies later on.  Since a couple of years now, we have the topic of containers.  So containers come with a lot of stuff.  There might also be something in.  So it's all about scanning.  But from the scanning to the outbound artifact, there's still a way to go.  So we need to collect this stuff.  We need to build a kind of a situation.  It requires an understanding of what are we going to do with it?  Is it actually relevant to build a kind of a compliance artifact?  Is there something that we have to take into consideration when we are looking at the stuff?  So we have to understand that we see, we have to assess the stuff that we are using, and  then we have to put it into a kind of a situation project, module, whatever we call it.  And this then someone should review in a kind of an approval saying, OK, that's good, or  that's not good, please do again.  So that we can be sure that it's correct.  So we have a kind of a requirement for an approval.  And whenever we talk about approvals, it's absolutely essential that we know who is doing  what so that we need a kind of users.  And we need probably to decide between those that are producing something and those that  are giving the approval.  So we have roles involved.  And also essential, if you do an approval, it's relevant to audit that this approval  has been has happened.  So it doesn't make sense if you cannot follow up later on who has given the approval.  So audit is absolutely essential as well.  This gives already a couple of requirements for kind of a solution that you have to build.  And then it happens that one project has a component, a second project has a component,  and probably there are more projects using all the same components.  So probably it's a good idea to have a kind of a package or data repository where you  store data that you have once curated or identified and curated there.  And so you do not need to do the same step over and over again.  I think having such a repository is good.  But the data that's arriving from the scan might not necessarily be complete.  There is probably a declared license with something that is not essentially what is  the one that is inside the repository.  So how can this really resolve?  You need more metadata.  And what you can do to get more metadata is to use some kind of package crawlers, crawlers  that are running around searching the Internet for additional information that can be added  to this package data.  Also it might be relevant that you have an option to look up for older versions.  So it's a kind of a source archive that you probably should include into this kind of  repository.  So you can look up data or binaries or things that are probably older and then you can assess  them in a separate approach to decode and understand what's in there.  Following up this, it turns out that it's also a good idea if you once identified that  there is something you don't want to use, for example a component that is out of license  and therefore is not capable to be reused or doesn't give you the right to use it actually,  then you do not want someone else to put it in his project again.  So it makes sense to have kind of policy and rules capability that prevents people from  doing things or pushing things into an approval flow just to hear that it's already denied  by someone else.  So this policy and rules thing is something that really might help you to get on and to  improve the process.  And whenever things are to be improved, a good base to understand how much it is improved  is to have certain kind of reporting and analytics.  So this should be something that is inside this kind of function as well.  Now we start to get away from the basics into the luxury parts.  Also cool to have would be something like a generator for all these kind of compliance  artefacts because it's pretty, I mean when we have a list of 100, 200 or 1000 components,  it's not really fun to assemble this all manually.  So having a kind of compliance artefact generator is something that is pretty helpful or could  be pretty helpful.  To assemble the right things into this kind of compliance artefact it might also be relevant  to have a kind of an understanding of what actually is required.  There is one option to say, okay we do always everything and do the worst case scenario  deployment.  But there is also an option to say I want to take the circumstances and only provide  as much as required.  So I have a kind of a solver that is capable of understanding the licenses and the situational  context and brings this together as the input for this kind of artefact generator so that  it can create suitable stuff.  And in addition to that we recognize and this is also why we put it as a new open source  solution into the market.  We saw that it's only few sources really have the information available or in a place put  together that is required to cope with the challenges for publication.  So the publication requirements, attribution requirements, it's often required to mention  the copyright holder, required to put in license stuff and so on and so forth.  But this is not necessarily exactly or simply to be derived from the package so sometimes  it makes sense to have a more detailed view into a repository to understand what are the  licenses and the copyrights attached.  This is done by such a kind of a license and copyright scanner or could be done.  It could also be done manually but having it automated might be a much better idea.  When you already are doing all this for the open source world we've learned that there  are some regulatory things that might want you to do in the coming off the shelf management  for third party components in the same place because handling it a little bit different  sort of components does not really make much of a difference anymore.  Also nice to have is the snippet scanning.  There is a real source code analysis for already used parts so that if a routine is taken from  somewhere that this is flagged and it says, oh look, this is something that we know from  these tools or probably this might be a copy and this might not be allowed or kind of modification.  But we saw in our practice that it's pretty hard to get this into CI CD because the amount  of false positives is so high and the base can be very narrow.  It's hard to really put this into flow, keep it in time and so often the outputs then are  there and if then else construct that is reused which is partly not too much to protect.  However, given all this, if this is not all done by one tool, it might make sense to have  something that's orchestrating it, keeping track of what's happening so that you can  have a status over all of this.  And now we're done.  This is more or less the capability model that we have developed and that we were generating  over the time of the last years and which is now as a kind of orientation map available.  You can use this to focus on particular parts.  For example, if you look into the outbound components, if you go back to our basic model  and say, okay, this is outbound to be, for example, open chain compliant, I need to have  this ordered log, I need to have the artifacts and if I want to automate it, I need to have  this artifact generator.  You can look on the inbound side and see, oh, there are different sorts of scanning types  that I can execute, probably in my case, just the source is relevant.  In other cases, it might be that there is just the container is relevant, whatever.  Or someone wants to really make sure, he often wants to make sure that the packages used  are really attributed correctly.  So probably they want to do this kind of license and author scanning, which is a very different  task from resolving transitive dependencies when you do the kind of package scanning.  So there is a lot of different things and it's good to understand the differences between  because they are easily mixed up and that's something that we really understood over the  time when we were talking to customers that they get confused by these different tasks.  And that's why we put this model out there.  It's available.  I will put on the links later on so that you can follow up and dive deeper and all these  tasks that I have described, they are described there and laid out and you will find responsibilities  and things broken down for this stuff.  When we were talking about inbound, there's one thing that I really have to go about.  I put it in an extra bucket because it's not, wherever we go, we find people just taking  containers as they are, even if you take a component, a software component, it's difficult,  it's dangerous.  So please, whoever is going to reuse things, make sure that you understand what's inside,  either by scanning or by just decomposing it manually, understand what you are using.  It's so important.  And these containers, there are so many other, they come with stuff, you won't never like  it.  But pay attention what's in there, it's absolutely essential.  Same with the components, but for containers, it seems like, I don't know, people seem to  believe that something is so ready to be reused that they don't need to spend the time on  looking into it.  I don't understand why it's that way.  But it's absolutely dangerous.  Then the next thing that we want to look at is the inner part.  Here we see actually two important things.  The first thing that, whatever you do, you should make sure that you resolve the obligations  dynamically, because there is a context, it's your situation, it's your IP requirement,  it is the business model that's behind it.  There are different things that influence the interpretation, and you have to make sure  that you really look for the effective licenses, not just the declared ones.  There's a lot of stuff out there that is declaring licenses, but unfortunately, it's  just a high level view, and deep down there are more licenses, you have to understand  this, this is very toxic, or could be toxic.  It's not necessarily, but it could be.  And finally, when you implement such a process in an organization, you must ensure the accountability.  It's so important.  That's something that no tooling chain can do for you.  This is something that you have to set up aside.  It's make sure that people have to stay, for example, or keep their project green.  There must be an indicator that saying, hey, approval is done, if not, people will go around.  And this is something that no tooling chain can ever provide you with.  You have to make sure that people are accountable for the results they are producing, and the  tooling chain can be the mechanism to do, to comply, to serve this.  But there must be an organizational barrier that's preventing these people from jumping  around.  There are a couple of uses for this capability model.  So why are you taking care of this capability model?  It is very helpful, and a couple of meanings.  The first is, it gives you orientation when you want to develop your organization.  So it can help to implement.  This is, for example, these are the dimensions that we typically put into our change projects.  There is a process.  There is the policy itself.  There is also the different tools or tool approaches that we have.  There is an OSPORT that needs to be established, and there is the change project itself.  And this should follow certain goals.  And we typically have a kind of a mechanism that's saying something like, okay, let's  put certain qualifications in Q1 so that we can ensure the basic move, and we enrich  capabilities.  We grow in maturity and professionality.  And finally, we step up and increase quality and seriousness of the overall process.  So you may want to use this to decide how you want to focus your rollout.  This is typically pretty much demand driven.  So if there is a business need to protect this or that or that, then you will have different  icons put in there than if another need drives the compliance effort.  So orientation is one thing that you can derive there.  The second thing is kind of understanding of what a certain tool actually can provide  you.  Here you see a couple of samples.  That's pretty simple ones because they're pretty much focused on one or two capabilities  each.  This is something where we want to get more into.  We want to use the model to describe different solutions.  And we want to offer this to give orientation on where you could use what kind of service.  And especially in combination with the map that we've seen before, the planning, it gives  you the orientation or understanding when to look for which tooling.  And so growing steps.  And this is then the map or the record that can help you on that.  It's also good if you want to compare solutions.  I mean, you can have now, if you say you want to do a setup and you get these kind of comparisons  then you can map the tools and get the promises from probably the vendors saying, hey look,  what are you serving and which competence.  Here's an outline of the competencies.  Are you coping with that?  And then the vendor takes the boxes and you can see better understand which might be the  right thing for your implementation plan.  So these are actually more the benefits.  This is also why in the next step we want to, based on this model, we want to grow further  in that section.  We want to map more tools.  We want to build a kind of catalog with this.  And I'm happy to get more information.  All the one I help are invited to join us and to put in also efforts to close these materials.  Probably also it's important to keep them up and running.  I mean, if I judge something today, it might be different tomorrow.  So it will be an effort to keep this in place.  And also there is still some work to do.  I mean, currently it's a reference architecture that we've put in there.  It's a capability model, overview of things that need to be done.  It's a functional view and it can be mapped into different technical architectures.  And also there are still, when you look into the repositories, then you will find also an  area of comments on each capability description.  And these comments sometimes contain questions because there might be different capability  to be achieved.  Or we could probably do it in a different way or tailor it differently.  And these questions, they should be finalized.  They should be answered probably or put aside in a documented manner so that we say, okay,  we can be sure that this will or will not be done.  It will continue to mature the model and probably one day we come up with the reference architecture.  Instead of having one that is a version number and going on, probably we can say, wow, this  is the reference architecture.  Finally there's also important these efforts that they have happened within the tooling  work group over the last one and a half years.  And there's also an approach to start from the data model side.  So having all these components is nice and you saw this tool orchestrator in the background.  The tool orchestrator needs to talk to these components, to initiate something, to push  an event, to trigger or to receive messages.  And so it's absolutely essential that we understand.
openchain_capability_model_0_179.png openchain_capability_model_180_1163.png openchain_capability_model_1164_2759.png openchain_capability_model_2760_4199.png openchain_capability_model_4200_4703.png openchain_capability_model_4704_8939.png openchain_capability_model_8940_9527.png openchain_capability_model_9528_9755.png openchain_capability_model_9756_9899.png openchain_capability_model_9900_9959.png openchain_capability_model_9960_10967.png openchain_capability_model_10968_12587.png openchain_capability_model_12588_15527.png openchain_capability_model_15528_25319.png openchain_capability_model_25320_25895.png openchain_capability_model_25896_29423.png openchain_capability_model_29424_32747.png openchain_capability_model_32748_34103.png openchain_capability_model_34104_34295.png openchain_capability_model_34296_35471.png openchain_capability_model_35472_35555.png openchain_capability_model_35556_38111.png openchain_capability_model_38112_42695.png openchain_capability_model_42696_42818.png