Difference between revisions of "GC Enterprise Architecture/Framework/BusinessGuide"
m |
m |
||
(17 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | {{OCIO GCEA Header}} | |
<multilang> | <multilang> | ||
− | @en| | + | @en|__TOC__ |
== Business architecture == | == Business architecture == | ||
Business architecture is a critical aspect for the successful implementation of the GC Enterprise Ecosystem Target Architecture. The architectural strategy advocates whole‑of‑government approach where IT is aligned to business services and solutions are based on re‑useable components implementing business capabilities in order to deliver a cohesive user experience. As such, it is essential that business services, stakeholder needs, opportunities to improve cohesion and opportunities for reuse across government be clearly understood. In the past these elements have not been a priority. It is expected that the IT culture and practices will have to change to make business architecture, in general, and these elements a primary focus. | Business architecture is a critical aspect for the successful implementation of the GC Enterprise Ecosystem Target Architecture. The architectural strategy advocates whole‑of‑government approach where IT is aligned to business services and solutions are based on re‑useable components implementing business capabilities in order to deliver a cohesive user experience. As such, it is essential that business services, stakeholder needs, opportunities to improve cohesion and opportunities for reuse across government be clearly understood. In the past these elements have not been a priority. It is expected that the IT culture and practices will have to change to make business architecture, in general, and these elements a primary focus. | ||
+ | <br> | ||
+ | === Design services digitally from end‑to‑end to meet the Government of Canada users and other stakeholders’ needs === | ||
+ | <br> | ||
+ | ==== Clearly identify internal and external users and other stakeholders and their needs for each policy, program and business service ==== | ||
− | + | In order to ensure that a service will be able to meet the users and stakeholders' needs, it needs to understand what needs it is trying to provide service for, who their users and stakeholders are, both internal and external. <br> | |
− | + | Once the needs, the users and stakeholders are defined, then a service provider can proceed to create a stakeholder mapping to further understand the relationship between the service and the users & stakeholders, ie. how a change in one component impacts the other. <br> | |
− | + | From there, the service provider can conduct need analysis of its users and stakeholder to develop a program, a policy or a service that meets their needs (this practice may also be known as stakeholder requirements or value mapping). <br> | |
− | + | This exercise can also help define the limitation/scope of the program/policy/service to better manage the expectation of their users/stakeholders. | |
− | |||
<b>How to demonstrate that the project fulfils this framework:</b> | <b>How to demonstrate that the project fulfils this framework:</b> | ||
Line 17: | Line 20: | ||
<b>Tools:</b> | <b>Tools:</b> | ||
* Business Case | * Business Case | ||
− | * Stakeholder requirements | + | * Stakeholder (Actors, Roles, Organizational Units) Mapping & Stakeholder requirements |
* Outcomes | * Outcomes | ||
− | * | + | * Business Process Map |
* Value Stream and Value Mapping | * Value Stream and Value Mapping | ||
+ | </br> | ||
+ | * <b> include policy requirement applying to specific users and other stakeholder groups, such as accessibility, gender-based plus analysis, and official languages in the creation of the service </b> | ||
− | + | To ensure that a service can be used by all its users, it is important to note the specific requirements for specific users and to that extent, it is important to take note and apply the policy that governs the service standards when providing service to the specific user groups.</br> | |
− | <b>How to | + | This will in turn enable the service to be far-reaching and more inclusive to all its users. |
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Outline what policies constrain the architecture | * Outline what policies constrain the architecture | ||
* Outline positive and negative impact the policy has on the architecture to meet the needs of the stakeholder | * Outline positive and negative impact the policy has on the architecture to meet the needs of the stakeholder | ||
Line 29: | Line 36: | ||
<b>Tools:</b> | <b>Tools:</b> | ||
* User Interface Design Principles | * User Interface Design Principles | ||
− | * perform Algorithmic Impact Assessment (AIA) to support risk mitigation activities when deploying an automated decision system as per ''Directive on Automated Decision-Making'' | + | </br> |
− | <b>How to | + | * <b> perform Algorithmic Impact Assessment (AIA) to support risk mitigation activities when deploying an automated decision system as per ''Directive on Automated Decision-Making''</b> |
+ | |||
+ | When a service has an in-system developed automation for decision making, it is essential that the service perform AIA, to ensure that the result of this decision making is impartial and fair, and the impact of that decision would be the same as if the decision is made manually, only faster. </br> | ||
+ | The use of this type of system must closely follow the Directive on Automated Decision-Making. | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Provide the impact level based on the completion of the conceptual AIA | * Provide the impact level based on the completion of the conceptual AIA | ||
* Describe how the architecture will address the recommendations coming from the AIA | * Describe how the architecture will address the recommendations coming from the AIA | ||
Line 36: | Line 48: | ||
<b>Tools:</b> | <b>Tools:</b> | ||
* AIA Results (Conceptual) | * AIA Results (Conceptual) | ||
− | * Model end-to-end business service delivery to provide quality, maximize effectiveness and optimize efficiencies across all channels (for example, lean process) | + | </br> |
− | <b>How to | + | * <b>Model end-to-end business service delivery to provide quality, maximize effectiveness and optimize efficiencies across all channels (for example, lean process)</b> |
+ | |||
+ | When creating a service, make sure the service delivery is modeled end-to-end to make sure the intended end users can actually reap the benefit of the service being offered. </br> | ||
+ | Go through the business process map step-by-step to ensure all points/nodes within the process behaves expectedly resulting in an intended outcome.</br> | ||
+ | Ensure all points/nodes within the process is optimized.</br> | ||
+ | Create all possible positive and negative scenarios that can possibly occur. </br> | ||
+ | Then go through different possible scenarios to ensure the service is still being delivered correctly, effectively and efficiently.</br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Summarize the delivery of value to customer across the architecture’s business ecosystem and the contribution of each stakeholder to the value | * Summarize the delivery of value to customer across the architecture’s business ecosystem and the contribution of each stakeholder to the value | ||
<b>Tools:</b> | <b>Tools:</b> | ||
+ | * Business Process Map | ||
* Business Impact Assessment | * Business Impact Assessment | ||
* Value Stream and Value Mapping | * Value Stream and Value Mapping | ||
+ | </br> | ||
+ | === Architect to be outcome‑driven and strategically aligned to the department and to the Government of Canada === | ||
+ | * <b>identify which departmental/GC business services, outcomes and strategies will be addressed</b> | ||
+ | |||
+ | To ensure that the Government of Canada provide the best service to its citizen, the services provided needs to be cohesive, ie. the work conducted by each department needs to complement each other to avoid overlap and to ensure continuance of service from one department to another.</br> | ||
+ | In order for a service to be meaningful, it needs to be tied into the driver of why the service is required and the outcome expected from a departmental mandate. | ||
+ | The service can affect the mandate directly/indirectly, however, one needs to justify the needs of the service in relation to the actual mandate of the department. | ||
− | + | <b>How to demonstrate that the project fulfils this framework:</b> | |
− | |||
− | <b>How to | ||
* Outline the GC/Departmental Strategies the architect aligns and/or implements | * Outline the GC/Departmental Strategies the architect aligns and/or implements | ||
* Describe the architecture's contribution to realizing the appropriate outcomes of the strategy | * Describe the architecture's contribution to realizing the appropriate outcomes of the strategy | ||
Line 52: | Line 78: | ||
* Outcomes (intimidate and ultimate) | * Outcomes (intimidate and ultimate) | ||
* Business services (External) | * Business services (External) | ||
− | * establish metrics for identified business outcomes throughout the life cycle of an investment | + | </br> |
− | <b>How to | + | * <b>establish metrics for identified business outcomes throughout the life cycle of an investment</b> |
+ | |||
+ | Once we know which outcome that a service is tied into, and whether or not it is directly affecting the outcome expected, we need to be able to justify the effort required to build the service vs. the outcome exerted by the service.</br> | ||
+ | We need a way to quantify the impact of this service / establish a metrics for this service. </br> | ||
+ | This is an important step to ensure that we can prioritize the effort correctly to identify and build the right service that is of high priority with the budget assigned.</br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* What are the metrics used to ensure that the outcomes are being realized | * What are the metrics used to ensure that the outcomes are being realized | ||
* What data is required for the metrics and identify how any gaps in the data will be addressed. | * What data is required for the metrics and identify how any gaps in the data will be addressed. | ||
<b>Tools:</b> | <b>Tools:</b> | ||
− | * Value Stream (Measure KPI linked to benefits outcomes and objectives | + | * Value Stream (Measure KPI linked to benefits outcomes and objectives) |
− | * translate business outcomes and strategy into business capability implications in the [[GC Enterprise Architecture/Business Capability Model| <b>GC Business Capability Model</b>]] to establish a common vocabulary between business, development, and operation | + | </br> |
− | <b>How to | + | * <b>translate business outcomes and strategy into business capability implications in the [[GC Enterprise Architecture/Business Capability Model| <b>GC Business Capability Model</b>]] to establish a common vocabulary between business, development, and operation</b> |
+ | |||
+ | Once we understood the outcomes and strategy to achieve the outcome, we need to translate it into business capability implications. Historically, the Business Capability Model is a common vocabulary between business, development and operation.</br> | ||
+ | When the plan conveyed is understood by the development and operation, it would be easier to obtain the system required. </br> | ||
+ | Having an open communication between the various teams also helps in getting the right solution that closely match the business requirement.</br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Outline the business capabilities involved in achieving each outcome | * Outline the business capabilities involved in achieving each outcome | ||
<b>Tools:</b> | <b>Tools:</b> | ||
Line 68: | Line 106: | ||
=== Promote horizontal enablement of the enterprise === | === 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 | + | * <b>identify opportunities to enable business services horizontally across the GC enterprise and to provide cohesive experience to users and other stakeholders</b> |
− | <b>How to | + | |
+ | In creating any service, we always need to go back to think about the users/stakeholders. Put ourselves in the users'/stakeholders' shoes. If we are at the receiving end of the service, what kind of experience do we get when we are trying to get the service. Does the user need to know where to get related services, or can we provide them with a seamless service, a cohesive service ? How do we provide a good experience to the users / stakeholders ? </br> | ||
+ | We need to start thinking more of an enterprise level, starting at the departmental level first. How can we enable this service across the department ? Is there any opportunity to reuse what we have in other areas of the department ? What do we need to do to leverage this process ? </br> | ||
+ | We need to plug in to community of practices, network of expertise or other working groups in order to exchange information, understand the various obstacles experienced by others, get lessons learned from others' experiences, share lessons learned, learn from others how they overcome similar obstacles in their work, share your solutions to others. </br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Summarize the departmental / GC opportunities where the architecture could be reused | * Summarize the departmental / GC opportunities where the architecture could be reused | ||
* Summarize departmental/GC architectures that impact or influence the ability of the user having a cohesive experience | * Summarize departmental/GC architectures that impact or influence the ability of the user having a cohesive experience | ||
Line 77: | Line 120: | ||
* Departmental Value Stream model | * Departmental Value Stream model | ||
* Projects to Value Stream Script | * Projects to Value Stream Script | ||
− | * reuse common business capabilities, processes and enterprise solutions from across government and private sector | + | </br> |
− | <b>How to | + | * <b>reuse common business capabilities, processes and enterprise solutions from across government and private sector</b> |
+ | |||
+ | If there is a business capabilities, processes or enterprise solution that can be utilized in creating the service, eg. perhaps during the exchange of information from working groups, community of practices, workshops or even from working with private sectors, that are proven to work, we should consider using it prior to inventing our own. </br> | ||
+ | This will optimize the time required to build the approach or the solution. Rather than having to proof the concept or solution actually works, use the ones that have a proven record. </br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Describe the plan and approach to standardize the realization of the business capability so it can be reused within the department and GC | * Describe the plan and approach to standardize the realization of the business capability so it can be reused within the department and GC | ||
<b>Tools:</b> | <b>Tools:</b> | ||
* Projects to value Stream Script | * Projects to value Stream Script | ||
* Business Capability Heat map | * Business Capability Heat map | ||
− | * publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services | + | </br> |
− | <b>How to | + | * <b>publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services</b> |
+ | |||
+ | Going back to the previous point on thinking at an enterprise level, one of the ways to enable a service that we build across the GC is by having it published in the open for other departments to see and re-use. Then and only we can create a cohesive horizontal enterprise services to create a cohesive experience to the users / stakeholders. </br> | ||
+ | |||
+ | <b>How to demonstrate that the project fulfils this framework:</b> | ||
* Outline the plan to allow other public sector organizations to reuse the common capability | * Outline the plan to allow other public sector organizations to reuse the common capability | ||
<b>Tools:</b> | <b>Tools:</b> | ||
Line 91: | Line 143: | ||
− | @fr| | + | @fr|__TOC__ |
+ | |||
+ | |||
+ | == ARCHITECTURE OPÉRATIONELLE == | ||
+ | L’architecture opérationnelle est un aspect essentiel à la réussite de la mise en œuvre de l’architecture cible de l’écosystème intégré du GC. La stratégie architecturale préconise une approche pan gouvernementale où les TI sont harmonisées avec les services opérationnels et les solutions sont fondées sur des composantes réutilisables mettant en œuvre des capacités opérationnelles afin d’offrir une expérience utilisateur cohérente. Par conséquent, il est essentiel de bien comprendre les services aux entreprises, les besoins des intervenants, les possibilités d’améliorer la cohésion et les possibilités de réutilisation à l’échelle du gouvernement. Par le passé, ces éléments n’étaient pas une priorité. On s’attend à ce que la culture et les pratiques en matière de TI doivent changer pour que l’architecture opérationnelle, en général, et ces éléments soient une priorité. | ||
+ | |||
+ | |||
+ | === Conception entièrement numérique des services pour répondre aux besoins des utilisateurs du gouvernement du Canada et des autres intervenants === | ||
+ | |||
+ | ==== * Identifier clairement les utilisateurs internes et externes et les autres intervenants et leurs besoins dans le cadre de chaque politique, programme et service opérationnel ==== | ||
+ | |||
+ | Pour s'assurer qu'un service sera en mesure de répondre aux besoins des utilisateurs et des parties prenantes, il doit comprendre à quels besoins il essaie de fournir le service, qui sont leurs utilisateurs et parties prenantes, à la fois internes et externes.<br> | ||
+ | |||
+ | Une fois les besoins, les utilisateurs et les parties prenantes définis, un fournisseur de services peut alors créer une cartographie des parties prenantes pour mieux comprendre la relation entre le service et les utilisateurs et parties prenantes, c'est-à-dire. comment un changement dans un composant affecte l'autre. <br> | ||
+ | |||
+ | À partir de là, le fournisseur de services peut effectuer une analyse des besoins de ses utilisateurs et parties prenantes pour développer un programme, une politique ou un service qui répond à leurs besoins (cette pratique peut également être connue sous le nom d'exigences des parties prenantes ou de cartographie des valeurs). <br> | ||
+ | |||
+ | Cet exercice peut également aider à définir les limites/portée du programme/politique/service pour mieux gérer les attentes de leurs utilisateurs/parties prenantes. <br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * résumer les besoins et les résultats de chaque intervenant clé externe et interne dans le cadre de l'architecture | ||
+ | * démontrer comment l'architecture est axée sur les besoins et les résultats des parties prenantes internes et externes | ||
+ | <b>Outils :</b> | ||
+ | * Business case | ||
+ | * Cartographie des parties prenantes (acteurs, rôles, unités organisationnelles) et exigences des parties prenantes | ||
+ | * Résultats | ||
+ | * Carte des processus métier | ||
+ | * Flux de valeur et cartographie de la valeur | ||
+ | </br> | ||
+ | |||
+ | ==== * Inclure les exigences de la politique qui s’appliquent à des utilisateurs en particulier et à d’autres groupes d’intervenants, comme l’accessibilité, l’analyse comparative entre les sexes plus et les langues officielles, dans la création du service ==== | ||
+ | Pour s'assurer qu'un service peut être utilisé par tous ses utilisateurs, il est important de noter les exigences spécifiques pour des utilisateurs spécifiques et, dans cette mesure, il est important de prendre note et d'appliquer la politique qui régit les normes de service lors de la fourniture du service à un groupes d'utilisateurs.</br> | ||
+ | Cela permettra à son tour au service d'être étendu et plus inclusif pour tous ses utilisateurs. | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Décrire quelles politiques contraignent l'architecture | ||
+ | * Décrire l'impact positif et négatif de la politique sur l'architecture pour répondre aux besoins des parties prenantes | ||
+ | * Décrire comment l'architecture prend en charge l'éventail complet de la conception de services et de l'expérience utilisateur | ||
+ | <b>Outils :</b> | ||
+ | * Principes de conception de l'interface utilisateur | ||
+ | </br> | ||
+ | |||
+ | ==== * Effectuer une évaluation de l’incidence algorithmique (EIA) pour appuyer les activités d’atténuation des risques lors du déploiement d’un système décisionnel automatisé conformément à la Directive sur la prise de décisions automatisée ==== | ||
+ | |||
+ | Lorsqu'un service dispose d'une automatisation dans le système pour la prise de decision, il est essential que le service effectue l'EIA pour s'assurer que le résultat de cette prise de décision est impartiél et équitable, et que l'impact de cette decision serait le mëme qu si la décision est prise manuellement, mais plus rapidement. </br> | ||
+ | L'utilisation de ce type de système doit suivre de près la directive sur la prise de décision automatisée. | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Fournir le niveau d'impact basé sur l'achèvement de l'AIA conceptuel | ||
+ | * Décrire comment l'architecture répondra aux recommandations de l'AIA | ||
+ | * Décrire comment l'architecture répond aux exigences de la directive pour le niveau d'impact | ||
+ | <b>Outils :</b> | ||
+ | * Résultats AIA (conceptuels) | ||
+ | </br> | ||
+ | |||
+ | ==== * Modéliser la prestation de services opérationnels du début à la fin afin d’assurer la qualité, de maximiser l’efficacité et d’optimiser les gains d’efficience dans tous les canaux (p. ex., processus allégé) ==== | ||
+ | |||
+ | Lors de la création d'un service, assurez-cous que la prestation de service est modélisée de bout en bout pour vous assurer que les utilisateurs peuvent réellement tirer parti du service offert. </br> | ||
+ | Parcourez la carte des processus métier étape par étape pour vous assurer que tous les points/nœuds au sein du processus se comportent comme prévu, entraînant le résultat escompté.</br> | ||
+ | Assurez-vous que tous les points/nœuds du processus sont optimisés.</br> | ||
+ | Créez tous les scénarios positifs et négatifs possibles qui peuvent éventuellement se produire. </br> | ||
+ | Ensuite, passez en revue différents scénarios possibles pour vous assurer que le service est toujours fourni correctement et efficacement.</br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Résumer la livraison de valeur au client à travers l'écosystème d'affaires de l'architecture et la contribution de chaque partie prenante à la valeur | ||
+ | <b>Outils :</b> | ||
+ | * Carte des processus métier | ||
+ | * Évaluation de l'impact sur l'entreprise | ||
+ | * Flux de valeur et cartographie de la valeur | ||
+ | </br> | ||
+ | |||
+ | === Architecte axé sur les résultats et stratégiquement aligné sur le Ministère et le gouvernement du Canada === | ||
+ | |||
+ | ==== * Déterminer les services opérationnels, les résultats et les stratégies du Ministère et du GC qui seront abordés ==== | ||
+ | |||
+ | Pour s’assurer que le gouvernement du Canada offre le meilleur service à ses citoyens, les services fournis doivent être cohérents, c’est-à-dire. le travail effectué par chaque ministère doit se compléter afin d’éviter les chevauchements et d’assurer la continuité du service d’un ministère à l’autre.</br> | ||
+ | Pour qu’un service soit significatif, il doit être lié au moteur de la raison pour laquelle le service est requis et au résultat attendu d’un mandat ministériel.</br> | ||
+ | Le service peut avoir une incidence directe ou indirecte sur le mandat, mais il faut justifier les besoins du service par rapport au mandat réel du ministère. | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre:</b> | ||
+ | * Décrire les stratégies du GC et du ministère que l’architecte aligne et/ou implémente | ||
+ | * Décrire la contribution de l’architecture à la réalisation des résultats appropriés de la stratégie | ||
+ | <b>Artifacts:</b> | ||
+ | * Conduisent | ||
+ | * Résultats (intimidants et ultimes) | ||
+ | * Services aux opérationnel (externe) | ||
+ | </br> | ||
+ | |||
+ | ==== * Établir des mesures pour les résultats opérationnels déterminés tout au long du cycle de vie d’un investissement ==== | ||
+ | |||
+ | Une fois que nous savons à quel résultat un service est lié et s'il affecte ou non directement le résultat attendu, nous devons être en mesure de justifier l'effort requis pour créer le service par rapport au résultat exercé par le service.</br > | ||
+ | Nous avons besoin d'un moyen de quantifier l'impact de ce service / d'établir une métrique pour ce service. </br> | ||
+ | Il s'agit d'une étape importante pour garantir que nous pouvons hiérarchiser correctement les efforts pour identifier et créer le bon service qui est de haute priorité avec le budget alloué.</br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Quelles sont les mesures utilisées pour s'assurer que les résultats sont atteints | ||
+ | * Quelles données sont requises pour les métriques et identifier comment les lacunes dans les données seront comblées. | ||
+ | <b>Outils :</b> | ||
+ | * Flux de valeur (mesurer les KPI liés aux bénéfices, aux résultats et aux objectifs) | ||
+ | </br> | ||
+ | |||
+ | ==== * Traduire les résultats opérationnels et la stratégie en répercussions sur les capacités opérationnelles dans le modèle des capacités opérationnelles du GC pour établir un vocabulaire commun entre les organisations, le développement et les opérations ==== | ||
+ | |||
+ | Une fois que nous avons compris les résultats et la stratégie pour y parvenir, nous devons les traduire en implications en termes de capacités commerciales. Historiquement, le Business Capability Model est un vocabulaire commun entre l'entreprise, le développement et l'exploitation.</br> | ||
+ | Lorsque le plan véhiculé est compris par l'aménagement et l'exploitation, il sera plus facile d'obtenir le système requis. </br> | ||
+ | Avoir une communication ouverte entre les différentes équipes aide également à obtenir la bonne solution qui correspond étroitement aux besoins de l'entreprise.</br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Décrire les capacités commerciales impliquées dans la réalisation de chaque résultat | ||
+ | <b>Outils :</b> | ||
+ | * Évaluation de l'impact sur l'entreprise | ||
+ | * BCM départemental | ||
+ | * GC BCM (correspondance à D BCM) | ||
+ | * Flux de valeur | ||
+ | |||
+ | === Promotion de l’habilitation horizontale de l’entreprise === | ||
+ | |||
+ | ==== * Repérer les possibilités de rendre possibles des services opérationnels horizontaux à l’échelle du GC et d’offrir une expérience cohésive aux utilisateurs et aux autres intervenants ==== | ||
+ | |||
+ | Dans la création de tout service, nous devons toujours revenir en arrière pour penser aux utilisateurs/parties prenantes. Se mettre à la place des utilisateurs/intervenants. Si nous sommes à l'extrémité de réception du service, quel genre d'expérience obtenons-nous lorsque nous essayons d'obtenir le service. L'utilisateur a-t-il besoin de savoir où obtenir des services associés, ou pouvons-nous lui fournir un service transparent, un service cohérent ? Comment offrir une bonne expérience aux utilisateurs / parties prenantes ? </br> | ||
+ | Nous devons commencer à penser davantage au niveau de l'entreprise, en commençant d'abord au niveau du département. Comment pouvons-nous activer ce service dans tout le département ? Y a-t-il une possibilité de réutiliser ce que nous avons dans d'autres domaines du département ? Que devons-nous faire pour tirer parti de ce processus ? </br> | ||
+ | Nous devons nous connecter à une communauté de pratiques, à un réseau d'expertise ou à d'autres groupes de travail afin d'échanger des informations, comprendre les différents obstacles rencontrés par les autres, tirer des leçons des expériences des autres, partager les leçons apprises, apprendre des autres comment ils surmontent des obstacles dans leur travail, partagez vos solutions avec les autres. </br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Résumer les opportunités départementales / GC où l'architecture pourrait être réutilisée | ||
+ | * Résumer les architectures départementales/GC qui ont un impact ou influencent la capacité de l'utilisateur à vivre une expérience cohérente | ||
+ | (quels sont les plans pour garantir que l'utilisateur a une expérience cohérente à travers ces architectures et l'écosystème) | ||
+ | <b>Outils :</b> | ||
+ | * Capacité d'affaires | ||
+ | * Modèle de flux de valeur départemental | ||
+ | * Projets à Value Stream Script | ||
+ | </br> | ||
+ | |||
+ | ==== * Réutiliser les capacités opérationnelles, les processus et les solutions d’entreprise communs provenant de l’ensemble du gouvernement et du secteur privé ==== | ||
+ | |||
+ | S'il existe des capacités, des processus ou une solution d'entreprise pouvant être utilisés pour créer le service, par ex. peut-être que lors de l'échange d'informations provenant de groupes de travail, de communautés de pratiques, d'ateliers ou même de travaux avec des secteurs privés, qui ont fait leurs preuves, devrions-nous envisager de les utiliser avant d'inventer les nôtres. </br> | ||
+ | Cela permettra d'optimiser le temps nécessaire à la construction de l'approche ou de la solution. Plutôt que d'avoir à prouver que le concept ou la solution fonctionne réellement, utilisez ceux qui ont fait leurs preuves. </br> | ||
+ | |||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Décrire le plan et l'approche pour normaliser la réalisation de la capacité commerciale afin qu'elle puisse être réutilisée au sein du ministère et du GC | ||
+ | <b>Outils :</b> | ||
+ | * Projets à valoriser Stream Script | ||
+ | * Carte thermique des capacités commerciales | ||
+ | </br> | ||
+ | |||
+ | ==== * Publier en mode ouvert tous les processus, les capacités et les solutions d’entreprise communs réutilisables pour que les autres puissent élaborer et tirer parti de services d’entreprise horizontaux cohérents ==== | ||
+ | |||
+ | Pour en revenir au point précédent sur la réflexion au niveau de l'entreprise, l'une des façons d'activer un service que nous construisons dans l'ensemble du GC est de le faire publier en public pour que les autres ministères puissent le voir et le réutiliser. Alors et seulement nous pouvons créer des services d'entreprise horizontaux cohérents pour créer une expérience cohérente pour les utilisateurs / parties prenantes. </br> | ||
+ | <b>Comment démontrer que le projet remplit ce cadre :</b> | ||
+ | * Décrire le plan pour permettre à d'autres organisations du secteur public de réutiliser la capacité commune | ||
+ | <b>Outils :</b> | ||
+ | * Carte thermique des capacités commerciales | ||
+ | * Projets à Value Stream Script | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
</multilang> | </multilang> |
Latest revision as of 14:41, 21 January 2022
Business architecture[edit | edit source]
Business architecture is a critical aspect for the successful implementation of the GC Enterprise Ecosystem Target Architecture. The architectural strategy advocates whole‑of‑government approach where IT is aligned to business services and solutions are based on re‑useable components implementing business capabilities in order to deliver a cohesive user experience. As such, it is essential that business services, stakeholder needs, opportunities to improve cohesion and opportunities for reuse across government be clearly understood. In the past these elements have not been a priority. It is expected that the IT culture and practices will have to change to make business architecture, in general, and these elements a primary focus.
Design services digitally from end‑to‑end to meet the Government of Canada users and other stakeholders’ needs[edit | edit source]
Clearly identify internal and external users and other stakeholders and their needs for each policy, program and business service[edit | edit source]
In order to ensure that a service will be able to meet the users and stakeholders' needs, it needs to understand what needs it is trying to provide service for, who their users and stakeholders are, both internal and external.
Once the needs, the users and stakeholders are defined, then a service provider can proceed to create a stakeholder mapping to further understand the relationship between the service and the users & stakeholders, ie. how a change in one component impacts the other.
From there, the service provider can conduct need analysis of its users and stakeholder to develop a program, a policy or a service that meets their needs (this practice may also be known as stakeholder requirements or value mapping).
This exercise can also help define the limitation/scope of the program/policy/service to better manage the expectation of their users/stakeholders.
How to demonstrate that the project fulfils this framework: * summarize the needs and outcome of each key external and internal stakeholders in scope of the architecture * demonstrate how the architecture is focused on the needs and outcomes of internal and external stakeholders Tools: * Business Case * Stakeholder (Actors, Roles, Organizational Units) Mapping & Stakeholder requirements * Outcomes * Business Process Map * Value Stream and Value Mapping
- include policy requirement applying to specific users and other stakeholder groups, such as accessibility, gender-based plus analysis, and official languages in the creation of the service
To ensure that a service can be used by all its users, it is important to note the specific requirements for specific users and to that extent, it is important to take note and apply the policy that governs the service standards when providing service to the specific user groups.
This will in turn enable the service to be far-reaching and more inclusive to all its users.
How to demonstrate that the project fulfils this framework: * Outline what policies constrain the architecture * Outline positive and negative impact the policy has on the architecture to meet the needs of the stakeholder * Outline how architecture supports full spectrum of service design and user experience Tools: * User Interface Design Principles
- perform Algorithmic Impact Assessment (AIA) to support risk mitigation activities when deploying an automated decision system as per Directive on Automated Decision-Making
When a service has an in-system developed automation for decision making, it is essential that the service perform AIA, to ensure that the result of this decision making is impartial and fair, and the impact of that decision would be the same as if the decision is made manually, only faster.
The use of this type of system must closely follow the Directive on Automated Decision-Making.
How to demonstrate that the project fulfils this framework: * Provide the impact level based on the completion of the conceptual AIA * Describe how the architecture will address the recommendations coming from the AIA * Describe how the architecture meets the directive's requirements for the impact level Tools: * AIA Results (Conceptual)
- Model end-to-end business service delivery to provide quality, maximize effectiveness and optimize efficiencies across all channels (for example, lean process)
When creating a service, make sure the service delivery is modeled end-to-end to make sure the intended end users can actually reap the benefit of the service being offered.
Go through the business process map step-by-step to ensure all points/nodes within the process behaves expectedly resulting in an intended outcome.
Ensure all points/nodes within the process is optimized.
Create all possible positive and negative scenarios that can possibly occur.
Then go through different possible scenarios to ensure the service is still being delivered correctly, effectively and efficiently.
How to demonstrate that the project fulfils this framework: * Summarize the delivery of value to customer across the architecture’s business ecosystem and the contribution of each stakeholder to the value Tools: * Business Process Map * Business Impact Assessment * Value Stream and Value Mapping
Architect to be outcome‑driven and strategically aligned to the department and to the Government of Canada[edit | edit source]
- identify which departmental/GC business services, outcomes and strategies will be addressed
To ensure that the Government of Canada provide the best service to its citizen, the services provided needs to be cohesive, ie. the work conducted by each department needs to complement each other to avoid overlap and to ensure continuance of service from one department to another.
In order for a service to be meaningful, it needs to be tied into the driver of why the service is required and the outcome expected from a departmental mandate.
The service can affect the mandate directly/indirectly, however, one needs to justify the needs of the service in relation to the actual mandate of the department.
How to demonstrate that the project fulfils this framework: * Outline the GC/Departmental Strategies the architect aligns and/or implements * Describe the architecture's contribution to realizing the appropriate outcomes of the strategy Artifacts: * Drivers * Outcomes (intimidate and ultimate) * Business services (External)
- establish metrics for identified business outcomes throughout the life cycle of an investment
Once we know which outcome that a service is tied into, and whether or not it is directly affecting the outcome expected, we need to be able to justify the effort required to build the service vs. the outcome exerted by the service.
We need a way to quantify the impact of this service / establish a metrics for this service.
This is an important step to ensure that we can prioritize the effort correctly to identify and build the right service that is of high priority with the budget assigned.
How to demonstrate that the project fulfils this framework: * What are the metrics used to ensure that the outcomes are being realized * What data is required for the metrics and identify how any gaps in the data will be addressed. Tools: * Value Stream (Measure KPI linked to benefits outcomes and objectives)
- translate business outcomes and strategy into business capability implications in the GC Business Capability Model to establish a common vocabulary between business, development, and operation
Once we understood the outcomes and strategy to achieve the outcome, we need to translate it into business capability implications. Historically, the Business Capability Model is a common vocabulary between business, development and operation.
When the plan conveyed is understood by the development and operation, it would be easier to obtain the system required.
Having an open communication between the various teams also helps in getting the right solution that closely match the business requirement.
How to demonstrate that the project fulfils this framework: * Outline the business capabilities involved in achieving each outcome Tools: * Business Impact Assessment * Departmental BCM * GC BCM (mapping to D BCM) * Value Stream
Promote horizontal enablement of the enterprise[edit | edit source]
- identify opportunities to enable business services horizontally across the GC enterprise and to provide cohesive experience to users and other stakeholders
In creating any service, we always need to go back to think about the users/stakeholders. Put ourselves in the users'/stakeholders' shoes. If we are at the receiving end of the service, what kind of experience do we get when we are trying to get the service. Does the user need to know where to get related services, or can we provide them with a seamless service, a cohesive service ? How do we provide a good experience to the users / stakeholders ?
We need to start thinking more of an enterprise level, starting at the departmental level first. How can we enable this service across the department ? Is there any opportunity to reuse what we have in other areas of the department ? What do we need to do to leverage this process ?
We need to plug in to community of practices, network of expertise or other working groups in order to exchange information, understand the various obstacles experienced by others, get lessons learned from others' experiences, share lessons learned, learn from others how they overcome similar obstacles in their work, share your solutions to others.
How to demonstrate that the project fulfils this framework: * Summarize the departmental / GC opportunities where the architecture could be reused * Summarize departmental/GC architectures that impact or influence the ability of the user having a cohesive experience (what are the plans to ensure user has a cohesive experience across these architectures and the ecosystem) Tools: * Business Capability * Departmental Value Stream model * Projects to Value Stream Script
- reuse common business capabilities, processes and enterprise solutions from across government and private sector
If there is a business capabilities, processes or enterprise solution that can be utilized in creating the service, eg. perhaps during the exchange of information from working groups, community of practices, workshops or even from working with private sectors, that are proven to work, we should consider using it prior to inventing our own.
This will optimize the time required to build the approach or the solution. Rather than having to proof the concept or solution actually works, use the ones that have a proven record.
How to demonstrate that the project fulfils this framework: * Describe the plan and approach to standardize the realization of the business capability so it can be reused within the department and GC Tools: * Projects to value Stream Script * Business Capability Heat map
- publish in the open all reusable common business capabilities, processes and enterprise solutions for others to develop and leverage cohesive horizontal enterprise services
Going back to the previous point on thinking at an enterprise level, one of the ways to enable a service that we build across the GC is by having it published in the open for other departments to see and re-use. Then and only we can create a cohesive horizontal enterprise services to create a cohesive experience to the users / stakeholders.
How to demonstrate that the project fulfils this framework: * Outline the plan to allow other public sector organizations to reuse the common capability Tools: * Business Capability Heat Map * Projects to Value Stream Script