1. Introduction to ADM Guidelines and Tools
The adm and the adm cycle. Now we’re going to talk about what’s known as the Adm Guidelines and Techniques. So in the videos that follow in this section, we’re going to go through each of the tools and techniques that are part of the togas specification that are designed to help you to go through each of the phases. So we’ve talked about gap analysis and migration planning as part of the Adm phases in the last section, but let’s look at a little bit more detail in terms of what the toga specification says about each of these things.
2. ADM with Architecture Styles
Is how the togaf adm works with different architectural styles. Now this is a new section of togaf 9. 2 so it’s definitely worth reading this section of the toga specification if you’re familiar with togaf 9. 1 and want to see what the Open Group talks about different architectural styles. Now we are now laid into, you know, 2018 and onwards and different companies are doing different architectural styles. Styles are taking hold and they’re being successfully implemented in different companies. So the togaf adm actually should continue to work no matter what your architectural style is.
You just need to adapt your outputs, the documents and the artifacts to match the requirements of those styles. So it’s not the toga the steps that changes, it’s really your content metamodel. So it’s basically you change the content of your documents which is defined by your content metamodel. So you may have to develop different views or models and use different sets of tools to create these documents and diagrams and matrices and things like this because of this architectural style of your organization.
Now one popular style is called a service oriented architecture or soa. And togaf actually has an soa work group that is creating documents and designing service oriented requirements that are specific to that in relation with togaf. So if you’ve got no matter which architecture architectural style that you have, you might be able to find changes to the content metamodel that you can adopt. And if soa is your particular style, then you can certainly find more information about that.
3. Architecture Principles
Technique that we should talk about is the concept of architecture principles. Now, you’ll remember we talked about principles in the early phases of the adm, the vision phase and the preliminary phase. The principles are an enduring set of rules and guidelines that you follow when it comes to architecture. Now, the concept of principles is that once you’ve established them, you try to follow them and they don’t really change very often. Now you can change them, but you really want to set principles that are kind of like a lighthouse that guides you when you are creating your architecture. They’re defined during the preliminary phase, they’re reaffirmed during the vision phase and in subsequent phases to make sure that they’re still valid for your situation.
So a principle serves as a good rule, a statement by which you can use to make decisions. So instead of having no principles, which makes every decision something you really need to debate over for ages, if you’ve got a good set of principles, that should eliminate a number of the paths that you might take because they go against your principles. Let’s get into an example. An example here is of a data architecture principle. So this one principle has the name called data trustee. So good principles have a name and they also have this type of description.
So a data trustee is that each data element within your data architecture has a person or a group who is accountable for the data quality. So imagine as you’re creating your target architecture for data, you want to add a new piece of data to the mix. Let’s say you have a source of data that’s going to come into your system and that’s going to feed into a lot of things. Who is responsible for the quality of that data, ensuring that it remains? The better your data, the better your decisions, right? So this is one example of a principle and in general, your principles are going to have five elements to define them as good principles.
One of the criteria is that the principles must be understandable, right? So if you can explain it in a clear and unambiguous way, then it’s very hard to actually violate your principle because everyone understands what the principles are. robustness is the second thing. Essentially every principle should be definitive and precise. So there should be no vagueness in there. It should be basically it’s clear and it’s defined well. A complete principle is that these principles do cover all of the situations that you tend to encounter consistent principles. Basically you’re going to interpret them consistently.
There should be not contradicting principles, right? You don’t have one principle that says one thing and another principle that says something else. And therefore as you go through it, you can choose to obey one but not another, et cetera. So ideally, you want your principles to sort of all be consistent with each other and finally a stability, right? It’s of principles are enduring. So you’re not going to be changing principles on a week by week, month by month basis. So there should be a process by which you decide to stop following a principle or to modify.
4. Stakeholder Management
Includes a set of guidelines for what’s called stakeholder management. Now, a stakeholder, according to the definitions of the document, are an individual, a team, an organization, or some type of one of those that are having an interest in a system. Person who has absolutely no interest in the system would not be a stakeholder, but anyone who has any sort of interests in there could be considered a stakeholder. Now, as an enterprise architect, the skill of being able to get people to support you is very important. Okay? So you got to know who those powerful stakeholders are, and you need to be able to list who they are, understand what their concerns are and satisfy those concerns. So knowing who the important ones are makes things easier for approval. You shouldn’t fall into the trap. And it is a bit of a trap that one person is particularly noisy, one person is particularly eager to influence the design of the architecture, but it may not be their concerns that are really the drivers. So, one of the parts of stakeholder management is to develop a communications plan.
So once you understand who the stakeholders are and their importance, then you can sort of put together what level of detail each individual needs to have. Do they just need to be informed of decisions after they happen? Do they need to be in the room while decisions are taking place? If you can win the support of one key stakeholder, does that then line up their stakeholders that report to them, et cetera? Another part of stakeholder management is to identify where these different stakeholders have different concerns.
And their concerns might actually be a little bit in conflict and a little bit of opposite, right? Someone might want more control over a function or feature, and another stakeholder might be trying to get that opened into less control. And then you have to sort of navigate different conflicts between stakeholders. And so, if you have an understanding of who these people are, how important they are, what their concerns are, then you can start to navigate those rocks before it’s too late. Now, togaf contains a diagram like this. I think these are the terms.
So you’ve got powerful stakeholders and people who are not powerful, and then you’ve got stakeholders who really want to be involved and stakeholders who just need to be informed. And so there’s a low level for both, and you really don’t need to worry too much about them. And then there’s a couple of variations of people who have got high power but are low level of interest versus people who are high powered and high level of interest. And those are key players. So togaf has this definition of stakeholder management, and this is what you need to know for the.
5. Architecture Patterns
Do mention the concept of architecture patterns. Now, of course, the toka standard does not go into much detail about patterns. Patterns are one of these things that are emerging. So the concept of patterns defined by the famous Martin fowler is that an idea that has been useful in one practical context and will probably be useful in other. And so that is the concept of a pattern. Now, togaf has already we talked about building blocks, architecture building blocks and solution building blocks. And these are things, these are what you use when you’re defining your architecture.
You can grab your architecture building block and put it in place, but the concept of the pattern is the rules around when you use them, why you use them, how you use them, and the limitations around using them, for instance. So whereas the building block is the thing itself, the architecture pattern are sort of the best practices when it comes to using them. Now, like I said, this isn’t much in the specification, this isn’t much on the test. As far as I can tell, it is on the test requirements, but I don’t expect that you’ll see much about it.
So once you’ve developed a number of building blocks and your architectural capability is starting to grow, then you may want to establish rules and patterns for them. So you may not want to have your support call center building block just sitting there by itself. You may want to establish, these are the minimum requirements that we must have in order to get the call center involved. And that becomes the pattern for when you use that building block, for example.
6. Business Scenarios
The togaf library contains a business scenarios specification separately from the standard. Now also in togaf 9. 2, the concept of business scenarios has sort of raised in prominence and you’ll see this mentioned in the early, you know, phase, a vision phase. So what does that mean? What is a business scenario? There are four components of a business scenario. Risk component is either the business process or the business application or some set of applications. That is something that is operating on the business.
Then there’s the technology environment and the business environment. So in what scenario is this application or these people or this process operating? Then there are the people themselves and the software applications. These are called actors. It’s very similar to a use case if you’re familiar with use cases. And finally, what is the desired outcome? So you’ve established the environment, the people, the software systems, the processes that are going on and what is it that you want to happen? Right? So it might be a customer service type function.
Ultimately you want the customer to get an answer to their question, to get a resolution to their problem in a timely fashion, et cetera. So these you establish essentially the parts of the business that are trying to drive towards a desired business outcome. Now, when you create this business scenario, anyone should be able to understand the problem and your solution to that problem or your improvement to that by reading the business scenario. So like I said, we’re in the architecture vision phase. For instance.
You’re sitting there, you’re working towards what is the business doing and what is it that the business goal is? And so ultimately it becomes a business case. Like I said, anyone who reads through this should come to a very similar conclusion as you. And there may be some back and forth over what you can do to change the process or improve the application or to improve the capability of the business in order to improve the outcome. But you put your thoughts down in a pattern like that.
7. Gap Analysis
Is called gap analysis. Now, you’ll remember that we talked about gap analysis early on in the adm cycle. This is in the architectural domain phases which are B, C and D, as well as migration planning. Now, gap analysis is looking at the baseline architecture. If you recall, the baseline architecture is the architecture as it exists today, and then comparing that to the target architecture, which is your architecture that will exist when you reach your full implementation. And so you go through line by line, row by row within those two documents and you list out all of the differences.
And so anything that’s been added or changed or even intentionally removed is a gap that’s going to go into your gap analysis and you may even discover that something was accidentally removed or is missing from the target architecture that needs to be there. And so you’re going to have an opportunity to go back and correct your target architecture if it’s missing a key piece that needs to be there. And these things are totally normal and totally natural that things are not perfect the first time that you do this document.
And so you’re going to basically list all of these changes and you’re going to be able to basically explain why these things are needing to change, right? So basically this was added because of this new requirement. This was changed because it should improve this, this was removed because it’s unnecessary, et cetera. So there’s the whole process within the toga spec to go through this. Now, as part of the exam, you’re not going to have to know what the steps are for gap analysis. There are examples within the document, the toga standard, but you don’t need to know what they are, but you just need to know what gap analysis is and why it’s important.
8. Migration Planning
Guidelines and techniques. And the next one we’re going to talk about is called migration planning. Now you’ll remember as part of phase E and phase F, we are creating migration plans. But toga actually does contain more details in terms of what it means to do migration planning. If you look at the togaf 9. 2 specification, chapter 24, you will see that there’s a few paragraphs talking about migration planning. Now admittedly, it’s not a huge part of the standard and so you cannot really expect that this is going to be a huge part of the test.
But it is listed on the requirements and I am going through the requirements one by one here. There are five tables and matrices that are part of migration planning within the togaf standard. So these are the techniques. Again, you don’t need to know know them, but you need to know of them. So I won’t read through them. But you can see on screen that there are these five techniques.
9. Interoperability
This is another chapter within the avm Guidelines and Techniques section of the toga 9. 2 standard. The standard defines interoperability as the ability to share information and services. So we know as architects that when we’re designing documents, we’re designing requirements that the things that we’re doing and creating need to work well with others, stuff that is outside our scope. So we have given a scope of the enterprise that we are operating on, but that does not mean that we can build a firewall around our scope and not have to work with anyone else. There’s a couple of concepts, three concepts within operability.
One is called business operability. And that’s how business teams and processes work together with other business teams and processes outside of our scope. The information operability, which has to do with how data is shared. And this is big into data architecture. And finally, technical interoperability, which is how technical services connect to one another. So how are data going to be shared between two business partners in a secure manner? Right? So you need to be able to have that pathway between one service and another that needs to talk to each other. For instance.
So as we went through the architecture definition from phase A all the way into phase D and E, there are elements of interoperability in each of those phases. Now, I’m not going to list them and go through all of them, but if you think about everything from phase A, which is the vision phase, and the business scenarios process all the way through BC and D, which are we’re defining the business data technology and application architectures, then we all do have to keep in mind this concept of the outside world. So again, we’re not developing stuff in a silo here. Everything that we do in some respects interacts with other.
10. Business Readiness Transformation Assessment BRTA
Phase of the adm. One of the concepts that we talked about was how ready the business is for change or how the business handles change. So as an enterprise architect, one of your goal, of course, is not only to get people to agree to your changes, but then for those changes to get implemented and to be successful, for you to unlock that business value that your changes are designed to create. So the business transformation readiness assessment, or btra, is a tool or a system that is part of the toga specification that will help you to determine the readiness factors of your organization.
The btra is defined as a tool that is used for evaluating and quantifying an organization’s readiness to undergo change. Now, really, there is no point in working on your architecture and creating all these great documents if either nobody will read them or if they do implement them, that there’s going to be something that happens that makes it a big failure, or that you’re not unlocking any of the value. Right? So we’re coming at this from a way of everybody wants to succeed here. So what is the unique characteristics of your organization that will give your requirements that you’re creating a chance to succeed? Now, within the toga 9. 2 standard, there are some recommended activities for BRT a business readiness transformation assessment.
There are five of them. So number one is to determine the readiness factors. Number two then, is to present those readiness factors using what are called maturity models. Then you assess the readiness factors, and then you assess risks for each of those readiness factors, and you identify the ways that mitigations improvement actions. And finally, you’re going to get those. Once you’ve assessed the things that you need to do to get around the risks of your business readiness for change, you implement that into the phase E and F in terms of your migration plan.
So it may be that your enterprise is very in. Certain aspects of your enterprise may be very resistant to change. And so you have to then structure your implementation plan to address those and to be able to say, we’re going to do this in such a way that it’s going to be virtually riskfree to the Enterprise or we’re going to do this in a pilot project first, or we’re going to do the least risky thing first, or we’re going to do the highest value thing first, or whatever order that you have to order things in whatever mitigations you have to put in place, basically to get around your organization’s resistance for change.
Now, the toga standard lists a number of what are called readiness factors. And so you saw in the last list that readiness factors were a big factor. What are readiness factors? Those are things like vision. Vision is your ability to define and communicate what it is that you want to achieve. Right, so we have this phase, a vision phase, and if you can come up with a really strong vision and get everyone to bind on the vision, that’s going to mitigate your readiness for change. The desire, willingness, resolve of the organization, of course, the need for the change.
So if there’s not much of a need or there’s some varying level of need across the organization, that’s going to be a factor. And on it goes. Business case funding, whether you have a really strong champion or sponsor. So if you have a really senior person who’s well liked across the organization, they’re able to take your case and becomes a really strong champion for change, or if that person is resistant to you or doesn’t want to change, then that’s a challenge, right? So all of these items that are listed plus more could be factors that are impacting your readiness to change.
Let’s look at an example. So let’s say the need for change is one of the readiness factors. And so you say, how strong is the business need for these changes to enterprise architecture that you’re proposing? Does every part of this business recognize this as being a need? And do you have the strong backing of leadership for these needs? Do they recognize them as needs as well, et cetera? So you’re going to start to ask yourself these questions and again mitigate them, address them, refactor your work packages, refactor your business case in order to strengthen.
11. Risk Management
The adm is called risk management. Now, the name of risk management is pretty self explanatory. It’s a technique used to mitigate risk when you’re implementing an architecture project. Now business is about risk, and it’s about mitigating those risks in order to reap those rewards of taking the risks. But it doesn’t mean we ignore the risk. We still need to understand what are the risks. So when you assign, when you define your target architecture, we need to say, well, we’re about to run from first base to second base. If I can use a baseball analogy.
What are the risks of giving up first base to get to second? And are those acceptable level of risks, or is there anything we can do to mitigate that? So again, we have to identify these risks, and we have to be able to measure them, track them, and that way when we mitigate them, we can see that we are actually effectively mitigating them. Inside the toga standard, there’s two definitions. One is called the initial level of risk, and the other is the residual level of risk. The initial level of risk, as the name implies, is basically the risk that exists if you do nothing to mitigate it.
Okay? So if you are going to go from A to B and you don’t do anything else to mitigate that risk, you’re going to have to define what those risks are. Residual level of risk is what’s left over once you’ve mitigated. So you can’t eliminate risk entirely. Those activities with zero risk usually have very low reward, but you can mitigate the risks. And so you need to understand this stuff still could happen. We have these measures in place. We have these pilot projects. We have these surveys. We have these other things. But even if you mitigate them, maybe we can’t mitigate all of it.
So I’ll give you an example of risks.There’s one type of risk that’s called client acceptance risk. So let’s say you have, as a goal of your adm process, is to increase the level of self sufficiency of your customers. You’re going to create a self service portal. And instead of having everyone call you on the phone or to come to you in person in the store, you’re going to try to push everyone to go to your website and to do stuff themselves. And that’s part of the purpose of the project, is to lower your costs, increase self sufficiency of your customers. One of the risks of a project like that is the client acceptance risk.
So are your clients going to enjoy serving themselves? Are they going to feel that that’s something that they don’t want to do, for example? So do you define this risk? How do you measure it? So how do you know that the clients are accepting or not accepting to this kind of change? So you may end up having lots of surveys. You may have bring in customers, show them the new process, show them the new portal and ask their opinion. And try to get a broad cross section of your clients to give you their opinion before you roll this stuff out. As an example, how do you measure it and then how do you mitigate it? So let’s say the clients in these surveys don’t like the new portal and are going to miss having someone to talk to, et cetera.
Is there something an intermediate step that you can do to assure people that this is a better level of service for them or maintain that the existing level of service isn’t going away, et cetera. And again, there was always a residual level of risks and so understanding the criticality of it. So if you do get clients that do not accept the new portal as much as you dream, what is the possible cost to the business? All right? Are you increasing your costs to run these things but not reducing your expenses because customers are not using it, et cetera, et cetera. So understand.
12. Capability Planning
Techniques says capability based planning. So the toga Standard defines capability based planning as a business planning technique that focuses on business outcomes. It also says that capability based planning should be done by the business. It should be business driven and ideally business led. But what does that really mean? Well, most organizations that we work for, whether they are public sector, private sector, no matter what industry they’re in, typically they’re organized functionally. You have your HR department, your finance department, your development department, the It department, your call center department, your design department, all over the company.
Things are pretty much functional, vertical essentially. But your company is actually delivering services horizontal. So it’s going to be from your design department through your development department to your technology department, out to the final customer. So all departments must be rowing the boat in the same direction and on a particular cadence in order to give the optimal service to the customer. So the functions themselves have to work together to deliver any particular capability. So let’s say your company wants to develop this reputation, or has this reputation of having flawless, beautiful, gorgeous, just things that just work products.
I’m not going to name the company that I have in mind, but you might know of this phone producer and computer producer that is known for sort of beautiful, functional products, but who is responsible for creating those products that are nearly flawless. It is multiple business functions that have to work together in order to achieve that. And so you’ve got your product designers who are working with software developers, who are working with your manufacturer partners, as well as into the retail and sales channel in order to get that experience. What the customer feels is an experience when they open the box and they touch feel and start using one of these products for the first time.
It’s the entire company, pretty much that has to have their ducks in a row to deliver this experience. And it’s not just because your manufacturing department does an excellent job. If your product design department doesn’t do a good job and your software development department doesn’t do a good job and your retail department doesn’t do a good job, then you’re going to fail on that capability. So capabilities cross functional teams. So capability based planning focuses on business outcomes. So like I said, it’s not good enough just to have the best sales team. Your capability is actually.
