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

1. Phase C, Application Architecture, Step 1

We are now into the second half of phase C, which is the application architecture. A reminder that the application architecture, which falls into phase C along with the data architecture, is the A in the B acronym. This is where you develop the baseline application architecture, develop the target application architecture, and identify the gaps between the baseline and target. All right, similar to data and business phases, step one is, as always, to select reference models.

So go to the architecture repository and select any relevant application architecture reference models or patterns based on what you know the drivers of this project to be, and select relevant architecture viewpoints to demonstrate later how those concerns are being addressed. So, when you’re doing your application design, when you’re choosing the software solutions that will run to solve the business needs, you’ll have to choose the right views, which could be how software communicates with each other and those types of diagrams. Finally, identify appropriate tools and techniques for capturing, modeling, analyzing, and documenting the architecture. Hopefully, this is going to be along the same lines. You’re going to keep some consistency with the BDAT—the business and data techniques. So if you’re using a modelling tool, you’re going to create the appropriate models using that tool, and if you’re storing it and documenting it within the architecture repository, you’re going to use the same tools, hopefully. So as always, there are some steps under Step 1, and I’m going to go through them briefly.

So step 1.1 is, of course, to determine your modelling process. I won’t repeat this. This is the same as the other steps, but, based on your organization, how much detail you go into modelling needs to be defined. Step 1.2 is to get the artifacts, which are at first the catalogues of your application building blocks. And in this step of phase C, application architecture, you’re going to have this concept of logical, physical, and service applications. Those catalogues go into the various matrices and views; a couple of examples are the application portfolio catalogue and interface catalog. Step 1.3: You move on from the catalogues to the matrices. And so related to matrices, as always, are relationships between things. Okay? So, for instance, you can map the applications to the business services that they help deliver. You can identify user and organisational dependencies. There are matrices within matrices, such as the application organisation matrix rule, the application matrix, and the application function matrix. Step 1.4 is now that you’re onto that third artifact, which is a diagram.

Diagrams present information based on viewpoints. And so once the functionality of your software is known, you start to think about things like configuration, right? So you’ve got your application communication diagram, application user location, and enterprise manageability. We’re talking about processes and applications at this point. Step 1.5 says you’re going to have to identify the types of requirements that you need to be creating within this phase. So this is where you get into the actual application requirements. The application requirements provide input into both the data and the technology domains. So obviously, if you’re going to choose one type of application architecture, let’s say you go with SAP to solve particular problems. Well, that’s going to have implications on your data design because SAP has a certain way of modelling data, and it’s going to have implications on your technology because, of course, servers and other things are required to set up SAP. And so this is again where you’re going to come up with requirements that your architecture needs to meet. So that’s it for step one. In the next video, we’ll get into Step 2 of the Phase C application architecture.

2. Phase C, Application Architecture, Step 2

Okay, we’re on to step two of the application architectures of phase C, the other half of phase C, which says develop the baseline application architecture description. So we know the baseline; I’ve said it enough times. The baseline is the existing application architecture within your organization. So we need to sort of delve into that to the necessary level. So obviously, the depth of what you get into is going to depend on how much of that sticks around. Give me an example. I once worked at a big oil company back in the days when we were going to go and instal SAP to avoid the Y2K bug. The company had about 50 applications in its architecture at that time, and at least 20 of them were affected by this SAP install. They were just going to blow away large swaths of the existing applications. So obviously you’re much more concerned with the applications that are going to remain. Those 30 out of 50 people who may be affected but will still live after the implementation versus the 20 you already knew would die. You’re more concerned with what they do than how they’re organized. So you go into your architecture repository and identify the application architecture building blocks, if they exist, and you use that to build your architecture. Obviously, you don’t reinvent the wheel. Go find those pieces that you can put together. Finally, step one was a lot about modeling, and so you’re going to use those models in step two to develop your baseline architecture.

So that’s the general architecture for applications. These are one of the easier application architecture domains. Because once you’ve defined a catalogue and a list of existing applications, you can then create the matrices and tie those applications to their business functions. It’s just a matter of talking to the right people to figure out how those applications work, whether there’s a model running underneath, and how they connect with the data. As a result, this is more of a fact-finding mission than a design mission for the future of business processes. This is like an application, and these things have documentation if they’re off the shelf. So hopefully this is one of the easier domains to document. So we’re at the baseline here. We’re going to get into the video next, “Step 3,” which is talking about target. So stay tuned for that.

3. Phase C, Application Architecture, Step 3

Okay, we’re into step three of the application architecture design. Step three says to develop the target application architecture description. And so we all know by this point that the target description is to be developed to the level that the enterprise needs. If you’ve got certain standards within your company that say you need to do the work, then obviously you need to follow those. Keep in mind, of course, that if you are going out and researching and finding applications that require a lot of decision-making, then you’re obviously going to want to do a lot more documentation around those that define those requirements. You’re going to start to decide if performance, cost, throughput, number of servers, or whatever those features are that the software needs, You can start to pick and choose and make those decisions. At this stage, the purpose of the target architecture supports your target vision, your target business architecture, and your target data architecture.

So obviously, if you’ve got this vision of a distributed system where each office can operate independently, there’s no tie-in to the central office except in a batch process and yada, yada, yada. Well, then, this is where you talk about application requirements. The application needs to be able to perform locally. The application needs to understand the differences between currencies. The application needs to understand, calculate, tax, and be multilingual. and all those requirements come out. Go into the architecture repository, pull out the building blocks just like you do in the baseline, and you can start to piece those pieces of things together, and hopefully a lot of it already exists. And again, if you’ve developed models in step one, you can use those models to develop your new target architecture. So now things are starting to come together. You’ve defined the business architecture. Obviously, in phase B, the data and application are sort of done side by side. You do one and then the other, but then they influence each other. So, if you want to choose application requirements that have an impact on data, you need larger databases, these data-sending processes, a data warehouse, business intelligence, and so on. This is why they are put in the same phase. They’re both in phase because they influence each other. So that’s the target. That is it for step three. We’ll talk about step four in the next video.

4. Phase C, Application Architecture, Step 4

Okay, we’re onto step four, which is performing the gap analysis. We have our baseline architecture in hand, and we have our target application architecture in hand. And now it’s essentially ensuring that they’re valid, that all of the various views of the application architecture are considered assistant. So you don’t have boxes missing from the it view that are present in the business view, or things that are connected to each other here that are still connected, or firewalls, or any of the other things that are going on. Finally, validate these architectures against your principles to ensure consistency.

So, if you’ve defined an architecture principle and an application principle, go through that list and ensure that what you’re proposing is consistent with what you’ve defined. So, again, the business requirements, the stakeholder concerns, when we’re in the business architecture phase and we’ve created a target business architecture, does the application architecture support the business architecture and obviously identify gaps? So this is where you’re going to find, let’s say in the case of installing SAP and blowing away 20 applications, the gap, right? So, these 20 applications must be removed, and this one application must be installed in all configurations and changes. These things are like dominoes, and all the applications that connect to them need to be changed or adapters need to be created. So this is a side by side comparison. What are the implications of moving to the target architecture? So once you’ve identified those gaps, you’re ready to move on to the next step. That’s step five, and that’s when we start building the roadmap. So I’ll see you there.

5. Phase C, Application Architecture, Step 5

Okay. Step five of the application architecture domain is to identify the candidate roadmap. So we just finished talking about the gaps. So now we’re extracting these differences from the gap analysis, and those differences end up becoming features that get added to the architecture over time. And if you recall the baseline and target, we’ve not yet at this stage defined whether we’re going to try to do it all at once, whether we’re going to step into it, or whether maybe it’s impossible to try to do it all at once. We’re not even there yet. We’re just extracting these differences. We’re going to list them out, and they’ll be added to the roadmap.

Okay? And so the roadmap, when we consolidate it, is going to be used to prioritise these activities. We’re going to group the word packages. Again, this is not the face for that, but we’re listing out the roadmap. So once the roadmaps are complete, that’s where the opportunities and solutions phase comes in. So that’s it for step five. Like we said, once you make these decisions and start going and installing new applications, you have to start considering all of the repercussions, all of the dominoes that are going to fall, and the things that need to be changed in other applications. Maybe you weren’t planning to, but then you realised that there’s no way that the file format is going to be the same. And so you need to make a change, at least to the data importer for this thing. The next step for the net is to define the consequences. So we’ll see in that video.

6. Phase C, Application Architecture, Step 6

So step six of the application architecture is resolving any impacts. It’s the same process that we went through for data changes and for business changes. It’s trying to understand the implications of these decisions. If you’re shutting down certain applications, upgrading them, or moving to a new version that doesn’t support these features, what does that mean? Does it impact other architectures? And so if you’re working in an environment that has a partitioned architecture, you’re working in a large organization, and your scope is only limited to a certain department, maybe what you’re doing impacts others. Okay? You also need to do this; it’s part of getting your head out of the sand. Look around and see what other changes have happened.

So being a bit proactive and not expecting people to come to you with every little change If you package up this work if it needs to be shared, maybe if you go ahead and instal a large work package, other departments will benefit, right? And finally, are there other projects that are already underway? Maybe they’re in the midst of development, or there are roadmaps out there that have project plans. And you need to understand that from the work side, that has not yet happened. That is the resolving effect. So we’re nearing the end of this application architecture. We’ve got the big meeting coming up next in step seven. We will conduct a review with stakeholders. So that will be a big milestone there.

7. Phase C, Application Architecture, Step 7

All right, we are into step seven of the application architecture, which is the formal stakeholder review. This is obviously an important milestone where you get to present your work to a large group of people and get their formal sign-off in order to proceed. But before you do that, you want to make sure that the architecture that you are about to present conforms to the original purpose of the project, especially the statement of architectural work.

And so, if there are specific business drivers, specific business goals, and you’ve been told that you’re expecting to save X amount of dollars, or increase revenue by X percent, or all of those things that have been put into the project as purposes, how does what you’ve got so far conform to that? Okay, if it’s not conforming, if, let’s say, you’re supposed to save money and you get to this point and you’re like, “Wow, this isn’t going to save any money,” I mean, full stop, right? You have to stop at this point, and maybe this requires a meeting, but you’ve got to make sure that you understand how it’s conforming at this stage before you get in the room.

Do the business and data architectures need to change due to the things that you’ve come up with within the application architecture? Now the data architectures are easier to change because, obviously, once you’re going out and making certain decisions, you’re going to purchase this enterprise system, which is going to need X and Y. Obviously, you’re going to need to define data structures and interfaces and how data gets pushed around. At this point, it’s much easier to say, “Well, you know what, this business process that we’ve defined is probably not possible, it’s probably not wise, and there are too many risks.” So I’ll give you an example. Let’s say you’ve decided during the business process that you want to be able to respond to mortgage applications instantly.

They’re literally standing at the counter; they’ve submitted their paperwork; the teller enters it and presses the button; and within seconds, they’ve been turned down or accepted. But you get into the application layer, and you start talking about the delays. Once you go out to get their FICOscore, you’ve got to go do certain due diligence on external systems outside your control. These are now dependent on communication layers. So you start to realise that maybe this business process, at a minimum, needs several hours. And so there’s just no way, at a technical level, that you can logistically come up with an answer within seconds. So that’s just an example. But sometimes, when you do the application layer, you do realize, “Oh, well, the business is just going to have to accept that we can’t reasonably, with the money that we probably know we have, deliver them the real-time answers or the types of business processes that they wish.” And that might just be as simple as going back and tweaking that and saying, “You know what? This is going to be a one-day process on an instant process.” So the application and data architectures both have impacts on the technology architecture. And so, like I said, if you’re going to identify, you need X number of servers, and they need to be local, and each office is going to need to have its own web farm and DA DA DA.

Well, that’s the constraint. You’re going to go into the technology-architecture phase, talk to the technology architect, and say, “These applications need to run for these businesses, for these local offices.” And at this point is when you can book that meeting and have that big review, go through everything with the stakeholders, keep in mind their viewpoints, and present to them the documents that they would understand. Obviously, this is the application architecture we’re talking about. So we’ve got to have a couple of conversations addressing the business needs and the technology needs, sort of like one conference conversation. But that’s the milestone there: presenting to stakeholders and getting their feedback. Next, we’re almost finished. Step eight is the finalisation of the architecture based on this feedback. So we’ll talk about that in a second.

8. Phase C, Application Architecture, Step 8

Okay, step eight of the application architecture is to finalise the architecture. So you’ve had the meeting, and you’ve gotten some feedback. Right. You might have to rerun the numbers. You may have to cut costs. You may have to do some things based on that feedback. Or maybe you just got the green light. Yeah, we love it. Go ahead. So now you go back to the architecture repository and see if these building blocks that you’re putting in place have industries or standards that are on the left side of the enterprise continuum. Right? So there might be some generic things that can be used instead of developing something custom for your organization.

Obviously, all documentation and the architecture definition and requirements need to be finalised and cross-checked against the business requirements one more time. I know we’ve done that in steps seven and six in terms of making sure that the architecture is conforming, but you might as well make sure that every single business requirement listed in the business requirement document is covered in the application requirements as well. And so this is when you’ve finalised everything. You’ve got all your diagrams and all your matrices, and everything is sort of finished, and you’re almost ready to move on to the next phase. But first, you’ve got step nine of this phase coming up, and we’ll see that in a second.

9. Phase C, Application Architecture, Step 9

Alright, step nine of the application architecture is to create the Architecture Definition Document. So we’ve been working all through this based on baseline and target architectures, based on defining requirements. And so now we are basically creating the Architecture Definition Document document.That is the formal output of this phase. If you’re going to make certain decisions about building blocks, doing this internally and doing it overseas, and how things are being designed, this needs to be documented. And this is obviously part of the larger scheme of the Architecture Definition Document. Make sure that the application architecture section is complete.

So that’s pretty much it for phase C. Part two of phase C, the application architecture section We are making our way through BDAT here. We’ve gone through the business data and application layers. In some ways, the technology layer is going to be a result of all of these conversations that you’ve had and all of these documents and diagrams you’ve created. The technology layer almost comes together now. Obviously, you need to think about security, firewalls, networks, lag times, speeds, throughputs, and things like that at that layer that you haven’t had to think about yet. But a lot of those requirements are going to be fed to you, and you just have to meet them. So coming next, we’re going to talk about that. It is the technology architecture in its early stages.