1. Phase E, Opportunities and Solutions, Step 1
We are into Phase E opportunities and solutions. We’re going to go through the steps one by one to remind you where phase E? It’s about halfway through the architecture development cycle. The purpose of phase E is to get you to the initial complete version of the architecture roadmap based on the gap analysis of those individual architecture domains. And then today determine if you need to do an incremental approach. Or you can get to the target architecture all in one go, formulate the version one 0. 1 of the implementation and migration strategy and identify and group work of packages. So step one of phase E is to determine and confirm key corporate change attributes.
So the purpose of this step is to determine how your enterprise architecture can best be implemented and take advantage of your organization’s business culture. This is kind of coded, but it means knowing what you know about your company, what can you do to make sure that it’s implemented the easiest way possible? Okay, so your company might be extremely slow to act. The decisions take a long time. And so maybe you want to get all those decisions in there at once and try to do it all at once approach, or perhaps getting stuff in incrementally doesn’t raise too many eyebrows, can get approved easily. And over time, you do phase A, phase B, phase C of your own deployments and finally get the whole thing in.
So there’s a thing in togaf called a business readiness for Transformation assessment. And it’s a whole process you can go through to assess how your company is ready for change. And so you do that as part of, I believe it’s part of phase A, to determine how your company is ready for change. Now, this is where you’re taking that input and analyzing it and saying, okay, this is what we want to do, how do we do it? What’s best for our company? There’s an artifact that’s part of this phase called the Implementation Factor assessment and Deduction matrix. And so you take all your stuff and your assessment of the company and you start putting that into this deduction matrix.
And so for organizations that have got a history of enterprise architecture, then this might be very simple, right? So you may have well established process for change, and it may not be such a big deal for you, but if you’re not used to enterprise architecture and this level of formality and doing the level of planning that’s required in order to get changes implemented, then this could be a bigger step. So take note of that. So that was step one. Coming up in the next video, we’ll talk about step two, so stay tuned.
2. Phase E, Opportunities and Solutions, Step 2
So step two of phase E, which is the opportunities and solution phase, says determine business constraints for implementation. And so this is where you identify some of those business drivers that are going to cause you to have to change your implementation plan. Okay, so you going into this process, have a notice of the business drivers. There may be a lot of businesses have seasonality to them, and so you need to have something. You can’t be making major changes to the platform during the end of the calendar year. So from October 1 to January 1 is pretty much out of bounds. You may have big product launches. So every September your company has a big launch. Your company’s name is Apple. And so you don’t do these kind of implementations during your busiest season of the year. You may have budget issues. I know a lot of companies need to get a lot of work done before April 30 because that’s when their budget runs out. And so you’re going to make certain decisions for implementation around these kind of issues if there’s a law that goes into effect. So by December 31, your company has to be in compliance with this. Those are also constraints. So the purpose of this is when you’ve got now, you know, in the end of phase D, you know what you want to do. And now we’re talking about what are the restrictions on how you do it. Okay, so those are the constraints we’ll review. Depth three come up next.
3. Phase E, Opportunities and Solutions, Step 3
All right, we’re into phase e here, opportunities and solution. We’re looking at step three. Step three says review and consolidate gap analysis results from phases B to D. Phases B to D are the architecture domains bdat, business data architecture I’m sorry, business data application and technology. And so in order for you to consolidate the gap analysis, you have to create the consolidated gap solutions and dependencies matrix. This is an actual thing, an artifact of this phase. Chapter 28 of the togga spec 28. 2 goes into details on what goes into this matrix.
But this allows you to identify the solution building blocks and architecture building blocks that could address these gaps. And so let’s say you’ve got your list of gaps come out and it says that you are expecting traffic to triple on your website. You’re going to need a bigger server, you’re going to need to go into more of a farm, and so you can pull out the building blocks associated with that type of architecture. So now you take these gap analysis, you put them onto a single list. Okay, so now this is part of the consolidation. And at this stage we’re just about to get into grouping of work packages.
But before we do that, we’re going to want to reorganize things so that related items are grouped together. And so if there’s a lot of gaps around your sales process, around your sales systems, around all those things, then you’re going to keep them all in one place and you’re going to see some commonalities, you’re going to see a single solution that would solve some of these problems, et cetera. So the reorganization helps you with the design of the solution. So here we are at the end of step three. Next is step four. Thanks a lot.
4. Phase E, Opportunities and Solutions, Step 4
We are looking at the steps of opportunistic solution. This is step four, which says review consolidated requirements across related business functions. Okay? So really what this is, is you need to look at the requirements, the gaps, the solutions, the factors assessment matrix that you created in the last step to identify the minimum set of requirements, okay, that would lead to more efficient and effective implementation across business functions. So if there’s a single solution that can satisfy multiple requirements, that’s something that you should seriously consider because that’s obviously easier in many ways around.
Okay? So instead of having a list of 45 requirements, if you consolidate this and it’s really only 15 requirements, then things are a lot easier. And part of this is starting to see that different businesses, different organizations within your enterprise are having the similar problems, similar they’re coming up with their own solutions. And so there may be opportunities here. That’s why it’s called opportunities and solutions. The opportunity could be that you need to develop a solution across the company, across the enterprise.
So instead of every department having its own authentication, its own way of managing user ids and passwords, if you had a central authentication system and a central management of user ids and passwords, that makes everyone’s life a lot easier. standardizes things, reduces the risk, reduces cost, all sorts of things. So this is where you find these opportunities. So that’s basically step four is to consolidate these requirements. We’re about one third of the way through here of the phase II. So coming up next is step five, which is to reconcile interoperability, which is hard word to say, so stay tuned for that.
5. Phase E, Opportunities and Solutions, Step 5
We’re on to step five of phase E of the Opportunities and solutions. Phase. Step five says consolidate and reconcile interoperability requirements. So interoperability, obviously, from between the bdot phases, business to technology interoperability is sort the requirements for application or for a system or a solution essentially to be able to work with other solutions. Okay, so you’re going to consolidate all of these requirements across various phases. What parts of your requirements require interoperability? Then you have to decide that there are conflicts. So if your system absolutely needs to be able to access your customer database, let’s give it a more concrete example.
You have system B over in this part of the company, and it needs to be able to read from your customer database. It’ll never do an update, it’ll never do a write. It just needs to be able to read. But there’s not an existing method for them to get there. There’s no api. Everything is sort of protected. This application, the database is behind a firewall. And there’s a lot of complexity in trying to get access across different networks and security concerns. So this is an interoperability conflict. And so this is what you have to do is sort of figure out how you’re going to minimize these conflicts. Okay, so there’s only two approaches, or there’s two basic approaches.
Approach one is to create a new building block nto work between the conflict and this new building block in this example could be an api, right? So you could develop a system that provides a public api on a very limited basis, very strong authentication, very limited functionality. An application that runs inside that particular network that provides that functionality, that’s a new building block. And now other solutions that ever need to access this customer database can leverage that same building block in the future or even in this phase. That’s option one is to create a new building block that works between them. And option two is to modify the existing building blocks to work together.
And what that means is if there was a way that the system that has a customer database to export that as a file and upload that to an ftp site. And that just becomes a job that runs within the bounds of the existing application. That means the application you’re developing that needs the customer database, the application that has the customer database can work together. There’s no middle component. There’s no new function that sits in between them. They’re actually just been modified to work together. So those are the two basic ways that you’re going to get around up interruptability. But this is the stage of the process that you address that. All right, so that is step five of Opportunities and Solutions. Step six is talking about dependencies, which is another set of complexities. So we’ll talk about that right after this.
6. Phase E, Opportunities and Solutions, Step 6
Alright, we’re on to step six of opportunities and solution phase. This is refine and validate dependencies. So refine the initial dependencies, ensuring that any constraints on the implementation and migration plans are identified. Okay? So dependencies are going to be things that need to be in place before you can do what you want to do. So for instance, the It department might have the plan to update all of the computers. We’re going to get Windows ten, we’re going to have more memory, we’re going to have more disk space, everyone’s going to have faster cpu.
That’s on the books and that’s on the plan for this year. And you’re developing a desktop application that needs this speed. So that’s a dependency and you need to identify that and make sure that that’s something that can be relied upon. If the It department doesn’t end up upgrading everyone’s computers, you’re going to be in a tough place because you’ll have potentially a system that can’t perform that well, or maybe some computers can even run it. So that’s just an example of a dependency. So the other thing is, of course, other systems.
If your company is upgrading to sap for the back end enterprise level customer data, then you’re going to have that as dependency and you can’t do the projects you want to do until that project has been completed. So that’s a huge one. So in migration planning, in the term migration planning, essentially addressing these dependencies is one of the major goals. It is the basis for most migration planning. So this is a very important step. So that’s step six, kind of next step. We’re just past the halfway part here. We’re getting on to step seven.
7. Phase E, Opportunities and Solutions, Step 7
Okay, we’re into step seven of the Opportunities and Solutions phase, phase E. Step seven says confirm readiness and risk for business transformation. So there is a process within toga called Business Transformation Readiness assessment. You can see, I think it is chapter 30 within the troja 9. 1 spec, and there is a process for determining how ready your company is for transformation or change. This was done as part of Phase A, and so now we’re looking at the results of this review and we’re seeing how it’s going to impact our architecture roadmap and our strategy. Okay, so you may have various aggressive plans to solve a lot of the company’s problems. And it’s very bold and it’s very challenging and ambitious, I guess is the word I’m looking for.
But if your company has certain qualities that make these sort of bold, ambitious plans very risky, then this is something that you have to really seriously consider. So your job here is to identify, classify, and mitigate the risks for transformation. Now, I want to talk to you a bit about what these risks could be. Okay? So we would have gone through this in Phase A in terms of doing it, but it’s important at this point to sit and think, well, what are the types of things that happen with companies that make it risky to do certain deployments and certain aggressive, bold actions? Okay, so for instance, you need a very strong leader who believes in your result and will. It’s almost called a champion.
You need a champion that’s going to really lead from the front and be the leader that takes this output and turns it into reality. If you get a lot of people who are naysayers and who are always afraid of change and protecting their own departments, and they’re going to push against you, push against you. If the entire top level of the company is made up of people resistant to change, and there’s nobody that’s really strong enough to be able to take those people on, that’s a business risk. That’s something unique to your company that’s not going to be found in another company. I mean, it’s pretty common, but it’s not universal. Funding is another example.
So if you have a clear budget and a clear source of funding, if you’ve got a company that’s profitable making money, and you know that you’re going to spend x million dollars in the next twelve months to get your company from point A to point B, that’s great. But if you don’t, if it’s just an exercise in creating this bold vision, but you don’t really have any money lined up in order to implement it, well, that’s a risk, right? Strong governance. Obviously togaf has governance built into its framework. But if you have a really good governance model and really good governance, we talked about the levels of governance. It’s beyond just the architecture governance, technical governance, executive governance across the company.
So if a company is well run that way, then that’s a good sign. But again, if a company makes arbitrary decisions and there’s not really responsibility and they don’t have the accountability and all those functions of governments aren’t present, well, then that’s a risk. And so there’s a whole bunch of them. I won’t go through all of them at this point, but these are the kinds of risks that in step seven of phase E. We need to classify a document and start to mitigate. There’s a document, an artifact of this phase called Consolidated Gap Solutions and dependencies. And so you’re starting to fill out there’s a template for this. We start to fill out this form with the readiness risk that goes into this. We’ll find out this document will appear in some of the steps that follow as well. So that’s it for step seven. Hopefully that was helpful. We’ll get on to step eight.
