1.
1<br />The process of change<br />Supporting Policy Crafted<br />In order to lay the foundation, policy is crafted to support the program. Policy writers, however, do not always have a clear view of operational issues.<br />New Program Announced<br />A new program is announced, with requirements for joint service delivery with partners and internal collaboration across departments.<br />One-way Policy<br />Policy is sent for implementation with little recourse for change, meaning gaps in requirements can be difficult to address with revisions to policy.<br />Bridging Partner Relationships<br />Having a clear view of partners and the requirements of joint service delivery is critical. Trying to bridge these gaps during or after implementation can be difficult and time consuming.<br />Implementation Planning<br />Implementation planning requires an even greater degree of detail in understanding the connections and requirements of the organization’s many units.<br />Inclusive Requirements<br />A good deal of requirements are identified in implementation; units whose involvement wasn’t predicted, or whose requirements weren’t properly captured slow the rollout. <br />IT Requirements Catch-up<br />Without a clear view of the supporting systems, it’s difficult to identify support requirements and ensure that systems are in place.<br />

2.
2<br />Typical organizational challenges<br />Impact analysis by new initiatives limited to participant knowledge<br />PLANNING & EXECUTION<br />Inconsistencies in program and project context<br />Duplicated effort when creating program and project context<br />GETTING THE BIG PICTURE<br />Difficult to understand aggregated impacts of programs and policies<br />Limited documentation on the “business” of MOE<br />Difficulty in producing integrated, enterprise level reports<br />Increasing cost of maintaining overlapping or duplicated systems<br />Missed opportunites to leverage existing infrastructure<br />Information duplication and inconsistencies in multiple systems<br />LEVERAGING TECHNOLOGY<br />

3.
3<br />What is an enterprise business architecture?<br />“Business architecture (BA) is a business driven disciplined process that decomposes the enterprise’s business goals and strategies, the assets and processes required to execute them, as well asidentify their impact on business goals.”<br />(EA Glossary V1.0)<br />

4.
4<br />How EBA can help<br /><ul><li>Leading strategic best practice for business design

5.
Enables generation of program/project metrics at a strategic, enterprise level

6.
Alignment with modernization efforts at the OPS level

7.
Enables view of Ministry wide impacts for decision makers

8.
Consolidated operational view of how we deliver services

9.
Enables a client centric services viewSingle point access to services</li></ul>Strategic<br />Clients<br /><ul><li>Accelerates program and service design

10.
Informs connections between policy & operations

11.
Reduces duplication of data gathering

12.
Common service delivery approach

13.
Standard definitions</li></ul>Operational<br />

14.
How do we use an enterprise business architecture?<br />5<br />Designing a new program/ operationalizing a new policy or regulation<br />Who else in the organization is doing something similar?<br />Who is going to be affected by the change?<br />Determining the scope of a new policy or regulation<br />Who are my stakeholders?<br />Do I need to flag someone for the program design?<br />Who else is interfacing with the same target group?<br />At the start of a project<br />How can I create an aggregated report for this regulated body?<br />Can I leverage work already done elsewhere?<br />What data are we already collecting?<br />Deciding where to pull information from for a report<br />Who is collecting the information already?<br />Writing requirements for a new system<br />Can we leverage existing systems?<br />

15.
What is an enterprise business architecture?<br />6<br />Strategies<br />Enterprise wide mandate<br />Program goals<br />Information required to operate<br />Program mandate<br />Accountabilities to and from stakeholders<br />Business rules<br />Enterprise wide objectives<br />Client needs<br />Clients<br />Business processes<br />Services<br />Key stakeholders, relationships and accountabilities<br />An inventory of programs<br />The context for why your business exists<br />How your business works<br />An inventory of services<br />The accountabilities for each service<br />Performance measures<br />Clients<br />Inventory of SLAs, MOUs<br />Performance measures for service providers<br />Players<br />Processes to deliver programs<br />Accountabilities to and from clients<br />Delivery model<br />