5. Phase B – Business Architecture
Up actual architecture documents. This is the bdat phases. Business data, application of technology. Remember earlier in this course I talked about the application domains of togaf and those are the four. This is Phase B, which is the first one, which is business architecture. We’re fortunate that B and Business start with the same letter. So Phase A, Architecture Vision, is about developing a basic architecture vision and a high level overview of what you want to develop. Now that we get into Phase B, we’re talking about business architecture and you’re developing the target.
Within the toga specification, we have the concept of baseline architecture, which is the architecture as it exists today, and the target architecture, which is the end goal of where you want your architecture to be. There’s also the concept of transitional architectures, which may be waypoints along the way. If you can’t go straight from your baseline to your target in one step, you may have transitional architectures in between. The other purpose of this phase, besides developing the architecture, is to develop the roadmap. The roadmap basically is analysis of your baseline architecture and your target architecture, where you identify gaps between them, and then those gaps become work items that go onto your roadmap.
So the business architecture is based on your architecture vision. So once you’ve identified where you want your company to go, you can sit down and look at your business requirements, your business architecture, and what adjustments need to be made in order to get to where you want to go. The inputs of them are all fairly straightforward. As I’ve said in the past phases, you basically take all of your existing materials in the architecture repository, everything that you did in the preliminary phase, the phase A, particularly business principles, goals and drivers, your capability, stuff, communication plan, et cetera. The architecture principles and all of this gets fed into Phase B.
So you’ve got your draft documents that were created as well in the Phase A. So the steps for Phase B are that you are basically going to have to select any kind of reference models, viewpoints and tools within the context of toga. A reference model is basically a standard model for doing something. So if you’re working in the banking sector, there may be business architecture standards for banking. If you’re working in education, there’s probably architecture standards for education, et cetera, et cetera. So if you need to go to your industry and choose architectures that other companies are also implementing, you can choose those as reference models.
Develop the baseline business architecture again, you may already have most of it. If this is not your first time through togaf adm, you may already have your architecture well documented. If you don’t, you may want to get an understanding of where you are today. What’s your current business architecture? Where are the business units and the processes? How do systems connect to each other? Then you develop your target.So once you’ve got your vision, you’re going to know where you want to go and then you’re going to want to know what you need to do to change your business architecture in order to get there. The gap analysis is the difference between the two. Those gaps become work items.
Those work items go on to roadmap and the last step is to resolve impacts. And so if you’re starting to make decisions that say, you know what, we need to outsource this function, we are not call center people. We do not need to have a whole call center department. We should look into finding people who have better outsourcing capability. Well, that’s an impact on your current business and you’re going to have to go and start to resolve those impacts on other parts of your business. Then you basically come up with your business architecture. You’re going to want to do your formal review. So you go around to all the various stakeholders and you tell them, this is where we’re going with the business architecture.
Once they give you their feedback, you can finalize that. And by the end of Phase B, you have a finalized business architecture definition that’s called version 1. 0 within the toga standard, which means it’s finalized, signed off on and approved as an output from Phase B. If you need to go back to any of your phase A, deliverables your vision to your business goals business drivers and revise those you can you’re going to have the finalized, approved baseline and target business architectures in this phase any kind of requirements which are draft because you get all of your requirements together to make an architecture requirement specification.
And then the roadmap, any of the business requirements elements of the roadmap come out the artifacts. Now there’s a lot of them. So as you’re going through to create your business requirements, you’re going to be looking at various diagrams, lists, matrix, et cetera. Now you’ll see these on the screen. Again, you don’t need to memorize them, but you should know that the business interaction matrix is probably a business diagram. That’s a business matrix that’s required for the business requirements, et cetera. So take a look at these artifacts and get a sense of this is part of the business. Okay? Business requirements.
We’re not talking about data, we’re not talking about applications, we’re not talking about technology, we’re talking about processes and business. The ones that are highlighted in red are new for togaf 9. 2 that were not part of the togaf 9. 1 standard. So I should say, yes, there was a lot of changes relatively in this standard for version 9. 2, for this Phase B compared to the rest of the phases, which didn’t really change much at all, phase B got the most update. So to recap Phase A, the architecture vision phase is about establishing the business goals and Phase B is about once you know where you want to go, how do you get there for the business.
6. Phase C – Information Systems Architecture
Now phase C is a little bit different. It says Information Systems Architectures. But as you know, we’re talking about bdat, which is business, data, application and technology. If phase B is business and phase D is technology, then phase C is actually both data and application. So I look at it as a bit of an odd duck, and here’s a picture of a duck. I saw this actually in per person last summer. But basically phase C contains two phases in one. One is to define the application architecture. The other is to define the data architecture. Now, the toga specification doesn’t say under which order you need to do this. And so you can decide whether you want to work on them together, whether you want to work on one and then the other and in which order you want to do it. In the end, you’re going to end up with both data and application requirements, gaps, et cetera. So you end up with two sets of outputs for each of these architecture domains, but the specification doesn’t tell you what order to do them.
Now as we’re going through these bdat, we went through business, we’re going to go through data and application, you’ll notice a pattern that the inputs are all basically the same, the steps are all basically the same, and the outputs are all basically the same, except they’re focused on their individual domains. So that’s a tip. So the purpose of phase C, information Systems Architecture, is to develop the target information systems architectures for both data and application. And of course, the purpose is also to get those candidate roadmap items, which are work items that go into the roadmap based on the gaps between the baseline and target. In the coming up videos, we’re going to look at both.
7. Phase C – Data Architecture
Of phase C. So this is phase C, the data architecture. The purpose of this half is to develop the target data architecture and also you’re going to get the data related candidate architecture roadmap items. The inputs to phase C are pretty much the same as phase B and will be the same as phase D as well, which are all of your previous work. All of the stuff in the architecture repository, phase A stuff, preliminary phase stuff, anything that was developed in phase B, which is the business architecture roadmap and the business architecture documents, those are also inputs into phase C. We align by developing the business phase. First we’re going to basically develop the data architecture based off the business requirements.
The steps for developing the data architecture very similar to the business architecture, you’re going to select any reference models that you may have available. You develop your baseline data architecture and your target data architecture. Then you look at the differences between the two and you can develop a gap analysis. Any of those gaps become work items that go onto the roadmap and then if you’ve got impact so let’s say you are starting to recommend changes that are going to be impact other teams, impact other departments. Let’s say you want to recommend that the customer information live in a single system and all other systems must now go and request customer information from that one system instead of hosting their own copy of it.
If you’re going to come up with major impacts, you’re going to have to resolve those impacts. And that involves talking to people, that involves documenting it and getting buy in essentially across the organization to see if we had a single source of truth for the customer. How does that impact you and how can we resolve that? You conduct a formal stakeholder review, finalize the data architecture, and finally you end up with your version 10, the finalized architecture definitions and so the outputs become any revisions to previous phases, your baseline and target architecture to version 10.
The work items are on the roadmap as well as the Architecture requirements section. The data requirements section of the architecture requirements gets filled in with any gap analysis. The artifacts are thankfully not that many and you’ll notice that most of these artifacts relate to data in some way. So the Data entity, data Component catalog, data Entity business Function matrix application data matrix is a new artifact for version nine two. But when you see the word data relating to an artifact, that gives you a hint or a clue that this is part of phase C data Architecture.
8. Phase C – Application Architecture
Phase C is the application architecture. Again, we’re talking about phase C and the purpose of this phase is to develop the target application architecture and develop any candidate roadmap items based on the work items that come up when you assess the gaps. Again, the inputs are going to be everything from previous phases, the business and data related roadmap map. So if you’ve done the data first, then that gets inputted into the application changes. That’s the significant one. The steps are again pretty much the same reference models, develop both the baseline and target application architectures, perform the gap analysis, get the candidate roadmap components based on those gaps, resolve any impacts. So if you are making major changes that affect other people, we have to start working on the buy ends for those.
And you conduct your formal stakeholder review, get their feedback, get their sign off. And once you finalize that, you created the application architecture documents. So it’s the baseline and target application architecture to version one and the application section of the architecture requirements documents. The artifacts, there’s a few, but again, we’re talking about software and we’re talking about applications. So you’ll see a lot of the word applications or software or interface in these application names. There’s nothing but new that’s been added for 9. 2. And again, don’t have to memorize these, but understand that when you’re talking about the application communication diagram as an example, that’s probably an application requirements phase that’s going to be worked on.
9. Phase D – Technology Architecture
The architecture domains that we’re trying to define. This is Phase D. The technology architecture. So phase D, the technology Architecture happens after we’ve already defined the business data and application only. Then we move on to technology issues. After this we’re going to get into types of planning and putting stuff into calendars and things like that. The purpose of the technology architecture is to develop the technology architecture, the target technology architecture, and to identify any roadmap items that we need to put onto our work list. Based on the gaps, the inputs are pretty much similar to the previous business data and application phases, except on the technology input.
You’ll see, number two says product information on candidate products. And so if you are going to select a third party application, for instance, you may need to understand what hardware they require. You need additional servers or you need to purchase hosting or enter certain contracts. So any kind of product information becomes inputs into your target technology architecture. The technology principles are also part of this. Any of those draft architecture documents in phase B and C, the Architecture Roadmap items that are business data and application as well. So again, any of those previous phases become inputs.
The steps are also pretty much the same. You’re going to select reference models, tools, develop the baseline and target technology architectures, do the gap analysis between them, define any candidate roadmap components, so any changes you need to make to your technology based on the changes you’re making to the data and applications, et cetera. And if these are significant changes, then you need to resolve impacts. You do the formal stakeholder review, you finalize the architecture, you get sign off and you can create the technology architecture definition.
So the outputs of Phase D are the Architecture definition document which includes the final versions of the baseline technology architecture and the draft technology Architecture, as well as those components, part of the architecture requirements and again, putting this stuff into Architecture Roadmap. So now we’ve sort of come to the end. Again, like I said, in the beginning of bdat of the architecture domains, we’ve developed baseline and target architectures for business data, application and technology. So in the coming lessons we can start talking about analyzing those, coming up with a plan, prioritizing them and putting together, starting to work with other teams to get this plan to put into motion.
The artifacts produced at the technology level, again are all technology related. The standards, portfolio, environments and locations, platform network computing, these are all technology terms. And so if you see these on the exam, you should know that this is Phase D, the technology architecture. One of the notes in the togaf 9. 2. So you’ll see this I guess more and more into the future toga standards. But toga 9. 2 made a special point of pointing out that about emerging technologies. So one of the criticisms of togaf is because it does take so long, seven or eight years to do a revision to the togo standard. Technology changes a lot faster.
And so our roles as architects have to be above the standard and we have to be more responsive to our clients and to our companies. And that includes understanding if there’s a big trend in now, mobile was the trend a few years ago. But if there’s a big trend in modular computing, a big trend in cloud, a big trend in drones, then if that’s relevant to your business, your role as an architect, especially in the technology space, is to look for opportunities and these new technologies, understanding that the decisions that you’re making today impact your company for months and for year to come. Then you’re the one that’s responsible for bringing forward some of these new ideas.
