TOGAF 9 OG0-091 Part1 – Phase D In Detail: Step by Step

1. Phase D, Technology Architecture, Step 1

In this section, we’re going to talk about Phase D, which is the technology architecture steps. On screen is an overview of the technology architecture phase. It is the T in the dot acronym. And the goal is to create baseline and target technology architectures for version 10 while identifying any gaps between the baseline and target. In this lesson, we’re going to talk about step one in more detail. So step one says to select reference models, viewpoints, and tools. So the first part of that is to go into your architecture repository and pull out any reference models or patterns that already exist based on your knowledge of the business drivers at this point.

The second part of that is to start developing those viewpoints because, you know, you’re going to be speaking with technology-focused stakeholders. You’re going to need to be able to address their concerns. So, obviously, you may be focusing on the business and addressing their concerns as well as developing new business solutions to their business problems. But the technology people are going to be more concerned with how it impacts our servers, how it impacts our network, are we moving to a cloud-based architecture, and do we have security concerns? All of those technical concerns get raised at this level, and you need to start developing those viewpoints. The third part of that is to identify appropriate tools. And so within the technology space, there are some really good tools that map out networks—where the firewalls are, where the servers are, all the IP addresses, all the applications running on those servers, et cetera. So you’re going to identify those, or maybe they already exist.

Technology professionals are also usually pretty good at keeping their network maps and other information up to date. So underneath Step One, of course, are these substeps, and it’s the same here as in the other BDAT phases. Step 1.1 is to determine your overall modelling process. And again, let’s say most of your changes are going to be focused on applications and not on technology. That you expect the technology won’t be impacted, that things will be updated in place, that you’re not going to need new servers, that you’re not going to need new networks, and that you’re not going to need any sort of new connections. Then you may not need to go so deep on this technology part. Okay, so this is going to be dependent on the standards of your organization. 1.2 says to identify any required catalogs. And so having a list of all of your applications and what servers they run on in your technology portfolio is going to be one of those catalogs. The standards of technology within your organisation are another catalog. Okay? The matrices, once again, represent the relationships between things, and so there is only one matrix that TOGAF recommends, which is known as the application technology matrix.

Again, the technology supports the applications. Step 1.4 is to identify required diagrams, and within technology, they love diagrams, and there are a lot of them. So environment and locations; platform decomposition; processing; networked computing hardware; communications; engineering You’re going to go into the togas section, and you’re going to look at these things. You can Google them as well and see these diagrams. Okay, step 1.5 says to identify the types of requirements to be collected. All right, so you’ve taken all of your catalogs, matrices, and diagrams; they’re all complete. And now you start to identify the requirements that need to be met by the architecture. Is there anything that the technology team and the technology group need to do that this new architecture is trying to tell them to do?

And finally, step 1.6, which is unique to the technology architecture domain, is Select Services. Now, to remind you, services—I can call them business functionality—are available to applications across your enterprise. And it’s generally supported by your IT department or by some outside vendor. This is email services, printing services, authentication, and credit card processing. As a business unit within the application, you do not develop your own emailing capability. You’re calling SMTP; you’re calling other services to do that. same with credit card processing. You’re hopefully not creating your own credit card processing application unless you’re a credit card processor, I guess. But you’re tying into an existing one. And so in this step, you’re starting to say, “Well, what services does the company need to provide to the business units?” There are things that the business units are doing inside their own applications that can be centralised and provided to everybody. So if there’s a type of service that three or four of your business units are providing independently, why not centralize? That just becomes central. So that’s it for step one. In the next video, we will get into step two.

2. Phase D, Technology Architecture, Step 2

So step two says to develop the baseline technology architecture description. So the baseline description of your existing technology architecture So what? Servers, networks, firewalls, and all those technology elements already exist. Again, I think that most large companies already have this. The technology teams are pretty good at keeping documentation updated on what they have installed. As a result, this may be fairly simple for you.

How much of your technology is actually changing? Like I said before, if your technology isn’t changing and you think there’s going to be no new requirements or very minimal requirements, you may not have to do much work on the baseline technology architecture. Identify the relevant technology-architecture building blocks. So you go into your architecture repository and you pull out your ABCS and your SPCS, your architecture building blocks and solution building blocks that relate to technology architecture. And finally, you’re going to use these models that you developed in Step 1 to create this baseline architecture document. Okay, so that’s pretty much it for step two. Like I said, I think this is going to be one of those easier steps because a lot of this should exist. And you’re talking about physical things here, so you’re talking about servers and networks. So in the worst-case scenario, you go and look at the servers and find out what the servers actually are. So it becomes more of an inventory step. So that’s it for step two. The third step is up next.

3. Phase D, Technology Architecture, Step 3

All right, onto step three of the technology architecture. Step three says to develop the target technology architecture description. So the target architecture, as we all know, is the desired architecture. So you need to develop the description of that to the level that’s needed. Again, if there are very few changes to the technology architecture, it’s going to pretty much match the baseline pretty much.If you’ve got radical changes, you’re going to need to get into a lot of detail in terms of what’s changing, what servers you need, and how that’s going to work. So the target technology architecture supports the vision, the business, and the data and application phases.

And you need to identify relevant building blocks. So if you go into your architecture repository, you can pull out building blocks. If those building blocks do not exist, you may have to create some in order to create this technology architecture. So again, keep in mind that you’re going to have to talk about this technology architecture with the relevant stakeholders. As a result, building the viewpoints for those as you go will be necessary. So develop this architecture to a level that you can then explain to people. Obviously, you’ve got models that were developed in Step 1 that can now be used in the target architecture just like they were used in the baseline architecture. That should help. Let’s get on to the next step. Step four is in the next video.

4. Phase D, Technology Architecture, Step 4

We’re on to step four, which is the gap analysis step. So, obviously, you need to validate your architectures by going through the baseline and target architectures and looking at them from various perspectives, which are the business view, the technology view, and various stakeholder perspectives, to ensure that they’re consistent, okay, and accurate.

So make sure that your architecture supports those technology principles and those business objectives and constraints that we’ve identified in the vision phase and phase eight. So we’re being consistent here. We’re not recommending the types of technologies that we’ve described in our technology principles. Go against them. Make sure that your architecture model is complete. And so as you go through the various requirements, make sure that you’ve got all those domains that cover those requirements. Okay? So if you’re going to need mobile applications, that’s going to be what the servers are that support that and what the processes are that are needed for that. And finally, the whole purpose of this step, I guess, is to find those gaps. As a result, your baseline architectures reflect your current situation, while your target architectures reflect your desired state. And there’s a gap analysis technique that TOGAF describes in Part 3, Chapter 27 of the Toga Spec, that will tell you how to identify those gaps and find the differences and document those. So that is step four of the technology architecture. Let’s get on to step five.

5. Phase D, Technology Architecture, Step 5

Okay, moving along here, we’re into step five of the technology architecture phase. This is a list of potential roadmap components. And so you’ve created your baseline architecture and your target architecture. You’ve run your gap analysis in the last step. And so all that stuff gets fed into what’s called a “technology roadmap.” Okay? These are the features that will be developed over time. So the roadmap is required to prioritise the activities. And so, for example, in the technology space, oftentimes if you’re needing new environments, you’re needing multiples of those environments. You need a development environment, a QA environment, a staging environment, and a production environment. Those things can be deployed at different times.

They’re not all provided at the same time or on the same date. You start off with a development environment, which could be available for several months before you need to have the production environment ready. And so you’re creating a roadmap and saying, “Well, this is roughly when we’re going to need new servers to be brought online.” We’re going to need this time, at this time, at this time, okay? All of this roadmap gets fed into your opportunities and solutions. And we’ll talk about that in phase E, obviously, coming up next. But the opportunities and solutions are where we start to take this roadmap and turn it into work packages. So that’s all the information I have. So that’s step five of the technology architecture. Let’s talk about step six.

6. Phase D, Technology Architecture, Step 6

As a result, step six of the technology architecture states that impacts must be resolved across the architecture landscape. Obviously, once the technology architecture is finalized, you need to sort of analyse how this impacts the wider business. What kind of implications does it have? You’re an enterprise architect on a specific project. scope; this is part of the phase’s beginning. Phase one is to define your scope. And so you’ve defined your scope.

Now, is anything that you’re doing starting to impact stuff that’s outside of your scope? Those people need to be brought into the loop on that. Are there changes that have been happening that need to be accounted for? Okay. So some other project that you’re not part of has just recently gone live, and they’ve got some cool features, and you can start to use those features. For example, I recently worked in a company that provided their own internal cloud environment. Right. They have a whole setup that’s cloud-based that’s rolled out department by department. And so you’re coming up with the need to do this, and suddenly there’s a whole cloud option available to you that wasn’t there before. So what other changes are happening independently of your projects that you can take advantage of now? The other thing, of course, is that as you’re doing these things, maybe you need to step back and say, “We need to have this as a service that the entire company enjoys.” What other opportunities are available for sharing? Okay. And finally, there are often times when projects are already underway, already in progress.

The business does not stop developing applications or developing projects as you’re going through your TOGA phases and your ADMA phases. So you have to have some sort of knowledge of the projects that are going live soon, either this quarter or next quarter. Is anything you’re doing going to be affected by that, okay? Or anything else they’re doing that affects you? So just make sure that what you’re doing doesn’t cause any problems. There’s no point in a big revamp of a project going live when you are recommending they get rid of it. You’re going to have to sort of deal with those things. So that’s the resolution of the impacts for the technology phase. Let’s get on to step seven next.

7. Phase D, Technology Architecture, Step 7

Now, step seven is the formal stakeholder review within the technology architecture phase. It’s actually quite simple. A lot of the other phases have more steps here. This step only has two substeps. So step one is to ensure that your architecture conforms to the original purpose of the project and that your statement architecture works. So it’s just basically making sure that when you started, you had certain business drivers; there were certain things that were told to you that were high priorities and that were reasons for you to redo this architecture.

And you’re going to make sure that what you’ve got now conforms to that. And once you’ve done that, you go right into stakeholder review. Obviously, the stakeholders in the technical phases are frequently your company’s technology people—the VP of Technology, the CIO, and others. And so you’re going to be presenting to them on a technical level. And you’re going to have—I mean, architects in this case are often fairly specialized. And so the technical architect who’s working on this has a big background in technology, can speak the language, talk the talk, and understands trends within technology fields. So they’re going to go in, present this design to the technology stakeholders, speaking in their language and terms, and essentially get approval for our feedback to move forward with this. And if you do get feedback from them, they’ll say, “No, we don’t like this,” or “You’re going to have to do this.” That’s when you go and refine what you’re doing, go back and represent, and then you get the approval. All right? That’s step seven.

8. Phase D, Technology Architecture, Step 8

We’re on to step eight of the technology architecture definition phase. Phase D. This step states that the architecture, the technology architecture, must be finalized. And so you’re going to need to select the standards for each of the building blocks, reusing as much as possible from reference models that were pulled out of the architecture repository. You must ensure that all of your documentation for building blocks is complete and fully documented. Okay. Again, the cross-check of your overall architecture against business goals In the architecture document, document the rationale for building block decisions. You’re going to also document your final requirements. Traceability documents the mapping of the architecture within the architecture repository.

There’s a lot of wrapping up and finalising work products going on here. So the work products are the outputs of the phase. And so one of the products of this phase is your gap analysis. And so you’re going to need to finalise your gap analysis for your technology phase. Step eight. We’re almost done. There’s only one step left, and that’s step nine.

9. Phase D, Technology Architecture, Step 9

All right, we’re on to step nine of the technology architecture phase. Phase D: This is the architecture definition document. Step So the next step is to document the rationale for building block decisions in the Architecture Definition Document. So as you’ve created your architecture and you’ve decided to use certain building blocks, you want to make sure that you’ve got the justifications for those written down, documented at every I, dotted T, crossed T, et cetera. The Architecture Definition Document as a whole has different sections for each of those architecture domains.

And this section is to create the Technology Architecture section of that document. So basically, you’re going to have the fundamental functionality of the technology, any of the dependent building blocks, any interfaces that you’ve chosen, any sort of third party that needs to map into your environment, mapping your technology to the business entities, et cetera. And so within this Technology Architecture Definition Document, you might have to use some graphics and your models. So if you’ve created network diagrams and application server maps, that can go all in here, and that’s it for phase D. We’re out of the four BDAT domains now. It can get, hopefully, a bit more interesting. We get into opportunities and solutions, which is Phase E, in the next section. Just remember, if you have any questions about these, I’m always available to answer them. You post them to the discussion group, and I’ll respond to them as best I can. So thanks a lot. We’ll see you in the next section.