How the TOGAF Standard benefits Enterprise Architecture (EA)
For the next 45 minutes. We'll talk about TOGAF standard and enterprise architecture in a more general context. Our expert here today is Ben Kalland and well, maybe we start with the short introduction. That's what's your background for this topic and the otherwise. So yeah, thank you for having me. I'm a trainer and I have a collection of training areas.
I train. Most of them are frameworks. I show you a sort of a meta framework here because when we are in IT we could Organize our activities into a few large boxes. We design things. We develop things according to the design.
We then deploy the services or software or whatever we have designed. Then we operate it. But we also need to plan everything to govern and to improve. And for each of those that there are frameworks that fit the particular needs. Here we can see if we are in the operational part.
Service management, for instance, ITIL is a good framework. But today we are going to talk about TOGAF, which is a framework mainly for planning and designing. ITIL is not very good for that. If you are mainly interested in improving things, lean would be a good framework. If we are developing software, for instance, Scrum could be a model for that a deployment project could be organized according to PRINCE2 If we want to govern everything, then COBIT is a framework that's suitable for governance. So what we are mainly interested in today is this part.
We are planning and designing things. We used the word enterprise architecture for describing the activity of planning and designing how an organization works. So we are mainly going to talk about those. I may mention occasionally some of the other frameworks, but this is the main topic for today before we actually go more into architecture directly. How do you see these frameworks? Do they work nicely together or I mean, would you choose some and then stick to that? Or how do you do it? There's the classical answer from any consultant.
It depends. You can actually have a situation where you use all of these frameworks in the same organization. This nothing preventing you from doing that. However, you need to be aware that they are all somewhat incompatible in terms of terminology. They may use the same term in different meanings, or they may talk about the same thing, but use a different terminology just as an example in ITIL we have a concept called practices. We have the same concept in TOGAF, but it's called capabilities and the same concept.
In COBIT and it's called management objectives. So you just need to be aware that there's no such thing as a common framework for everything. A framework to rule everything. So just you can pick and choose and you can create your own version of this because you need to do in the organization. You need to decide which is your sort of go to framework. What is the terminology you're going to use.
All of these are adaptable. You can change them according to your needs, but yes, it's possible to use all of them at the same time, and many organizations use more than two or three of them. I'm not sure if I've ever seen one organization that uses all of them, But yes, there are many other frameworks.
For instance, DevOps would be somewhere here between operation and development. And FitSM would be very close to the ITIL here if you could basically put any common framework in this image just to show the relationship. Yeah, you mentioned the different terms and the, the one things what might be good to clarify regarding TOGAF: It's called enterprise architecture. So, well, first of all, enterprise is it only for the big, big things, big companies. The other part is, of course, the architecture. So yeah, what is enterprise architecture? Let's take the first part.
What is an enterprise? You could have the wrong impression that the enterprise means that it has to be a huge multinational organization in order to have some kind of enterprise architecture. In this context, enterprise means anything. It could be a small group, it could be the whole industry. In some cases it could be a government department. It doesn't have to be a for profit type of enterprise.
So it's quite an umbrella term, meaning any organized activity, it can be an enterprise. And that's a follow up question to that, of course, is do we need enterprise architecture for all companies? I would say no, because there are small companies. Let's say you have a coffee shop or a restaurant. It would be rather stupid to have a very organized enterprise architecture for such an organization. There's a term for stupid in Lean.
It's called waste. You don't want to do it. Waste is when we invest resources and we don't get any value out.
So I wouldn't advise a small restaurant to go and do some enterprise architecture. It's mainly interesting in a in a situation where you have quite a lot going on, you need to understand what's going on and that's when you need the, the architecture. So what is actually architecture? Many people, when we talk about architecture, think about buildings, and that's natural because that's the most common way of using the term. But it's not only buildings that have architectures.
A city has architecture, an organization has architecture. So you could say that the art of architecture is to the describe how something works, what are the parts of it and how do they fit together. So when you talk about organizations, then we need to know what is our business model, what kind of processes, what kind of services do we have, what kind of software I'll be using, How is our data flowing here? What kind of technology do we need? So all of this is under the umbrella term enterprise architecture. So you could talk about business architecture, you could talk about technology architecture, all of these sort of under the same term. So architecture or in this case enterprise architecture, is describing how do we do things, how do we do it now? And more importantly, how are we going to do this in the future? So we talk about the what we have now as is or in TOGAF speak it's the baseline architecture. And then we have the to be or TOGAF speak it's the target architecture.
So you describe the organization, model it, and then you communicate about this to other people. That's why you would need an architecture. Okay, well then if we talk about more closely about TOGAF you already mentioned a few things about it, but briefly, I mean, while TOGAF is rather large entity, but briefly, how does TOGAF work and what do you do with it? Actually, I already mentioned that from TOGAF a point of view how TOGAF see is that you have a so-called domain. So we have an area of business architecture, information system architecture and technology architecture, but you could actually use it in any way you feel.
If you feel that we need a process architecture or a service architecture that's potentially all right, you can use TOGAF for that. And the structure of TOGAF is that there's a method called the ADM the architecture development method, and then there's a number of separate documents describing different parts of it. So there's a document describing how do business scenarios, there's one part that describes how do you create the repository for TOGAF and so on. It's modular.
So it's a number of different sort of independent documents and TOGAF is a collection term for all of this. Well, ADM is is kind of the crucial or the most central part of TOGAF. So maybe you could say a few words more about that one. Yeah. Let's have a look at the ADM.
The most common metaphor for ADM is that we have this kind of image where we have a number of circles. There are phases, so TOGAF’ ADM is architecture development method. So this is basically a method where you follow a systematic approach to do the architecture. So let me talk you through this, how it works up there. We have something called a preliminary phase.
This is something you do basically only once. This is where you set everything up. You hire architects, you decide on what the tool you're going to use and decide in the budget who is going to do what. So you do this once and then when it's done, you're good to go and then you can start doing actual architecture. So this is not really architecture, but this is setting everything up.
So that's basically if you haven't been using TOGAF before. Exactly. That's you need to do something.
So the trigger for preliminary phase is, we need to do something. And the end point of the preliminary phase is that now we have established an architecture capability and then when you actually do the architecture, then you'll always start from A and then you go this way through the phases. So I'm going to talk you through this briefly. So how does this work and what is the benefit of having a such a structured approach to doing architecture? The first phase architecture vision is really about scoping. So this is about understanding what we are supposed to do and how much, how deep, how broad for for whom, what is the point of this. So this is the discussion you have with the whoever has or I should have sort of asked you to do the architecture so you have a sponsor or some kind of stakeholder that says, let's do this thing.
And the A phase is about understanding, what do you mean? If the request for architecture work is very good, then you can start doing architecture, But usually it's not. Usually it's a bit vague. You need to plan that and then you need to ask more questions. What do you mean? Do you mean this or do you mean that? So this is really about scoping and this phase ends when we have agreed on the scope. So you get permission to do it to continue with the actual architecture work. But you could say that in the vision phase you do at least some kind of high level architecture work because you can't go further unless you have some kind of common understanding of what are you supposed to do here? So this is always this is compulsory according to TOGAF.
You always have to start with A you can't start with migration planning unless you have a if you have some kind of of common understanding of what this is about before you do anything else. But then the next is we have three phases here. We have business architecture, we have information system architecture and technology architecture. These three are basically the same.
It's just that they are interested in different domains, different areas. So the order can be anything if you don't have to start it. And because if the business architecture is already there and we don't need to change it, just go directly into the information system architecture, or we can skip even that and just look at the technology or the other way around. They don't go anywhere near those to be just due to business architecture.
So there's no order. They just are this order to make the image look nice. So it's basically at the same time you can do it at the same time. Yes, you can go back and so on.
So these are the phases where you actually do the architecture. This is architecture work. So as input, you have a common understanding what are you supposed to do? And the output is the architecture.
So this is paperwork, You do plans, you do designs, and you put them all into the repository. So after these three phases, you already have some kind of architecture, But then you have two more phases here. Both are about migration, planning, the name of the phases of opportunities and solutions and migration, migration planning.
But as you can see, a diagram, there's something called transition planning iteration. So you iterate between those two. And the main difference here is that the Phase E is mainly about creating a high level roadmap. In what order are we going to do things? Because usually when you do architecture, it's not something you can do it as one project the next month. It's usually something that goes over several years and then you need to have some kind of roadmap.
What are you going to do this year? What I've been going to do next year, What are we going to do to a year after that? And when the roadmap is somewhat ready, you go deeper into the migration planning. You look at the projects, what kind of budget do you have, what kind of resources do you have? And you make a particular project plan and then you use whatever project management method you have in the organization. TOGAF is neutral. That does not mandate the specific method. You can use anything, you can use PRINCE2, or you can use any something you invented yourself.
It doesn't matter. But this is really project management or really more correctly planning for the project that is not really doing the project yet. It's just for planning. So you iterate between those two phases until you have a migration plan.
So in short, architecture vision is about understanding what we are going to do. B, C, D is about actually doing it and then E and F is about planning for the migration in which order with whom, who is going to do what and where do we get the money to do it? And in the TOGAF model now the architecture is official, now it's approved, it's somewhere in the repository and after this it's under the change control. You can't change it unless you have a change management process for it. Up to that moment, you can change anything. So if an architect thinks that it is actually bad, I'm going to do it in a different way.
That's just business as usual. That's something you are allowed to do. There's no change management as such. Of course, we may have some change management in the project if you go of a budget or something, but it's not really a change management for the architecture. But when you are finishing at the if, then the architecture is, so to speak, upload a step or some kind of approval and then it should be under change management because otherwise what can happen is that somebody changes something. And we don't know because there is no model for doing that.
And then you have the next phase, which is called implementation governance. This is not really architecture work in the sense that it's not about modeling something or making diagrams, it's about controlling the implementation. So when we do architecture, you have to be aware that if you do not control the implementation, you are basically giving them free hand to do what they want and why. But what is the point of architecture if you don't somehow govern the usage of architecture? So implementation governance is about making sure that whenever they're seeing an implementation project that they do follow the architecture. So and of course, this should be some kind of governance model. What are we going to do if somebody is not compliant? What are we going to do if they have a good reason to do something differently than what the architecture say? So we should have some kind of governance model for how to do that.
But the phase G is really about governing the implementation. It's not the actual implementation doesn't take a stand on both how you do a software development, for instance, it just says that it has to follow the the architecture and we have a model of how to govern that. And then the last one of those circles is called architecture change management.
It's called the phase, but it's not a phase in the sense that when everything else is done, then you do change management. This is something that can be done at any time. But this is about controlling changes to the architecture. So the results from that can be no, we are not allowing any changes.
So that's called architecture enforcement. And then we can have a dispensation, which means that we're not going to change our architecture. But you are allowed for a limited time to do something else. The reason could be money, time, risk …something like that. So we have a phase called change management that that is mainly interested in, in, in controlling the changes to architecture.
And then in the middle you have something quality requirements management that is also not the phase in the sense that it's not something that happens after everything is, it's always there. And you can see that the arrows goes from both directions. So anywhere, anytime an architect creates something new, they need to have a look at the requirements management. Is there any requirement I need to be aware of the care of? And also it might happen that an architect gets, uncovers a new requirement but didn't know that's Actually an requirement.
He puts it into the requirement repository. So this is a structured way of working. That's the point of the ADM.
Instead of having a sort of an ad hoc or improvising style of doing things, we have a systematic approach, divided interfaces, and that gives a structure to the architecture work. So would you say that's the main benefit of using TOGAF? or what do you say, what, what are the benefits. So it's a rather heavy model in a way. Yeah, it's true it look might look the quite bureaucratic because there are a lot of inputs and outputs and and documents and deliverables going here and there. The benefit would be that instead of having an unsystematic way that everybody does things in different ways. You have a controlled and auditable way of doing things.
So you can say, Are you done with this phase? Do you have this deliverable? Can I check it so it gives you a systematic way of doing and usually this is a good thing. TOGAF however, allows you to go outside the model. It's not a prescriptive model in the sense that you have to do this in order to be compliant. This is just a template for how you could organize your own work. Actually TOGAF says that in the preliminary phase.
Then you start doing architecture work. You should take TOGAF and adapt it to your own needs. It's not intended to be used as such.
It's intended to be adapted and tailored to your own organization. But this is not the whole picture of the TOGAF. There is more. There is more
Usually there is more. The reason I wanted to start with this is that very often when we talk about TOGAF we are actually talking about the ADM so that people say that we are following TOGAF for what they are actually saying. We are following the ADM, but there's more. There's a, for instance, there's a set of tools you can use or technologies or techniques you can use for all of these. For instance, how do you do that? All these is how do these risk analysis, how do you do business transformation, readiness? All of these are collected in a in a special document that it's called Techniques. There's another document that describes the repository they're going to use.
And I'll show you a set of other documents here. These are all separate documents. They are part of the trigger standard. For instance, if you're interested in value streams or business capabilities of business models, you will find about 50 pages each, a document describing those business scenarios. There's a very good document called the Practitioners Approach Following TOGAF’ ADM that's written by an experienced, experienced or maybe a couple of experienced architects.
And it's very different from the TOGAF itself because TOGAF itself looks like a list of giant checklist. This is more like a book where you how you actually use this. It's free to use it's 160 pages.
So it's really a book it's not particularly adapted into. Obviously, it's something you read for a week because you would really need to think about all the things. So there are a lot of additional content beside the ADM explaining the ADM, but still ADM is the core of the idea. You can't really say that you're using TOGAF if you use everything else, but not the ADM.
That sounds a bit strange. So. So yeah, ADM is the the heart of the TOGAF standard. There's a question that what's the cost of using TOGAF? You mentioned it's free, some parts. Yeah. Let's talk about cost of course the actual use it's free, it's readily available.
It's again, if you print it yourself, it's free, you can buy it as a book and then it costs you like a book costs. It's a few dollars, a few euros. It's not much. There's no licensing model that you have to buy to be able to use it. If you want to use the TOGAF a trademark, then for incentive, If I train a course called TOGAF something, then I need to pay a license fee for that.
But if you're talking about an organization that wants to use the figures for themselves, that's free. But actually nothing is free in life. So of course it costs because you need architects and you need to train them. That's probably going to cost something. And of course it takes time. That means all all of this money.
I don't think anybody can answer the question how much how much does it cost to use it? You could turn it the other way around. How much does it cost you if you don't use TOGAF? Because actually it gives benefits to you, and if you don't use it, you won't get those benefits. So it depends on what you are counting as a cost. But yes, the standard itself is free.
So basically you can go to the website of the Open Group and get them to send it from there and then study yourself or however you want to do it and implement it. The best way to what you can do. But there is not licensing fee.
No, no licensing. Yeah, yeah, yeah. And the related to that one is that I mean, can the company be kind of TOGAF certified? Actually, no, there's no such thing as a certification for an organization like you, You could be a certified against ISO 20,000 or ISO 19,000, 9000 or something like that because you can use TOGAF in so many ways.
You can use part of it, you can use the whole thing, you can pick and choose. So there's no certificate for an organization, but there are certificates for users. So you can certify an individual that I know enough about TOGAF So there is an training process for that.
And then you can get the certificate that, yes, you have understood the most part How TOGAF works that's very similar to how ITIL works. There's no such thing as an ITIL compliant organization, but there are ITIL certified individuals who have taken the course And passed the test. And then basically these individuals kind of had the responsibility to bring the right way. Exactly. And that's one. So what actually the levels for them, the individual.
But I see I think I have you have two levels. You have the foundation level, it's also called level one. And then we have the practitioner level, which is called level two. It used to be called Certified, the second level. But now with the newest version of TOGAF, it's called Enterprise Architecture Practitioner, and the first level was Enterprise Architecture Foundation. Both are usually two day courses and both end in a certification test.
They are quite different. The test, the first test is a typical foundation test. Which of the following is or is not something. And then you pick a multiple choice and you have 40 questions and you need to get 24 of them. That's 60% right.
For the practitioner level, it's very different. It's only eight questions, but they're long. It's a huge scenario. And then they ask, you are now the lead architect, What would you recommend as the next step? And then you have four different answers. If you ask for the best one, you get five points.
Answer pretty good. You get three points. If you get a bad answer then one point and you get it really, really bad, you get zero points and then you need to get enough points too. So it's it's very difficult. It's also a multiple choice, but it's not like you can just pick very quickly.
This is the right thing. So you have to really think about it and it takes some time. But having said that, many people think actually that the practitioner test is a bit easier because it's applying. You don't have to know anything by heart. You can it's an open book test.
You can have TOGAF open, you can check anything you want to check. And it's really about understanding. So it's people usually like that kind of test more than the foundation test.
What is the difference between compliant and consistent and conformant? And then you scratch your head, then you're not really sure how well it says practitioner. So yeah, because it is practicing TOGAF. Yeah, well then you have this also over here mentioned the Bridge. So actually those people who have already passed TOGAF 9 certificates and they have passed the second level.
So they are TOGAF 9 certified. They don't need to take any of those. They can take something called a Bridge except it's a one day course and a short exam. And the content of that is only what has changed in the newer version. So you don't need to go through everything here. Unfortunately, it's not possible if you have TOGAF 9 foundation only to take the Bridge. Then
you have to either get the certification and then take the Bridge, or then you have to go through both foundation and practitioner. And actually not surprising there. The question that what then is the major difference between the TOGAF the new version and the previous version? Yeah, let's go back a few steps here. I talked in depth about ADM.
This has not really changed that much. The are minor changes, but basically it's the same. However, what has changed is the structure of TOGAF and there's a lot of new information. So I'm going to show this again. Look at this.
Applying of ADM using Agile sprints really, really new.Nothing about that in the old version, the digital technology guide, the readiness assessment, the roadmap development that is new, the leaders guide establishing and evolving in a capability to take TOGAF standard into this digital enterprise that's new. So basically you could say that TOGAF has evolved into the new thinking of agile and digital that was not present in in the Older version. There's a 1 to 1 microservices architecture that also did not exist in the TOGAF 9.
And actually we have a new government reference model. So and many of these also are updated from, from the old version. So the ADM as such, not much changed, but almost everything else has been updated and has been enhanced.
They've been digital and agile thinking. So that's the main difference here. In the foundation course, you won't see that much difference. a little bit, but
not too much. In the practitioner course it's quite a lot of difference compared to the to the old version. So would you recommend updating to the new version if you have the previous one? Absolutely. Let me show the first here. Most of those frameworks have a version number.
Actually PRINCE2 not the version number. I think it's just a it's just PRINCE2. Or it was the number of points that method formerly known as PRINCE.
Anyway, we had we are not talking about TOGAF the 10th edition. We're talking about COBIT2019 And ITIL 4. There's absolutely no reason to study any of the old versions.
So if you are new to this, always take the newest version, it's like you're using the the newest map you can get by using an old map. But occasionally you will find that it's not valid anymore. So always go with the new one. And then the second question, or maybe the even the actual question, if you are already certified, do you actually need to recertify? It depends on the situation. If TOGAF for you, it's only something nice to have that looks good in your CV. Maybe you feel that it's not worth spending too much time on finally getting it updated.
But on the other hand, if what you do is very close to what is new in TOGAF, if you do something with Agile, if you do something with digital or something like that, it probably is worth taking the bridge exam. So depends on, on, on. How do you actually see TOGAF in your own situation? I would always recommend to have the newest version of any of those frameworks. How many individuals there actually are worldwide with the TOGAF certification? Roughly, I forgot to check the exact number, but about 130,000 all over the world. That's all versions. Actually, only about 100 of those are for the latest version.
So if you take the latest version You will be in a very elite group with, with very, very little competition in that area, at least for a while. At least for a while, Before most of the people update to the versions. There is one question you briefly mentioned about the TOGAF providing different kind of methods to do the things. Is there some specific tools that should be used in TOGAF? Is it kind of integrated to some of the tools? Actually TOGAF is very agnostic about tools.
It doesn't specify or mandate anything you can do use TOGAF with any tool. So basically have a paper and then you can, you can basically do architecture with TOGAF. So it doesn't need to have a tool.
But there are of course quite a lot of different tools that are more or less TOGAF compliant. I don't see it as a necessary necessity to have a tool that is completely compliant because you will change it anyway. You adapt it to your organization. So you don't need to have a specific tool for that.
There are some tools that sort of have the Open Group approval, but it's not, I don’t see it as necessity and the continuation question Was about Archimate this is about Archimate because Archimate is also something that the TOGAF, err Open Group owns, but that there's no link between them in the sense that you don't need to use Archimate if you want to use TOGAF you can use any notation language you wish, but of course if you study Archimate you will realize that it fits very well into the TOGAF framework, so it might be useful, but it's not necessary. Okay, good. Then there's some question about Agile in there. You briefly mentioned, this agility somewhere here Agile sprints. How do you see how agile TOGAF is? Actually, yeah, it's a good question because if you look at the ADM, it's very easy to see that this is actually the history of this is a waterfall method and it still shows in the sense that TOGAF it sort of implies that then you have the vision, you have the big picture, and then you go deeper and deeper and deeper until everything is done. However, when you if you're talking about, for instance, software development according to TOGAF you can very well in phase G, that's where the agility applies.
You can really well use TOGAF as the model for doing architecture and then use whatever scrum or whatever Agile method you want to use in the software for development. It works very well and there's actually the document describing how to do Scrum. According to TOGAF, another question or other sort of facet of the question is, is TOGAF itself agile? And again, basically no, but in practice, yes, because you can do these planning iterations, however agile you want, you can do it, but they're very quickly too expensive you want. There's nothing preventing you from them.
But having said that, of course you can see in the language and and the way they describe it that the history of TOGAF really is in the nineties. So you can see some of this, but it does take a lot of steps into the agile world. So I would say that it's very, very possible to use TOGAF often in our organization that these already agile So and then there are some well kind of a comment that it's looks a little bit complex which it might look is there kind of like a smaller version or easier version or something like? A TOGAF light? yeah, not really in the sense that the Open Group does not provide you with a scaled down version, but it does allow you and actually encourage you to scale down so you can take TOGAF as it is and then decide we are going to skip some of the deliverables, we are going to skip that phase because it's not relevant for us for instance, in Finnish government, they use a scaled down version of TOGAF.
This may be one fourth of the full version. It's been translated into Finnish. It's called JHS 179.
For those of you who speak Finnish, it's basically a TOGAF clone with everything that is waste taken out. So you can do that. Then you can make a very small version of this, but you have to do it yourself. There's no model that you can take. That this is the the most important thing that you need to take. You have to decide on yourself what is what you want to include.
Probably because it's it's very different for different kind of organization. So it's probably not useful to create TOGAF light version. You could do it, but nobody has done it, at least publicly.
So I'm not aware of any any sort of smaller version of TOGAF that would be publicly available and useful as such, except this Finnish version which actually is available if you speak in Finnish, but it's only in Finnish Sorry for language barrier How do you see about TOGAF evolving in the future and do you think it continues to be relevant in the future. Yeah. Let me show this again. Most of these frameworks are evolving.
Then they realize that the world changes, then they add things, move things. So it's true for ITIL it's true for COBIT, and it's definitely true for TOGAF. TOGAF is modular, so it's kind of easy to just add one more thing to it, maybe take something out.
So perhaps we don't need to have a new version in the future. Maybe it's just a small update and then let's say blockchain becomes a big thing in architecture. Then maybe there's just a 30 pages on how to use blockchains in this kind of architecture, and it's added maybe the digital library or maybe through the standard itself.
But because of the modularity, it seems to be rather easy to do add later. So I definitely think that they should be working on and work done in the background and usually maybe 5 to 7 years something happens and there's a new version. Yeah, and basically that's how it has been. So before this one was the TOGAF 9 and there was a little bit modified Version 9.2. Yeah. So probably at some point they might as well be modified from this. Yeah, yeah, yeah. Okay.
You actually were involved in the when, when this TOGAF the latest version. So the 10th edition was, was developed, you, you were involved in this beta stage of the testing. Any, any comments of that? Yeah. Maybe I can tell you something about that.
I did sign an NDA so I'm not really sure how much I can tell you. I was not really something that you can really involved in the actual standard. The standard works the way that there are people all around the world who are members of Open Group and they voluntarily volunteer their day to do it to create the standard.
I was involved in the beta testing of the new version, so I had to look at the exams. I took them myself and I commented every question, Is this a good question? Is this a stupid question or is this actually one question was completely wrong. So I made a comment about that and within two days they changed it.
So I did have some effect on how the TOGAF will be tested and they are live now with the test. So that was my role. I saw some previous versions, so I'm aware of some last minute changes that they've made to the TOGAF standard, but I'm not sure if that's even interesting. This is what it is and it will will then develop from there. Just in an interesting exercise, though, to see how these things actually happen, who writes the questions and how do they then make the sample exams and things like that. So it was kind of eye opening.
No, I mean, after all, it's a world wide standard and basically it's more or less everybody in the world is or can be involved. So yeah, but yes, so the new version is live and, and also the testing and certifications available are available on the websites and well, actually, I mean we basically have spent all the time what we have. So I think at this point it would be good to mention that this webinar is recorded and you can find it in the future on the websites, both in Tieturi and Informator so you can share it with your colleagues if you want to. And we're going to have another webinars coming up, so see them on the website also and please register for those. And then as said, I mean, there are these training courses and tests available.
So if you think that TOGAF could be interesting for you, then please check this ones and consider that if a career in architecture would be your choice. So yeah, thank you very much. Thank you. This has been really, really a good session. So have a very good day, everybody, and I hope to see you on, at least on the webpages.
2023-02-22 20:29
