Difference between revisions of "Archived Enterprise Solutions material"
Line 46: | Line 46: | ||
Enterprise or shared IT solutions, assets, and services. | Enterprise or shared IT solutions, assets, and services. | ||
+ | == Value proposition == | ||
+ | * '''For''' Government of Canada employees, | ||
+ | |||
+ | * '''Who''' are involved in modernizing their departmental programs and services. | ||
+ | |||
+ | * '''Enterprise solutions re-usability framework''' is a classification framework and registry of GC reusable assets based on common business capabilities and user journeys, | ||
+ | * '''That''' enables employees to provision reusable assets when modernizing their departmental programs and services and to contribute reusable assets for others to reuse. | ||
+ | |||
+ | * '''Unlike today''' where there is limited guidance for reusability resulting in GC departments implementing duplicated assets. | ||
+ | * '''The Enterprise solutions re-usability framework''' establishes an operational framework to increase reusability across GC departments that will result in the following benefits: | ||
+ | |||
+ | == Reusability Classification Framework == | ||
+ | {| class="wikitable" | ||
+ | |+ | ||
+ | !Option | ||
+ | !Description | ||
+ | !Illustration | ||
+ | |- | ||
+ | |Centralizated | ||
+ | |These reusable assets are standardized to the entire GC in a consolidated manner, governed by a centralized authority and are provisioned by a single centralized service provider. It maximizes utility of major investments which address common business needs, have Enterprise-wide scope, long durations, and require participation from all departments and agencies. | ||
+ | Example: SSC Secure Cloud Enablement and Defense (SCED), desktop standards, data standards | ||
+ | |||
+ | Pros: Enables cohesive, horizontal integration across Enterprise to enables consistent frictionless utilization by stakeholders and administration. Maximizes consistency of technology. | ||
+ | |||
+ | Cons: Increases risk of vendor lock in. Does not allow for department specific customizations to address non-standardized business processes. | ||
+ | | | ||
+ | |- | ||
+ | |Distributed | ||
+ | |These reusable assets are identified by common departmental needs, governed by those departments and are provisioned through distributions and shared/clustered instances of the assets. This model leverages enterprise standards, product owners, departmental clusters, governance and oversight. This model may also leverage distributed technical infrastructure to support solution clusters. | ||
+ | Examples: FMT accelerators / Product Owner guardrails / Open Source toolkits, distributions, and templates, M365 (MS Teams) – Federated via DCAM tenants. | ||
+ | |||
+ | Pros: Recognizes layered approach of Enterprise Architecture Framework and enables governance of one or many aspects of Business, Information/Data, Application, Technology, Security, and Privacy for reuse by departments with similar business processes or non-functional requirements. | ||
+ | |||
+ | Cons: Although the risk of vendor lock in is mitigated comparted to the Enterprise Service Model, it may be challenging to replace technology components that span multiple departments. | ||
+ | | | ||
+ | |- | ||
+ | |Interoperable | ||
+ | |Reusable assets are developed by departments using standards and published for provisioning by others. This stand alone, or decentralized option allows departments to implement their own unique assets but publish and consume APIs and Open Source software centrally led guidance and standards. | ||
+ | Examples: IBM Curam (BDM – Public Cloud-hosted Containterized microservices exposed as APIs) | ||
+ | |||
+ | Pros: Enables reactive solutions to address business processes not shared across departments. Limited risk of vendor lock in. | ||
+ | |||
+ | Cons: Limits reuse across departments. Talent supporting technology components in the federated model have fewer opportunities to build skill sets useful across the Enterprise. | ||
+ | | | ||
+ | |- | ||
+ | |Departmental | ||
+ | |Reusable assets are developed for provisioning within a department or are not reusable at all as there is are no common business capabilities and user journeys. | ||
+ | This option allows departments to implement one-off, niche services, with reuse within their department or none at all. | ||
+ | |||
+ | Examples: Agriculture Canada SeqDB – Botany, Mycology, and Entomology Collection Management | ||
+ | |||
+ | Pros: Enables maximum flexibility for departments | ||
+ | |||
+ | Cons: Does not easily allow for reuse. Encourages niche skills not portable across the GC | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | == Registry of GC reusable assets == | ||
+ | {| class="wikitable" | ||
+ | |+Proposed model for registry | ||
+ | !Classification | ||
+ | ! | ||
+ | !Business capabilities addressed | ||
+ | !User Journeys addressed | ||
+ | !Source of assett | ||
+ | |- | ||
+ | |Centralizated | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Distributed | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Interoperable | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Departmental | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | |asset name | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |} | ||
+ | |||
+ | == Detailed Enterprise Solution Fact Sheet == | ||
+ | Any truly enterprise solution should be able to easily describe itself and it's qualities & properties. Use the following fact sheet to hold and maintain the quick reference information for any solution that has merit for the enterprise. The values can then be used by anyone either looking to compare potential alternatives or looking to improve / extend the existing enterprise solution. The information in this chart also provides an indirect guideline for those involved with the enterprise solution to highlight gaps and develop a roadmap towards a more well rounded solution. | ||
+ | {| class="wikitable" | ||
+ | |+ | ||
+ | ! colspan="4" |General | ||
+ | |- | ||
+ | |Name: | ||
+ | | colspan="3" | | ||
+ | |- | ||
+ | |Major Business Capability: | ||
+ | | | ||
+ | |Business Owner: | ||
+ | | | ||
+ | |- | ||
+ | |Minor Business Capability: | ||
+ | | | ||
+ | |Service Owner: | ||
+ | | | ||
+ | |- | ||
+ | |Specific Business Capability: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Nuanced Business Capability: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Date endorsed by GC EARB: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Website: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |How many departments use it? | ||
+ | | | ||
+ | |How many users? | ||
+ | | | ||
+ | |- | ||
+ | ! colspan="4" |Operational Costs | ||
+ | |- | ||
+ | |Last Year CAP EX ($k) | ||
+ | | | ||
+ | |Last Year OP EX ($k) | ||
+ | | | ||
+ | |- | ||
+ | |This Year CAP EX ($k) | ||
+ | | | ||
+ | |This Year OP EX ($k) | ||
+ | | | ||
+ | |- | ||
+ | |Next Year CAP EX($k) | ||
+ | | | ||
+ | |Next Year OP EX ($k) | ||
+ | | | ||
+ | |- | ||
+ | |# of people to operate: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Last Year: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |This Year: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | |Next Year: | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | ! colspan="4" |Information | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |- | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | | | ||
+ | |} | ||
== DRAFT: Framework for Enterprise Solutions Options == | == DRAFT: Framework for Enterprise Solutions Options == | ||
'''JOHN to update!''' | '''JOHN to update!''' |
Revision as of 10:09, 11 January 2021
< GC Enterprise Architecture < Enterprise Solutions
Branding
Current:
Enterprise Solutions
Alternatives:
Re-usability
Re-usable assets
Enterprise Services
Enterprise Capabilities
Enterprise Shared Services
Enterprise-wide initiatives
Centralized solutions/services
Enterprise or shared IT solutions, assets, and services.
Value proposition
- For Government of Canada employees,
- Who are involved in modernizing their departmental programs and services.
- Enterprise solutions re-usability framework is a classification framework and registry of GC reusable assets based on common business capabilities and user journeys,
- That enables employees to provision reusable assets when modernizing their departmental programs and services and to contribute reusable assets for others to reuse.
- Unlike today where there is limited guidance for reusability resulting in GC departments implementing duplicated assets.
- The Enterprise solutions re-usability framework establishes an operational framework to increase reusability across GC departments that will result in the following benefits:
Reusability Classification Framework
Option | Description | Illustration |
---|---|---|
Centralizated | These reusable assets are standardized to the entire GC in a consolidated manner, governed by a centralized authority and are provisioned by a single centralized service provider. It maximizes utility of major investments which address common business needs, have Enterprise-wide scope, long durations, and require participation from all departments and agencies.
Example: SSC Secure Cloud Enablement and Defense (SCED), desktop standards, data standards Pros: Enables cohesive, horizontal integration across Enterprise to enables consistent frictionless utilization by stakeholders and administration. Maximizes consistency of technology. Cons: Increases risk of vendor lock in. Does not allow for department specific customizations to address non-standardized business processes. |
|
Distributed | These reusable assets are identified by common departmental needs, governed by those departments and are provisioned through distributions and shared/clustered instances of the assets. This model leverages enterprise standards, product owners, departmental clusters, governance and oversight. This model may also leverage distributed technical infrastructure to support solution clusters.
Examples: FMT accelerators / Product Owner guardrails / Open Source toolkits, distributions, and templates, M365 (MS Teams) – Federated via DCAM tenants. Pros: Recognizes layered approach of Enterprise Architecture Framework and enables governance of one or many aspects of Business, Information/Data, Application, Technology, Security, and Privacy for reuse by departments with similar business processes or non-functional requirements. Cons: Although the risk of vendor lock in is mitigated comparted to the Enterprise Service Model, it may be challenging to replace technology components that span multiple departments. |
|
Interoperable | Reusable assets are developed by departments using standards and published for provisioning by others. This stand alone, or decentralized option allows departments to implement their own unique assets but publish and consume APIs and Open Source software centrally led guidance and standards.
Examples: IBM Curam (BDM – Public Cloud-hosted Containterized microservices exposed as APIs) Pros: Enables reactive solutions to address business processes not shared across departments. Limited risk of vendor lock in. Cons: Limits reuse across departments. Talent supporting technology components in the federated model have fewer opportunities to build skill sets useful across the Enterprise. |
|
Departmental | Reusable assets are developed for provisioning within a department or are not reusable at all as there is are no common business capabilities and user journeys.
This option allows departments to implement one-off, niche services, with reuse within their department or none at all. Examples: Agriculture Canada SeqDB – Botany, Mycology, and Entomology Collection Management Pros: Enables maximum flexibility for departments Cons: Does not easily allow for reuse. Encourages niche skills not portable across the GC |
Registry of GC reusable assets
Classification | Business capabilities addressed | User Journeys addressed | Source of assett | |
---|---|---|---|---|
Centralizated | ||||
asset name | ||||
asset name | ||||
Distributed | ||||
asset name | ||||
asset name | ||||
Interoperable | ||||
asset name | ||||
asset name | ||||
Departmental | ||||
asset name | ||||
asset name |
Detailed Enterprise Solution Fact Sheet
Any truly enterprise solution should be able to easily describe itself and it's qualities & properties. Use the following fact sheet to hold and maintain the quick reference information for any solution that has merit for the enterprise. The values can then be used by anyone either looking to compare potential alternatives or looking to improve / extend the existing enterprise solution. The information in this chart also provides an indirect guideline for those involved with the enterprise solution to highlight gaps and develop a roadmap towards a more well rounded solution.
General | |||
---|---|---|---|
Name: | |||
Major Business Capability: | Business Owner: | ||
Minor Business Capability: | Service Owner: | ||
Specific Business Capability: | |||
Nuanced Business Capability: | |||
Date endorsed by GC EARB: | |||
Website: | |||
How many departments use it? | How many users? | ||
Operational Costs | |||
Last Year CAP EX ($k) | Last Year OP EX ($k) | ||
This Year CAP EX ($k) | This Year OP EX ($k) | ||
Next Year CAP EX($k) | Next Year OP EX ($k) | ||
# of people to operate: | |||
Last Year: | |||
This Year: | |||
Next Year: | |||
Information | |||
DRAFT: Framework for Enterprise Solutions Options
JOHN to update!
Enterprise Solutions may be governed using three general models that provide relative advantages in terms of addressing technical debt, minimizing total cost of ownership, maximizing use of talent, maximizing consistency of technology and business processes, and optimizing infrastructure.
Model | Illustration |
---|---|
Enterprise Service Provider Model. This model provides all services to the entire Enterprise in a consolidated manner, governed by a centralized authority, and is fully integrated across all instances. It maximizes utility of major investments which address common business needs, have Enterprise-wide scope, long durations, and require participation from all departments and agencies.
Pros: Enables cohesive, horizontal integration across Enterprise to enables consistent frictionless utilization by stakeholders and administration. Maximizes consistency of technology. Cons: Increases risk of vendor lock in. Does not allow for department specific customizations to address non-standardized business processes. |
Centralized Model Icon |
Product Owner Model. This model uses departmental clusters or business owners to govern distributed instances of enterprise solutions. This model leverages enterprise standards, product owners, departmental clusters, governance and oversight. This model may also leverage distributed technical infrastructure to support solution clusters.
Pros: Recognizes layered approach of Enterprise Architecture Framework and enables governance of one or many aspects of Business, Information/Data, Application, Technology, Security, and Privacy for reuse by departments with similar business processes or non-functional requirements. Cons: Although the risk of vendor lock in is mitigated comparted to the Enterprise Service Model, it may be challenging to replace technology components that span multiple departments. |
Decentralized Model Icon |
Federated Model. This stand alone, or decentralized model allows departments to implement their own stack components, influenced by standards, using APIs via interoperability standards. Governance manages exemptions from the Standard; however, a decentralized enterprise with multiple service delivery methods and business units may be successful in finding justifications for significant deviations for standards.
Pros: Enables reactive solutions to address business processes not shared across departments. Limited risk of vendor lock in. Cons: Limits reuse across departments. Talent supporting technology components in the federated model have fewer opportunities to build skill sets useful across the Enterprise. |
Federated Model Icon |
Framework for Determining what Constitutes an Enterprise Solution
To be considered an enterprise solution, a project must meet five criteria which distinguish it from department specific solution:
Enterprise Solution | Department Specific Solution | |
Objective | Standardize and consolidate internal or external operations to address a common business need. | Separate internal or external operations to addresses a mandate-specific business need. |
Scope | Impacts whole of government. | Impacts individual departments. |
Investment | Requires significant investment and formal approvals (i.e. Cabinet and/or TB), and affects existing accountabilities. | May or may not require significant investment and formal approvals; does not affect existing accountabilities. |
Duration | Involves long-term solutions. | Involves short, medium or long-term solutions. |
Discretion | Participation is mandatory. | (Not applicable.) |
When to Pursue an Enterprise Solution
If a potential initiative meets the five criteria for enterprise-wide initiatives, as outlined above, the decision whether to pursue such an approach will be based on the assessment of seven additional criteria which address value for money and feasibility. Overall, decisions will be based on net value (overall) as individual criteria might be in conflict.
Value for Money
- Value: Does it represent a net improvement in value for money—i.e. economy, efficiency and effectiveness—as compared to the status quo/other options? (See Annex 1 for specific checklist.)
- Interdependencies: Is an enterprise-wide approach required to support other interconnected initiatives?
- Risk: Does it reduce operational risk through enhanced operational security and integrity? Are the respective risks of pursuing an enterprise-wide approach less than those of adopting department-specific approaches?
Feasibility
- Timing: Is the timing favourable for such an initiative given the current context and competing priorities?
- Equity: Will it result in equitable and consistent treatment across departments?
- Funding: Is funding available, aligned with current priorities, and recommendable in light of opportunity costs? Are the long-term total costs of not proceeding (e.g. continuing to pay for the maintenance of silo’d legacy infrastructure) greater than those of adopting an enterprise-wide approach? Are the individual and collective financial impacts on departments a net benefit?
- Capacities: Is there an existing organization (e.g. a common service organization) that could provide the service? Is there a lead organization or cluster with the necessary resources, expertise and commitment to successfully execute?
Enterprise Solutions Critical Success factors
Any solution that is worthy of of use across the entire GC should allow the consumers to successfully achieve their objectives by providing an accessible, enabling, extendable, fast, monitored, reliable, scalable, secure, and self-service common base service in an open, cost-competitive, collaborative, iterative, proactive, timely and transparent manner.
Key Words | Definition (all are where appropriate) | Examples of how to enable | Ways to measures success |
---|---|---|---|
enabling | empowering the consumer to achieve their objectives | multiple methods to engage any one service, simplicity, compatability, accessibility | Client feedback surveys |
extendable | allowing the consumer to extend the service to meet their objectives beyond the common base | APIs, Delegated Access to configuration | adoption rates, client feedback surveys |
fast | each engagement with the service is responded to quickly | measure, decompose and improve; compare all changes to baseline | MTRs on ITSM, service response times |
monitored | both the service provider and the consumer have visibility into the state and quality of the service | End point visibility, network monitoring, pagerduty.com, SIEMs, cloud platform native tools, new relic, dynatrace | transparency, continual improvement of coverage |
reliable | the service has been architected to have be able to have a high service level objective | Redundancy, Resiliency, Geographic distribution, high availability models, workload pattern scaling | planned availability % vs total availability % |
scalable | the service is able to be expanded to new consumers quickly and efficiently | Well-documented onboarding plans, pre-planned expansion posture, automation | delivery or enablement time |
secure | allowing the consumer to trust the service | Encryption Everywhere!
Solution categories: advanced persistent threat protection, anti malware, AI, breach and attack simulation, communication fraud protection, cyber threat intelligence, data classification, data governance, data leakage prevention, data rentention, endpoint detection and response, identity and access management, incident response, insider threat, IoT, intrusion detection & prevention, mobile application / mobile device management, multi-factor authentication, network detect and response, network traffic analysis, secure data erasure, secure file transfer, SIEM, orchestration, automation and response, user and entity behavior analytics, vulnerability management |
vulnerability rates, compliance rates, incident rates, impact of implementation to service |
self-service | allows the consumer to not have to engage with any thing other than the service itself to consume it | APIs, Delegated Access to configuration | adoption rates, client feedback surveys |
common base | satisfies a common base set of requirements that all consumers need | standards: base configuration, security, performance | adoption rates, client feedback surveys, # change requests |
open | allows the consumer to participate in the road map for service evolution | published road maps, open communication channels, real time community engagement | participant rates, # of comments received, # change requests, client feedback surveys, consumer tone analytics (https://www.ibm.com/watson/services/tone-analyzer/) |
cost-competitive | allows the consumer to see exactly how their money is being spent to provide the service, and is in line with competing service providers | entreprise agreements, open source, minimal waste or excess components, automation, scaled to utilization | per consumer rate, total cost versus other services offered, per service provider rate, capex versus opex rate to offer the service |
collaborative | allows the consumer to partner with the service provider to throughout the life cycle of the service | GCCollab, Social Media, working groups for road map, active listening | adoption rates and client feedback surveys |
iterative | allows the service to continually change to add, adapt or remove componets over time | start small and add value and be stable each release | number of stable changes & releases |
proactive | allows the service provider to act before being asked to do so | partner with consumers, articulate business value, be transparent, be the experts in the domain and recommend service improvements, every year each service should improve without a budget increase. | reduction in ITSM calls, client feedback surveys |
timely | allows the consumer to consume the service without lengthy or costly upfront engagements | Clear instructions, automation, "smart" decisions and assumptions, avoid dead ends, partner your consumers before being asked to to "increase the runway" | Instrument, interconnect, & improve |
transparent | allows the consumer to be fully aware of the state of the service being provided | Dashboard (per user category), status pages (https://status.status.io/), published road maps, published runbooks, automation libraries, user guides, embedded client execs, planned vs. unplanned outages feeds | Client feedback surveys, technical usage statistics |
Critical Success Factors
In order to effectively realize an Enterprise Solution, there are a number of principles that should be considered:
- Alignment: Ensure that the initiative aligns to the near and long-term business objectives of the organizations being affected
- Needs Assessment: Identify users' needs at the beginning; this also includes cost considerations (projects delivered on time and on budget).
- Governance: Create clear lines for approval and decision making; and ensure that there is accountability at all levels
- Flexibility: Determine the capability of organization(s) to implement the project effectively and quickly to maximize the gains of engaging in an enterprise wide initiative
- Optimization and Sequencing: Ensure that the right people are doing the right work at the right time
- Evaluating: Assess and adjust project deliverables and milestones continually throughout the process:
Determining what Constitutes an Enterprise-wide Initiative[edit | edit source][edit | edit source]
Copied from Supporting Enterprise Government: A Government of Canada Vision and Strategy (Draft – November 2014)
To be considered an enterprise-wide initiative, a project must meet five criteria which distinguish it from department-specific initiatives:
Enterprise-wide Initiative | Department-specific Initiative | |
Objective | Standardize and consolidate internal or external operations to address a common business need. | Separate internal or external operations to addresses a mandate-specific business need. |
Scope | Impacts whole of government. | Impacts individual departments. |
Investment | Requires significant investment and formal approvals (i.e. Cabinet and/or TB), and affects existing accountabilities. | May or may not require significant investment and formal approvals; does not affect existing accountabilities. |
Duration | Involves long-term solutions. | Involves short, medium or long-term solutions. |
Discretion | Participation is mandatory. |
Service & Digital Target Enterprise Architecture
The Service & Digital Target Enterprise Architecture and Whitepaper were presented at GC EARB on July 16, 2020 for pre-endorsement.
The Service & Digital Target Enterprise Architecture defines a model for the digital enablement of Government of Canada services that addresses many of the key challenges with the current GC enterprise ecosystem.
- It seeks to reduce the silos within the current GC ecosystem by having departments adopt a user and service
delivery centric perspective when considering new IT solutions or modernizing older solutions.
- It advocates a whole-of-government approach where IT is aligned to business services and solutions are based on re-useable components implementing business capabilities optimized to reduce unnecessary redundancy.
- This re-use is enabled through the use of published APIs shared across government. This approach allows GC to focus on improving its service delivery to Canadians while addressing the challenges with legacy systems.
GC EARB and the EA Framework
The Business Architecture layer of the the EA Framework has the following assessment criteria for GC EARB reviews:
- Promote Horizontal Enablement of the Enterprise
- Identify opportunities to enable business services horizontally across the GC enterprise and to provide cohesive experience to users and other stakeholders
- Reuse common business capabilities, processes and enterprise solutions from across government and private sector
- Publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services.
Decision Making Framework for Enterprise Solutions is included as part of the presenter template
Supporting Enterprise Government: A Government of Canada Vision and Strategy (Draft – November 2014)
- Enterprise-wide initiatives aim to maximize the effective functioning of the Government of Canada as a modern enterprise by:
- seeking feasible solutions that provide Canadians with the greatest overall value for money;
- leveraging the full potential of new technology; and
- improving the alignment and coherence of federal investments in business operations and services.
Existing definitions and references from policy documents:[edit | edit source][edit | edit source]
The TB Policy on Service and Digital defines “Internal Enterprise Services” as “A service provided by a Government of Canada department to other Government of Canada departments intended on a government-wide basis.”
The policy states that departmental heads are to use enterprise or shared IT solutions, assets, and services. The policy indicates that department heads are to update the Service Inventory is catalogue of external and internal enterprise services that provides detailed information based on a specific set of elements (e.g., channel, client, volume, etc.).
The TB Policy on Service and Digital states that PSPC is responsible for providing common enterprise solutions and services related to the following: electronic document records management systems, case and workflow tracking solutions, and collaboration platforms. Whenever possible, PSPC is responsible for delivering these services in a consolidated and standardized manner. PSPC’s services are provided on a cost-recovery basis.
Benefits of Enterprise Solutions
- Horizontally enable external and internal business services and provide cohesive experience to users and other stakeholders.
- Reduces the total cost of ownership, that includes procurement, development, operation maintenance and decommission for services by streamlining the number of GC digital solutions.
- Enhances integration and collaboration, creates transferable skill sets, and leverage innovative work across the GC and the private sector.
- Maximize enterprise investment by consolidating solutions into Enterprise Solutions, based on Business Capability Model (BCM)
Health Canada classification model
- Business Capability
- Solution, specific tool
- Component
Digital Core Architecture Guiding Principles
Build Once, Use Everywhere
Build solutions, components and processes for the GC, and reuse across departments; select common over department-specific.
Business before Technology
Derive the solution definition from business requirements and user needs. Design and run the solutions based on overall end to end process.
Standard over Custom
Use standard to maximize integrity, sustainability and interoperability. Design for flexible adoption of enhancements and upgrades.
User-Centricity
Design with, build for, and deliver the best experience to internal and external users. Focus on the needs of users, using user-centred methods.
Treat Data as an Asset
Design to maximize data use and availability. Use the data you collect and implement analytical tools. Reuse existing data where possible.
Design for Security and Privacy
Balance user and business needs with proportionate security measures and adequate privacy protections.
Cloud First
Explore “… as a service” (XaaS) cloud services first. Cloud first but not cloud only… for On Premise, try to adhere to Cloud qualities (e.g. zero modification).
Maximize Benefits
Strive to maximize the benefits for the enterprise; optimize total cost of ownership and minimize risk. Design to be measurable and accountable.
Integration
Enable interoperability based on standard components and solutions. Minimize the number and complexity of the interfaces.
Input from Gartner
In a shared services model, the customers of the shared services are part of the formal board of directors, governing the strategic intent of the shared services organization and determining what service levels will be provided.
Centralization is most commonly successful in forms of government with a single, strong leader such as a governor, a strong mayor or county executive, or a president, where the role has significant power over the machinery of government.
There are occasional exceptions to both of these situations, but creating a centralization model in the parliamentary form of government is extremely challenging because the parliamentary model usually doesn’t envision enterprise authority vested in any one person.