L'entreprise, les systèmes et l'architecture d'application (Best Practice?)

Question

Je suis actuellement chargé de créer une documentation, guide d'architecture cohérente pour le développement de logiciels. Nous avons beaucoup de gens intelligents faire les bonnes choses, mais tout simplement pas cohérente et répétable.

Nous utilisons Guide Architecture d'application 2.0 de Microsoft comme point de départ. D'où vient avec une architecture d'application est assez (je ne dirai pas facile) simple. Peut-être parce que j'ai deux ou trois années d'expérience en tant que développeur j'ai donc une assez bonne compréhension de ce domaine et il y a aussi des charges d'exemples et d'orientation.

Depuis notre organisation a deux applications qui forment 1 ou plusieurs systèmes que nous avons ensuite installons « à » clients ... nous avons pensé qu'il serait logique de créer une architecture système et une architecture d'entreprise ainsi. Et c'est là que les problèmes commencent.

Il n'y a pas d'orientation cohérente là-bas. Si vous recherchez des exemples « Architecture système », les choses que vous revenez est si différent que je me demande s'il y a une façon de le faire.

« Standard »

De mon (Limited - clairement) la compréhension de tout cela, l'architecture du système est une abstraction de 1 ou plusieurs architectures d'applications illustrant la façon dont ils travaillent ensemble pour former un système. En outre, une architecture d'entreprise est une abstraction plus montrant comment votre système (s) correspondent à une des organisations d'entreprise et la façon dont elle interagit avec les processus d'affaires, la stratégie et comment elle Integrats dans d'autres systèmes de l'entreprise.

• Dois-je complètement tort?
• Y a-t-il des normes là-bas (et où je peux les trouver)?
• Faut-il prévoir des normes, ou bien une architecture système « bien » être simplement un document dans un format qui est clairement et facilement compréhensible et utile à ses lecteurs?
• Qu'est-ce que les architectes chevronnés penser à cette approche si?

Je ne veux pas simplement énumérer un ensemble de motifs liés SOA qui peut être utile ... Je voudrais faire un peu plus concentré sur ce que nous faisons, ce qui est la construction de solutions financières sur un service lié Architecture.

Mise à jour: Qu'en est- TOGAF (9) . Quelqu'un at-il l'expérience avec du tout et il vaut la peine d'essayer de le comprendre en détail.

Answer 1

Je soumettais la question, il y a quelques jours, mais la recherche continue et après avoir lu littlegeek 's Reponse, je pense que je l'ai trouvé un livre blanc intéressant que j'ai trouvé très instructif et intéressant.

Lire: Comparaison des Méthodologies Top Quatre Enterprise-architecture Par: Roger Sessions

un extrait ...

- - - - - - - - - - - 8 <- - - - - - - - - - - -

De nombreuses méthodologies d'entreprise d'architecture se sont succédés au cours des 20 dernières années. À ce stade, peut-être 90 pour cent du champ utilisez l'une des quatre méthodes:

• Le cadre Zachman pour l'entreprise Architectures Bien que l'auto-décrit comme un cadre, est en fait plus précisément définie comme une taxonomie
• Le cadre d'architecture Open Group (TOGAF) -Bien appelé un cadre, est en fait plus précisément définie comme un processus
• L'architecture peut être entreprise fédérale considérée soit comme une architecture d'entreprise mis en œuvre ou une méthode prescriptive pour créer une architecture d'entreprise
• La meilleure méthodologie Gartner-peut être décrit comme une pratique architecturale de l'entreprise

Ce livre blanc traite ces quatre approches de l'architecture d'entreprise. Il le fait dans le contexte d'une société fictive qui fait face à des problèmes d'exploitation très fictionnels. Ces problèmes comprennent:

• systèmes informatiques qui sont devenus ingérables complexes et de plus en plus coûteux à entretenir.
• systèmes informatiques qui entravent la capacité de l'organisation à répondre aux actuels et futurs, les conditions du marché en temps opportun et rentable.
• STRATÉGIQUES des informations qui sont constamment hors date et / ou tout simplement faux.
• Une culture de méfiance entre les deux parties d'affaires et de la technologie de l'organisation.

- - - - - - - - - - - 8 <- - - - - - - - - - - -

Le Livre blanc m'a aidé de plusieurs façons.

1. Il m'a donné une bonne introduction et de l'histoire de l'architecture (architecture d'entreprise spécifiquement)
2. Il m'a présenté à ce que l'auteur suggère est les 4 principaux Architectures d'entreprise disponibles.
3. Et continue ensuite de les comparer d'une manière logique et simple avec de bons exemples que je pouvais identifier.

Je ne peux pas dire que toutes mes questions ont été répondues et je suis maintenant prêt à mourir :-), mais beaucoup est devenu plus clair et donc je pensais que quelqu'un d'autre là-bas peut également trouver ce utile.

Je valoriserait encore des commentaires, suggestions et questions que vous pourriez avoir à ce sujet.

Answer 2

Vous semblez avoir une bonne compréhension vraiment bien de la situation et la compréhension du domaine de la artchitecture.

« Systèmes » Architecure est peu plus difficile à définir - peut être chercher « solution » ou « IT », mais il semble que vous cherchez comment votre architecture logicielle se rapporte au monde du serveur physique, avec un peu de mise en réseau jeté

  

« Nous avons beaucoup de gens intelligents qui font les bonnes choses, mais tout simplement pas cohérente et répétable. »

Alors, étant TOGAF 8 moi-même Certifed, - je dirais que TOGAF apporte un sentiment de « méthodologie » aux différents aspects de la définition architecture et un moyen d'apporter un groupe technique spécialiste des variours ensemble et épingler que fermement aux objectifs de l'entreprise. TOGAF aide également à comprendre la nécessité d'une architecture de la gouvernance et apporte fermement l'idée du changement (de toutes les parties techniques, données, systèmes, logiciels et entreprises) dans le processus.

1. Méthode architecture développement
2. Modèle de référence technique
3. Normes de base Informations
4. Enterprise Continuum

Toutes les informations sur aider à recueillir l'effort Archtecture et de fournir une approche cohérente pour le développement et EA.

Il aide également les clients à comprendre ce que vous faites et comment vous pouvez présenter TOAGF comme méthode de montrer comment il va ensemble.

PS -. Je ne déclare TOGAF comme utiles ne la citation que je l'ai tiré comme TOAGF aborderait pour vous

Il y a d'autres architecte framworks là-bas.

Answer 3

Je n'ai aucune expérience pratique sur EA, mais je suis en fait à bord avec elle. Parmi les 4 premières méthodes d'évaluation environnementale, j'ai rencontré les trois premiers. Je ne sais pas celui de Gartner, peut-être en raison de la non-disponibilité de ses documents. À mon humble avis, quand nous parlons d'EA, nous parlons en fait d'aligner des affaires avec la technologie. Donc, toutes les méthodes d'évaluation environnementale doit être orienté vers les entreprises. Sinon, ce n'est pas du tout EA.

Je pense que TOGAF est tout à fait utile et compréhensible. Oui, il est un processus qui évolue l'architecture de référence actuelle dans l'architecture cible. principes d'architecture agissent comme les conseils de haut niveau de développement EA. Les principaux composants de TOGAF sont l'architecture d'entreprise, l'architecture de l'information, et l'architecture de la technologie. Et chacun d'entre eux peut avoir ses propres modèles d'architecture. NIH a mis en place une évaluation environnementale avec FEAF. Il est un bon exemple pour la mise en œuvre EA. Je pense qu'il est tout à fait similaire à l'approche TOGAF, au moins du point de vue des résultats attendus.

Answer 4

La seule tentative raisonnable de créer un cadre de modélisation pour EA a été jusqu'ici Archimate: https: // en.wikipedia.org/wiki/ArchiMate

ArchiMate est une norme technique de The Open Group et est basée sur les concepts de la norme IEEE 1471.

En outre, voir le lien ci-dessous à propos des artefacts EA et la traçabilité entre les:

https://www.ontario.ca/document/go-its-56-ops-enterprise-architecture-principles-and-artefacts-appendix-ontario-public-service