Line 9: |
Line 9: |
| | | |
| | | |
− | The scope of the EA Playbook focuses on the assessment piece, which is looking for evidence on where the project/program sits in the overall GC Target Architecture (currently in draft) and how it aligns to the GC direction. It complements the Whitepaper for the GC Enterprise Architecture (currently in draft) that will be published soon. <br> | + | The scope of the EA Playbook focuses on the assessment piece, which is looking for evidence on where the project/program sits in the overall GC Target Architecture (currently in draft) and how it aligns to the GC direction. It also complements the [https://docs.google.com/document/d/19ZCSC32ZRXm_A4eC1OdA5dcXvJMEuwqt2RKteGeaUE0/edit# Service & Digital Target Enterprise Architecture Whitepaper] (currently in draft) that will be published soon. <br> |
| | | |
| | | |
Line 126: |
Line 126: |
| <h4><b><u>Architect to be Outcome Driven and Strategically Aligned to the Department and to the Government of Canada</b></u></h4> | | <h4><b><u>Architect to be Outcome Driven and Strategically Aligned to the Department and to the Government of Canada</b></u></h4> |
| | | |
− | The whole notion of creating a program or project is to support departmental mandate. Thus, it needs to be clear what mandate a program or project is supporting, how the outcome of the program or project supports the mandate and measure how effective it is in supporting the mandate. A project or program may indirectly support a mandate, however, its derivative outcome may still be able to be tied into a mandate. Everything needs to be tied in to the mandate and everything needs to be measurable. If a department is not sure how a program or project is supporting its mandate, or how it can be measured, then perhaps the program or project may not be required to begin with. | + | The whole notion of creating a program or project is to support departmental mandate. Thus, it needs to be clear what mandate a program or project is supporting, how the outcome of the program or project supports the mandate and measure how effective it is in supporting the mandate. The mandate can be broken down into Strategic Outcomes. A project or program may indirectly support a mandate, however, the derivative outcome it produces may still be able to be tied into one of the strategic outcomes which support departmental mandate. Everything needs to be tied in to the mandate, or one of the strategic outcomes, and everything needs to be measurable. If a department is not sure how a program or project is supporting its mandate or its strategic outcome, or how it can be measured, then perhaps the program or project may not be required to begin with. |
| | | |
| A system or solution that is the end result of a program or project also needs to strategically align to the direction of the Government of Canada. For example, if we know at the end the GC will be going to the cloud, then program or project needs to at least have a plan in place on how to migrate it to the cloud whenever its ready. Another example, if we know at the end the GC will be using NextGen, then all HR related interim functionality need to plan for transitioning to use NextGen when it becomes available. <br><br> | | A system or solution that is the end result of a program or project also needs to strategically align to the direction of the Government of Canada. For example, if we know at the end the GC will be going to the cloud, then program or project needs to at least have a plan in place on how to migrate it to the cloud whenever its ready. Another example, if we know at the end the GC will be using NextGen, then all HR related interim functionality need to plan for transitioning to use NextGen when it becomes available. <br><br> |
Line 163: |
Line 163: |
| | | |
| <h4><b><u> Promote Horizontal Enablement of the Enterprise</b></u></h4> | | <h4><b><u> Promote Horizontal Enablement of the Enterprise</b></u></h4> |
− | * Identify opportunities to horizontally enabled business services and provide cohesive experience to stakeholders
| |
| | | |
− | * Reuse common business capabilities and processes from across government and private sector
| + | By having a common business capability terminology, it becomes easier to figure out if one solution is essentially a duplicate of another solution. It also becomes easier to find out if a department has obtained a solution to enable a business capability, and thus, the same solution may be leveraged to solve similar problem in another department. This horizontal enablement across departments would support reduction in IT spending through achieving economy of scale in procuring the same licenses. It would also support better collaboration between departments and easier data exchange. |
| | | |
− | * Publish in the open reusable common business capabilities and processes (in the Open Government portal) for others to develop cohesive horizontal enterprise services | + | |
| + | * <b><I>Identify opportunities to horizontally enabled business services and provide cohesive experience to stakeholders</b></I> |
| + | |
| + | |
| + | |
| + | * <b><I>Reuse common business capabilities and processes from across government and private sector</b></I> |
| + | |
| + | |
| + | * <b><I>Publish in the open reusable common business capabilities and processes (in the Open Government portal) for others to develop cohesive horizontal enterprise services</b></I> |
| | | |
| | | |