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

3. Phase A, Architecture Vision, Step 3 (Updated)

All right, on to step three of the architectural vision. Step three says to confirm business goals, business drivers, and constraints. So, you know, you want to identify at the business level: what are the goals of the business going forward in years one, three, five, and ten? Where does the business want to go? What about the growth areas? Where does it see a doubling of growth? Where does it see business being slowed down? You need to understand how the business sees itself growing so that your architecture solution can accommodate that.

And then the other point about these drivers is that obviously something has happened to you. They don’t just start up enterprise architecture projects because they had a dream one night, right? There’s a reason why they want you to come and solve certain problems. And so what are the drivers that are causing them to say, “We need a better architecture organisation now?” We need proper architecture. It may have been some disaster that happened six months ago—all your services crashed—or you are getting complaints from customers, right, that the wrong products are being shipped to the wrong stores or whatever. Those things start to add up, and somebody says, “Stop! What we’re doing isn’t working.” We need to come up with a more thorough, systematic way of developing applications and finding this architecture. So what are those drivers? Maybe the expenses are out of control.

There are lots of different drivers, and you need to understand why they called you if this already exists. Maybe the business goals and the business drivers are in a document somewhere, but you still need to ensure that those are up-to-date, go to different people, and clarify for your own purposes that these are the correct ones that you should be focusing on and defining constraints that must be dealt with. So we all live in the real world here, and there’s not unlimited time, an unlimited budget, or unlimited resources. Those are not the only constraints, but those are some of the more popular ones. You need to break it down on paper and understand what the constraints are that you’re dealing with. If you have contracts with a vendor that have you locked in for the next ten years, or if you have a big project that needs to start in January, as we mentioned in the preliminary phase, And you need to have this done before then. Or there’s a time of year, such as Christmas, Thanksgiving, or whatever, when your company is unable to undertake new development work. It’s just not something that you want to do. You want to have that done beforehand. These are constraints, and you record them and have to accommodate for them when you’re doing your architecture. So, yeah, these are the business goals and the drivers, etc. So that’s it for step three. In step four, we’ll see you in the next video.

4. Phase A, Architecture Vision, Step 4 (Updated)

Okay, we are on to step four of phase eight, the architecture vision phase. And then this step is to evaluate the business capabilities. Now, this is a bit vague and a little complicated. There are two main business capabilities that we’re talking about here. One is the ability of the enterprise to develop and use the architecture that you are going to create for them.

So it’s all well and good to go off and create this fancy cloud-based system with all this flexibility and mobile applications. But if your company doesn’t even like email and still uses fax machines for most communications, jumping from that to a mobile environment might be a bit of a leap, and you need to understand your capabilities in that respect. And two are what they call the baseline and target capabilities of the enterprise itself. What this means is that your company might be struggling in terms of finances, okay, or in terms of being able to successfully deploy and develop projects quickly. You may have a history of failed projects, so you know that even the best laid plans somehow don’t come true. So you have to be brutally honest and say that the enterprise itself has some challenges.

Maybe there are more people that need to be hired within different departments that are not architecture-related. So, even if you get this magical mobile architecture, if your organisation has these challenges and you have to acknowledge them, how you define an architecture for that type of organisation is important. And you obviously want to identify any gaps in the architecture’s capability. So we did the architecture capability in the preliminary phase. You hired people for certain roles, and when you get into the vision phase, that’s when you start to realize, “Oh, we need a proper business analyst.” We can’t just do this. We don’t have this capability that we thought we had, or if this becomes more complicated, then you have to iterate. And this goes into the concept of ADME iteration. But you can go back to phase A and reestablish the architect ability, right? Reassign the roles, maybe establish the governance, but maybe it’s not working out. And you need to go back and reestablish that and come back to phase A.

That’s a real thing that we really need to address. And finally, if there is a gap or some type of limitation in the enterprise, that goes back into informing the design of the architecture. So we said this in the second point above, but basically, if you understand that your organisation is the type of organisation that needs to take baby steps, okay, you need to work on one thing at a time. You cannot be trusted to work on five projects at once and deploy five projects successfully. You need to focus the organisation on a single change and build up some successes, and maybe then, at a later point, accept that there might be two or three going at once. You understand these things about your company, and that understanding goes back into your architecture. And, at this point, you can define how your organisation handles changes, whether it can handle large changes or not, when you’re breaking down the work packages and determining the size of each work package. So that was step four. I hope that made some sense. We’ll get into step five in the next video.

5. Phase A, Architecture Vision, Step 5 (Updated)

All right, so step five is to assess your business’s readiness for transformation. TOGAF has a thing called a business transformation readiness assessment that you can use to evaluate the organization’s ability to adapt to changes. So we touched on this in the last step a little bit, but basically, if your organisation is going to be very resistant to change, if you know that there are certain groups that like to do things their own way and are very difficult to convince to change their ways, well, that’s a risk. And the business transformation readiness assessment is designed to identify these types of risks, mitigate them, and cut them off at the source. Or maybe you need extra communication. Maybe you need to go up the chain and get the executives involved in convincing this department that they need to change. There are lots of mitigations for these types of risks.

Sometimes you just have to accept them. And sometimes, again, if you make your work packages extremely simple, it may delay the ultimate rollout of the final target architecture, but you may be able to make changes in small steps. And the outcomes of this BTRAassessment are incorporated into whatever capability. Like I just said, step four. and it also informs the architecture. When you’re designing the target architecture, again, you’re going to find mitigations. You’re going to be able to reduce work packages, slow things down, speed things up, work around people, and work around problems. This happens as a result of some of the information that you’re getting in this step. So that was step five. We’re about halfway through the vision phase. We haven’t really talked about developing the vision yet. Step six is up next, and we’ll get there. Stay tuned.

6. Phase A, Architecture Vision, Step 6 (Updated)

Okay, step six of the vision phase is to define the scope. And when we say scope here, we’re not talking about the same scope that’s in the preliminary phase. The preliminary phase involved determining the scope of enterprises affected. This scope has to do with what is going to be in the baseline architecture and what is not.

So, if you’re focusing on the technical architectures and you’re in the IT group and hosting, and how things are deployed and changes are tracked for compliance with certain government regulations, let’s say this round of the ADMS in the coming months, where you’re developing these requirements and definitions, if you’re focusing on the technical architectures and you’re in the IT group and hosting, and how things are deployed and how changes are tracked for compliance with certain government regulations, Then you can say, “You know what, if we focus on the It and get that right, then we can move on to the sales function.” We can move on to the customer service function in future rounds. Okay? So having a very well defined scope, possibly a narrower scope, makes your life so much easier. It’s not every problem if somebody comes to you when you’re talking to stakeholders and says, “Oh, my problem is that customers are asking for an estimate for some work and it takes us three weeks to get back to them.” And you’ll know because your scope isn’t the estimation system, it’s not that group of people who are in charge, and you can bring it to their attention.

You can certainly write that down and make sure everyone knows that that’s a concern. But you know, you don’t have to solve that particular problem because it’s not in your scope. So this is the scope of the architecture itself, defining what is in and, of course, more importantly, what is out of the baseline and target architectures. It’s important to note that there are often different levels of detail, and that the point of this is that you need to know what level of detail is required. So for your baseline architecture, especially if you’re doing bottom-up, you can be sort of very light in terms of going and saying, “Well, this is what we have,” and not necessarily needing to get deep, deep, deep into data models and all of those sort of things. However, when it comes to the target architecture, it necessitates a high level of detail because that is what you want to hand over to the implementation teams to implement. So you must understand that you do not need to spend twelve months defining your baseline scope when defining the scope. Okay, there’s the breadth of the enterprise.

This is the Enterprise scope once more. How far across the enterprise breath means how far across the enterprise this specific project will COVID Again, if you focus on the IT department that limits its coverage of the enterprise, the level of detail required for partitioning architecture and partitioning is covered more in the Part Two exam and the Part Two course, unfortunately. But essentially, it means you can have an architecture group working on this and a different architecture group working on that. And if you do it right, you start off together, you separate, you go off and do each individual bit, and when you come back and merge them all together, you’ve got a larger architecture that’s been worked on by multiple people. So you need to understand if any of that is going on, the domain, the BDAT, business data, application technology, and you need to understand that, like I said, if you’re focusing on technology, you don’t have to go so deep into the business domain, okay? Then you can just focus on application and data, and then the technology underneath. So the time period to COVID is part of the scoping. So if you’re trying to define an architecture for COVID over the next ten years or the next whatever, that’s a larger project to try to come up with. Intermediate architectures lie in between.

Transition architectures are the final target, which is something massive and completely different, versus if you know you’re going to do this again in two years and you only need to worry about the next two years’ worth of architecture and changes that may occur that limit the scope of that. And finally, if there are any existing architecture assets that can be borrowed and used, So if you’ve done this before, if this is not your first time through the ADMS, you can go back and say, “Well, we already have the target definition documents; we don’t have to recreate the business; we already have the baseline definition documents; etc.” Or maybe there are some industry standards. So some pieces of your architecture can just be grabbed from the banking coalition. You don’t have to invite them all over again. That sounds like a lot, but it’s very important. Same with the enterprise scope, but it’s very important that you try to define your scope as much as possible. It makes your life easier. And when something falls through the cracks and does happen, we all know that things get forgotten or somebody makes a comment that doesn’t get written down. The scope is really what’s going to save you and say, “Oh, you know what? This wasn’t in scope.” We have a very comprehensive scope document, and it doesn’t even mention anything about this. And so that’s going to be very important. Or if something’s very important to someone showing them the scope document, they can say, “No, you must add this and that to make your life easier and their life easier.” All right, so that’s the scope; we’re past the halfway mark now. Step seven is up next. So what do you see there?

7. Phase A, Architecture Vision, Step 7 (Updated)

All right, this is step seven of the vision phase, phase A. And in this step, we’re going to confirm architecture principles, including business principles. Now, we went through this architecture principle process in the preliminary phase, and so you might be surprised that it’s coming up again right away in phase A. But it’s there, and basically, you have to ensure that the architectural principles are the most current. If there’s any ambiguity, if there are certain things in there that aren’t clear, you need to go to the right people and get those ambiguities clarified.

And if there’s something that’s missing or that ambiguity gets clarified, you go and get endorsements again from the right people for the new items that are being added to the principals. So it’s a very simple step; there’s not one in most cases. You’ll just look at them and verify that you just did them a couple of weeks ago, so they’re still valid, but have a look at them at this point. Coming up next is the biggie: architecture vision development, which is the whole purpose of this phase. So stay tuned for that.

8. Phase A, Architecture Vision, Step 8 (Updated)

Now, we’ve all been building up to this moment. This is step eight of the “architecture vision” phase, which is to develop the architecture vision. You take the stakeholder concerns that were gathered in the first few steps—business capability requirements, anything that’s scope-related, those constraints that are on your architecture and the architecture principles—all of that comes together, and you end up with a high level. TOGAF calls this version 0.1 of the baseline and target architectures. Now, you might think we’re only a few weeks into this process and we’re already coming up with a solution, but this isn’t really what this is. It’s at a very high level. For instance, the Toga spec even offers that you can just draw some diagrams, boxes, and lines and just say, “This is where we’re going to go out and source a solution for enterprise resource planning.”

And this is the ERP solution that goes here. It’s going to replace these five existing modules. We’ll go out and get countingsystem, which will replace these two modules. It may just be some boxes and lines, but you’re going to have to be able to see that these are the problems that I’ve identified, and here are all the boxes and lines that are going to solve those problems. So, yeah, it’s very high level, but then this is what you can go and start talking to people about and saying, “This is what I’m seeing, and these are the solutions that it’s going to have.” So it’s basically within your existing baseline environment and the target environment. These are high-level definitions, and that becomes the vision. And, while it may appear to be something very complicated, once you’ve started talking to people, there are drivers who have gotten you. If your problem was that your website kept crashing during the busiest shopping day of the year, And so, you know, you need to rethink the way that you’re doing technology hosting and the way things are prepared for. You may already kind of know what the problems were. You verify those through the stakeholders, and then you’re able to say, “Well, what we really need to do is find a system that can scale on demand and have infinite scaling capability and draw that out, and you’ll kind of have an idea of what that’s going to look like.” So that’s the vision. There are still a couple of things to do in this phase before we can call it done, but we’ve got someone to work with now. I’ll see you in step nine.

9. Phase A, Architecture Vision, Step 9 (Updated)

Okay, now we’re on to step nine of phase eight, the architecture vision phase. This step states that the target architecture value and KPIs must be defined. So the first thing you need to do is develop a business case for the architecture and the changes required. What we’re doing when we’re working within an organisation is having to make an easy case for spending the money to make these changes. So if we need to go out and purchase $100,000 worth of software, we need to be able to say, “Well, that’s going to save us 100,000 person hours of labour per year, and that’s going to save us $10 million per year.” And so spending $100,000 to save $10 million is a no-brainer.

So we need to start developing what the potential savings are and what the costs will be in order to create this business case. We need to review the value propositions with each of the stakeholder groups. So, you know, you’re dealing with the executives, the IT group, the sales group, and customer service—those people who are key primary stakeholders. You need to be able to say this plan is going to save you money, it’s going to make your job easier, it’s going to turn around response times, it’s going to make your customer service scores go up—all of those value propositions. One thing that always appears in TOGAF is that you need to be able to measure these things when you’re doing the architecture. So if you’re going to say it’s going to save you $10 million or it’s going to save you 100,000 person hours of labor, you should be an architect, and even with just an organization, you’d be able to measure this.

And so what metric are you going to watch? The current value is X, and then the future value is half of X, and you know that you saved that. If you need to do that as part of the architecture to design and develop these metrics, that’s worth doing. Just keep in mind though: if you’re trying to save money or reduce time and you don’t currently have the metrics, obviously starting to get them is a value proposition for executives and for people who are curious about that. But it’s easier when you already have metrics that you can compare against. Assess the business risk. Obviously, within IT and technology projects, you always have to be cognizant of risk. So what is the thing we talked about earlier in this phase, and somewhat in the preliminary phase, of understanding the various risks that come with the project? Whether it’s the transformation risk, okay, but you have to sort of assess that risk. There is a risk management chapter in TOGAF, so those are the four substeps underneath step nine. We’re coming up to step ten, so see you next. Video.

10. Phase A, Architecture Vision, Step 10 (Updated)

Okay. Transformation risks and mitigation activities are identified in step ten of the Architecture Vision phase says. Right? We just talked about risk within the value propositions, but one of the things you really need to do is identify any risks associated with the architecture vision and assess the initial level of risk. Certain things are bound to happen in can always; what are the worst-case scenarios, and how likely are they to occur? And what is a mitigation strategy?

TOGAF defines two levels of risk that should be considered, and I think you should take a closer look at this as this might be on the exam. The “initial level of risk” is the level of risk that you would have faced before you started to implement any sort of mitigations against that risk. So, for example, suppose you’re going to develop a new order entry system, but your initial level of risk is, of course, that orders can get lost and customer records can get misplaced, and so on. As a result, this could be disastrous. But you can mitigate that by having proper backups, by having the system running in parallel, and by running a pilot program. You’re going to have different things that you can do that will prove that the system is working correctly before you go all in and before you commit a catastrophic failure. level of risk. And so the residual level of risk is your assessment of what the risk is after implementing mitigations. And so if you do a proper backup and you have the old system on standby and you can switch over to it and flip a switch, and you’re doing this in a pilot project, et cetera, et cetera, then your level of risk is going to be a lot lower.

Okay? And you have other risks. Maybe the cost is risk and the time is risk, but if you do this properly and the mitigations are going to have a residual level of risk, that’s pretty low. And it’s important to keep in mind that if you are planning to do pilot projects and run these things in parallel, you can include that in the statement of work. Okay? So address these risks and put them in the document. Understand that you are expecting that you’re going to have to do a B+ or some combination of that in order to launch this project. Division’s Transformation Risks and Mitigation Activities step. We’re coming up to the last step, and that’s probably the most important step: the statement of the architectural work. That’s in the next video. and stay tuned for that.

11. Phase A, Architecture Vision, Step 11 (Updated)

All right, we are in the last step of phase A. This is step eleven: develop a statement of architectural work and secure approval. Now this is one of the bigger steps of Phase A. We always have to approach this, and we said this at the beginning: the architecture is going to be treated like a project. So, at the end of this project, you must understand what your deliverables are, what your work products are, and by work products, we mean the artefacts and documents that result from the architecture work that must be produced.

This may not be your first time through the cycle. Remember that the AD/HD cycle goes around and around and around, and it can repeat itself years after you just go around forever. So as you go through the cycle, you’re going to not necessarily need to reinvent the wheel or readdress documents; the documents may all pretty much exist, as may all your baseline documents, etc. So you need to ensure that your performance metrics are built into our project. We just talked about performance metrics in the last video. But you must be able to promise and measure that what you’re seeing will occur and that there are performance-related work products that are linked to this. Continuing on, are there any new work products that need to be created so that this is your first time through the cycle? Everything is new.

If you’ve been through the AD cycle several times, you might realise that there’s some documentation that doesn’t exist that you’ll need to create, and that you’ll need to identify if there are existing word products that need to be changed. So let’s say technology has changed and your customer service building block needs to handle text messages, Snapchat, and things like that. So these are existing work products that, as you might expect, need to be changed. This leads to the question of how these changes will affect other work products. So if your customer service function does expand to include texting, SMS, Twitter, and things like that, what is the impact of that change on other things? And again, determine which architecture domains should be developed and to what degree, and what views are opposed to those things. So, once again, if you’re going to be in an IT-focused project and you know the business isn’t going to change much, the underlying technology will need to grow and improve to support the business.

Then you might focus more on those technology domains and less on the business because the business is not the focus this time. Light on business, heavy on technology in between, on application and data, and then views are targeted to specific stakeholders and their points of view; their perspectives continue on. We must evaluate the resource requirements for the work. So for the architecture work, we need to know it’s going to take three months. It’s going to take five people, and it’s going to take $20,000. You need to make estimates of the resources required and put together a roadmap together.This will be available to you in two to four months. Get a schedule and rough it out. Just like a normal project, right in the start-up phase of a development project, the project manager puts a schedule together. Okay? Again, performance metrics This comes up again and again in multiple steps. a communications plan. So obviously, if you know that there are certain stakeholders that need to be communicated with frequently, you can have that as part of your communications plan.

If they’re high-level people and they just need brief status updates, but they need them monthly, then that goes into your communications plan. Review and agree on the plans with the sponsors, and secure formal approval for the Statement of Architecture work. So once you’ve got all these plans together—the project schedule, the high-level vision, all these plans that come together—you’re going to go through your business sponsors and review them, and they’re going to say yes. And the final thing, of course, is to get their formal signature to proceed and say, “This is great.” We want you to deliver this. So that was the architectural vision phase. I’ve always looked at the “architecture vision” phase as being one of the most significant phases, even though it’s the second phase in. But this is where you’ve got this high-level vision. You’re putting boxes and lines on a piece of paper. Maybe you go deeper with it. You’re putting together business plans. There’s a lot going on in this phase. And then the rest, B, C, and D, go into digging deeper into those, and ENF puts the plans together. GNH deploying. This all starts off with this. This is the spark that lights the fire. Next, we’ll talk about the business domain, which is phase B. And so we’ll get into that in the next video. Thanks.