1. Phase G, Implementation Governance, Step 1
Okay, this is second to last phase of the adm cycle. It’s called Phase G, Implementation Governance. Remind you on screen you can see Implementation Governance is around the 09:00 on the adm cycle. The main purpose is to do governance duties, making sure that the development and implementer teams are following your target architecture and giving, giving you the business value that you’re expecting. Your job is to update the baseline architecture as changes are implemented. So step one of this, Phase G is to confirm the scope and priorities for deployment. So this is where you’re sitting and you’re meeting with the Development and Implementation Management.
And obviously you’ve lived with this architecture and this definition and these requirements for quite some time. And you have got some ideas as to how you’d like to see things done. And so you’re going to come up with these recommendations for them to say, well, ultimately it’s their job to fulfill the requirements and to deliver the business value that you’re expecting. But these are my recommendations. You’re also going to let them know what your priorities are. And so if you’re saying the main thing that we want to get out of this is what? Service oriented architecture where every back end piece of data is accessible to a front end piece through services?
If that’s your dream, you have to express the main priorities of this architecture. If you think there’s going to be deployment issues, So let’s say there’s a complicated migration and you’re going to have to have data taken from one set of hosting providers to another, there’s going to be some downtime for the application. You’re going to have recommendations around that as well. Now, within our architecture, we have architecture building blocks and solution building blocks. So we are identifying which building blocks are in need of a replacement and things like that. So being very clear about our architecture and what we’re expecting at the end of this.
And finally for step one, there is a gap analysis that’s happening. So you’ve got your baseline enterprise architecture, and you’re really basically telling them, listen, to get from here where we are to where we want to be, we need to get a new piece of software for this, roll out some new hardware for that, shut down this line of business, do this, do that, whatever your recommendations are. Those are the gap analysis. And you’re to explain to the deployment team and implementation teams. These are your gaps. So that’s step one coming up next. The next step for phase.
2. Phase G, Implementation Governance, Step 2
All right, step two of the implementation governance phase is to identify the resources to do these development and deployments. So the first step of that is what is the system development methods that are going to be used to do these? So you might have certain methods in house. You may have an in house team of developers and they have a certain way of doing development. And so these get identified. If you’re going to hire an outside company, you need to know also how they do development. So you need to also make sure. So once you’ve identified what the approach is, then you need to make sure that you are available to monitor this, get these conformance requirements that you have, and it gets the feedback to you on the designs.
So let’s give a hypothetical. Let’s say that your in house development team uses a very agile approach and they’re expecting to be able to do incremental deployments along the way. Every three or four weeks, they’re going to do a deployment to production with one feature or one change. They do this very rapidly and that’s fine. That’s their technique. And I actually think there’s pros and cons to it, but people like it. But how? As an architect, your job is this overriding governance role to ensure that the business value is being developed and that they’re following your requirements fairly closely.
So you need to make sure that there’s parts in this process, milestones that you attend the status meeting. You don’t have to attend every single scrum every single day, but you make it a point to attend certain days, especially when you’re getting close to a release point. So make sure that you get the feedback from the team and that you’re able to get the information that you need. So that’s pretty much it for step two. It’s pretty simple, just those two points. Coming next, we’ll talk about step three. This is when development has started in earnest, so come back for that.
3. Phase G, Implementation Governance, Step 3
Okay, we’re on to step three of phase G implementation governance. In this step it says guide development of solutions deployment. So the first thing that you need to do in this step is to formulate project recommendations. So we’re into the development and deployment now, and this is when things are down to individual projects, objects, okay? And so as the architect and the role of governance here, your role is partly to manage the impacts, not manage them in the sense of having to resolve them, but at least to document them. And so if change requests are coming through, then that goes through the change request process and that becomes an impact and you document that. If there are timeline changes, if the roadmap changes, you document that.
Okay? Second part of that is to create the architecture contract. Now the architecture contract is kind of a big deal. Within TOGAF this is the concept that within the business team and the development team and the architecture team, there’s going to be agreement in what we’re developing and what the solution needs to do in terms of performance. Okay? And by performance, I mean it needs to do certain things. And so just as if you’re hiring an outside company to go and build you a website, even if you’re dealing with internal development, internal project teams, you’re going to lay out, I need a website and I need the following 20 things. And these are my must haves. And they’re going to have to sign off literally a signature on those 20 things.
And they can’t just deliver 15 out of the 20 and think that they’re done because they’re not. So that’s the architecture contract. The business also commits to this so that they can’t come back later and say, well, we thought it was the 21st thing. It’s written down on paper. Everyone’s clear. These are the 20 things, the Enterprise continuum. So obviously as we’re developing solutions, solution building blocks come out of those and solution building blocks get put onto the Enterprise continuum. You may have very organization specific building blocks or these might be generalized that they could be shared, but basically you’re going to put them in Enterprise continuum. Refer to my lesson on Enterprise continuum if you want more specific details on how Enterprise continuum works.
Now we’re getting into the development of services. If you recall, within the meaning of toga, a service is a function that generally the It department provides to the entire company, or at least it’s supported across the company. And so it’s not a mail. Email is a service, right? Or file storage is a service, okay? Active directory where you’ve got employee authentication, that’s a service. Not one business owner, not one department manages that. So if there’s any new services that come out of this work, you’re going to be part of that operational requirements. We talked in the last phase about how operations as we’re getting into development here, we have to understand the costs of things and how they impact the ongoing operations.
And so if there are operational requirements. So let’s say that the operational people need admin tools to be able to manage things, or they need production, staging, development environments and things like that. Those are operational needs. And the Produce implementation plan. So at the end of Phase G implementation governance, you’re going to have an actual plan for rolling these things out. It’s not just a roadmap and a timeline anymore, it’s actually how we’re going to do the plan. So that’s step three, which is guiding development. And coming up next, we’re going to step four, which will be the fun part, which will be compliance reviews. So come back for that.
4. Phase G, Implementation Governance, Step 4
Okay, we’re on to step four of Phase G implementation. Governance. Step four says perform Enterprise architecture. Compliance reviews. This is a very straightforward step inside of the toga spec. It says review ongoing implementation, governance and architecture compliance. And so we’re into this development of the solution solution. The implementation teams are doing the developments and the deployments. And so what your job is at this stage is compliance. When the solutions are getting close to being implemented and we’re into some sort of testing or staging process, you’re going to look at them and make sure that they’re delivering the features and functions that you outlined in your Architecture Definition document and part of the architecture contract.
So conduct post development reviews. And at this stage, at the end of step four, we can close out development. Now, maybe all the solutions are deployed, but the solutions are developed and we’re into a testing. And that’s where you can say, sign off, and it’s compliant. All right, so that was step four. Again, a very straightforward step, not too many steps within it. Coming up next is step five, even shorter one. So stay tuned for that.
5. Phase G, Implementation Governance, Step 5
So this is step five of the implementation phase. And step five says implement business and It operations. So now that we’ve finished with the development of projects, we’re into deployment. And that moves over to the operations side of the game. Okay, so those services, if we’ve got services that are being developed and delivered, you’re making ensure these services come online. These business services in terms of providing service to the customers, any sort of training and skills that your end users are going to need training on, these new softwares and techniques, obviously not your job to do that. But this is the phase of the architecture development method that we’re in and any sort of communications documentation.
So if you need to create user manuals and distribute them to the right people, you’re going to be making sure that gets done. And maybe the more important part of this step is to update your baseline architectures. So now once either the transition or the target architecture has been deployed, then the baseline gets updated to that and you keep your architecture repository up to date. Make sure the operations documents in terms of IP addresses and all these things are up to date as well. Again, some of these tasks are not necessarily your job to do, but this is when it happens. So that was step five. We’re almost done. Step six is the last step, and that’s when we’re to be closing up the implementation. So come back for that.
6. Phase G, Implementation Governance, Step 6
All right, we are here in step six of Phase G implementation governance. Step six says perform post implementation review and close the implementation. So now that the implementations are completed at this step, okay, we’ve already know that the architectures are incomplete clients. We already know that the services and everything’s been deployed successfully. Now you’re going to conduct a review just to make sure that there’s no errors, that everything is functioning as expected. Of course, again, the implementation team is going to have a warranty period and they’re going to make sure that the stuff implemented is working. But as the architect uses, make sure that that’s still going on.
The second substep of that is to publish those reviews and close the project. And so you’re going to go back to the architecture governance board, go back to the business owners, and you’re going to say, yes, I’ve reviewed it. The target architecture has been realized. Maybe it’s just been implemented and everything’s going well. We don’t know about the results of it yet, so we’re not into measuring the business value being attained at this point yet. But as far as you know, everything is operating normally. And you’ll go back to these people and say, that architecture that I have been working on for the past so many months is ready and it’s live.
Okay, so closure on Phase G will be when solutions are fully deployed. Once. I think the key word here is the once because there’s always going to be follow ups, right? So you do a deployment and you know that within a couple of weeks, you’re going to need to fix some bugs and you’re going to little things here and there need to be mopped up. But that’s part of ongoing operations, right? So Phase G is not going on while the applications are 100% bug free and everything’s going 100% perfect. That’s not the measurement of success we talked about earlier on in the phases.
In the planning, you have success factors and so 100% perfection shouldn’t have been on your success factor. The success factor at this stage is going to be the successful deployment. Now of course, we’re going to have to measure the business value and make sure that we’re on our way to tracking to that. But that’s not at this point. That was Phase G. Phase G is closed. That means everything is deployed and we are now moving on to Phase H. Phase H is a bit of a waiting phase, but coming up in the next section, we’ll get through Phase H and we’ll just sort of close out the adm cycle. It’s the last phase of the adm cycle.
