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

1. Phase B, Business Architecture, Step 1A

Hi there. We’re into Phase B, which is the business architecture steps. To remind you, phase B is the second phase of the architecture development cycle. The whole purpose of phase B is to develop the baseline and target business architectures and then identify the gaps between those target and baseline business architectures. Step one of phase B is to select reference models, viewpoints, and tools. This means you’ll have to search your architecture repository for business architecture reference models and patterns that are relevant to your industry and the types of businesses you’re in. So that’s step one. Then you want to select relevant viewpoints so that you can go to those business stakeholders and demonstrate that their concerns are being addressed.

So let’s say you’ve got a chief financial officer. You need to understand what it is that he’s going to be particularly concerned about, and it might be the financials. And so that’s the relevant viewpoint. The third part of this step is selecting tools. So if you need to acquire software or have particular modelling tools in order to capture things, this is when you identify what you’re needing. It could be Evernote, it could be Microsoft Word, or it could be something sophisticated. That is an IBM rational tool that is used for modeling. And underneath step one are some substeps. And so the first substep under step one, which I’m calling 1.1, is that you have to determine what your modelling process is going to be. So, obviously, when you’re talking to your business stakeholders, when you’re out there mapping your business model, you need to follow a certain process, which could be UML or any number of modelling processes, but the company, and there should be standards within the organisation for doing that.

So step 1.1 is to determine the modelling process. 1.2 talks about service granularity. Now, this is sort of a tricky concept, but essentially, you need to really understand what business your business is in. Okay? So within Toga, they define microlevel functions, macrolevel functions, and services. There’s a little bit of a grey area between all of these things, but micro-level functions are basically a process that your business does. So let’s say the process of sending out invoices has a specific end; you know whose job it is, but there’s not a whole VP of invoices. You don’t have a whole invoicing department, right? This is just a subfunction of finance. On the other end of the scale are the macro-level functions, which affect your entire company. I put HR here, or human resources. So there isn’t a VP of HR. In general, there is a whole HR department. But HR is involved in everything, right? From every interview request to hiring, the day-to-day and month-to-month management of your employees, raises, firings throughout your entire organization, benefits, and things like that, And you’re not in the business of HR, right? So these are functions that your company performs, but they are not its business of your company.

Services are basically what your company provides, right? So the customer wants a website built. Well, that is a service. Your company builds websites. As a result, there are project beginnings and project endings. You know how to build a customer base based on a price list or a cost sheet, and there are processes in place; you want to get better at this. Okay. Services are functions that have a service contract. The third substep is to go through and identify which catalogues you’re going to need. So you may not need to revise as many times during this phase, run, or AD. Maybe a lot of those catalogues already exist. Maybe changing the business model isn’t a high priority for you. You’ve got a very specific technical thing that you’re looking for. But as you’re getting into this phase, you have to identify what you’re going to need. And so go through the list of catalogues we have on the screen and make some suggestions, like the actor catalogue or organisation actor location catalog, process, event control, and product catalogs. These are lists, primarily a catalogue of Toga speakers. And so, as you would imagine, once you have a list of every employee and their role and their job title, that feeds into a lot of other things. In the next video, we’ll continue on with step one.

2. Phase B, Business Architecture, Step 1B

Okay, we’re continuing on with step one of phase B in this step 1.4. Now that we’ve identified the catalogs, we’ll go on and identify the matrices. Okay? The matrices are generally like spreadsheets; they are relationships between things in columns and rows. OK, again, you’re going to use these matrices in the development of other things within your architecture. A couple of examples are the actual role matrix and the business interaction matrix. Step 1.5 is to identify diagrams. Okay, so we have catalogue matrices. Now we’re into diagrams.

This is the third type of artifact. Diagrams are defined as things that present information based on a set of viewpoints. As a result, the type of information could be the same. You’re going to have one diagram that’s facing the sales team, and it might be a different diagram for the technical guys because they have different sets of concerns. Use case diagrams, process flow diagrams, organization diagrams, decomposition diagrams—there are examples of that. And the 6th substep under Step One is that you have to identify what types of requirements you need to be collected. Okay, so now that we’ve gotten all those artefacts together, we’re starting to think about the business requirements. So one thing I found in the Togga document that says requirements is: what would the target architecture have to do in order to satisfy the concerns of the stakeholders? I think that’s a pretty good quote for that. Okay, so once you’ve defined your business requirements, data application, and technical feed off of that, That’s why we’re doing business first. So that’s step one. In the next video, we are going to be talking about step two.

3. Phase B, Business Architecture, Step 2

All right, now we’re on to step two of phase B, which is the business architecture phase. The purpose of step two is to define and develop the baseline business architecture. To remind you, the baseline architecture is what currently exists. Okay? So when we’re talking about business architecture, we’re talking about the lines of business that you’re in, the way that you interact with your customers, and the way that businesses pass data between each other, not the data level at the data architecture, but those interfaces. Okay, so these are your business requirements, and we need to define them as they currently exist. In a typical company, as in many others, you do this from the bottom up, which means you go out and talk to people, conduct research, investigate, contact them, and request a list of this. You make contact with each department. What software do you use? You have to sort out everything that currently exists.

So the other thing to keep in mind is that there’s a concept within TOGAF that you need to define upfront how deep you’re going to go into each of these architecture domains. And so you have the four domains of business data, application, and technology, and you don’t necessarily need to go to the maximum level of detail on every single domain. That could be a waste of time; that could take months; and that could be expensive. If you know that what’s going to end up resulting from your vision is basically a business that doesn’t change too much, You’re going to make a fundamental infrastructure-type change, but the business itself is going to stay on and not have any fundamental business changes. You might say, “Well, I don’t have to get so deep in the business architecture; I can only go to a certain level.” Your company may have standards on this. So it depends again on how much will be carried over to the target architecture. So again, if 99% of your business architecture is going to remain in the target architecture, you don’t, and this is not your primary concern, obviously. And step one talked about modeling, and you’re going to take some of those models and incorporate them into your baseline architecture. Next, we’re going to move onto Step 3 of the Business Architecture Definition. Stay tuned.

4. Phase B, Business Architecture, Step 3

Alright, we’re talking about business architecture. We’re onto step three. Step three says to develop the target business architecture. So we just went through InStep 2, the baseline business architecture. Now we’re moving on to the interesting bit. How are you going to change the business architecture to meet the needs of the stakeholders? Okay, so again, similar to the baseline, if not much is changing, then the level of detail required is going to be less. If there are a lot of changes, you may have to dig a bit deeper. The purpose of the business architecture is to support the architectural vision.

Obviously, if the vision contains certain elements, you must COVID them here. And just like with the baseline architecture, you can use models that were developed in step one to develop your target architecture. We’re going through these steps, and some of them aren’t all that difficult. On screen, there are only three lines that say “develop the target.” Well, that’s quite a bit of work. Right? So to go down and assign the target is going to take you a lot of time. But this is what the framework is about. It’s basically telling you the steps, and you have to go and do the work. So coming next, we’ll go down to step four, which is what happens after you’ve done the baseline, the target. Stay tuned for that.

5. Phase B, Business Architecture, Step 4

Okay, we’re on to step four of the business architecture definition. This one says “perform gap analysis.” Now, you know that gap analysis is generally the difference between the baseline and target, okay? And you say, “Oh, well, in the baseline, we had this, but in the target, we added the following three things, and those are the gaps that need to be taken into account.” So the first thing that you do in gap analysis is validate the architectures, including all the different views. And so, basically, you’re doing a sanity check. You’re making sure that your different views are not saying different things, even though they’re aimed at different people.

The facts, the things written on that paper, there should not be information on one point of view that does not appear on any of the other points of view that are relevant to those points of view. Ensure that your architecture supports all the principles, objectives, and constraints. So, obviously, we began in the preliminary phase, followed by phase a of defining the principles and comprehending the business objectives and constraints imposed on this project. So obviously, if your constraint is that it has to be done in three months, or if the constraint is that it has to save money and not cost money, or whatever your constraint is, you’re going to start looking at what you’re talking about and seeing if those things are covered.

Your principles, again, are guiding certain ways that you operate and do business, so make sure that you’re being true to yourself there. Step three of this step is to test your models for completeness. So, returning to the requirements, returning to the stakeholders who have stated that we need to save money on customer service, be faster at turning around new product ideas, and reduce our manufacturing error rate. All those different requirements that came to you—you have to make sure that those requirements are covered. Obviously, if an important stakeholder had an important requirement and you haven’t even discussed it, you’ve missed something and will have to go back and add it. So once you’ve identified the gaps and validated your models, everything seems complete. Now you list out what the differences are, and that’s it. So, the next step in Step 5 will be discussed in the following video.

6. Phase B, Business Architecture, Step 5

Alright, this is step five. So now that you’ve identified the gaps, you pull those gaps out, and those become your roadmap components. Step five says to identify candidate roadmap components. So first, you’re going to extract those differences out of the gap analysis. Okay? And these become the features that need to be added to your architecture. Again, remember that you don’t have to do them all at once. You can transition these things; you can put them into work packages. But we’re working on the business architecture phase.

We’re not at that point yet. These all become roadmap features. Okay? And again, these are only the key differences that need to go on the roadmap. Prioritizations must be done using the roadmap. So as we’re getting into phases C and D and Phase F, you’re going to start building up this road map. You’ll begin to notice things that are most important and things that are nice to have, or even things that would be nice if they were a side benefit type of deal. And third, this candidate roadmap again feeds into Phase E, which is Opportunities and Solutions. Opportunities and solutions arise when you pull all of these roadmaps together to make one consolidated roadmap. So this is one quarter of that. Is this a business plan? All right, we’ve not done yet. We still have step six to go, and we’ll come up with that in a second.

7. Phase B, Business Architecture, Step 6

Okay, we’re still in Phase B, which is the business architecture definition. The sixth step of phase B is to resolve any impacts. Now that you are creating your business architecture, obviously the whole company has not come to a stop. There are other projects going on. Your IT department might be busy doing things, and your developers are busy doing things.

There are multiple projects going on. Your project managers are busy at all times. And so you’ve gone through this process to this level, and as you’re starting to say, “Okay, we’ve decided that we’re going to phase out the customer service and offshore that to a third party in the Philippines,” you’re going to have to understand those implications. Okay, you’re starting to talk about projects that are coming up in the next six months or next twelve months to bring new technology into your call center. Well, if you are removing that call center, that might have an impact on that other project. So do your decisions within this phase have impacts on other architectures that were not part of your scope, and vice versa? Is there stuff that’s happened outside that you didn’t actually get to account for up to this moment? So if there’s been a new technology that was purchased, maybe your company went out and bought a new subsidiary, a new company that’s going to be merged in, suddenly you can stop and say, “Oh, does that impact what I’m doing?” Maybe it doesn’t.

And finally, you’ve come to some conclusions. You’re starting to build these architectural building blocks. Things are starting to come together. Perhaps there are other projects and architecture departments going on in parallel streams that could benefit from this work that you’ve done so that information can be shared, but does what you’ve worked on have an impact on projects that are already in the works? Maybe there’s stuff that’s going live or is going to go live, or that stuff impacts you. So this is really about raising your head up.If you’re busy working and have your head down, you just look around and see what’s going on—what’s changed? And do I need to tell other people? All right, we’re starting to come towards the end of phase B now. We’ve gone through them all: defining baseline target architectures, identifying gaps, developing a roadmap, and resolving impacts. Coming up next is, is step seven, and this isan important step when you’re going to go off and talk to other people about what you’ve been doing. So stay tuned for that.

8. Phase B, Business Architecture, Step 7

Alright, step seven of the business architecture phase is to conduct a formal stakeholder review. This is where you’re now going back to your business stakeholders and saying, “Okay, I’ve analysed it.” This is what I’ve come up with. They’ve already bought into your vision. So this isn’t going to be some earth-shattering thing. But as you start to dig deeper and determine the implications and how it affects other projects underway and things like that, this might be an interesting conversation. Okay, so the purpose of the stakeholder review is to ensure the architecture conforms to the original purpose of the project and the Statement of Architecture works.

So when you came out of Phase A with a Statement of Architecture and listed all of the things that they required out of your architecture, this was going to be part of that process. And then you’re going to have a big meeting. You might have several meetings. Again, this might be an interesting discussion that makes you go back and rethink some of your assumptions. But you’re going to basically have to go off-tweak. People might have questions that you need to go and document and come back with the answers to. Sounds simple, but this is where you present your work and get confirmation that you’re on the right track. So that’s step seven. We’re almost done. We need to get into this finalization. So coming up next is step eight.

9. Phase B, Business Architecture, Step 8

Alright, step eight of the business architecture phase is to finalise the business architecture. Okay, you’ve had your meeting, you’ve gotten a lot of feedback, and you probably made a tonne of notes. There are people with questions. Some people may not have been completely satisfied. You’ve gone back, you’ve tweaked it, and you’ve gotten to this finalisation step. Okay, so go back to the architecture repository. For example, if you need to add more building blocks, you must delve deeper into something.

Figure out that there are other building blocks that can be pulled into this. Obviously, complete all the documentation that’s been required up to this point. The output section of Phase B is going to tell you all the different documents that you need to come up with at this point. Again, cross-checking against your business goals And so again, if your business goals are to increase revenue, cut costs, and all of those wonderful things, making sure that the business architecture you’ve defined to this point meets those goals is going to happen a lot within TOGAF. You have to go back and validate that your assumptions are correct and that what you’ve created matches what you’ve defined as your business goals. And so this isn’t the first or last time I’ll mention this part. And again, not only the documentation but all the artefacts, the matrices, the lists, and the catalogs—every work product that comes out of the architecture—gets finalized. That’s it for step eight. We have one more step before we exit phase B. So let’s do that.

10. Phase B, Business Architecture, Step 9

Okay, step nine is the final step of Phase B, which is the business phase. And the step says, “Create the architecture definition document.” So we’ve done all that work. We’ve defined everything and finalised everything. Now we’re going to create the definition document in this document; that’s when you start to document your building block decisions. Why is the call centre here? Why is the sales team there? Why is this here? Why is that there? We’re going to have to start filling out the overall architecture document. So there’s a business architecture section, and the subsections of that are the business footprint, description of business functions, management footprint, standards, rules, and guidelines, and the skills matrix and job descriptions for those key roles. Those are all things that go in the architecture definition document, and your business architecture documents will feed into that. So that’s it. You’re done. The business architecture I say done, but obviously these things are a little bit iterative. You might be going back when you get into data and application and realise that you have to go back and tweak something within Phase B; that’s all normal, but that is the bulk of Phase B if this is the time that you go through it. Coming up next, we’re getting into the seconddomain, Phase C, which is the data architecture. So come back and stay tuned for that.