2.2 Concevoir des solutions avec la réutilisation adaptative de la conception à l'esprit
Objectifs d'apprentissage
À la fin de cette section, vous serez en mesure de :
- Décrire comment les heuristiques de conception de solutions d'affaires et les motifs sont utilisés
- Discuter du rôle de l'architecture d'entreprise (EA) et des domaines d'architecture connexes
- Distinguer l'architecture d'entreprise de l'architecture de solution
Alors que la pensée informatique (computational thinking) emploie couramment une stratégie ascendante pour élaborer des composants bien structurés, la réutilisation adaptative de la conception adopte une méthodologie descendante, mettant l'accent sur la création et l'assemblage de solutions d'affaires en combinant des composants de conception existants. Un composant de conception (design component) est un élément réutilisable au sein d'un système plus vaste qui sert un objectif spécifique. Ces composants, semblables à des blocs de construction de solutions de bas niveau, nécessitent des modifications minimales. Cette approche, souvent appelée informatique à grande échelle, diverge des instructions algorithmeiques individuelles. Au lieu de composer des instructions pour l'exécution d'actions spécifiques par la décomposition de la pensée informatique, la réutilisation adaptative de la conception identifie les composants appropriés en fonction des exigences articulées des utilisateurs potentiels de la solution d'affaires, communément appelés parties prenantes. La ou les méthodes utilisées pour identifier ces besoins seront discutées en détail dans le Chapitre 9 Génie logiciel. Bien que la réutilisation adaptative de la conception considère généralement les conceptions algorithmiques comme des blocs de construction, elle utilise des techniques similaires (c'est-à-dire la décomposition, la pensée logique et la reconnaissance de formes, l'abstraction (abstraction)/généralisation, la modularisation, les tests et le débogage (debugging)) pour identifier et réutiliser les blocs de construction.
Les conceptions structurelles qui découlent de l'approche descendante de réutilisation adaptative de la conception pour la conception de solutions d'affaires sont appelées modèles d'architecture de solutions d'affaires. Une architecture de solution (solution architecture) est une conception structurelle destinée à répondre aux besoins des futurs utilisateurs de la solution. Lorsqu'une conception structurelle répond à ces besoins, elle est considérée comme « architecturalement saine » pour le problème en question. De plus, pour accélérer l'assemblage de solutions complètes, l'approche de réutilisation adaptative de la conception s'appuie sur des modèles architecturaux ou des assemblages de composants qui ont été développés à partir de conceptions antérieures. Lorsque la granularité de ces modèles architecturaux est au niveau des sous-systèmes, ils sont appelés architectures de famille de systèmes ou patrons d'architecture. Un patron d'architecture (architectural pattern) est une solution réutilisable à un problème récurrent dans la conception d'architecture logicielle. Le Chapitre 10 Gestion des architectures d'entreprise et de solution fournit plus de détails sur les différents niveaux de motifs et sur la manière de les organiser et de les enregistrer dans des catalogues de motifs pour faciliter la réutilisation.
Motifs de conception de solutions d'affaires
Les solutions d'affaires sont des stratégies/systèmes créés pour résoudre des défis spécifiques dans une entreprise. Elles visent à rendre les opérations plus efficaces, à améliorer la prise de décision et à contribuer au succès global. La création de solutions d'affaires est un processus multifacette et complexe, exigeant des connaissances dans différents domaines technologiques et le secteur d'activité pertinent. Une étape cruciale de cette procédure est la définition de l'architecture de la solution, servant de plan directeur, et guidant l'ensemble du processus de conception et de mise en œuvre. Un plan (blueprint) est un plan ou une conception détaillée qui décrit la structure, les composants et les spécifications d'un bâtiment, d'un produit, d'un système ou d'un processus.
La pensée informatique et la réutilisation adaptative de la conception sont simplement des méthodes utilisées pour amorcer et/ou accélérer la conception de solutions d'affaires en fournissant un ensemble complet de méthodes pour développer des solutions logicielles aux problèmes d'affaires, par exemple, la collecte des besoins en solutions, la construction et le déploiement de solutions clés en main. Ces solutions seront discutées en détail dans le Chapitre 9 Génie logiciel.
Comme expliqué précédemment, l'approche de la pensée informatique et de la réutilisation adaptative de la conception ne fournit que des techniques de haut niveau pour aider à créer ou à réutiliser des composants. En conséquence, l'une des critiques typiques est que ces approches sont trop vagues, car il n'est parfois pas clair en quoi elles diffèrent des autres formes de pensée. C'est pourquoi les experts dans l'application de ces méthodes sont généralement des architectes chevronnés qui peuvent reconnaître instinctivement quand divers types de composants peuvent être réutilisés. Lorsque vous demandez à Martin Fowler, expert en architecture d'entreprise chez Thoughtworks, pourquoi une architecture de solution d'affaires particulière est solide dans un contexte donné, il répondra souvent qu'elle lui « semble bonne ».
Plutôt que de considérer la pensée informatique et la réutilisation adaptative de la conception comme un ensemble de techniques de bonnes pratiques, il est préférable de les considérer comme des motifs de processus qui peuvent être appliqués et adaptés pour aider à créer un modèle d'architecture (architecture model) de solution d'affaires, qui représente le contenu de l'architecture d'application. Les motifs de processus peuvent, à leur tour, tirer parti d'autres motifs de processus plus ciblés. Lorsque les motifs de processus qui font partie intégrante du processus de création d'un produit de travail deviennent des règles empiriques, ils sont appelés heuristiques.
Pleins feux sur l'industrie
Étude de cas : Faciliter les achats en ligne grâce à une conception intelligente
Imaginez une boutique en ligne appelée SwiftShop. Ils avaient un problème. Même s'ils avaient beaucoup de produits formidables à acheter, les gens quittaient leur site web sans rien acheter. C'était comme avoir un magasin rempli de clients qui entraient et sortaient sans rien acheter ! Le défi commercial était que SwiftShop voulait rendre les achats sur son site web plus faciles et plus amusants. Ils voulaient que les gens restent plus longtemps, achètent plus et reviennent encore et encore. SwiftShop a décidé d'utiliser des astuces de conception intelligentes pour améliorer son site web et le rendre super facile à utiliser. Voici comment ils ont fait :
- Patrons de conception d'interface utilisateur (UI) : Navigation par fil d'Ariane : SwiftShop a ajouté des fils d'Ariane pour que les acheteurs puissent facilement voir où ils se trouvaient sur le site web et retrouver leur chemin s'ils se perdaient.
- Indicateurs de progression : Lors du paiement, SwiftShop a mis en place des barres de progression pour que les acheteurs sachent où ils en étaient dans le processus d'achat.
- Patrons de conception d'architecture de l'information (IA) : Tri de cartes : SwiftShop a demandé à de vrais acheteurs d'aider à organiser leurs produits. En triant des cartes et en demandant aux gens comment ils regrouperaient les choses, SwiftShop a facilité la recherche de ce que les clients cherchaient.
- Recherche à facettes (Faceted search) : SwiftShop a ajouté des filtres pour que les acheteurs puissent affiner leurs recherches par des attributs comme le prix, la taille et la marque.
- Patrons de conception d'interaction (IxD) (Interaction design (IxD) patterns) : Achat en un clic : Pour accélérer le processus d'achat, SwiftShop a permis aux utilisateurs enregistrés d'acheter en un seul clic.
- Recommandations personnalisées : SwiftShop a utilisé des algorithmes d'apprentissage automatique pour suggérer des produits que les clients pourraient aimer en fonction de ce qu'ils ont acheté auparavant.
- Résultats : Après avoir apporté ces modifications, SwiftShop a obtenu d'excellents résultats :
- Plus de personnes qui achètent : Grâce aux nouvelles fonctionnalités, plus de personnes ont fini par acheter des produits chez SwiftShop.
- Des acheteurs plus satisfaits : Les clients ont passé plus de temps sur le site web, ce qui signifie qu'ils ont davantage apprécié leurs achats.
- Plus de clients fidèles : Parce qu'il était plus facile de faire des achats, les gens ont continué à revenir chez SwiftShop encore et encore.
Ainsi, en utilisant des astuces de conception intelligentes comme la navigation par fil d'Ariane, les indicateurs de progression, le tri de cartes, la recherche à facettes, l'achat en un clic et les recommandations personnalisées, SwiftShop a fait de sa boutique en ligne un meilleur endroit pour faire des achats.
Stratification et modularisation
Deux heuristiques sont inhérentes à la conception de solutions d'affaires et à la création d'architectures de solutions d'affaires. Ces heuristiques sont connues sous le nom de stratification et de modularisation et peuvent être considérées comme des approches de conception suivies dans l'intention de répondre à des préoccupations architecturales.
La modularisation a déjà été introduite comme une technique de pensée informatique et de réutilisation adaptative de la conception.1 La stratification dans l'architecture de solution d'affaires implique la création de couches distinctes qui abstraient des aspects spécifiques de l'architecture globale. Cette heuristique (heuristic) permet la séparation des préoccupations entre les couches et améliore la modularité. Chaque couche comprend des composants, et une couche peut être constituée de plusieurs composants. Cette structure hiérarchique aide à organiser et à séparer différentes fonctionnalités ou responsabilités au sein de l'architecture, ce qui la rend plus facile à gérer et à comprendre.
La stratégie de stratification est basée sur le concept de séparation des différentes préoccupations. Cette méthode structure la conception logicielle en couches distinctes et empilées, chaque couche étant chargée de fonctions spécifiques. Généralement, les architectures de solutions d'affaires sont organisées en trois couches principales : la couche de présentation, la couche de logique métier et la couche de gestion des données. La couche de présentation (presentation layer) est le point de contact de l'utilisateur, gérant l'interface utilisateur (UI) et offrant l'expérience utilisateur (UX) (user experience (UX)), qui est l'expérience globale qu'une personne a lorsqu'elle interagit avec un produit, un service ou un système. La couche de logique métier (business logic layer) contient la logique métier de la solution ou de l'application d'affaires, séparant l'UI/UX des calculs centrés sur l'entreprise. Cette séparation offre la flexibilité d'ajuster les opérations commerciales à mesure que les besoins évoluent sans perturber les autres composants du système. Bien que non liée à un domaine spécifique, la couche de gestion des données (data management layer) est responsable de l'interaction avec les systèmes de stockage persistant comme les bases de données et divers mécanismes de traitement des données. Dans une architecture en couches, les informations et les commandes circulent à travers chaque couche, améliorant le niveau d'abstraction (abstraction) de la conception, qui désigne la granularité ou le détail avec lequel un système est représenté. Malgré son approche structurée et ses avantages en matière d'abstraction, les logiciels conçus de cette manière en couches peuvent tendre vers une construction monolithique, ce qui pourrait rendre les modifications difficiles. L'architecture en couches peut conduire à des couches étroitement connectées dans les logiciels, ce qui rend difficile de modifier une partie sans affecter les autres. Cette connexion étroite peut également rendre plus difficile la mise à jour ou l'expansion du logiciel.
Une structure monolithique (monolithic structure) est un type de système ou d'application où toutes les parties sont étroitement combinées en une seule unité. Cette configuration signifie que tout, de l'interface utilisateur à la gestion des données et au traitement, est interconnecté au sein d'une seule grande application logicielle. Bien que cela puisse rendre le système plus facile à configurer et à gérer initialement, cela signifie également que la modification d'une partie peut nécessiter des changements dans l'ensemble du système, le rendant moins flexible. Comme illustré à la Figure 2.10, il existe de nombreuses variations plus récentes d'architectures en couches qui offrent également des capacités complémentaires, telles que les architectures à plusieurs niveaux, les architectures orientées services et les architectures de microservices.2
Une couverture détaillée de ces architectures spécifiques ne fait pas partie de la portée de ce chapitre. Elles seront discutées plus en détail dans plusieurs chapitres ultérieurs. Il est fondamental de comprendre que chaque modèle d'architecture logicielle est conçu pour relever les défis clés rencontrés dans ses modèles précédents. Être bien familiarisé avec diverses approches architecturales vous permet de concevoir une architecture robuste et efficace pour votre projet spécifique. Bien qu'aucune architecture logicielle ne puisse prétendre à une perfection absolue, une approche peut être considérée comme très appropriée ou « relativement parfaite » si elle s'aligne bien avec les exigences et les objectifs spécifiques de votre projet actuel.
Domaines d'architecture au niveau de l'entreprise
L'architecture au niveau de l'entreprise englobe divers domaines qui définissent la structure, les composants et les opérations d'une organisation entière. Ces domaines fournissent un cadre complet pour la gestion d'une entreprise.
Jusqu'à présent, nos efforts ont été centrés sur l'emploi de la méthodologie de réutilisation adaptative de la conception pour construire des architectures de solutions d'affaires adaptées à des projets individuels. Dans ce cadre, nous visons à faciliter la conversion des exigences de solution en un concept de solution cohérent, des aperçus complets des systèmes d'affaires et informatiques, et une collection d'activités de mise en œuvre, formant essentiellement le plan de projet. Cependant, parce que l'approche de réutilisation adaptative de la conception est descendante, il est possible de commencer à l'appliquer à un niveau supérieur. Le niveau de l'entreprise est généralement le niveau le plus élevé d'une organisation, et il couvre toutes les fonctions stratégiques et tactiques. Une entreprise s'étend souvent sur plusieurs organisations.
L'architecture d'entreprise (EA) est apparue au début de l'ère de l'information dans les années 1970, et divers cadres d'architecture d'entreprise (EAF) ont été développés et utilisés au fil du temps. The Open Group Architecture Framework (TOGAF) est l'un de ces cadres. Selon TOGAF, un domaine d'EA (EA domain) représente les architectures d'affaires, de données, d'applications et de technologie. Bien que les cadres spécifiques puissent varier, le Tableau 2.3 illustre les domaines d'architecture d'entreprise courants.
| Architecture | Objectif | Composants |
|---|---|---|
| Architecture d'affaires | Définit la stratégie, les objectifs, les processus et les fonctions d'affaires de l'organisation | Modèles d'affaires, processus, capacités et structure organisationnelle |
| Architecture de l'information | Gère les données et les actifs informationnels | Modèles de données, diagrammes de flux d'informations, gouvernance des données, normes de données et métadonnées |
| Architecture d'application | Conçoit et organise les applications logicielles | Portefeuille d'applications, intégration d'applications et conception d'interfaces |
| Architecture technologique | Spécifie le matériel, les logiciels et l'infrastructure technologique | Serveurs, réseaux, bases de données, services infonuagiques, protocoles de sécurité |
| Architecture de sécurité | Assure la protection des actifs informationnels, des systèmes et des réseaux | Politiques de sécurité, contrôles d'accès et mécanismes de chiffrement |
| Architecture d'intégration | Facilite la communication et l'échange de données sans heurts | Intergiciels, systèmes de messagerie et motifs d'intégration |
| Architecture de processus | Définit et optimise les processus d'affaires | Modèles de processus, diagrammes de flux de travail et métriques de performance |
L'EA adopte une perspective holistique, traitant l'entreprise comme un système unifié ou un système de systèmes. Son objectif principal est d'intégrer des processus disparates, manuels et automatisés, dans un environnement cohérent, réactif au changement et aligné sur la stratégie commerciale de l'entreprise. L'EA implique la conception de systèmes complets pour soutenir les processus d'affaires, allant au-delà des systèmes logiciels ou technologiques individuels. En standardisant et en intégrant les processus fondamentaux à travers les différentes divisions commerciales, l'EA facilite l'alignement et l'optimisation des opérations à l'échelle de l'entreprise.
L'architecture de solution complète l'EA en adaptant des solutions système spécifiques pour répondre aux besoins commerciaux et technologiques définis. Tandis que l'EA se concentre sur la définition de la situation actuelle et des objectifs futurs de l'organisation, l'architecture de solution assure la disponibilité en temps voulu de systèmes appropriés pour satisfaire les exigences commerciales.
Les architectures TOGAF favorisent la réutilisation des blocs de construction mais manquent d'une méthode prescriptive pour les gérer. La réutilisation adaptative de la conception devient précieuse dans ce contexte, impliquant la compréhension des architectures d'entreprise et l'adaptation de modèles et d'implémentations préexistants. La gestion détaillée de l'EA, des architectures de solution et l'exploitation des EAF sont explorées plus en détail dans le Chapitre 10 Gestion des architectures d'entreprise et de solution.
Architecture et modèle d'affaires d'entreprise
L'architecture d'affaires d'entreprise est un cadre complet qui définit la structure et le fonctionnement d'une organisation entière. Elle est liée aux activités commerciales de l'entreprise et aux documents et diagrammes qui décrivent la structure architecturale de cette entreprise. Elle caractérise les aspects processus, organisation et localisation de l'EBA en question. Les EBA se composent généralement de différentes capacités commerciales regroupées en catégories, comme illustré à la Figure 2.11. Dans cet exemple, les catégories d'échantillon incluent le produit, les ventes et le service. Les capacités commerciales présentées sous les différentes catégories ont généralement leurs propres modèles d'affaires qui font partie du modèle d'affaires global de l'organisation. Notez qu'il est clair d'après ce diagramme que les heuristiques de stratification et de modularisation jouent un rôle important dans la structuration des modèles de capacités.
La modélisation de l'architecture d'affaires aide à extraire le modèle d'affaires global de la capacité d'une organisation, qui comprend l'ensemble des processus sous-jacents nécessaires pour opérer les diverses capacités de l'organisation.
Un modèle d'affaires (business model) est un cadre qui décrit comment une entreprise crée, livre et capture de la valeur. Il couvre la manière dont une entreprise génère des revenus, identifie son public cible et définit les produits/services qu'elle propose. Le modèle d'affaires comprend le modèle d'organisation, de localisation et de processus, comme décrit dans les sections suivantes. Il peut inclure des modèles supplémentaires, tels que le modèle financier, qui ne seront pas abordés ici. Pour illustrer ce qu'un modèle d'affaires implique concrètement, nous nous concentrerons sur une capacité typique de trading d'instruments financiers, qui pourrait être l'une des capacités du modèle d'affaires global d'une organisation opérant dans l'industrie des marchés mondiaux. Les modèles d'organisation, de localisation et de processus sont généralement représentés à un niveau d'abstraction logique, qui est la représentation la plus détaillée pour ces types de modèles. Notez à nouveau que les heuristiques de stratification et de modularisation jouent un rôle important dans la structuration de ces modèles.
Modèle organisationnel
Le modèle organisationnel est la structure et la conception d'une organisation, décrivant comment les rôles, les responsabilités et les relations sont définis. Il fournit un cadre pour comprendre comment les diverses composantes au sein de l'organisation interagissent et collaborent pour soutenir ses fonctions. De plus, il offre des définitions claires des rôles et une matrice de mappage des processus aux rôles.
Les définitions de rôles encapsulent un ensemble de capacités fonctionnelles essentielles pour qu'un individu puisse gérer un ou plusieurs processus d'affaires distincts, comme indiqué au Tableau 2.4. Il est courant qu'un individu remplisse plusieurs rôles. La matrice processus/rôle délimite quels rôles d'affaires sont responsables de processus d'affaires particuliers. Typiquement structurée au niveau du processus métier élémentaire, cette matrice peut également être étendue à des niveaux plus généraux lorsque cela est bénéfique.
| Titre du rôle | Responsabilités | Rapports |
|---|---|---|
| DBA (administrateur de base de données) | Gérer et surveiller les activités de la base de données | Responsable informatique ou VP de l'informatique |
| DSI (directeur des systèmes d'information) | Leadership informatique global | PDG (président-directeur général) |
| Employé RH | Opérations des ressources humaines | Responsable RH |
En général, la matrice des rôles est une représentation visuelle ou un tableau qui décrit les différents rôles au sein d'une organisation et leurs responsabilités respectives. Elle aide à clarifier et à communiquer la répartition des tâches et des autorités entre les différentes positions ou départements.
Dans un modèle d'affaires de négociation d'instruments financiers, divers rôles contribuent au fonctionnement global de l'organisation, comme indiqué au Tableau 2.5.
| Titre | Rôles et responsabilités |
|---|---|
| Traders |
|
| Équipe de vente |
|
| Opérations de back-office3 |
|
| Gestionnaires de risques |
|
| Conseillers juridiques |
|
| Professionnels de la technologie |
|
| Ressources humaines |
|
En plus de ces titres, il existe deux couches de gestion principales : la haute direction et la gestion des systèmes. La haute direction est chargée de la supervision de divers secteurs au sein de l'organisation, englobant de nombreuses unités commerciales, départements d'opérations et autres domaines clés. Ce niveau comprend des rôles tels que les directeurs de division, les directeurs de groupe et les gestionnaires de risques, qui assurent collectivement le bon fonctionnement et la direction stratégique de l'entreprise. D'autre part, la gestion des systèmes est dédiée au fonctionnement routinier du système de trading. Cela inclut des postes comme le gestionnaire de site, le gestionnaire de maintenance des systèmes, le gestionnaire de contenu et le personnel du service d'assistance, qui collaborent tous quotidiennement pour s'assurer que le système de trading est opérationnel, bien entretenu et convivial.
Modèle de processus
Le processus d'affaires est une série de tâches, d'activités ou d'étapes interdépendantes effectuées de manière coordonnée au sein d'une organisation pour atteindre un objectif commercial spécifique. Le modèle de processus d'affaires peut être encapsulé dans un cadre de hiérarchies de processus d'affaires. Ces hiérarchies illustrent visuellement le résultat de la décomposition de processus complexes, une méthode connue sous le nom de décomposition de processus. Cette décomposition (decomposition) est effectuée jusqu'à ce qu'elle atteigne le processus métier élémentaire (EBP) (elementary business process (EBP)), qui est une activité fondamentale et indivisible au sein d'une entreprise qui n'est pas subdivisée en processus plus petits (c'est-à-dire la plus petite unité d'activité commerciale). La Figure 2.12 illustre un exemple de modélisation de processus d'affaires pour la création d'une commande.
Les EBP possèdent des caractéristiques distinctes qui les rendent remarquables dans le contexte des opérations commerciales. Ils sont considérés comme significatifs et candidats à une analyse approfondie. Les EBP sont généralement associés aux actions d'un seul utilisateur, soulignant une responsabilité ciblée au sein de l'organisation. De plus, ces processus peuvent englober des activités manuelles et automatisées, reflétant la nature diverse des flux de travail commerciaux contemporains. L'implication de l'utilisateur dans les EBP est concentrée à un moment précis, rationalisant l'aspect temporel de ces activités. La préservation des distinctions commerciales cruciales entre les processus assure clarté et cohérence. Enfin, les EBP visent à laisser le modèle d'entité (entity model) conceptuel dans un état cohérent, contribuant à l'intégrité des données et maintenant une représentation fiable des entités et des relations de l'organisation où le modèle d'entité représente les divers objets ou concepts et leurs relations au sein d'un système. Une cartographie des processus (process map) affiche l'ordre des processus choisis parmi les hiérarchies de processus, en soulignant leur connexion aux rôles responsables de leur exécution. Une hiérarchie des processus d'affaires (business process hierarchy) organise les activités d'une entreprise, des processus larges et généraux aux tâches spécifiques, ce qui facilite la gestion et l'amélioration du fonctionnement de l'entreprise. La Figure 2.13 illustre une hiérarchie de processus d'affaires de haut niveau qui pourrait être utilisée pour tout processus d'affaires manufacturier.
Au sommet de la hiérarchie, il y a trois processus d'affaires fondamentaux :
- Gestion des clients : Ce processus joue un rôle central, interagissant avec diverses activités conçues pour acquérir, retenir et développer les relations clients. Il se concentre sur tous les aspects de l'interaction client. Il y a trois sous-sections comme suit :
- 1.1. Client cible : Les clients découvrent d'abord une entreprise et ses offres grâce à divers efforts de marketing. Ils évaluent ensuite ces offres pour décider si elles répondent à leurs besoins, ce qui conduit à une décision d'achat. Après l'achat, les clients peuvent avoir besoin d'un support, qui est fourni pour assurer la satisfaction. Une expérience positive peut transformer ces clients en acheteurs fidèles et en défenseurs de l'entreprise et maintenir de solides relations clients.
- 1.2. Équipe de prospection : Cela implique d'identifier les prospects potentiels et d'évaluer leur probabilité d'achat. Cela comprend :
- 1.2.1. Prospection : Cela inclut de contacter les clients avec des promotions et des publicités.
- 1.3. Prise de décision : Cette étape se concentre sur la création et l'évaluation de prototypes de produits pour s'assurer qu'ils répondent aux normes requises avant le lancement.
- Développement de produits : Cela englobe l'ensemble du cycle de vie d'un produit, de la génération d'idées initiales à la conception et au développement jusqu'au lancement. Il y a quatre sous-sections :
- 2.1. Conception de produits : Cela se concentre sur la création et l'évaluation des conceptions de produits pour s'assurer qu'elles répondent aux normes requises avant les tests.
- 2.2. Assurance qualité : L'AQ implique de vérifier la qualité de la conception et de la faire correspondre aux exigences listées.
- 2.3. Définir les matières premières : Les matières premières sont les substances de base nécessaires à la fabrication des produits. Il peut s'agir de choses tirées de la nature, comme le bois, le pétrole ou les métaux, qui sont utilisées dans la fabrication de tout, des bâtiments aux vêtements et à la nourriture. Le type de matière première utilisée affecte la façon dont les produits sont fabriqués, leur qualité et leur coût. Cela comprend :
- 2.3.1. Gestion des matériaux : Une bonne gestion des matériaux est importante pour les entreprises afin de s'assurer qu'elles en ont suffisamment pour répondre à la demande, maintenir la production en douceur et réduire les déchets, rendant l'ensemble du processus plus efficace et durable.
- 2.4. Planification des tests : La rédaction d'instructions détaillées pour la mise en place et la conduite de tests d'utilisabilité, y compris la manière de sélectionner les participants et d'enregistrer les commentaires, est importante et comprend :
- 2.4.1. Directives de test : Règles qui aident à garantir qu'un produit ou un service fonctionne bien et est sûr avant d'être mis à disposition ou utilisé. Ces règles guident la manière de tester l'article, les outils à utiliser et les problèmes à rechercher, visant à résoudre tout problème trouvé. L'objectif principal est de s'assurer que le produit fait ce qu'il est censé faire et répond aux normes de qualité.
- 2.4.2. Directives de qualité : Ce sont des règles qui aident à garantir que les produits ou services sont constamment bons et répondent aux besoins des clients. En suivant ces directives, les entreprises visent à satisfaire leurs clients, à réduire les erreurs et à travailler plus efficacement. Cela implique de vérifier et d'améliorer régulièrement la façon dont les choses sont faites pour s'assurer qu'elles répondent à des normes élevées.
- Commande à l'encaissement : Il s'agit d'un flux d'affaires complet qui commence lorsqu'un client passe une commande et se termine lorsque le paiement est reçu et enregistré :
- 3.1. Gestion des commandes : Le processus commence lorsqu'un client passe une commande via une méthode choisie, telle qu'une plateforme en ligne, un appel téléphonique ou un représentant commercial.
- 3.2. Gestion du crédit : Une vérification de crédit est effectuée pour s'assurer que le client a le crédit nécessaire pour effectuer l'achat. Si le client passe la vérification de crédit, la commande est approuvée pour le traitement. Sinon, elle peut être retenue jusqu'à ce que le paiement soit sécurisé ou annulée.
- 3.3. Exécution : Les produits requis sont alloués à partir de l'inventaire. Si les produits ne sont pas disponibles, cela peut déclencher une commande en attente ou un processus de fabrication.
- 3.4. Paiement : Le client effectue un paiement en utilisant l'une des méthodes de paiement acceptées.
- 3.4.1. Facturation : Cette étape commencera si le client paie avec un bon de commande (c'est-à-dire que le client peut utiliser différentes méthodes de paiement telles que la carte de crédit ou le virement bancaire). Une fois la commande expédiée, une facture est générée et envoyée au client, détaillant le montant payé et/ou dû pour les produits ou services fournis.
- 3.5. Rapports : Des rapports sont générés pour analyser le volume des ventes, l'efficacité de la collecte des paiements et les habitudes d'achat des clients.
Les définitions des EBP comprennent de brèves explications des activités au sein de chaque processus. Ces descriptions, lorsqu'elles sont associées au flux de processus approprié, servent de base pour progresser vers des étapes de conception complexes et aident à la création continue de spécifications fonctionnelles. De plus, elles mettent en évidence toutes les hypothèses établies lors du développement architectural, délimitent les règles pour les décisions qui nécessitent une intervention manuelle et, le cas échéant, fournissent des détails de référence croisée pour assurer la compatibilité avec les exigences fonctionnelles de l'application en cours de développement.
L'attribution de numéros aux EBP reflète leur placement au sein de structures hiérarchiques, permettant leur liaison à divers produits de travail dans les domaines commercial, organisationnel et spécifique à la localisation, ainsi qu'aux modèles pertinents.
Les diagrammes de cartographie des processus illustrent l'ordre des processus choisis parmi les hiérarchies de processus, en se concentrant sur leur connexion aux rôles responsables de leur exécution. Les cartographies des processus mettent spécifiquement en évidence les processus clés qui revêtent une importance commerciale particulière. Bien que chaque processus présenté dans une cartographie des processus soit également inclus dans la hiérarchie des processus d'affaires, tous les processus de la hiérarchie ne sont pas représentés dans les cartographies des processus. Les diagrammes de flux de processus peuvent représenter divers éléments, tels que les événements commerciaux déclenchant un processus, les résultats de l'achèvement d'un processus, les processus eux-mêmes, la séquence des étapes du processus, les interruptions du flux de processus, les possibilités de répétition, les choix, l'exclusivité entre les processus et toute note supplémentaire. La Figure 2.14 illustre un diagramme de cartographie des processus pour un processus d'affaires de la commande à l'encaissement.
Figure 2.15 illustre le processus de gestion des commandes au sein d'une entreprise. Il commence par la gestion des commandes, où les commandes sont reçues et vérifiées pour leur exactitude. Vient ensuite la gestion du crédit, qui évalue le crédit du client pour s'assurer qu'il peut satisfaire aux exigences de paiement. Le processus passe ensuite à l'exécution, où la commande est préparée et expédiée. Ensuite, pendant le paiement, le client est facturé et le paiement est traité. La facturation est une partie détaillée de cette étape, où une facture est générée et envoyée au client. La dernière étape est le reporting, où l'entreprise génère des rapports sur les volumes de ventes et les transactions financières. Ce processus se termine une fois toutes les étapes achevées, garantissant que chaque commande est traitée efficacement du début à la fin.
Modèle de localisation
Un modèle de localisation fait référence à un ensemble de règles utilisées pour analyser et prendre des décisions liées au positionnement d'entités, d'activités ou de ressources. Le modèle de localisation conceptuel montre comment les processus d'affaires seront distribués géographiquement. Au sein du modèle de localisation, les définitions des types de localisation spécifient l'identification des localisations en fonction de leur type et de leur zone géographique générale. De plus, le modèle de localisation contient une matrice illustrant la relation entre les processus et les localisations, indiquant les types de localisation spécifiques où chaque processus a lieu.
Architecture technique d'entreprise
L'architecture technologique d'entreprise est un cadre complet qui définit la structure, les composants et les interrelations des systèmes technologiques d'une organisation pour soutenir ses processus et objectifs commerciaux. En général, l'ETA guide le développement et le support des systèmes d'information4 et de l'infrastructure technologique d'une organisation. Par conséquent, elle caractérise les architectures d'application, de données et d'infrastructure technologique de l'organisation et décrit leurs modèles. La technologie prend en charge l'exécution des services de systèmes d'information, qui à leur tour prennent en charge les fonctions (function) commerciales et les services connexes. Les modèles d'architecture d'application, de données et d'infrastructure technologique peuvent être décrits via des plans à différents niveaux d'abstraction (abstraction), y compris la présentation, le conceptuel, le logique et le physique. Les heuristiques de stratification et de modularisation jouent un rôle important dans la structuration de ces modèles.
Le niveau d'abstraction indique la mesure dans laquelle une conception est éloignée des détails technologiques tangibles. Ce niveau d'abstraction peut différer selon les divers domaines architecturaux, mais quatre niveaux principaux sont largement reconnus :
- Présentation : À ce niveau, l'architecture est simplifiée sous une forme pour rationaliser la communication des idées essentielles, en particulier aux dirigeants d'entreprise. La distillation de diagrammes architecturaux complexes en visuels plus simples et de haut niveau garantit que les messages clés sont transmis efficacement.
- Conceptuel : Ce niveau offre une vue plus structurée de l'architecture, omettant délibérément de nombreux détails. La raison de ne pas inclure certains détails est qu'ils peuvent ne pas être pertinents pour l'objectif visé du diagramme ou qu'ils n'ont pas encore été décidés.
- Logique : L'architecture est décrite en détail mais reste incertaine quant aux technologies spécifiques. Elle vise à donner un aperçu complet sans s'engager sur les technologies particulières qui seront utilisées pour la construction finale.
- Physique : Ce niveau se concentre sur les spécificités technologiques réelles utilisées ou à utiliser dans la réalisation de l'architecture, ce qui en fait la représentation la plus concrète des quatre.
Concepts en pratique
Industrie manufacturière
Les opérations commerciales sont couramment articulées à travers un cadre de chaîne de valeur, un concept issu des pratiques manufacturières. De manière analogue à l'industrie manufacturière où des matières premières comme l'acier sont transformées en divers composants, chaque étape de la chaîne de valeur joue un rôle dans la création d'un produit fini, tel qu'une voiture. Dans notre approche, nous avons utilisé l'heuristique de modularisation pour décomposer les opérations commerciales en étapes distinctes constituant les éléments d'une chaîne de valeur. De plus, l'heuristique de stratification a été appliquée pour structurer la chaîne de valeur en couches d'éléments. Chaque couche de ce modèle s'appuie sur la sortie de la couche précédente pour exécuter sa fonction spécifique. Cette méthodologie améliore la compréhension de la manière dont la valeur est ajoutée séquentiellement tout au long du processus d'affaires.
Modèle d'architecture d'application
L'architecture d'application (application architecture) est un sous-ensemble de l'architecture de solution d'entreprise qui comprend un processus pour architecturer et concevoir l'architecture d'application ainsi que le modèle d'architecture d'application réel, qui représente le contenu de l'architecture d'application. L'architecture d'application aide les organisations à décider comment investir dans de nouveaux logiciels et systèmes. Elle garantit que tout nouveau logiciel examiné, conçu ou mis en service peut bien fonctionner avec les systèmes que l'organisation possède déjà. Cela inclut les logiciels entièrement nouveaux, les mises à jour d'anciens logiciels, l'amélioration d'anciens logiciels, ainsi que l'achat et la mise à jour de progiciels.
Figure 2.16 illustre un modèle d'architecture d'application conceptuel du exemple de modèle d'affaires de négociation qui a été introduit précédemment dans cette section. L'objectif d'une architecture d'application conceptuelle est de démontrer comment les membres de l'organisation interagissent avec l'architecture d'application depuis différents emplacements lors de l'invocation de processus d'affaires. Cet exemple illustre trois bureaux distincts accueillant un large éventail d'utilisateurs, y compris la direction, le trading, l'informatique et d'autres.
Figure 2.17 pousse un peu plus loin l'architecture d'application de trading conceptuelle et décrit à quoi pourrait ressembler l'une des architectures d'application alternatives au niveau logique. L'objectif de l'architecture d'application logique est d'identifier les différents blocs fonctionnels au sein de l'architecture sans entrer dans les détails de la façon dont ils se connectent et/ou s'utilisent mutuellement.
Réfléchissez-y
Architecture d'affaires d'entreprise
Quel est le mécanisme qui déclenche la création de domaines d'organisation, de localisation et de processus pour décrire une architecture d'affaires ? Comment la décomposition (decomposition) aide-t-elle à décrire les architectures technologiques ?
Indice : Le domaine de l'organisation se concentre sur la structure, les rôles, les responsabilités et les relations au sein de l'entreprise. Le domaine de la localisation traite des lieux physiques ou virtuels où se déroulent les activités commerciales. Le domaine des processus explore les processus d'affaires qui animent la chaîne de valeur et les activités opérationnelles.
Le processus implique de diviser un système ou une architecture en éléments plus petits et plus discrets, ce qui facilite l'analyse, la compréhension et la communication efficace. Les architectures technologiques dans les entreprises peuvent être très complexes, impliquant de nombreux composants et interdépendances. La décomposition simplifie cette complexité en décomposant l'architecture en morceaux plus petits et compréhensibles. Chaque composant peut ensuite être analysé et compris indépendamment.
Figure 2.18 est une vue simplifiée du modèle d'architecture d'application de trading logique qui fournit des légendes pour expliquer ce que les différentes fonctions sont censées accomplir. Il est de bonne pratique de documenter les fonctions de cette manière. Il est également de bonne pratique de fournir un diagramme supplémentaire qui inclut des légendes identifiant les technologies tierces réelles utilisées pour implémenter les différentes fonctions.
Modèle d'architecture de données
Un modèle d'architecture de données (data architecture model) est un cadre conceptuel qui décrit comment une organisation structure, organise et gère ses actifs de données. L'architecture de données fait partie de l'architecture de solution d'entreprise plus large. Elle englobe le processus de conception des modèles d'architecture d'information et de données réels, représentant le contenu au sein de l'architecture de données. Ce cadre aide les organisations à planifier stratégiquement les investissements dans les solutions de gestion des données et les systèmes associés. Les solutions de gestion des données évaluées, conçues et livrées doivent coexister harmonieusement avec celles déjà établies, gérant les bases de données nouvellement développées ainsi que les extensions de bases de données existantes.
En général, l'information peut être extraite des données brutes, la connaissance peut être tirée de l'information, et la sagesse peut être obtenue de la connaissance. La plupart des entreprises désignent la relation entre les données, l'information, la connaissance et la sagesse comme la pyramide du savoir. Une richesse d'informations supplémentaires liées à la gestion des données et à la pyramide du savoir est fournie dans le Chapitre 8 Gestion des données. La modélisation de l'information est le processus utilisé pour décrire les métadonnées nécessaires à la compréhension des données, des processus et des règles pertinents pour l'entreprise, comme illustré à la Figure 2.19.
Dans le processus collaboratif de modélisation de données (data modeling), les parties prenantes informatiques et commerciales établissent une compréhension partagée des termes commerciaux essentiels, connus sous le nom d'entités, qui finissent généralement par être représentés comme des tables contenant des données dans un système de gestion de base de données relationnelle. Cela implique de définir les attributs qui caractérisent ces termes et d'établir les relations entre eux. La capacité à maintenir et à documenter le modèle de données fait partie intégrante de la capacité d'une organisation à répondre aux divers besoins d'acquisition de données à travers des projets commerciaux critiques. Essentiellement, un modèle de données bien entretenu sert d'élément fondamental pour assurer la cohérence et l'efficacité dans la gestion des diverses exigences en matière de données.
Figure 2.20 est un exemple d'architecture de données conceptuelle au niveau de l'entreprise pour une compagnie d'assurance. L'objectif de l'architecture de données conceptuelle d'entreprise est d'illustrer les différents types de référentiels de données et la manière dont les données sont collectées et gérées au sein de l'entreprise.
Concernant les données qui circulent à travers l'architecture d'application, il peut y avoir de nombreux types de données et diverses façons de représenter les modèles d'architecture de données correspondants. Une base de données relationnelle organise les données en tables où chaque ligne représente un enregistrement unique et chaque colonne représente une propriété de cet enregistrement. Elle utilise un langage appelé SQL pour gérer et interroger les données. Les bases de données NoSQL sont conçues pour stocker et gérer des données qui ne s'intègrent pas parfaitement dans des tables et peuvent gérer divers types de modèles de données comme des documents ou des graphes.
Pleins feux sur l'industrie
Réutilisation de la conception
La réutilisation adaptative de la conception joue un rôle crucial dans diverses industries aujourd'hui, y compris le secteur de la santé, où son impact est profondément significatif. Comprendre et exploiter la réutilisation adaptative de la conception dans les soins de santé peut conduire à des solutions innovantes pour des problèmes médicaux complexes, améliorant les soins aux patients et les résultats des traitements. Un excellent exemple de son application est la conception de valves artificielles qui peuvent remplacer les valves cardiaques naturelles chez les personnes.
La valvulopathie cardiaque est une affection où une ou plusieurs valves du cœur ne fonctionnent pas correctement, entraînant une perturbation du flux sanguin. La solution traditionnelle implique un remplacement chirurgical par des valves prothétiques, qui peuvent être dérivées de sources biologiques ou fabriquées à partir de matériaux synthétiques. La réutilisation adaptative de la conception dans ce contexte fait référence au processus innovant de conception de ces valves cardiaques prothétiques en réutilisant des matériaux, des technologies et des principes de conception existants du domaine médical ou d'autres domaines. Cette approche peut accélérer le développement de remplacements de valves cardiaques plus efficaces, durables et sûrs.
Architecture d'infrastructure
L'architecture technologique est un composant fondamental de l'architecture d'entreprise, soutenue par quatre piliers principaux : le calcul, la mémoire, le stockage et le réseau. Elle décrit l'organisation et la fonctionnalité du cadre technologique des solutions ou du système d'une entreprise. Cela englobe la configuration du matériel client et serveur, les applications fonctionnant sur ce matériel, les services que ces applications fournissent, et les protocoles et réseaux facilitant la communication entre les applications et les composants matériels. Il est important de distinguer l'architecture technologique de l'architecture système. L'architecture système (system architecture) traite des applications et des données, de la façon dont elles sont liées les unes aux autres et du processus d'affaires qu'elles soutiennent ensemble. L'architecture technique (technical architecture) comprend les capacités logicielles et matérielles pour activer pleinement les services d'application et de données.
Reportez-vous à la Figure 10.36 pour un exemple d'architecture technologique conceptuelle au niveau de l'entreprise pour une entreprise fictive. L'objectif de l'architecture technologique conceptuelle d'entreprise est d'illustrer les différents types de composants matériels qui font partie de l'infrastructure de l'entreprise et la façon dont ils sont agencés à un niveau élevé.
Enjeux mondiaux de la technologie
Impacts plus larges de la réutilisation de la conception
Se concentrer sur la réutilisation de conceptions et de technologies existantes peut faire gagner du temps et de l'argent, mais cela pourrait également limiter les nouvelles idées et innovations, car les concepteurs pourraient s'en tenir trop étroitement à ce qui a déjà été fait. Cette approche peut avoir plusieurs effets :
- Socialement, elle pourrait ne pas répondre aux besoins de tous les utilisateurs, surtout si la technologie ne tient pas compte des différentes cultures ou modes de vie, ce qui entraînerait l'exclusion de certaines personnes.
- Éthiquement, il y a une question d'équité et de savoir si la technologie sert tout le monde de manière égale, car le fait de s'appuyer sur d'anciennes conceptions pourrait ne pas bien relever les défis actuels ou futurs.
- Environnementalement, bien que l'utilisation de conceptions existantes puisse réduire les déchets et économiser les ressources, elle pourrait également continuer à utiliser des technologies obsolètes et moins écologiques au lieu de développer des options plus propres et plus efficaces.
- Économiquement, les pays qui disposent déjà de nombreuses conceptions et technologies pourraient prendre de l'avance parce qu'ils ont plus à réutiliser, ce qui rend plus difficile pour les pays disposant de moins de ressources de rattraper leur retard ou de rivaliser.
Bien que la réutilisation des conceptions présente des avantages, il est important de réfléchir également à ces impacts plus larges et de s'efforcer de trouver un équilibre entre le recyclage d'anciennes idées et la création de nouvelles pour s'assurer que la technologie continue de s'améliorer d'une manière qui soit bénéfique pour tous.
Figure 2.21 illustre une architecture physique possible pour le exemple de modèle d'affaires de négociation qui a été introduit précédemment dans cette section. Ce diagramme représente la disposition des composants matériels réels qui constituent l'infrastructure de la solution de trading. Il délimite également l'endroit où les blocs fonctionnels de l'architecture d'application sont physiquement déployés. Notez que cette architecture technologique physique tire parti de la disposition et des composants de l'architecture d'application d'entreprise illustrée précédemment au niveau conceptuel.
Une architecture d'application physique alternative pour la solution de trading est présentée à la Figure 2.22. Le diagramme ne délimite pas l'endroit où les blocs fonctionnels de l'architecture d'application sont physiquement déployés.
Vue d'architecture des systèmes d'information
Les vues d'architecture sont des représentations de la conception globale du système qui intéressent différentes parties prenantes. En plus des modèles d'architecture d'application, de données et de technologie, les architectes informatiques créent des vues spécifiques pour communiquer et s'assurer que le système répond aux besoins des diverses parties prenantes. Une architecture est généralement transmise par un ou plusieurs modèles d'architecture qui offrent collectivement une description claire de la structure du système. Un modèle singulier et englobant est souvent trop complexe pour être facilement appréhendé, affichant chaque relation complexe entre divers éléments commerciaux et techniques.
Tout comme un architecte conçoit différents aspects d'un bâtiment, tels que des schémas de câblage pour les électriciens, des plans d'étage pour les propriétaires et des élévations pour les urbanistes afin de répondre à leurs besoins uniques, l'architecture d'un système d'information est également décomposée en diverses vues pour une communication efficace entre ses parties prenantes. Dans le monde de l'informatique, par exemple, un architecte pourrait créer des vues spécifiques de la disposition physique du système et des mesures de sécurité. Ces vues adaptées garantissent que les parties prenantes, chacune avec ses propres préoccupations et domaines d'intérêt, ont une compréhension claire des composants du système pertinents pour leurs intérêts.
De l'architecture d'entreprise à l'architecture de solution
Après avoir identifié les caractéristiques commerciales et techniques à travers les diagrammes discutés dans la section précédente, des modèles de solution peuvent être développés et des implémentations peuvent être créées. Cela implique de construire de nouveaux composants si nécessaire et de les combiner avec des composants de conception réutilisables obtenus à partir d'un catalogue de motifs. Si des implémentations de ces composants réutilisables existent déjà et peuvent être personnalisées, l'implémentation de la solution devient beaucoup plus rapide. Cette approche permet d'éviter de réinventer la roue et de développer des composants logiciels ou des systèmes qui existent déjà, en se concentrant plutôt sur l'assemblage de composants existants pour l'efficacité.
Portée d'applicabilité des modèles
Figure 2.23 illustre les dimensions clés pour représenter et catégoriser les modèles d'architecture, les diagrammes associés et les motifs connexes. Ces domaines d'architecture s'alignent sur la norme TOGAF, comme discuté précédemment. Le diagramme illustre également les niveaux d'abstraction (abstraction) pour caractériser divers modèles architecturaux. De plus, il introduit la portée de l'architecture (architecture scope) comme une autre dimension, classifiant l'étendue d'applicabilité des modèles au niveau de l'entreprise, du portefeuille ou du projet. La portée de l'architecture désigne l'étendue et les limites dans lesquelles les considérations, décisions et solutions architecturales s'appliquent.
Les architectures au niveau du portefeuille ou du domaine se concentrent généralement sur des collections de solutions et de projets associés à une unité commerciale spécifique, comme le marketing ou les ventes dans une grande organisation. En revanche, l'architecture au niveau du projet ou du système est orientée vers des solutions et des projets individuels au sein de ces unités commerciales. Définir la portée d'un modèle est crucial car il existe une relation directe entre la portée et le niveau de détail réalisable dans un plan. Cela est dû à la nécessité d'une généralisation accrue, telle que la simplification, la sélection de fonctionnalités et le regroupement, à mesure que la portée du plan s'élargit.
La technologie au quotidien
Réutilisation adaptative de la conception : Des maisons écologiques à partir de matériaux recyclés
La réutilisation adaptative de la conception peut considérablement bénéficier aux personnes dans la vie quotidienne en favorisant l'efficacité, la durabilité et l'amélioration des expériences utilisateur. Imaginez un quartier appelé EcoHomes, où toutes les maisons sont construites à partir de vieux matériaux provenant de bâtiments démolis ou inutilisés. Il s'agit de construire de nouvelles maisons sans avoir besoin de produire ou d'acheter plus de matériaux, ce qui aide l'environnement. Chez EcoHomes, les architectes et les constructeurs prennent des éléments comme des briques, du verre et du bois d'anciens sites et les utilisent pour construire de nouvelles maisons modernes. Par exemple, des poutres en bois d'une ancienne grange deviennent une partie du salon d'une nouvelle maison, ajoutant une touche cool et ancienne à un design moderne. Les fenêtres d'un ancien immeuble de bureaux laissent entrer beaucoup de lumière du soleil, réduisant le besoin d'éclairage électrique. EcoHomes est un succès car il montre comment la réutilisation des matériaux de construction peut économiser de l'argent et aider la planète. Les personnes qui y vivent ont des factures d'énergie plus basses et sont fières de leurs maisons uniques et écologiques. Cette histoire montre comment l'utilisation de ce que nous avons déjà de nouvelles manières peut faire une grande différence pour nos portefeuilles et le monde.