TOGAF 9 OG0-091 Part1 – Phase C (Data) In Detail: Step by Step

1. Phase C, Data Architecture, Step 1

So now we’re getting into phase C, which is the information systems architecture steps. I’m going to break it up into data and application in separate sections here. We don’t need to COVID information systems as a single entity because the steps of information systems architecture are the data and application steps separately. Anyway, the phase information system doesn’t have its own steps. So, just to refresh your memory, space C is the third phase of the cycle and the fourth phase of the overall adm. We’re only going to talk about the data architecture in this video. It is the D and B, and the purpose of it, like the business architecture and the next two, is to develop the baseline and target architectures and identify the gaps.

So some of this is going to appear quite repetitive because the four architecture domains are really treated similarly in business, data, application, and technology. There are nine steps in each of those domains, and they’re basically the same nine steps. But for the sake of completeness, we’re going to COVID this in this section separately. We’re not going to sort of lump them all together. So step one is to select the right reference models, viewpoints, and tools for the data architecture. Okay? So you’ve got to select relevant data architecture models and patterns from the architecture repository based on your known drivers. And then, because we’re dealing with data architecture, we also have to select the correct viewpoints.

Okay? So when you’re dealing with data architecture, which is how data flows between departments and applications, your technology people are going to be very interested in this, and the security team will be super interested in this. Even your business team needs to understand at least that the people in this department have access to these elements of a customer record, but not that element and those kinds of restrictions and constraints. And finally, similar to every domain, you need to identify tools. And so if you need to do data modeling, there are different, you know, data modelling tools, and you might end up with things like classes and diagrams or flow charts that show how data flows, flow charts. And so you need to identify these tools. And we’re getting to the substeps. There are five substeps underneath the data modeling. So, obviously, number one, but it determines the overall modelling process. So, depending on your organization, you’re going to have standards for doing data modeling. You might require super-extensive analysis, you might not, and you might have lots of data documentation.

Data seems to be one of those areas that’s usually well documented because you’re dealing with databases. Databases are your tools. You can just print out a class diagram or a data diagram right from within SQL Server. And so coming up with data models is actually one of the easier things. Hopefully the references are all there, so the level of detail is going to be dependent on your organization. Step 1.2 is about what catalogues you need. Okay? So you’re going to take the business service information diagram out of the business architecture phase and bring it in here. This will tell you which business services to use and what data to trace back from the application to the business function to data entities. This is going to result in an inventory. This catalogue is a list, so an inventory of the data needed to be in place to support your vision is the raw material for other things. And the suggested data catalogue is the data entity data component. Catalog 1.3 is to identify required matrices. Again, matrices are more like a spreadsheet. It is divided into rows and columns. So this shows the relationship between things.

The suggested ones are the data entity-data business function matrix and business services information. Again, we talked about that in the business phase. And any type of application data matrix is not recommended. I’m just going to keep going here. Step 1.4 is to identify any required diagrams, okay? Just like we said in the business view diagrams, we can create different diagrams expressing the same piece of information from different viewpoints. And so we’ve got the conceptual data diagram, the logical data diagram, the security diagram, the migration diagram, and the data lifecycle. Those are examples of diagrams. Finally, under step one, step 1.5 is to identify the types of requirements to be collected. So you’re getting right into the data requirements, okay? Again, once you create the data requirements, the application and technology domains take that as input. And that’s why data requirements come second. And the purpose of these requirements, of course, is to identify what requirements coming from the business and from the stakeholders need to be met by the architecture. So anyways, that was step one of the data requirements phase. We’re going to get on to step two in the next video, so stay tuned for that.

2. Phase C, Data Architecture, Step 2

So step two of these four domains, in particular the data domain, is to develop the baseline data architecture. Okay, so the baseline description is the existing data architecture. And again, this could be very easy to get. If you have data-processing services and databases, that is your current architecture. Usually, you’re going to have to understand the data layers and how those things are handled when you’re wrapped in security and stuff like that.

If your data isn’t really going to change too much, if the concept of a customer and what fields you collect, the concept of a widget and what fields you collect, and your product catalogue don’t change much, maybe it’s going to stay largely intact. You don’t have to do as much if the data and architecture are not going to change. It is also necessary to identify any architecture building blocks related to the data that already exist in the architecture repository. And in step one of this phase, we created a bunch of models using modelling tools. Identify which modelling tools So you’re going to grab those models and use them to find your baseline. So that’s step two. We’ll cut into step three in the next video.

3. Phase C, Data Architecture, Step 3

Hey there. We’re into step three of the data architecture. This is the target data architecture description. So in step two, we develop the baseline. Step three: we’re moving up to the target. So again, the level of detail needed is going to be dependent on the situation. So obviously, if you’ve got a lot of data changes, new applications, new web services, and new Windows services going live, you’re going to have to get very detailed with this stuff.

And if it’s largely the same, you can rely on the baseline architecture to handle this. The purpose of the target architecture is always to support the architectural vision. same in every phase. You have to identify any relevant data architecture building blocks that exist in the architecture repository. And again, you can use models. If you’ve done any data modelling in the first step, you can use those models to support your architecture in this step. So we’re moving on down the road here. This is the target. You know what’s coming up next. We’re going to have to define the gaps. So stay tuned for that.

4. Phase C, Data Architecture, Step 4

Okay, step four: perform a gap analysis of the data architecture. You have your baseline, and you have your target. You’re going to compare them side by side. Obviously. Step one of that is to validate the architectures, making sure they’re complete and that you’re not missing bits of data objects or relevant entities within any of these diagrams. When you’re developing these views for each of the different stakeholders, it’s going to give them a full picture and not make them blind to certain things. Ensure that the architecture follows your data principles.

So obviously, if you’ve got data principles that talk about how atomic your data structures are going to be, service-oriented architecture, how things are served by web services, all those wonderful things, you’re going to make sure that your design and your definitions follow these objectives and principles. Go back and compare the results against the requirements. Make sure that you’ve covered every requirement. If you’ve got plans for new applications coming in or plans for new lines of business, those are all covered within your data analysis here. And then finally, with all that, you identify the gaps, and you’re going to know what the difference is between the target and the baseline. Pull those out and say, “Okay, we’re going to need a whole bunch of new tables.” We’re going to need System A to talk to System B, and there’s going to need to be a web service or some kind of service to serve data between these two. That concludes your gap analysis. Next, we’ll talk about where that goes, and where it fits on the roadmap. Stay tuned for that.

5. Phase C, Data Architecture, Step 5

Step five here is in the data architecture phase. Phase C is to identify the candidate roadmap. So you should be very familiar with this. We did this through the business phase, but now that you’ve got the gap pulled out, those get on the roadmap. The key differences from the gap analysis get added to the roadmap. You haven’t put them into work packages yet. You have not integrated the business data and application technology domains. This is just the data differences, okay? The roadmap is used to prioritise activities, and we said this in the last section as well. But all this feeds into phase E, which is opportunities and solutions. So right now you’re just filling in the blanks, making a list of them, and that becomes a candidate roadmap component. Okay, coming up next is step six. We’re about halfway through this at this point, so stay tuned for that.

6. Phase C, Data Architecture, Step 6

So step six of the phase C data architecture phase is to resolve any impacts. You’ve got your gap analysis; you’ve done your roadmap. You know exactly what you need to do—the difference between the baseline and the target. Now that you’ve raised your head, you should get up from your desk, take a look around, and figure out what this means. If you’re going to distribute your data, let’s say one of your decisions is that each regional office is going to have to have copies of its own data instead of the data being stored in a central warehouse in the head office. Because one of your problems is that each location is having trouble getting real-time access to its own data. Well, then there are wider implications, okay? There are security implications. There’s the way your application is partitioned. Can your application handle local data stores?

Are you going to feed it into the head office and then feed it back out to the regions, or is it going to actually get fed into a local data warehouse within each region, and from there you just go back through this design and understand it? Once you’ve done one thing, how does that impact other parts of your project? Does it impact other architectures that are outside the scope of your domain here? Is there any other change that needs to be accounted for besides this? So maybe there are other projects, and they’ve added more tables and upgraded to the next version of the database. Or maybe they’re making decisions that are even greater than that. So if those changes are happening outside your project, you need to account for them inside your own project. And, of course, if you’ve begun to create these data diagrams and have begun to understand where you are and where you want to be, you create data building blocks, solution building blocks around that, does that get shared with others for use in their own projects? So that is the impact-resolving part of phase six of phase C, the data architecture. We’re getting close to the end now. You’re going to have to present this to the stakeholders, so stay tuned for that.

7. Phase C, Data Architecture, Step 7

Okay, we’re into step seven of Phase C, the data architecture phase. This is where you present your data architecture designs to the relevant stakeholders. It’s very simple from a toga perspective. Make sure that your architecture conforms to the original purpose and the statement of the work. So if there were lines in the Statement of Architecturework that talked about the need for services and systems to talk to each other and data to live somewhere or have access to data, make sure those are all covered. and have that meeting. Present your data architecture to stakeholders and get their feedback. You’re probably going to have to go away. Tweak this or tweak that, right? Maybe you don’t have the answers to all their questions. Maybe you do. So you go, you present your work, and you either get approval or you have to come back and make a couple of tweaks. Either way, this is the next step for stakeholder review. We’re almost done. So coming up next is step eight, where you’re finalising the architecture.