Pass Your The Open Group TOGAF OG0-092 Exam Easy!

The Open Group OG0-092 TOGAF 9 Part 2 exam dumps vce, practice test questions, study guide & video training course to study and pass quickly and easily. The Open Group OG0-092 TOGAF 9 Part 2 exam dumps & practice test questions and answers. You need avanset vce exam simulator in order to study the The Open Group TOGAF OG0-092 certification exam dumps & The Open Group TOGAF OG0-092 practice test questions in vce format.

TOGAF 9.1 Specification for Part 2

6. Applying the Stakeholder Management Technique

Alright, we are here in the section that says how to apply this stakeholder management technique. So what is stakeholder management? So stakeholders are individuals, teams, or organisations that have interest in or concerns about the outcome of the architecture. So what does this mean? So, if your company has 10,000 employees, not all 10,000 people should have any kind of influence or even be interested in your architecture and designs. So you're going to basically be able to handpick out 20 or 30 representatives of different teams and departments, senior and junior, to cover all those sorts of bases within the different business interests. So within those 20 people, those are stakeholders; those are people who have either interests in or concerns about your architecture. Then there's stakeholder management, which is the process of trying to make everyone happy despite sometimes conflicting interests. So even within a group of 20 or 30 people, and that's just a number that may or may not represent the size of your organization, even within that group, some people are going to want their concerns to be the primary problem that you're trying to fix. And other people are going to be pushing; they're going to say that those concerns are not as important and that you should be trying to fix that other problem. Some people are going to want a more centralised system, some people are going to want a more distributed system; there are going to be interests that are conflicting, and you can't make all the people happy all the time, as they say. But you can't try to find a solution that is in the best interests of the business, considers everyone's concerns, and employs the stakeholder management technique collaboratively. So one thing you need to know—and you may already know this—is if you don't manage the stakeholders effectively, the project itself can fail. And what I mean by this is that if you lose the confidence of the head of the IT department or the head of an important business unit, they're going to stop supporting you; they're going to stop letting their people spend time talking to you; they're going to resist these types of changes; they're going to throw up roadblocks in your way. So it becomes a very political situation. So you really need to follow a proper process of communication, of soliciting feedback, of getting approvals, of getting things written down clearly, of getting sign-offs, and all those other things that basically allow people to feel like their input is being heard and accidental. As I just said, if you lose the support of somebody who's key, then once the head of that department loses confidence in you, maybe even the executives above and the VP are going to start to lose confidence because these people are high up in the organisation for a reason. Now you, as an architect, can't force the entire organisation to change its direction or to go in a new direction. So you need to sort of build this support, and you need to come up with this plan that everyone thinks is the best possible plan. So this is why stakeholder management is really one of the keys to getting your plans approved and implemented. So the Togaff stakeholder management technique involves identifying who these players are. Number two: classifying them. You've got to know if they're senior or junior, whether they're important or not, to determine a stakeholder management approach. And so Toga does provide one approach, and we'll get into that on the next slide. And finally, you're going to tailor certain deliverables to these people. So if you're talking to businesspeople who understand finances and numbers and their senior business people in the organization, you're going to have certain deliverables that speak to them. And you may not bring the technical and detailed deliverables to them, but when you're talking to the head of it, there's going to be some specific deliverables that you're going to be talking to him about. It's going to be his main concern. so many different deliverables to various audiences Now in the TOGAF model, you'll see that you're basically classifying the stakeholders based on their power. So can they throw up roadblocks, and are their complaints going to be important or not? and the level of interest. And by level of interest, it means someone might think you're designing an architecture that directly impacts their department, and you're going to be shutting down some business, adding up some business, and moving things around. That's a very high level of interest, but somebody whose life isn't really going to change is just mildly interested. Maybe there's some sort of indirect impact, but it's not really the purpose of what your project is, and that's more of a low level of interest. As you can see, if someone is important in the company but isn't directly impacted by it, you just have to sort of, let's say, keep them satisfied as opposed to people who are key players, high-powered, and are also directly at PAX. And then you're basically going to have to get their sign-off, get their approval, and get their total support. So that's the stakeholder management technique. Coming up next, we're going to talk about the TOAF content metamodel. Stay tuned.

7. Applying the TOGAF Content Metamodel

Hey there. So in this lesson, we're going to talk about how to apply the TOGAF Content Metamodel. So what is a metamodel? The dictionary definition says it is a precise definition of the constructs and rules needed for creating models. What does that mean? It is the rule for creating content that will eventually live in the architecture repository. So that is the definition of these pieces of content. So the TOGAF Content Metal Model is broken up into two categories. The first category is the core content. So this is the bare minimum of architecture content. So they're within the core of ADM. You've got a core set of documents that get created. This is the main content. And then in the extensions, the extension content is a lot more specific. It's in depth; it supports other things outside of the DM that support governance and other bits of that. So within the core metamodel, there are many different definitions of content. I'm putting them up on screen, and I won't go through them individually. But you've got actors and roles, and they belong to organisational units. There are data entities, services, and platform services. These all are defined precisely within the Content metamodel, and they all have relationships. And so, like I said, an actor has a role, and it belongs to an organisation unit, et cetera. Like that. These are defined within the Content Meta Model. This is a high-level overview of the Content Meta model. We went through this in the previous lesson. And so you can sort of see the principles, the vision, and the requirements; the different architecture pieces in the middle; and then the implementation plan and implementation governance at the bottom. But if we dig deeper into this, and this graph is also from the specification, we can see that different types of content are created within each of those essentially phases, the preliminary phase, the vision phase, and the requirements. And these are how they're classified within the Content Meta Model. So the architecture principles live within the preliminary phase. For instance, the architecture vision lives within the vision phase. The definition of the stakeholder lives within the vision phase. These pieces of content have classifications. Okay? So we can even dig down deeper than that. And like I said, these definitions are defined, and actors have roles, and roles have functions, and functions have processes. So all of these things are defined, and they have relationships. It goes a lot deeper even than this. And all of these things are individually defined. I'm not going to go through them. I don't think you really need to memorise them. You just need to know that the ContentMinim model contains the rules for creating content. And each of these terms has very clear definitions. Coming up next, we'll get into the first of the two reference models. This is the technical reference model. Stay tuned for that.

8. Customizing the Technical Reference Model (TRM)

Hey there. So in this lesson we're going to be going through this exam requirement, the TOGAF Technical Reference Model, and how to customise it to meet an organization's needs. So what is the technical reference? It's modelled first of all. It's a piece of foundation architecture, and if you recall the enterprise continuum, you'll recall that this is on the far left of that model. It is the most generic technical design model that can be created. It's supposed to be able to apply to any company in any industry, regardless of size. It is completely generic in my view; it's basically unusable without customization, and then obviously, this is the crux of the problem: how to customise it. So to summarise what the Technical Reference Model is, it's basically a set of applications running on top of a platform. Those two things are connected through an API, and the platforms themselves are on top of a network. When those two things talk through a communications interface, that's super generic. Any programme or computer can be described as that. So the diagram is on screen; you can see in yellow the applications, green the application platform, and in red the communications infrastructure and the various interfaces that run between them. The shape of the application platform and communication infrastructure is the way it is because what they're trying to say is that the way the application platform talks to the communications there should be fairly standard, right? If you're going to talk in TCPIP, all of your application platforms should use that network. You shouldn't be mixing and matching communication technologies, so standardise the interfaces between your communications network and your application, but otherwise most of those things can be quite diverse, with Macs, Windows, Linux, and all the different flavours under the sun talking to each other. So in a more detailed view, you can see the same diagram but with all of the names of the applications, services, and platforms on there. So, in the top, you can see three distinct entities: application software (still represented by yellow and gold); application platform (represented by green); and communications infrastructure (represented by red). The interfaces are between those bits, so obviously the application platform interface and the communications infrastructure interface. So at the top where you've got the yellowand gold business applications and infrastructure applications it's importantto know the distinction between the two. So a business application often maps to the actual business function; it doesn't always have to, but it is basically a customised piece of software for your company or for your industry. So for instance, you may have a point of sale. Cash registers that are running in your retail stores are business functions, as are accepting retail orders, accepting cash, and operating that machine, as well as the inventory application that keeps track of all of the boxes in the back of your stores and in your warehouse. Those are business applications, even employee times of entry. I also included the software, the customised software that goes into car-making robots. Those are all business applications, and they're actually performing the core business services that your business provides. As a result, you may notice that some of the items on this list become generic over time. So, despite the fact that you may have been working on a fairly specific employee time entry application over time, you adopt an industry standard application that is not specific to your business or industry. And so they become generalized. They become infrastructure applications eventually. Now the infrastructure applications, which are on the left side of those yellow boxes, typically have the following characteristics: Again, widespread availability is commercial, off-the-shelf, and not custom developed.There's the ability for interoperability with other software. So when you're buying stuff off the shelf, you expect whatever files come out of there. It can be opened in other applications, or it should be able to talk to other applications through some type of interface. It's going to contain a lot of features, probably more than you particularly need. Okay, when we get into the examples, we can see some of this. So these are the situations when you're buying off-the-shelf software that's not customised to your business. They're designing this piece of software that's good for most businesses until your business may only use features A, B, F, and Q, and other businesses use ABC and W. And between those features, there's some overlap. They don't completely overlap. The infrastructure applications are generally run within the global IT arm or in your local IT arm and are not part of a particular business unit. And applications are users end up using them. So one of the features of these applications is that they are not some sort of API or web service that sits in the background and cannot be interacted with by humans. Those are not infrastructure applications. So some examples of infrastructure applications are your email client, the wordprocessing software, and the spreadsheets. In this day and age, no company develops an email client or develops their own word processing application. And again, like I said, both of these things contain many features that your particular company may not even use. There are calendar applications, payment services, and any sort of CRM application or enterprise resource planning application. These groupware apps streamline anything in your system. Administrators have access to your network and can manage computers remotely. All your software development tools, your Visual Studio, your Eclipses, Xcode, and all those things like that Those are all applications that users use, but they are not specific to your business. On the application platform level, which is the green box, you've got a common set of services that many applications can end up using. The CRM lists a bunch of possible services in those green boxes. Your specific architecture will only include those services that are actually required. So if we look at this box again, you'll see all those different green boxes, but not every design is going to include every single one. These services are frequently distributed across your network. You're going to have different servers and processes and functions. So, for instance, your email service is provided by an email server, and your file sharing service is provided by a file sharing server, printing a web server database. They're all unique pieces of infrastructure and application platforms. Now, underlying the most simple part, I guess, of the communications infrastructure—which are the networks and the routers and the things that let these computers talk to each other—they're not insignificant. And when you start designing and rolling out the solution, you're going to understand your firewalls and how A is going to talk to B, especially if you move towards the boundary list information flow model where things can be shared across all these different organizations. But that's pretty straightforward to explain. Now, underlying all of that, CRM has this concept of qualities. And qualities are so old that even many years ago, before I even knew about TOGAF, I knew that applications had certain properties that were desirable, right? You want availability and performance, reliability, maintainability, scalability, and security. There's all these words that are usedto describe a robust, well designed application. And so all of the services, from the business layer down to the platform layer and down to communications, you want them to have a lot of these characteristics. You want your network to be secure, you want your applications to be secure, you want all of those services in the middle, et cetera. These are all adjectives. You want to describe each component. These are the qualities that the tierra talks about. As you can see, that's pretty much it. That's so generic that if all I gave you was this and said, "Go and implement that," you would say, "Well, you can't implement that." It's just a description of any design. So that's why you're being asked to customise this. We'll get into the next lesson, which is on tripleIRM, which is ecommerce systems architecture, which is a customised version of Trim. It's a more specific design still fallswithin it's a subset of Trim. So we talk about triple RM, and we'll talk about customising these things. So stay tuned.

9. Customizing the III-RM

There. In this lesson, we're going to talk about the Integrated Information Infrastructure Reference Model, otherwise known as triple IRM. Now this reference model is the second reference model that's included with the TOGAF 9.1 specification. We just discussed the CRM technical reference model, so let's move on to the IIRM. So triple A RM is a common systems architecture. From the standpoint of the enterprise continuum, it is intended to take into account more Internet and internet applications while focusing more on providers and consumers. And finally, it's an enabler of the Open Group's boundaries information flow, which is a concept that they're promoting. So on screen is the triple IRM model, the diagram of it, and the overview. You can see that it's a bit different than the diagram of the CRM. In this model, we've got only the application layer (the yellow and orange boxes), the platform layer (the green box), and the qualities that surround the whole thing in brown. And so you'll notice there's no mention of networking, no mention of operating system communication, and no APIs. All of those sorts of things have gone from the diagram. That's why it's slightly more specific than the CRM. And between the application layer and the data layer, you can see the business applications in yellow and the infrastructure applications in orange. Now this is a more detailed diagram. I don't expect you to be able to read all this fine print, but you'll have to go to the specification if you want to see it. But basically, it is the business applications, which are phone, fax, mail, video, conferencing, and a web portal. These are consumer applications. There are brokers of applications in the middle, and there are the providers. So there's a mail service. So you have the mail client as well as the mail service in the yellow boxes. Now in the orange boxes you have development tools, design tools, construction tools, programming languages, APIs, libraries, utilities, managers, and things like that. And then in the platform layer, you have directory services, naming and registration, publishing, subscribing—all of those sort of cross the company's platform-specific services. So that's the triple IRM. Coming up next, we're going to talk about the key deliverables of the admissions process, a big topic, so stay tuned for that.

10. Half Way Mark

Congratulations for making it roughly halfway through the course! I know a lot of the concepts are tough to grasp at first, and that's why I'm here to help. If you have any questions about TOGAF or the exam, hit the Questions tab inside the relevant lesson or on the course homepage to see if it's been asked before. Or you can ask the question yourself. Join in the discussion. Let's all help each other with TOGAF. And I encourage you to reach out to me inside the course for help if you need it.

Go to testing centre with ease on our mind when you use The Open Group TOGAF OG0-092 vce exam dumps, practice test questions and answers. The Open Group OG0-092 TOGAF 9 Part 2 certification practice test questions and answers, study guide, exam dumps and video training course in vce format to help you study with ease. Prepare with confidence and study using The Open Group TOGAF OG0-092 exam dumps & practice test questions and answers vce from ExamCollection.