All The Open Group TOGAF OG0-092 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the OG0-092 TOGAF 9 Part 2 practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

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, a requirement taken from the TOGAF nine and one-half part two exam requirements. It describes how an enterprise architecture can be partitioned to meet the specific needs of an organisation within the Toga specification. The concept of partitioning means that you've got multiple groups of architects working independently on the overall enterprise architecture, 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 organisations 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 the standard are 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 architectural 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 why 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 and a large group of architects. You need to allow people to work independently and not be bogged down by processes, meetings, and waiting for approvals. Finally, if you do it correctly, you can develop these things in a modular fashion, with architects working on one piece and then architects working on the other. And then, when the solution gets brought together, it's a great, wonderful solution, but it just doesn't come from the brain of a single individual. So they're done for a variety of reasons. Now the thing about the TOGAF specification is that there are certain steps that you're going to want to do within the preliminary phase in order to handle this partitioning. So the preliminary phase is when you're deciding, for instance, the organisation model for enterprise architecture. This is how you do architecture.

And so you're going to need to define the structure, the roles and responsibilities, who's doing what, how things are related within the preliminary phase, and make sure everyone has an understanding of whose job it is to do what. And then there's an integration piece that you come back to later and you say, "Okay, we want to have one overall view of the architecture with 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 another group in the same company that has a two out of ten capability. 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 to be creating certain artefacts and certain documents over here, you should be creating those same ones over there. So that's what the tough aspect means about partition. 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, which is the requirement of the exam within the TOGAF 9 specification. The architecture repository The concept of it is rather central to TOGF. I know you 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 TOGAF 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 metamodel, 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 the screen a diagram that outlines the relationships between those things. So the architecture metamodel is obviously the model through which architecture is performed. So the architecture development method and then the content meta 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 and standard information base are on the left side of the enterprise continuum. These are the more generic things that come through the foundational and industry-type architectures. That all feeds into the governance log, which is a record of your organization's governance—how decisions were made, compliances, any sort of capabilities—you know, all that stuff. The decision-making calendar, the project portfolio, and so on, all the way down to credibility, or the actual things that your organisation can do in terms of architecture. So you can see all these relationships on screen. Next, we're going to talk about iteration within TOGAF. Stay tuned for that. Thanks.

7. Iteration

So we're getting closer to the end of the requirements for the Part 2 exam. Here we're talking about iteration within TOGAF. The requirements specifically say how to apply iteration and different levels of architecture within the AVM. If we look at the iteration diagram within the TOGAF certification, you can see that there are actually a number of different types of iterations that can be done. And so, look at an example. There's this thing called architecture development iteration, and you can see as you get into the BDAT phases B 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, on your first pass through BDAT, you may be on a more superficial level, but all you want is to get through it and get a preliminary document.

And the second time through it, you get a bit deeper and more into the details, and the third time through it, that is a style of doing the analysis that is actually provided and described within this document. You've also got other types of iterations, like the transition planning iteration, which allows you to go through the opportunities and solutions back into migration planning but then back to opportunities and solutions and then back to iteration planning again. You don't have to make all those decisions and details with only one pass at them. You can go back and do it again, gaining more details as new information becomes available; the same is true for implementation governance and change management. That's a governance model. You go between managing those implementations and managing change and back to implementations, et cetera. So the documents are quite clear in terms of the different iterations. That's pretty much it for the requirements of the exam. The conclusion section will then tie everything together. Thanks a lot.

8. Adapting the ADM for Security

So in this lesson, we're going to be talking about how to adapt the AD for security. Now we all know that security is a huge concern right now. There are a lot of high-profile cases that have been making the news this year. Last year, Sony Pictures was hacked, as were Home Depot and Target, and all credit cards were stolen. Even the most high-profile targets were unable to secure their systems. But what these hackers 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 and find other machines that were on that network. And they found one server that had an 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 point-of-sale terminals and be able to capture all the credit card numbers 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 and you're working on a system that has some interface with the public and could be accessible from the outside, then there are modifications to the AD to handle that.

Okay? And as you know, security is something you need to think about from the start. It's not something that you sort of tack on at 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 front of it." No, you put security first and foremost. You bake it in, as they say. Okay? So the adm and the Togaspec have this role called the "security architect," which is a very specialised role, and he has a special set of skills that are focused on securing architectures. As a result, the security architect does not operate independently. He's actually baked into the ADM process. For every phase of the job, he's got a job to do. So we'll go through the phases one by one. Here is the preliminary phase. As the enterprise architect, one of his first responsibilities is to scope out the enterprise organisations that will be impacted. One of their roles is to scope the enterprise organisations impacted by the architecture project. Well, he's going to have to do the same thing. But when he starts implementing security features, it's going to impact people, it's going to affect employees, it's going to affect end users, and it's going to affect the way a sales team works.

He's going to have to define who the stakeholders are for that. Okay, you're going to have to define document security policies. So now, just as you have architecture standards, business standards, and good principles, you're going to have security principles, essentially, okay? You're going to do the same thing for security capability that you did for architecture capability. You determine your current location, your goal, and what is realistic for you. You're not going to go from having almost no security to being bank-level secure in one swoop, right? So you need to go from where you are to a place that you can easily get to and implement any sort of tools that relate to security architecture. In phase A, which is the division phase, the 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 will also need to carry around a small key fob that contains an RSA token and is used for two-factor authentication. So it's not going to be a point-and-click experience the way that you use the Facebook app, okay? And then define all the sign-off milestones.

So as you go through the adm process in your interfaces C, D, and E, you're going to have points in 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, okay? Disaster recovery and business continuity are optional bits. Identifying documents, anticipating regulatory environments, and calculating the system's document criticality So I understand 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 organisation out of Chicago, and they were saying that for every minute that their systems weren't working, it was costing them a million I think it was like that.So you can imagine that if the system is down for ten minutes during the middle of the day, that's $10 million that it's costing them in potential profits or losses and things like that. Knowing the criticality would change the way you handle security and how you begin to think about the types of attacks that your system could face, and so on. Phase B: We're getting into the bag phases here.

Determine who the legitimate actors are. Now we're getting into authentication and security, where these people need access to this system, but these people do not need access to the system. Like this third-party vendor who used a user ID and password to gain access to Home Depot's corporate network. Well, do they need that access? Maybe they only needed access to a single application. And that application should have been designed so that they could, using a VPN tunnel from network to network, go through a particular route or point-to-point firewall hole in the firewall and not just a user ID and password that could be accessed from anywhere. Okay, baseline the current security business processes. So now we're getting into sort of the baseline and target types of architecture work. Determine who will be inconvenienced and how much inconvenience is acceptable. Okay? So when we start talking about things like two-factor authentication and having 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, you're getting into the inconvenience side of the business.

So you have to determine, during the architecture phase, how much is acceptable for that. Identify and document interconnected systems outside the scope of the project. So there's no point in having this great, secure system and having a whole bunch of holes that application A needs to get into to get direct access to the database with no filter over it. You'll need to figure that out and see if you can mitigate some of the risks. Determine the assets at risk if something goes wrong. So that's always I used to work in a system where there were all these fancy things like multilayers of firewalls and multiple this and multiple that, and it got to the point where it was like, "Guys, we're not even storing the customer's name, we're not even storing their email address." 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 its security seriously. And so even an inconsequential marketing system that had 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 would be the cost in all those different forms? Determine the aspects of document ownership. Determine the document's appropriate security and forensic processes. So forensic processes are, of course, after the fact. So if you do get hacked, what logs are you keeping? Can you go to your firewall right now and say, "Copy the logs before they go?" Get overwritten?

A lot of these systems have running logs that override each other over a 24-hour period. So it's almost like the scene of a crime. And knowing immediately what you have to grab from this log file, grab that log file when something happens. What is the process? Identify the criticality and availability of the overall service and ensure its correct operation. Determine and document how much the security cost is justified by the threats. Again, this is what you're guarding. What's it worth? Are you going to spend a million dollars to protect that? There might be better ways to reassess and confirm the vision decision. So in phase B, you're in the business phase. The "regular" architecture is the same as the "nonsecure" architecture. You're always going to be getting into the details and making sure that your vision is still valid. Determine whether the identified security policies are in alignment or conflict. 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. However, as a security architect, his primary job may be to determine what can go wrong. That's sort of self-explanatory. So in phase C, now we're getting into the data and application layers of the TOGAF cycle.

Again, we baselined it in order to identify safe default actions in failure states. So you're talking about data and applications. When something goes wrong, should it be spewing out an error message to the user if it's under a denial of service attack? If it cannot access the database, the frontend is having trouble accessing the login database. Should it just let people in or should it reject them? Or what's? These default actions and failure states identify and evaluate recognised guidance and standards, as well as revisit assumptions. So again, we were talking in the previous phase about these systems that are beyond your control and how much they need holds that are becoming your security determination document or classification level. If you've got documents or data that needs to be extremely secure, 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, identifying the document, who owns those assets, the criticality of the availability, and the relationship of the system under design with the existing business disaster continuity plans. What asset aspects of the system must be reconfigurable to reflect changes? That's pretty self-explanatory. So you don't want to have the entire system always configurable. If you know certain things are coming, 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 and tighten the ability of people to make changes. Do they really need that lifespan of information if you have a free and open system where an admin user can log in and change any single record, any single column, any single row of your data using the interface? So again, in compliance with regulatory requirements, I went into a situation where I was working for a company where they rolled out a very short three- or six-month email policy, and the system would automatically purge emails older than this very short age. I think it's 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 were auto-deleted and it wasn't in response to the lawsuit that someone went in and deleted a bunch of emails, but if they simply had a policy in place that said we don't keep emails for more than three months and that was implemented, the system enforced it. There's no way for you to store emails beyond this period. If you need it, you've got to get it out of the email system. Then they can go to court and say, "Listen, that's our policy, it's been two years, and you're trying to sue us for something that happened two years ago." We don't have those emails anymore. So that basically falls under security. Protecting your company from lawsuits is a security need. The terminal approaches used to identify risks, identify actions, and identify events that weren't logged So again, with forensic logging, we want to be able to go back and see if the attack happened, what data was taken, the IP address of whoever is doing the work, etc. to rigour in, ensuring the accuracy of logged events So, non-repudiation is a fancy word, but it means that if the hacker can then go in and modify the logs, delete the log files, or change the IP address to another IP address, the whole thing is pointless, right? So you've got to ensure that your logging is on a separate system that is not modifiable once it happens, make it signed, or whatever.

Identifying Abby's attack is the whole goal of being a security architect. And again, what can go wrong? Phase. D. Technology, architecture. So the baseline for current security-specific technologies revisits the assumptions we talked about before as well as applicable and recognised guidelines and standards. So now we're in the technological phase. So within security, within technology, security has a long tradition, and so does the way the firewalls are set up, having a 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 the consumption of resources. So devise a method for measuring and communicating the effectiveness of festival security measures on an ongoing basis. Identify the trust clearance level. Identify the minimal privileges required. Now, that is, you know, the basic security policy.

Making sure that every account, every system account, the account that IIS runs under, or the privileged account that services run under has the minimal privileges required So, if someone is able to take over your web page, they won't be able to gain access to directories that they shouldn't be able to gain access to by simply being able to update web pages, mitigating security measures, and again, what could go wrong? Phase E identifies 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 with 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 been tested and is known to be working, etcetera; any other assets 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 that are reusable components, and then those go in the architecture repository and alongside the other pieces of architecture along the enterprise continuum. And as always, you can always determine what can go wrong at this point. Phasef migration As part of your planning, consider the impact of new security measures on other new components. Implement assurance methods by which the effectiveness of security measures will be measured. Identify the correct secure installation parameters and 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 disaster recovery. So all your backups and offsite storage and hot swap solutions and things like that—and I don't have to say the last bit—what can go wrong? So, in phase G, we're almost there now. This is the governance of implementation. So, remember, the architect's role in Phase G is not to do the implementation, but to be detached from it and to monitor it. So code reviews and design reviews and accepting making sure that the solutions being developed match the security requirements, reviewing evidence produced by the system, such as log files, and making sure that the system is responding exactly as expected to various situations, whether you're trying to attack the system or just log in or login three times, your account gets locked out, and so on. And training. So, if you're going to have a security system, people have to change their passwords, and people have to have a key. You must complete training for the new types of VPN login and timeouts. 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, something that didn't quite work, and things like that. Phase Eight—mostly this—is what has gone wrong. So now everything's implemented, and you're just making sure that security governance is working and that the security team, who would be charged with managing and maintaining security, are doing their jobs and incorporating security-relevant changes. So if there are change management and change requirements that come through here, then you need to start thinking about future enhancement. And that's it. Next, we're going to talk about service-oriented architecture in the TOGAF model. So stay tuned for that. Maybe have a little drink, and we'll get right back into it after this.

The Open Group TOGAF OG0-092 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass OG0-092 TOGAF 9 Part 2 certification exam dumps & practice test questions and answers are to help students.