1. Introduction to the ADM
You have set the table. The plates and the glasses are out. The knives and the forks are in their proper places. You are seated in your seat and you’ve got your napkin in your lap. It’s time to serve the main course. And of course, that main course is the adm, the architecture development method. The adm is the process by which an architecture is defined. The adm has ten phases. You’ll have to know each of them. Eight of them are arranged in a cycle called the adm cycle. We’re going to talk about each of those phases in the videos that follow. Inside of each phase of the adm, there is an objective. There are inputs, steps and outputs.
Now, these inputs generally come from your existing assets inside the architecture repository, although sometimes you do need to create new assets. During this process, you’re going to be working with, collaborating with the business and the collection of information from key stakeholders. I’m going to warn you that the first time you go through the adm, it will probably be pretty hard. You will have hardly any existing documents that you can pull from. You will be creating so much of this. For the first time, you’re going to be working with different parts of the business, establishing those contacts. The process will be new, not only to you, but to everyone else as well.
And to be honest, you might find some people that don’t really want to work with you. But eventually you will get through it. And if it doesn’t kill you, then the next time it will be easier. As you develop your architecture capability, it gets easier still. At some point in the future, your team will have everything it needs at its fingertips. The business will be tuned into the process and you’ll forget all about those early days. That the first time you went through the adm cycle. So the videos that follow, we’re going to go through the adm in more detail. We’re going to be talking about the adm next.
2. ADM Cycle
Particularly the adm cycle. We learned in the last video that there are ten total phases of the Adm and eight of them are arranged in a cycle. They are labeled from A through H. Now, the Adm cycle is actually designed to start over once you reach the end of the last cycle. But don’t get this confused. With adm being continuously running, there are significant, significant pauses at the end of each cycle for you to be looking for changes and for to be looking out into the horizon to see what possible opportunities there are to modify your architecture. So at the end of the last cycle, you basically pause for quite a time until you’re ready to start a new cycle.
In the center of the Adm cycle is the Requirements Management phase. Requirements Management Phase is also pretty much constantly running. What this does is it allows you to handle change while your adm process is underway. So you could be in the middle of your adm process and then suddenly a new requirement comes in that wasn’t brought to your attention before, or there was something significantly missed in the last cycle. The philosopher Mike tyson has said everyone has a plan until they get punched in the mouth. What that pretty much means is you could in advance try your best to plan for every contingency.
But then in the middle of your execution, you may have to pause what you’re doing, go back and revise a past cycle. Now, the other significant thing to know about the Adm cycle is that there are iterations that can be done on it. So you would think that you’re just going to go from A through H in a serial manner, but you may find yourself getting to the end of phase F and then wanting to cycle back to phase B to do a second pass at your requirements planning. So for each of these phases, you do have the option of going back and forth between two phases. And this is called iteration. Finally, TOGAF and the adm is designed to be tailored.
You are not expected to take the toga specification and implement it exactly as it’s written and try to follow it to the letter. One of the first tasks of the preliminary phase is to tailor TOGAF to your particular business needs. And so the Adm, if you don’t want to do a particular cycle or if it’s too onerous, or you’ve got other processes and other standards within your company and you need to adapt the adm, it can definitely be adapted for your needs. So you got to find out what works for you. But do remember that this exam, the Part One exam, is only on the standard as it’s written. So even though you can adopt.
3. Preliminary Phase
Phases. The very first phase at the very top of the adm is called the Preliminary Phase and it sits on top of the cycle, the Preliminary Phase. The purpose of it is to define your desired level of architecture capability and also to establish that desired level of architecture capability. And this includes defining some architecture principles. The Preliminary phase is also described in the standard as where, what, why, who and how we do architecture. So this is the setup, this is you getting into architecture and you need to establish some things as a company. How do you do this, who approves this, who’s involved? All those questions get answered.
Now, according to the standard we said before, there is an objective, there are inputs, steps and outputs. You do not need to memorize the inputs and the steps. For instance, for each of the phases, I’m going to mention them here for completeness and because the course might seem to be missing some things if I don’t. But do keep in mind as we go through this video and the following videos, that you do not need to memorize all of these things. But I do expect that this will start to make sense to you as we go through it. So the inputs to the Preliminary phase are pretty much all of the information that you have on hand.
So all of the togaf standards the togaf library as the other documents are called. Any other architecture frameworks that you are working with if it’s Prince Two or cobit or pmp, all those other frameworks that you may be using within your company. All of the Board of Directors strategies, the business plans, the It strategy, any kind of strategies, documents, business principles, goals why are you in business and what is your future as a business? All of that stuff gets inputs. And so you want to gather some of these documents, other frameworks, governance. And so if there’s architecture governance underway in your company, you want those.
We’re going to talk about getting your architecture capability up and running in this phase, but if you already have some information about that, then you’re going to want to bring that with you. Any other constraints, partnership agreements? Do you have major contracts with vendors that are going to impact your ability to make certain choices, any other documents, et cetera. So these are all sort of inputs. Now, the steps to this, again, this is the Preliminary phase. These are the things that you need to do in order to get yourself set up to start the architecture work. And once you set these up, you don’t necessarily have to come back to this again unless you want to make a change.
So we talked earlier in this course about defining what the enterprise is, particularly around scoping, what that means for your work, what projects, business units, what people are going to be covered by what you’re going to be doing here. We’re going to need to set up governance. So that means in terms of architecture governance, togef has a very particular definition of that, being able to handle change, get approvals, documentation, transparency, logging of all that stuff. The architecture team, we said the principles, the, the purpose of the preliminary phase was defining what you want for architecture and establishing that.
And so if you’ve got a four person organization, these are the roles, this is the background, this is the training, this is what you need. So we’re going to have to establish the people part of the architecture project, architecture principles. This is very important to the purpose of enterprise architecture. There’s a whole document within the extended togaf library talking about principles. But essentially, once you set up what you do and do not do within your organization, architecturally it makes a lot of your decisions easier. So let’s say you have as an architecture principle that you really much prefer to use open source projects.
And that’s going to be the basis for a lot of your decision making, is to lean towards open source, publicly supported code for as much as possible. Well, that’ll again, determine how you do certain projects. And so you start off defining the architecture principles. There’s a book within the togaf library to help you go through that. We mentioned how togaf is designed to be tailored. And so you’re going to want to do that. You’re going to want to say as we go through the steps and the phases, from preliminary phase all the way through to phase H, what do we add, what do we remove? Who needs to be part of this phase that the document doesn’t currently have them playing much of a role? You’re going to tailor toga as part of this.
And architecture tools we mentioned also before, the architecture repository is a very important source for all your documentation. It’s where everyone on your team and other teams are going to go to to find the latest requirements, the latest diagrams, the latest lists and catalogs of things. So do you need to purchase software to run your enterprise library or are you going to have that on a network drive or some type of knowledge management tool? This is the preliminary phase now. So at the end of the preliminary phase, all of these steps as you go through them, ends up creating outputs.
And so these are the outputs maybe of all these slides in terms of inputs and steps, outputs is where I would say you want to sort of have this knowledge for the exam. You want to know that at the end of the preliminary phase, you’re going to have a tailored toga, you’re going to have the request for architecture work defined, basically. The request for architecture work is basically the project. The architecture project. So it has a budget, it has people that work on it, it has a scope, it has plans, expectations, stakeholders, who signs off on this request for architecture work is basically the project approval for doing architecture work.
So all of these items become outputs from the preliminary phase. I do recommend that you read through the outputs just so that you know and understand and accept that part of the preliminary phase is this. We talked about architecture principles, and so one of the artifacts that is not necessarily a full on document is going to be a catalog of those principles. So this is the preliminary phase. This is again very important for establishing your architecture capability. You can come back to this in a future cycle if you want to improve your architecture capability, but generally you would not come back to the preliminary phase except to make changes to the way you do architectures.
4. Phase A – Architecture Vision
Of you who are taking the part one exam, you’ll often get questions about under which phase such and such activity occurs, and they will give you the answer as phase A, phase B, phase C. And so you should need to know the letters as well as the textual label of the phase. So this is phase A and Architecture vision phase. You see, it’s the first phase at the top of the adm cycle. The purpose of the phase A is to develop a high level aspirational vision of the business value to be delivered. Those are some wonderful words there, as well as to obtain approval of a statement of architecture work. Now, we mentioned before that the inputs to the phase and the steps are not super important in terms of your memorization.
There’s going to be a lot of repetition from phase A to phase H. You’re going to get a lot of repetition for these inputs. But I’ll highlight to you some of those highlights as we go through. So all of your outputs from your preliminary phase, which is request for architecture work, your business principles, your tailored architecture framework, the initial populated architecture repository, those are all important inputs into phase A. The steps of phase A are to establish the architecture project, and this is how you handle projects within your company. Architecture project is treated like a project, and so you could have a kickoff meeting, you could have a project manager status meeting, et cetera.
So basically the project has been approved, it has a budget, has a scope, and you are establishing the project. You identify the stakeholders, their concerns and the business requirements. And so that’s a big part, is to know these are the people that you need to make happy. These are the stakeholders, these are the business owners, the unit leaders, the vice presidents, the heads of certain parts of the company. And so you identify who they are and you document their concerns. And this could involve talking with them, hopefully. And then you put that all together and it becomes sort of a list of business requirements.
This is what these business leaders need to see change within their respective lines of business. You’re going to basically reconfirm that the business goals that you already understand to be true are still indeed true. A new addition to togaf 9. 2, an update if you will, is that step number four now says evaluate capabilities. In togaf 9. 1, it actually said evaluate business capabilities, but this has been slightly revised. Now, business capabilities are sort of the strengths and weaknesses of your business. And so if your business is really excellent at executing in the manufacturing area, you’ve got a really top notch organization running the manufacturing team and they never make mistakes.
And your quality is leading the industry. That could be like one of your top business capabilities, whereas some other part of your business may be something that needs improvement and so one of these steps is to go through a business scenarios process and basically evaluate the capabilities of your business. readiness for transformation is a really interesting concept. We all work within companies that have various willingness to change. And so you may work in a company where there’s a real big value on adaptability. And it’s been something that from the top of the organization drives home the willingness to try new things.
And that’s one type of company that you could work for, or you could work for a company that’s very risk, adverse, really hates change. There’s maybe certain parts of the business that are harder to change than others. And so you go into the project knowing, okay, we can’t just get from A to B in one big step. Working with these people, we need to show them this is what we’re going to do, this is how we mitigate it. We put small improvements into place and then they’ll go with us towards the goal. So you have to basically understand what type of organization you’re working for and how easy getting certain changes approved and how easy it is the business to actually make changes defining the scope of this project.
So we said architecture is a project. And so understanding that in this particular run through the adm, you’re only going to be focused on those four parts of the business. You’re happy with the way other three parts of the business are going, and so you’re not going to really address those other three parts. And so you define that in advance to say this is really focused on this particular set of business problems, there’s more steps making sure your architecture principles haven’t changed and hopefully they haven’t developed the Architecture vision. This is really where the meat and potatoes of this particular phase is. The architecture vision is basically a really highlevel idea that you have.
Once you’ve talked to the stakeholders, defined their concerns, and define the business requirements, you can start to think about potential solutions and you can start to put together a really high level story that you can talk to and you can get the stakeholders to buy into. So the Architecture Vision, you haven’t really delved into the details yet, you haven’t got hundreds of pages of documentation that you can distribute and get sign off on. But the vision is basically the executive overview, the top level overview of this is how we’re going to move the company in the next eight to twelve months to get us closer to these goals. This is why step number nine has to do with architecture value and the key performance indicators.
And so if you can come up with a vision, you can say if in the next twelve months we’re able to move the company to this target architecture, then we’re going to be able to unlock an additional $1 million per year in revenue. We’re going to reduce expenses by $200,000 per year for a net of 1. 2 million. And we can put together ways of measuring key performance indicators are basically ways of measuring that value. And so if you can come up with a vision and you can come up with the numbers to support what you’re saying, then that becomes your business case, that you go to everybody with transformation risks and mitigation activities.
So you do not want to obviously go to a new line of business and then risk your existing lines of business, for instance. So you need to identify in advance what potentially could happen if you do try to do this within the next twelve months. And what can you do to mitigate that, right? So that that becomes part of the documentation. And so those are basically objections that people can have, why are we not addressing this, why are we not doing this, why are we doing it this way, et cetera. Finally, the Statement of Architecture Work is that document that when you do meet with everybody, you present them your dream, you put the numbers out there, you say, I need your approval to continue on.
I want to get this business within the next twelve months to this point. This is the value we can unlock. Please sign your name on the dotted line and say that you’re okay to proceed to go ahead with this. And that’s a real big milestone. When you can finally get business leaders to say, we like your vision, we buy into your vision, go ahead and start to put that plan together. And so the Statement of Architecture Work is sort of the last step, and getting signatures on that paper, you deserve sort of this is a big milestone within the project. So obviously the outputs again, we said this is sort of when you go to the exam, the Part One exam, you’re going to be asked a lot about when certain steps are done.
So the approved Statement of Architecture Work, which is the last step we were just talking about, that’s one of the major outputs of this Phase A. If you do need to readdress your business principles, your business goals, that gets updated as part of this, hopefully you don’t need to touch that. Architecture principles again, hopefully you don’t need to change any of that. Your Business Capability Assessment, or as the hookup 9. 2 now calls a Capability Assessment, you go through and you do the business scenario steps. You’re going to come up with an assessment of your strengths and weaknesses, where you are, maybe where you want to be within as a business for each of these core capabilities, your tailored framework, I mean, you created that within the preliminary phase.
But if you do need to change that, then that becomes part of this. The architecture vision. We said this is one of the key principles. The purpose of Phase A is to create the vision and to get the Statement of architecture work. So the vision itself is an output. Then you start on the draft versions of the architecture documents. And so we haven’t yet talked about the four architecture domains bdat in any detail, but you start with version 0. 1 of what’s called baseline and target architectures. So within toga, version 0. 1 and version 1. 0 have particular meanings. 0. 1 means that it’s sort of like a high level draft. It hasn’t been approved yet, it’s just a starter document.
Version 1. 0 of a document means it’s final, it’s approved. That is the document that you’re working from, unless you need to make change requests to that. The baseline architecture is your current architecture. It’s the business processes data application of technology that your company currently has implemented. That’s your baseline. And the target architecture is where you’d like to be. So if you set your goals for twelve months in the future or whatever it happens to be for you, then you have your baseline architecture and your target architecture. And so phase A creates the draft documents for all those communications plan.
Of course you need to understand who the stakeholders are and that involves who do you have to keep updated, who has to sign off on you continuing, and who just needs to be informed. So there might be parts of the business where you can just send them an email or send them a copy of the document to say, hey fyi, this is where we are with this, but they don’t have veto power over you continuing. So you need to have that plan as part of the total gas spec is to come up with a communications plan. And so your architecture repository starts getting created based on after phase eight. Now we talked about artifacts.
So you’ll see, that the business capability map, the business model diagram, value stream map, these are in red, these are new for toga nine two. So there are three new artifacts as part of phase A, as part of toga 9. 2. The ones that are not in black are existing ones. You should be able to read these. See business model, business capability, value chain solution, concept stakeholder. Put that in your mind that anything that’s business or value or concept related is part of phase A. Okay, these are not part. Now this might be confusing when we get into phase B, but these diagrams are part of phase A and this could obviously come up.
So to recap what we just went through, the purpose of phase A architecture vision phase is the high level vision, including any immersion technologies that might impact your industry. So if you are seeing things on the horizon that you know within six months this is going to be a big thing. This is when you include this within your vision, you say we don’t need to be first, but we need to know that this change, this radical change is going to come to our industry. And we need to be prepared for it. Then our architecture vision and our high level description of what is the end state of the architecture. Right. This is the dream that you can sell into.
