TOGAF 9 OG0-091 Part2 – Advanced Topics for TOGAF Part 2

5. Partitioning Enterprise Architecture

Hey there. Welcome back. In this video we’re going to talk about partitioning the enterprise architecture. The requirement taken from the Toga 9. 1 part Two exam requirements says how enterprise architecture can be partitioned to meet the specific needs of an organization within the Toga specification. The concept of partitioning means that you’ve got multiple groups of architects working on the overall enterprise architecture independently and how do you manage those independent pieces so that you avoid some of the problems of having people working that way. So you can see here that there are several reasons why architectures are partitioned.

So you may have cases of really large organizations where individual specific architectures end up being in some type of conflict. For example, you have a group of entities that use Microsoft Windows as their standard and all of your architecture principles and your requirements to say that the architecture must follow this standard is based around that kind of decision. And then you’ve got another group within the same overall umbrella that has a standard for Linux boxes and open source operating systems and those architectures are in conflict.

And you can’t have a set of architecture principles or technical principles that say we are not going to try to include solutions that don’t run on Windows, but then these guys don’t even have Windows. So there’s going to be some reasons that you’re not going to be able to do it as one overall architecture. But that doesn’t mean that these things need to be completely different. You need to be able to manage those and have a governance model on top. You may also have lots of projects going on at once, a large group of architects.

You need to allow people to work independently and not be bogged down by processes and meetings and waiting for approvals. And finally, if you’re doing it right, you can develop these things in sort of a modular way where architects are working on one piece and then other architects are working on the other. And then when the solution gets brought together, it’s a great, wonderful solution, but it just didn’t come from the brain of a single individual. So there’s different reasons why they’re done. Now the thing about the Toga spec is that there are certain steps that you’re going to want to do within preliminary phase in order to handle this partitioning. So the preliminary phase is when you’re deciding, for instance, the organization model for enterprise architecture.

This is how you do architecture. And so you’re going to need to define the structure, define the roles and responsibilities, who’s doing what, how things are related within the preliminary phase and everyone gets an understanding of whose job it is to do what. And then there’s an integration piece that you come back later and you say, okay, we want to have one overall view of the architecture within the organization. You want to make sure that different groups are doing architecture in a similar way because you may have one group that has a very mature eight out of ten capability for architecture, and then another group in the same company that has a two out of ten.

And you’ve got to sort of manage that and make sure that everyone’s operating up to certain standards and that if they’re going creating certain artifacts and certain documents over here, that they’re should be creating those same ones over there. So that’s what the Togaspect means about partitioning. Coming up next, we’re going to talk about the purpose of the architecture repository. Stay tuned for that.

6. The Purpose of the Architecture Repository

Now we’re getting into the purpose of the architecture repository, that is the requirement of the exam within the Toga Nine specification, the architecture repository. The concept of it is rather central to Toga. I know we say that the Adm is the central process of TOGAF and the central theme, but all of those documents and all that stuff that comes out of the Adm and all of the other processes within Toga get stored within the repository. The repository contains six classes of architectural information and you may have heard these terms, but this all comes together here. So this is the architecture met model, the architecture capability, the architecture landscape, the standards information base, the reference library and the governance log. All of these things live within the architecture repository. So you can see on screen a diagram that outlines the relationships between those things. So the architecture met model is obviously the model of which you perform architecture.

So the architecture development method and then the content met model we talked about in a previous video, all that feeds into the architecture landscape, which is your BDAT, your definitions and your requirements that come out of that. The reference library, standard information based, these are the left side of the enterprise continuum. These are the more generic things that come through the foundation and the industry type architectures. That all feeds down into the governance log, which is a record of the governance within your organization, how decisions have been made, compliances, any sort of capabilities, all that stuff. The calendar of decisions, the project portfolio, et cetera, all the way down to the capability, which is the actual things that your organization can do in terms of architecture. So you can see all these relationships on screen. Coming next, we’re going to talk about iteration within Toga. Stay tuned for that. Thanks.

7. Iteration

So we’re getting closer to the end of the requirements for the part two exam here we’re talking about iteration within TOGAF. The requirement specifically says how to apply iteration and different levels of architecture within the a.m. If we look at the iteration diagram within the tough specification you can see here there is actually a number of types of iteration that can be done. And so look an example. There’s this thing called architecture development iteration and you can see as you get into the Bdot phases BC and D you can go all the way through that, through to migration planning and then loop back around again and go back to B. And this concept has to do with getting a little bit deeper. So maybe the first pass through BDAT you’re on a very sort of not as deep level, but you just want to get through it and get a sort of preliminary document.

And the second pass through it, you get a bit deeper and more into the details. And the third pass through it, that is a style of doing the adm that is actually provided by and described within this document. You’ve also got other types of iteration like the transition planning iteration allows you to go through the opportunities and solutions back into migration planning but then back to upward opportunities and solutions and then back to iteration planning again. You don’t have to make all those decisions and details and have only one pass at that. You can go do it a second time which allows you to get more details and as more facts come to life. Same between implementation governance and change management. That’s a governance model. You go in between managing those implementations and then managing change about implementations, et cetera. So the document is quite clear in terms of the different iterations. That’s pretty much it for the requirements of the exam. Coming up next, we’ll wrap it all together into the conclusion section. Thanks a lot.

8. Adapting the ADM for Security

So in this lesson we’re going to be talking about how to adapt the adm for security. Now we all know that security is a huge concern right now. There’s a lot of high profile cases that have been making the news in this year. And last year Sony Pictures got hacked, Home Depot, Target, all the credit cards got stolen and even the most highest profile targets are unable to secure systems. But what these hacks are telling us is that some obscure details are important. So in the Home Depot attack, the hacker actually used a user ID and a password from a third party vendor who had login credentials into their corporate network. Once they were inside the corporate network, they were able to sniff around, find other machines that were on that network. And they found one server that had unpatched version of Windows. Wasn’t up to the latest security patches and they were able to take control of that server and from there they were able to get access to the pointofsale terminals and be able to capture all the credit card and email addresses of people. So that is an obscure thing. You think that you have this server and it’s not on the public network, it’s on the internet.

Nobody’s going to get access to it, but people find their way in. So if security is a big factor for you, if you’re working on a system that has some interface with the public, could be accessible from the outside, then there are modifications to the adm to handle that. And as you know, security is something you need to think of from the start, but it’s not something that you sort of tack on the end of the project. You don’t get all the solutions ready, get ready to launch and say, oh yeah, by the way, we should throw a firewall in the front of it. No, you put security through and through. You bake it in as they say. Okay, so the adm and the toga spec have this role called the Security Architect, who’s a very specialized role and he has a special set of skills that are focused on securing architectures. So the security architect does not go off on his own and operate separately. He’s actually built in and baked into the adm process. For every phase of the adm he’s got a job to do. So we’ll go through the phases one by one. Here the preliminary phase.

One of his first roles is to scope the enterprise organizations impacted as you know, the enterprise architect, one of their roles is to scope the enterprise organizations impacted by the architecture project. Well, he’s going to have to do the same thing, but when he starts implementing thinking about security features, it’s going to unpack people, it’s going to impact employees, is going to protect end users, it’s going to affect the way the sales team works. He’s going to have to define who his stakeholders are for that, you’re going to have to define document security policies. So now, just the way you have architecture standards, business standards, principles, you’re going to have security principles. Essentially you’re going to do the same thing for security capability that you did for architecture capability. You figure out where you are, figure out the target, what’s realistic for you to get. You’re not going to go from having almost no security to being bank level secure in one sweep, right? So you need to go from where you are to where you can reasonably get to and implement any sort of tools that are relating to security architecture. In the phase A, which is division phase, his main job is to obtain management support for the security measure.

So the enterprise architecture team is creating the vision and they’re going to go off and sell their vision. Let’s say that the sales team is going to be able to do all their work remotely from their cell phones, while the security architect is going to be able to see. But these guys are also going to need to carry around with them a little key Fob that’s going to have an RSA token and it’s a two factor authentication. And so it’s not going to be as point and click, the way that you use Facebook app and then define all the sign off milestones. So as you go through the adm process and you’re into phase C and D and E, and you’re going to have points of time where the security team has to sign off and say, so far, this architecture meets our security needs and those get built into the timelines. Disaster recovery, business continuity, these are operational bits. Identifying document, anticipated regulatory environments, determine document criticality of the system.

So understanding that if this application goes down for even five minutes, what is the impact? There’s a story of a trading system for a high frequency trading organization out of Chicago and they were saying that for every minute that their systems weren’t working, it was good, costing them a million dollars. It was like that. So you can imagine if the system is even down for ten minutes during the middle of the day, that’s $10 million that it’s costing them in potential profits or, you know, losses and, and things like that. So knowing this, the criticality would actually change the way that you handle security and the way that you start to think of the types of attacks that your system can come under, et cetera. So phase B, we’re getting to the BDAP phases here, determine who are the legitimate actors. Now we’re getting into authentication and security where these people need access to the system, but these people do not need access to the system.

Like this third party vendor who had a user ID and password that they were able to get into Home Depot’s corporate network. Well, do they need that access? Maybe they only need access to one single application. And that application should have been designed so that they could, using a VPN tunnel from network to network that they had to go through a particular route or point to point. Firewall hole in the firewall, not just a user ID and password that could be accessed from anywhere. Okay, so baseline the current security business processes. So now we’re getting into sort of the baseline and target types of architecture work. Determine whom and how much is acceptable to inconvenience. So when we’re talking about things like two factor authentication and needing to have a key Fob every time you use the system, and having password requirements that are crazy special characters and 16 characters and it cannot be a dictionary word and those types of things, you’re starting to get into the inconvenience side of the business.

So you have to, during the architecture phase determine how much is acceptable for that. Identify document interconnecting systems beyond the project control. So there’s no point having this great secure system and having a whole bunch of holes that application A needs to get into the direct access to the database with no filter over it. You’re going to need to determine that and to see if you can mitigate some of those. Determine the assets at risk if something goes wrong. So that’s always I worked in a system once where there was all this fancy like, multilayers of firewalls and multi this, A, multi that. And you got to the point where it’s like, guys, we’re not even storing the customer’s name, we’re not even storing their email address that if they got our entire database it would be useless to them. So why are we going to this level now? It just happened to be for Visa and Visa takes their security seriously. And so even an inconsequential marketing system that has a database but didn’t store any user specific data in it still needed to have that level of security. Determine the cost of the asset loss. So if your database got stolen, what is the cost in all those different forms? Identify document ownership of assets. Determine the document appropriate security forensic processes. So forensic processes of course is after the fact. So if you do get hacked, what logs are you keeping? Can you go to your firewall in the immediate time and say copy the logs before they go get overwritten? A lot of these systems have running logs that override each other over 24 hours period.

So it’s almost like the scene of a crime. And knowing immediately what you have to grab this log file, grab that log file when something happens. What is the processes? Identify the criticality and availability and correct operation of overall service. Determine and document how much security cost is justified by the threats. Again, this is what are you protecting? What’s it worth? Are you going to spend a million dollars to protect that? There might be better ways and reassess and confirm the vision decision. So phase B, you’re in the business phase. It’s the same as the regular architecture, the non secure architecture. You’re always going to be getting into the details and making sure that your vision still is valid. Assess alignment or conflict of identified security policies. So if the security policies conflict with the business goals, then you need to document that, talk to people about that, raise the alarms, hey guys, they’re trying to get the users to do this, but this is the worst idea ever. Blah, blah, blah.

And finally this is going to be a common running theme in every phase. But as a security architect, his main job maybe in his entire career is determine what can go wrong. That’s sort of self explanatory. So phase C, now we’re getting into the data and application layers of the TOGAF cycle. Again, we’ve got baselining it identify safe default actions and failure state. So you’re talking about data, talking about applications. When something goes wrong, should it be spitting out an error message to the user if it’s under a denial of service attack? If it cannot access the database, the front end is having trouble accessing the login database. Should it just let people in or should it reject people or what’s? These default actions with failure states identify and evaluate applicable recognized guidance and standards, revisit assumptions. So again, we were talking in previous phase about these systems that are beyond your control and how much they need holds that have become in your security. Determine and document the sensitivity or classification level.

So if you’ve got documents or data and it needs to be extremely, you don’t want to sort of document your entire system and all of the information that a hacker needs to get into it and have that document here, there and everywhere, right? So you want to keep classified documents in a secure location, identify document who owns those assets, the criticality of the availability. Again, the relationship of the system under design with the existing business disaster continuity plans, what assets aspects of the system must be configurable to reflect changes. That’s pretty self explanatory. So you don’t want to have the entire system always being configurable. If you know certain things are coming along, then that’s fine. If things are pretty stable, you might as well lock them down. From a security standpoint, the goal when you’re overriding goals is to tighten control, tighten the ability of people to make changes. So if you have a free and open system that a minuser can log into your system and change any single record, any single column, any single row of your data using the minerface, do they really need that? The lifespan of information.

So again, in regulatory requirements, I went in a situation where I was working for a company where they rolled out a very short three month or six month email policy and the system would automatically purge emails older than this very short age. I think it was like six months. So any emails older than six months would get deleted from your inbox. And the reason they cited was regulatory. They said that essentially if they ever got sued, then any emails that exist in the system would be admissible as evidence. And if the emails had been auto deleted, and it was not as a response to the lawsuit that somebody went in and deleted a bunch of emails, but if they just had a policy in place that said, we do not keep emails beyond three months, and that’s implemented, the system enforces it. There’s no way for you to store emails beyond this period. If you need it, you got to get it out of the email system. Then they can go to court and say, listen, that’s our policy and it’s been two years and you’re trying to sue us or something that happened two years ago.

We don’t have that emails anymore. So that basically falls into the security. Protecting your company from lawsuits is a security need. The terminal approaches used to identify risks, identify actions and events that weren’t logging. So again, forensic logging, we want to be able to go back and see if the attack happened, what data was taken, IP address of whoever’s doing the work, et cetera. Rigor in, providing accuracy of logged events. So that non repudiation, that’s a fancy word, but it means if the hacker can then go in and modify the logs, if they can delete the log files, or they can go in and edit the IP address to some other IP address, well, the whole thing is pointless, right? So you got to ensure that your logging is on a separate system that is not modifiable once it happens or make it signed or whatever. Identifying average attack. That’s the whole goal of being a security architect. And again, what can go wrong? Phase. D. Technology, architecture.

So the baseline current security specific technologies, revisit assumptions, we talked about this before as well applicable, recognized guidelines and standards. So now we’re into the technology. So within security, within technology security as a long tradition. And so the way the firewalls are set up, having firewall between the Internet and your front end, and then another firewall between your front end and your application layer, and another firewall between your application layer and your database layer, et cetera. Identify methods to regulate consumption of resources. So engineer a method by which the efficacy of security measures will be measured, how effective they are, and communicated on an ongoing basis. Identify the trust clearance level. Identify minimum privileges required. Now that is, you know, that is basic security policies.

Making sure that every account, every system account, the account that the IIS runs under, the privileged account that services run under, have minimal privileges required. And so if someone is able to take over your web page, they’re not able to get access to directories that they should not have access to by just being able to update web pages, mitigating security measures and again, what can go wrong. Phase E identify existing security systems available for reuse. Of course, you want to reuse things as much as possible because reused things are proven and you’re not reinventing the wheel mitigation measures. Again, once you’ve identified the risk, you want to make sure you can mitigate those risks tested and reasonable security software.

So again, you’re not reinventing stuff, you’re going to use McAfee antivirus on your system because that’s tested and known to be working, et cetera. Any other assets are appropriate for reuse. And of course, populate the architecture repository with the new security building blocks. So, as we are creating these architecture pieces, we’re identifying the building blocks which are reusable components, and then that’s going to the architecture repository and along the side of the other pieces of architecture along the enterprise continuum. And as always, you can always have to determine what can go wrong at this point. Phase f migration planning. So, assess the impact of new security measures upon other new components. Implement assurance methods by which the effectiveness of security measures will be measured. Identify correct, secure installation parameters, the initial conditions. So when you’re talking about getting ready for installation, you’re talking about making sure the environment has the right security. That’s when you implement the disaster recovery. So all your backups and offsite storages and hot swap solutions and things like that, and I don’t have to say the last bit, what can go wrong? So phase G. We’re almost there now.

This is the implementation governance. So remember, the role of the architect at the Phase G is not to do the implementation, but to actually be detached from it and to be monitoring it. So code reviews and design reviews and accept making sure that the solutions being developed are matching the security requirements, review evidence produced by the system so log files and making sure that the system is responding exactly as anticipated. To various whether you’re trying to attack the system or just log in or log in three times, your account gets locked out, et cetera. And training. So if you’re going to have a security system, people have to change their passwords, people have to have a key Fob or the new types of VPN, login and timeouts and things like that. You have to do training for that.

And of course, we’re now switching from what could go wrong to what has gone wrong. So once you’re in the implementation phase, you’re starting to see the effects of security and something didn’t quite work and things like that. Phase H mostly this what has gone wrong? So now everything is implemented and now you’re just making sure that security governance is working, that the security team who might be charged with managing and maintaining security are doing their jobs, incorporate security relevant changes. So if there’s change management and change requirements that come through here. Then you need to start talking about future enhancement. And that’s it. Next we’re going to talk about service oriented architecture in the Toga model. So stay tuned for that. Maybe have a little little drink, and we’ll get back into it right after this.

9. Service Oriented Architecture (SOA)

Hi there. In this lesson we’re going to talk about service oriented architecture as a style of architecture. Now, service oriented architecture is abbreviated as So, and roughly it’s a style of architecture that looks at all the functions of the system as services. So you might be fairly familiar with this, but it’s more and more common in this way web world that we’re in, where you have a client and it’s calling a server and it’s a function call and it doesn’t care how the server actually does the work. It has no implementation knowledge, it’s just making a call and expecting a result.

So features of a service like this, they’re self-contained, they can call other services. So you do have Web services that call other Web services is a black box. And that means that, like I said, we do not know how it was implemented and we don’t care. We’re asking for it to do something and as long as it does it and returns the result in the expected format, that’s all we care about. Some examples of service oriented architecture would be something like the authentication service. So if you provide a user ID and password to it and it tells you yes or no, valid or not valid, that’s it. You don’t need to know the database structure, you don’t need to know column names, table names, you don’t even need to know how it comes up to that conclusion. It’s just implementing an interface and you’re trusting it that it’s doing the work. An email service.

So SMTP is like the original service oriented architecture where you’re sending off a to from subject body any potential attachments to the service. It does the work. You don’t have to implement the SMTP protocol on your own, it’s just a service. I’ve seen it’s more and more common that data access layers are done in the service model. So that means no front end calls to the database. If you need to get some data, there’s a method that you call and it returns the data.

It’s done through Web services model. It’s actually a hard disconnection between the front end and the application layer and then kind of report generation service. So if you are asking the system to go off and generate a report, you just make that request and you expect it to do its work. So the TOGAF spec talks about this and it says that the service model should use open standards. It’s one of those things. You’ve got different standards like Soap and Http and XML and Ajax and all these different web services and other models. These are often standards by W, three C and other organizations. And so if you’re going to have a services model, you might as well use standard communication channels, standard protocols, standard wrappers like XML to encode this and not try to roll your own entire interface because that defeats the purpose of it. Within TOGAF, the service oriented architecture is quite simple if you set it as an architecture principle, if you say right up front in the plenary phase that our company follows the service oriented architecture, and so all of the solutions cannot be tied all the way from the database to the front end, hard wired into that solution. It has to have services, publish an interface and all these things.

You also need to do changes to your governance model. So obviously if you put this as a principle, then the governance is going to actually have to reject architecture proposals that do not have a service oriented approach. The good thing about service oriented model is it’s easier to do the partitioning of architectures. Because if email is a service and database is a service, and authentication as a service, and reports are a service, teams can design those and they’re black boxes, architecture teams can go off and design those solutions as long as they follow the overall guiding principles and the strategy. And we’ll talk about that in the partitioning section.

But having a services oriented architecture makes it actually easier to do partitioning, and all is important is to handle the stakeholders. So, for instance, with a service oriented architecture, if you said that our database is a web service and if any application needs to access to it, it just has to call this URL with the right credentials, some people might freak out about that. Some people might worry about security, about their data being their data and they’re not wanting other people to see their data and et cetera. It becomes political, becomes controversial.

So definitely you need to get ahead of stakeholder management, tell them about the service oriented principles and get all the right buy in to do that approach. The other things to note are there are additional artifacts around services. And so in each of those phases as you’re creating catalogs and lists and matrices and diagrams, those artifacts, there’s going to be service oriented versions of those. And we talked about the content minimodel in a much previous lesson. And so as you’re creating these new artifacts and you’re changing some of these things around, your content metamodel actually has extensions around service oriented architecture. And so the architecture repository ends up having additional documents and things like that. Well, that’s what TOGAF had to say about service oriented architecture. Coming next, the Architecture maturity models. Very interesting topic, we’ll see it in a second.

10. Architecture Maturity Models

Hi there. In this lesson, we’re going to talk about Architecture Maturity Models. The exam requirements is that it’s the role of architectural maturity models in developing an enterprise architecture. I found this quote in the Toga Spec relating to maturity models.

I found that very interesting, organizations that can manage change effectively are generally more successful than those that cannot. And so right now you get this sense of architecture maturity models and they have to do with the way that organizations can handle change. Okay? So there’s a concept called Capability Maturity Models which is outside of Toga, outside of the Open Group. These provide an effective and proven method for an organization to gradually gain control over and improve its change processes.

So, CMM provides the following benefits. They describe the practices that any organization must perform in order to improve its processes. They provide a yardstick against which to periodically measure improvement. They constitute a proven framework within which to manage the improvement efforts. And they organize the various practices into levels at each level, representing an increased ability to control and manage the development environment. So, there’s an organization called SEI, which was the original developer of CMM in the 1990s. And as you can see the link on the screen, the SEI organization provides a framework to develop maturity models. And a framework to develop maturity models is a metal model. The other thing that the Toga Spec mentions is called the US. Department of Commerce. ACMM framework.

Okay? That was published in 2007. As you know, the TOGAF itself is based on a Department of Defense architecture framework. And so, again, going back to the US. Government to get frameworks is a common pattern here. So the Department of Commerce one is interesting. There are nine enterprise architecture elements, and those nine elements are rated on a scale from zero to five. And so across the nine, across the zero to five, you can be zero on all nine and score yourself as zero, or you can be a five on all nine and be perfect.

So it’s a scale from zero to 45. TOGAF does not actually prescribe a specific maturity model. So it mentions these two, but it basically just talks about the role that it plays in developing your architecture capability and your architecture skills. We’ll talk about architecture Skill framework in the next lesson, but basically, very interesting thing, I definitely recommend you look into it for more details. But all you really to know for the exam is that using these Capability Maturity Model frameworks allows you to judge yourself, your architecture capability. And by this, you can then know what to improve, what to work on on its skills assessment. In talking about skills, we got the final section called Architecture Skills Framework next. So stay tuned for that.

11. Architecture Skills Framework

Okay, here we go with the next final lesson, which is Architecture Skills Framework. So the exam requirements, the requirement is the purpose of the Architecture Skills framework and how to apply it within an organization. So I found this quote in the Togga spec interesting. Skills frameworks provide a view of the competency levels required for specific roles. So the skill frameworks will define the roles within a work area, the skills required by each role, and the depth of knowledge required to fill the role. So in an architecture space, we have to admit that there’s a lack of general agreement on what it means to be an enterprise architect. What I do as enterprise architect might be different from what you do and your job as an enterprise architect.

And if you go to a different company, they do the completely different ways of architecture. And so it’s hard to go out on the market advertise for an enterprise architect bringing people to interview and how do you know that they’re knowing of architecture to the same degree and level that your company does? So how do you assess this? And it’s easier to assess developers because there’s code that you can review or there’s developer certifications. You can do coding tests during the interview, you can point to your website or your application or your mobile app and say I did this. And that sort of speaks for you as well. But enterprise architects don’t have these luxuries.

So the TOGAF Architecture Skills Framework attempts to address this need by providing definitions of the architecting skills and proficiency levels required of the personnel, external and internal who are to perform the various architectural roles defined within the Toga framework. So we got to the, you know, closer to the end of the course here, and we’re finally talking about all of the people who are part of the architecture team. You’ve got board members, the sponsor, the manager, you’ve got the individual architects, business architects and data architects, application architects and technology program or project managers, an It designer.

So even down to the level of the person who’s designing the system at that level, they are got an architecture role and there’s a lot of people who also have their fingers in that pie. So the Architecture Skill framework allows you to define which skills are absolutely critical and which ones are sort of less so for each of these roles. So TOGAF has a category of skills, and there’s generic skills, business skills, enterprise architecture skills, program project skills, it general knowledge skills, and technical It skills, and then even legal skills.

So those are generically things you can be ranked on as an architect. So TOGAF has definitions for each role and the level that role needs to be at. So for instance, we’ll take the architecture board member, they need an expert level in the leadership category, but only background level, which is the lowest level in data design category. You do not need your board members to understand proper data design, as long as the person who does the data design can go and explain to them these are the, you know, the costs, the features, the benefits, etc. I’m not going to list all of the roles and skills and proficient levels, but the Tower spec does actually list for all of those roles for all of the skills. On a scale of one to four, what’s the most critical and what’s least critical?

So check that out. I’ll end up here with this quote from the toughest speck. A fitting quote for the end of the last lesson. Enterprise architects are visible, coaches, team leaders, business to, technical liaisons, computer science and industry experts. And yeah, we’re all that, aren’t we? So that’s it. We’re going to get into the conclusion of this course. Thanks a lot for sticking by and see in the next video.