The document discusses the challenges of implementing new programs and policies without proper planning. It notes that policy is often crafted without fully understanding operational needs, and new requirements are identified late in implementation. This can lead to gaps and delays. The document then introduces enterprise business architecture as a solution to help understand interconnections, avoid duplication, and better support strategic decision making and change management across an organization.

1. 1 The process of change Supporting Policy Crafted 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. New Program Announced A new program is announced, with requirements for joint service delivery with partners and internal collaboration across departments. One-way Policy Policy is sent for implementation with little recourse for change, meaning gaps in requirements can be difficult to address with revisions to policy. Bridging Partner Relationships 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. Implementation Planning Implementation planning requires an even greater degree of detail in understanding the connections and requirements of the organization’s many units. Inclusive Requirements 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. IT Requirements Catch-up Without a clear view of the supporting systems, it’s difficult to identify support requirements and ensure that systems are in place.

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

3. 3 What is an enterprise business architecture? “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.” (EA Glossary V1.0)

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

10. Informs connections between policy & operations

11. Reduces duplication of data gathering

12. Common service delivery approach

13. Standard definitionsOperational

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

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