Wer braucht Enterprise Architecture und warum?

Copyright © 2009 Zabegalin E.V.

1 Aktueller Stand architektonischer Methoden und Praktiken

IN Im Ausland entwickelt sich seit langem methodisch und praktisch ein bestimmtes Themenspektrum, dessen Gegenstand die Architektur von Komplexen ist organisatorische und technische Objekte wie Unternehmen, „elektronische Regierungen“, Unternehmensinformationssysteme.

IN Russland, obwohl die Begriffe „Informationssystemarchitektur“„IT-Architektur des Unternehmens“, „Architektur des E-Governments“ sind längst in Mode gekommen und unter IT-Spezialisten weit verbreitet; ernsthaftes methodisches Interesse an „architektonischen“ Themen besteht nur in einem engen Kreis begeisterter Spezialisten (einschließlich Autoren von Publikationen). , Aktivitäten, die in diesem Bereich hauptsächlich pädagogischer und Popularisierungscharakter haben.

Wenn wir also über die Standardisierung „architektonischer“ Methoden in Russland und deren anschließende breite praktische Anwendung in inländischen Unternehmen sprechen, dann scheint dies eine Frage ungewisser Zukunft zu sein. Es ist jedoch notwendig, die „architektonische“ Bewegung in russischen Unternehmen jetzt praktisch in Gang zu setzen.

„Enterprise Architecture“, auf Russisch „Enterprise Architecture“ (AP), hat sich zu einer allgemeinen Disziplin als Etappe in der historischen Entwicklung vieler Methoden im Zusammenhang mit der Architektur automatisierter Informationssysteme entwickelt – dies sind die Methoden von J. Zachman, Art . Spivak, CIMOSA, GERAM, TOGAF usw. Die Analyse dieses historischen Prozesses wird in recht umfassend dargestellt.

Zu den bekanntesten und bedeutendsten Quellen moderner methodischer Ideen und Praktiken der AP gehören heute:

Das Zachman Framework für Unternehmensarchitektur;

ISO 19439:2006-Standard „Unternehmensintegration – Framework für die Unternehmensmodellierung“;

ISO 15704:2000-Standard. Industrielle Automatisierungssysteme – Anforderungen an unternehmensweite Referenzarchitekturen und -methoden;

„Federal Enterprise Architecture“ (FEA), praktiziert und entwickelt von der US-Regierung;

„Extended Enterprise Architecture Framework“ (E2AF), entwickelt von der unabhängigen Organisation „Institute For Enterprise Architecture Developments“;

Das Open Group Architecture Framework (TOGAF).

Parallel dazu wurde im Jahr 2000 in Russland ein konzeptionelles Architekturdiagramm des „3D-Unternehmens“ entwickelt und veröffentlicht, in dem die Matrixideen von J. Zachman um eine dritte – die Zeitdimension – ergänzt wurden, um die Transformation der Unternehmensstruktur widerzuspiegeln .

Es wird darauf hingewiesen, dass das große Interesse am Thema AP auf das dringende Bedürfnis moderner Manager und Analysten nach einer mehrdimensionalen Systembeschreibung und Planung des Entwicklungsprozesses von Organisationen (einschließlich Unternehmen) zurückzuführen ist. Das Interesse an einer solchen Beschreibung ergibt sich zumindest aus der praktischen Notwendigkeit, stets über ausreichend aussagekräftige Kenntnisse über die aktuelle Struktur der Organisation zu verfügen, die auch für eine rationale Planung der Transformation der Organisation unter veränderten Bedingungen genutzt werden können. Wenn solches Wissen in entfremdeter Form in einer Organisation verfügbar ist, unterstützt und genutzt wird, wird es zu einem wirksamen Managementinstrument. Dies gilt insbesondere für neue Führungskräfte und Manager von Organisationen (Unternehmen).

Abbildung 1 – Manager und Analysten haben ein praktisches Bedürfnis, stets über ausreichend umfassende Kenntnisse über die Struktur der Organisation (des Unternehmens) zu verfügen.

Gleichzeitig ist der Abstraktionsgrad und die Komplexität der meisten der aufgeführten Methoden nach wie vor sehr hoch und kann deren effektiven Einsatz in Organisationen durch ihre praktischen Manager und Spezialisten behindern. Verschiedene Arten von „Matrizen“ und „Würfeln“, die in den aufgeführten Methoden vorgeschlagen werden, können übermäßig künstlich und daher für die praktische Anwendung unpraktisch erscheinen. So scheint beispielsweise der Charakter derselben „Zachman-Matrix“ eher philosophischer als ingenieurpraktischer Natur zu sein; es handelt sich vielmehr um eine schematisch visualisierte Konkretisierung eines systematischen Ansatzes zur Analyse großer und komplex strukturierter organisatorischer und technischer Objekte. Dies leugnet jedoch keineswegs den enormen methodischen Wert und die praktische Bedeutung der sich entwickelnden Disziplin AP.

Im Interesse der praktischen Anwendung der AP-Disziplin kann die Überwindung dieser Künstlichkeit mit der Suche nach einer Antwort auf die Frage begonnen werden: Wer und warum in einem Unternehmen könnte „Enterprise Architecture“ benötigen?

2 Zweck der „Unternehmensarchitektur“

Abbildung 2 zeigt schematisch die Struktur und den Inhalt eines generalisierten Unternehmens. Aus diesem Diagramm wird deutlich, dass AM, als Modell betrachtet und eingesetzt, in einem Unternehmen praktisch nur als Managementinstrument gefragt sein kann, da weder technisches Personal noch Produktionspersonal AM zur Erfüllung seiner Produktionsfunktionen benötigen.

Diese Schlussfolgerung ergibt sich aus der Tatsache, dass alle im Diagramm angegebenen Verwaltungsobjekte gleichzeitig Objekte sind, die im AP-Modell widerzuspiegeln sind, das in Zukunft auch zu einem Verwaltungsobjekt werden wird (das Architekturmodell des Unternehmens ist im Diagramm als dessen Komponente dargestellt). ).

Abbildung 2 – Allgemeine Struktur des Unternehmens

Als Managementtool kann AP zur Unterstützung aller Hauptfunktionen eingesetzt werden – Analyse, Planung, Organisation, Motivation, Kontrolle, Koordination.

Abbildung 3 – Unternehmensarchitektur kann zur Unterstützung grundlegender Verwaltungsfunktionen verwendet werden

Aus der Rolle von AP als Managementtool lassen sich mindestens zwei Hauptfunktionen der „Enterprise Architecture“ ableiten:

in der operativen Führung des Unternehmens - Hierbei handelt es sich um die Formalisierung und Bereitstellung von entfremdetem Wissen über die bestehende Struktur und Funktionsweise des Unternehmens;

im Rahmen der strategischen Unternehmensführung - das ist Formalisierung und Bereitstellung

entfremdetes Wissen über die geplanten strukturellen und funktionalen Veränderungen des Unternehmens.

Abbildung 4 – Hauptfunktionen der Unternehmensarchitektur

AP kann mit diesen Funktionen auf allen Managementebenen eingesetzt werden: von der Unternehmensmanagementebene bis zur Shopebene. Dies wird (explizit oder implizit) durch bekannte Methoden gewährleistet –

„Zachman Framework for Enterprise Architecture“, „Extended Enterprise Architecture Framework“, „TOGAF“,

„GERAM“, ISO 19439-2006-Standard (Stufen „Generic“, „Partial“, „Particular“).

Nach J. Zachman werden im Schema „3D Enterprise“ die spezifischsten und konsistentesten Managementebenen für den Einsatz von AM vorgeschlagen – „Hauptbedürfnisse, Ziele, Pläne, Einschränkungen“, „Geschäftsmodell“, „Logisches Modell“, „Technisch“. Architektur“, „Detaillierte Umsetzung“, „Nutzungspraxis“.

3 Zusammensetzung von „Enterprise Architecture“

Alle Architekturmethoden stimmen darin überein, dass für eine ausreichend aussagekräftige Beschreibung der Struktur eines Unternehmens (einer Organisation) viele verschiedene Standpunkte (Ansichten) auf dieses Gerät verwendet werden müssen. Diese Gesichtspunkte können auch als architektonische Domänen, inhaltliche Aspekte usw. bezeichnet werden. Die Beschreibung (und Modellierung) der Struktur eines Unternehmens aus vielen verschiedenen Perspektiven führt zur „Unternehmensarchitektur“.

Unterschiedliche Methoden nutzen unterschiedliche architektonische Perspektiven. Zum Beispiel:

im Zachman Framework for Enterprise Architecture sind dies „Daten“, „Funktion“, „Netzwerk“, „Personen“, „Zeit“, „Motivation“;

im Extended Enterprise Architecture Framework (E2AF) sind dies „Business“, „Information“, „Information“

Systeme“, „Technologie-Infrastruktur“;

in GERAM und in ISO 19439-2006 sind dies „Funktion“, „Information“, „Ressource“, „Organisation“;

Im TOGAF sind dies „Business“, „Information“, „Application“, „Technology“.

Dem Autor dieses Artikels erscheint es praktisch ratsam, eine solche Vielfalt methodischer Ansätze zur Auswahl inhaltlicher Aspekte der AP durch die Verwendung eines einfachen und verständlichen Prinzips zur logischen Ableitung dieser Aspekte zu überwinden.

Ein solches Prinzip kann aus einem gemeinsamen Grundverständnis eines „Systems“ als einer Menge gezielt interagierender Elemente folgen. Darauf aufbauend lassen sich grundsätzlich folgende grundlegende und leicht verständliche inhaltliche Aspekte der „Enterprise Architecture“ identifizieren:

1) Konstruktionsaspekt- Ein Unternehmen besteht aus vielen verschiedenen physischen und Informationskomponenten, darunter: Anlagevermögen und anderes Eigentum, verbrauchte und produzierte Energie, Personal, Papierdokumente, elektronische Informationen, Automatisierungs- und automatische Steuerungsausrüstung, d. h. dies sind die „Bausteine“ aus denen sich das Unternehmen physisch zusammensetzt. Für diesen Aspekt kann auch ein synonymer Begriff verwendet werden – struktureller Aspekt.

2) Funktioneller Aspekt- Das Unternehmen betreibt die Herstellung von Produkten, die Erbringung von Dienstleistungen sowie den Kauf und Verkauf von Rohstoffen, Materialien, Produkten sowie die Durchführung von Technologie- und Geschäftsprozessen. Das heißt, dieser Aspekt unterscheidet die äußere und innere Manifestation der Aktivitäten des Unternehmens.

3) Logischer Aspekt- Die Tätigkeit des Unternehmens ist zielgerichtet; seine Bau- und Funktionsstrukturen richten sich nach den Zielen des Unternehmens. Dieser Aspekt unterstreicht den geschäftlichen Sinn der Gründung und des Betriebs eines Unternehmens.

Die Hauptkomponenten der logischen Struktur eines Unternehmens sind spekulative Komponenten wie Zweck, Mission, Vision, Ziele des Unternehmens, sein Platz auf dem Markt, Grundsätze für die Auswahl der Haupttypen seiner Gebäudekomponenten, Funktionsprinzipien und Entwicklung des Unternehmens Unternehmen.

IN In der Zachman-Matrix wird dieser Aspekt durch den Namen der ersten Zeile angezeigt, „Scope“ („Der Zweck der Zeile 1 besteht darin, die Grenzen des Unternehmens zu definieren, was enthalten ist ...“).

IN Federal Enterprise Architecture (FEA) ist ein „Performance Reference Model“.

IN E2AF und GERAM heben den logischen Aspekt nicht explizit hervor und beziehen ihn in den Aspekt „Geschäft“ ein. In den E2AF-Kernprinzipien heißt es jedoch: „Keine Strategie, keine Unternehmensarchitektur … Kein Geltungsbereich – Keine Unternehmensarchitektur.“

Der Umfang und die Ziele und Ziele legen den Abstraktionsgrad der Unternehmensarchitektur fest ... Geschäftstreiber, Ziele und Ziele sind führend ... " .

IN Der logische Aspekt von TOGAF entspricht der „Architecture Vision“ („... Schlüsselelemente der „Architecture Vision“- ...

Unternehmensmission, Vision, Strategie und Ziele ..., umfassen Architekturprinzipien, definieren den Umfang der Unternehmensabdeckung, die spezifischen Architekturdomänen ... ").

Wenn wir die Überprüfung des logischen Aspekts zusammenfassen und philosophische Sprache verwenden, können wir die Notwendigkeit behaupten, dass der logische Aspekt der Unternehmensstruktur die „Integrale Idee des Unternehmens“, „Integrales Konzept des Unternehmens“, „Integrales Konzept von“ darstellt the Enterprise“, auf Englisch können wir anbieten – „The Notion of the Enterprise“.

4) Chronologischer Aspekt- Ein Unternehmen entsteht, betreibt und verändert sich im Laufe der Zeit. Der vergangene, aktuelle und geplante Strukturzustand des Unternehmens muss erfasst werden, es handelt sich also um eine „Life History“.

In GERAM werden in ISO 15704-2000, ISO 19439-2006 viele Lebenszyklusphasen vorgeschlagen, um den Zeitaspekt zu strukturieren: „Identifikation“, „Konzept“, „Anforderungen“, „Design“, „Implementierung“, „Betrieb“, „Stilllegung“.

IN TOGAF-Methodik – Architecture Development Method (ADM) – der Zeitaspekt spiegelt sich in der Abfolge der Phasen der Entwicklung, Implementierung und Änderung der „Unternehmensarchitektur“ selbst wider.

Das Schema „3D-Enterprise“ ermöglicht die Planung des langfristigen Zustands des Unternehmens, einschließlich einzelner Projekte und Entwicklungsprogramme, in der Zeitdimension des AP. Die Reihenfolge der Implementierung technologischer Komponenten (Systeme) eines Unternehmens kann insbesondere Folgendes umfassen: strategische Analyse von Zielen und Bedürfnissen, Entwurf technischer Lösungen, detaillierte Implementierung eines Lösungssystems, Implementierung von Lösungen, Nutzung (Betrieb) des Systems , Verbesserung des Systems.

Abbildung 5 – Hauptgesichtspunkte zur Struktur des Unternehmens

Somit kann „Unternehmensarchitektur“ als die Struktur eines Unternehmens definiert werden, die von seinem Management aus mindestens vier Hauptgesichtspunkten (in vier Hauptaspekten) betrachtet und durch einen entsprechenden Satz von vier Haupttypen von Architekturen dargestellt (einschließlich modelliert) wird Unternehmen: logisch, konstruktiv (strukturell), funktional und chronologisch.

Als Komponenten der Unternehmensgebäudearchitektur können berücksichtigt werden:

Organisationsarchitektur ist die Organisationsstruktur eines Unternehmens;

Immobilienarchitektur ist die Eigentumsstruktur eines Unternehmens;

Informationsarchitektur ist die Struktur vieler Dokumente (organisatorischer, regulatorischer, technischer usw.) und Informationsdatenbanken eines Unternehmens;

Produktions- und Technologiearchitektur ist die Struktur der Produktions- und Energiekapazitäten eines Unternehmens sowie die Struktur von Instrumentierungs- und Automatisierungskomplexen und Automatisierungsausrüstungskomplexen.

ZU Zu den Komponenten der funktionalen Architektur eines Unternehmens können gehören:

Struktur funktionaler Systeme und Subsysteme des Unternehmens;

Struktur der Geschäftsfunktionen und Geschäftsprozesse des Unternehmens;

Strukturen des Material- und Informationsflusses im Unternehmen.

Abbildung 6 – Umfassende Darstellung „Enterprise Architecture“

Neben den vier Haupttypen der Unternehmensarchitektur sind weitere möglich, die anderen Gesichtspunkten entsprechen, zum Beispiel:

Unter IT-Architektur versteht man die Struktur vieler automatisierter Informationssysteme (Informationstechnologien) eines Unternehmens;

Geschäftsarchitektur ist die Architektur eines Unternehmens, betrachtet ohne seine IT-Architektur.

4 So erhalten und nutzen Sie Enterprise Architecture

Die Unternehmensleitung kann auf zwei Arten einen AP erhalten: Erstens durch die Entwicklung eines AP mit den Vollzeitmitarbeitern des Unternehmens und zweitens durch die Inanspruchnahme externer Berater.

Der erste Weg erfordert von der Unternehmensleitung Folgendes:

Bildung einer Arbeitsgruppe, die dann in einen ständigen Architekturdienst des Unternehmens umgewandelt werden muss;

Auswahl und Kauf eines vorgefertigten spezialisierten Computerprogramms für die elektronische Modellierung von AM und Schulung von Unternehmensspezialisten in dessen Verwendung;

Eigenständige Entwicklung und Dokumentation der methodischen Unterstützung für AP;

unabhängige Entwicklung von AP.

Die Entwicklung eines AP durch externe Berater erfordert den Abschluss eines Arbeitsvertrags durch die Unternehmensleitung:

zur direkten Entwicklung von AP;

zur Entwicklung und Dokumentation methodischer Unterstützung für AP;

einen Unternehmensarchitekturdienst zu erstellen.

Auf dem Markt vorhandene Computerprogramme zur elektronischen Modellierung von Geschäftsprozessen und Systemstrukturen ermöglichen es, Datenbanken elektronischer Modelle aus ihren Fachformaten in das WWW-Format zu konvertieren und diese dann auf der internen (Intranet-)Website des Unternehmens zu veröffentlichen. Dies ermöglicht Ihnen die Umsetzung

bequemer und lizenzfreier Zugang für Manager und Unternehmensspezialisten zum elektronischen AP-Modell.

Anschließend kann der gebildete und vorbereitete Architekturdienst des Unternehmens im Interesse des Managements, das strategische Entscheidungen über die Entwicklung des Unternehmens trifft, selbstständig Probleme der Modellierungsoptionen für den zukünftigen Stand des Architekturentwurfs lösen.

Liste der verwendeten Quellen

1. Zinder E. „3D-Unternehmen“ – ein Modell der Strategie eines sich wandelnden Systems. „Director of Information Service“, Nr. 4, 2000. http://www.sept2000.ru/articles/2008/03/03/1/.

2. Zinder E. Unternehmensarchitektur im Kontext Unternehmensumstrukturierung. „Intelligent Enterprise/Corporate Systems“, Nr. 4, Nr. 7, 2008.

3. Galaktionov V. Systemarchitektur und ihr Platz in der Unternehmensarchitektur. „Direktor des Informationsdienstes“, Nr. 5, 2002.

4. Danilin A., Slyusarenko A. Architektur und Strategie. „Yin“ und „Yang“ der Unternehmensinformationstechnologien. M. Internet-Universität für Informationstechnologien, 2005.

5. Drozhzhinov V., Shtrik A. Standardisierung der Architektur von US-Regierungsabteilungen. PC-Woche/RE. Nr. 28, Nr. 31, 2005.

6. Zachman John A. Das Zachman-Framework.http://www.zachmaninternational.com/

7. Das Amt für Verwaltung und Haushalt. Federal Enterprise Architecture (FEA).http://www.whitehouse.gov/omb/e-gov/fea/

8. Schekkerman J. Extended Enterprise Architecture Framework Essentials Guide. Institut für Unternehmensarchitekturentwicklungen, 2006.http://www.enterprise-architecture.info/

9. Das Open Group Architecture Framework (TOGAF).http://www.opengroup.org/architecture/togaf8doc/arch/toc.html

10. Generalisierte Unternehmensreferenzarchitektur und -methodik (GERAM). IFIP-IFAC, 1999.

11. Ivanova I.A. Management: Lehrbuch. - M.: RIOR Verlag, 2004.

1. Architektonische Beschreibung des Unternehmens: Wie lässt sich die Arbeitsorganisation sichtbar machen?

Unternehmensarchitektur ist die Art und Weise, wie sie organisiert ist. Wie es organisiert ist (Architektur), hängt davon ab, wer woran arbeitet und wer diese Arbeit benötigt. Ein Unternehmen ist immer irgendwie organisiert, ob gut oder schlecht. Die Organisation (Architektur) eines Unternehmens ist unsichtbar, es kann jedoch eine vollständig sichtbare Architekturbeschreibung erstellt werden. Liegt eine Architekturbeschreibung vor, dann kann diese genutzt werden, um die Organisation des Unternehmens von allen an dieser Organisation interessierten Parteien (einschließlich der in Organisationsfragen kompetenten Personen) zu diskutieren – und dann besteht die Chance, dass die Organisation verbessert werden kann. Wenn es keine architektonische Beschreibung gibt, die auf irgendeinem vom Kopf entfremdeten Informationsträger dokumentiert ist, dann hat jeder eine (frag nicht welche) Beschreibung in irgendeiner (frag nicht welche) Form im eigenen Kopf und sogar während eines Gesprächs diese Beschreibung kann für eine Person drei- oder viermal geändert werden. Wenn es um die Organisation der Arbeit in einem Unternehmen geht, hat garantiert jeder unterschiedliche Vorstellungen von den Vereinbarungen, und das Ergebnis der Arbeit im Rahmen solcher Vereinbarungen wird in Krylovs Fabel über den Schwan, den Krebs und den Hecht beschrieben.

Eine Architekturbeschreibung besteht aus einer Reihe von Diagrammen, durch die Menschen ihre Finger bewegen, um die Struktur der Organisation zu verstehen und sich dann darauf zu einigen, was in der Organisation geändert werden muss. Eine Architekturbeschreibung ist in erster Linie ein Instrument zum Abschluss von Vereinbarungen zwischen wichtigen Personen (Stakeholdern) über wichtige Aspekte der Arbeitsorganisation. Es besteht kein Grund, organisatorische Vorschriften (die sowohl wichtige als auch nicht sehr wichtige und im Allgemeinen viele Wörter enthalten) mit einer Architekturbeschreibung zu verwechseln, die nur das Wichtigste enthält, aber so formal wie möglich ausgedrückt wird, um dies zu vermeiden Fehler.

Zur Beschreibung der Unternehmensarchitektur wird eine spezielle Sprache, ArchiMate, verwendet. Diese Sprache ermöglicht es Ihnen, die wichtigsten Dinge in der Organisation eines Unternehmens aufzuschreiben – und die kleinen Details zu ignorieren.

Machen wir gleich einen Vorbehalt, dass wir in Archimete nur die Arbeitsorganisation für Büroplankton beschreiben können. In Architem können keine Objekte realer materieller Produktion beschrieben werden, es werden nur Informationen zu diesen Objekten beschrieben. Kein Kartoffelkochen, kein Schweinetransport von Maschine zu Maschine – darüber nur und ausschließlich Informationen. Archimate ist ideal für Banken und Versicherungen, Zentralen (von denen aus keine echten Werkstätten sichtbar sind), Konstruktionsbüros (wo schwere Balken nur in Computermodellen und Papierausdrucken zu finden sind) und sogar für Bauzentralen (wo sie mit der Erteilung von Anweisungen und der Buchhaltung befasst sind). was getan wurde, aber sie selbst tun nichts mit ihren Händen). Aber diejenigen Teile des Unternehmens, die das Anziehen von Muttern nicht berücksichtigen, sondern die rostigen Muttern nach Erhalt aus dem Lager tatsächlich anziehen, können von Archimate nicht beschrieben werden. Aber bitte stellen Sie die Lagerbuchhaltung bzw. die Gestaltung und Abrechnung der Arbeiten dar.

Ein Architekt ist derjenige, der eine Architektur entwirft, die alle Beteiligten zufriedenstellt. Er entwickelt diese Architektur, beschreibt sie in Form von Archimate-Diagrammen und stimmt sie mit verschiedenen wichtigen Personen ab. Der Moment der Beschreibung der Architektur auf Archimete ist unwichtig. Diejenigen, die einfach nach dem Diktat in Archimeite (Spanisch, Suaheli) schreiben, können nicht als Architekten bezeichnet werden, sie sind nur Schreiber (Schriftgelehrte). Okay, Erzschreiber (Erzschreiber).

Für viele Leute, die als Architekten ernannt wurden, war es eine völlige Überraschung, dass der unvermeidliche Übergang von der Darstellung der Ergebnisse verschiedener Interviews auf Archimate als „Architekturbeschreibung wie sie ist“ zum Schreiben einer „Architekturbeschreibung in der Zukunft“ und unmittelbar darauf folgte Enge Kommunikation mit den Vorgesetzten bezüglich der Umwandlung der neu erstellten Archimate-Diagramme in eine Organigramm-Realität des Unternehmens. Der Archmate wird Ihnen bei Ihrer Sache genauso wenig helfen, wie die Rechtschreibprüfung von Word Ihnen dabei helfen wird, den Nobelpreis für Literatur zu gewinnen.

Du wurdest gewarnt.

2. Personen, Programme, Ausrüstung

Für Archimate ist die Anwesenheit von drei Personen das Wichtigste in einem Unternehmen Arbeitsebenen, bei denen das menschliche Element jeweils abnimmt: von Leuten, Programme Und Ausrüstung. Menschen ohne Programme sind hilflos; Programme ohne Hardware sind tot. Geräte ohne laufende Programme sind ein nutzloses Stück Hardware; Programme ohne laufende Leute werden auch nicht benötigt. Daher muss die Unternehmensarchitektur alle drei Arbeitsebenen in ihrer Wechselbeziehung abbilden.

Jede Ebene hat ihre eigene Darsteller der Arbeit, und deins Arbeitsgegenstände arbeiten. Tatsächlich besteht die Arbeit darin, dass die Darsteller die Arbeitsgegenstände irgendwie verändern. Künstler und Arbeitsgegenstände werden normalerweise durch Substantive dargestellt, Arbeit durch Verben und Verbalsubstantive. Wichtig ist, dass die Arbeitsgegenstände selbst nichts zu tun wissen, sie sind passiv. Aber die Performer sind aktiv, sie arbeiten an Objekten und nutzen Objekte.

Die Ebene der Menschen ist aussagekräftig. Die Menschen hinter den Informationen sehen die Objekte der umgebenden Welt, die diese Informationen darstellen. Sie schauen sich die Wettervorhersage an und sehen das Wetter von morgen (und keine Beschreibung des Wetters), sie schauen sich den Baubericht an und sehen die Anzahl der tatsächlichen Stockwerke (und nicht den Bericht selbst), sie schauen sich die Gewinn- und Verlustrechnung an und sehen Sie den gleichen Gewinn. Menschen haben Ziele, Autorität (sie können anderen Leuten Befehle erteilen, Arbeiten auszuführen) und Verantwortung (sie müssen versprechen, dass sie die Befehle anderer Leute ausführen werden). Nur auf dieser Ebene gibt es zielgerichtetes Handeln.

Die Programmebene ist die Verarbeitung der in Daten enthaltenen Informationen. Aus einigen Daten erstellen Programme andere Daten, die sich sowohl im Format als auch im Inhalt unterscheiden. Niemand verspricht irgendjemandem etwas (Programme können nichts versprechen, das können nur Menschen) und gibt keine Anweisungen (nur Menschen können Anweisungen geben), verfolgt keine Ziele (nur Menschen haben Ziele). Auf dieser Ebene weiß man, was die Daten in der realen Welt bedeuten: Schließlich ist es gefährlich, Kilometer zu Kilogramm zu addieren. Die Hauptaufgabe der Programmebene besteht darin, sicherzustellen, dass die auf die richtige Weise verarbeiteten Daten die richtigen Personen zur richtigen Zeit erreichen.

Die Hardware-Ebene ist eine seelenlose Welt, in der es keine Datenverarbeitung mehr gibt, sondern nur noch Datenspeicherung und -weiterleitung. Natürlich gibt es auch Programme auf Hardware-Ebene, aber die sind von anderer Art – niemand weiß hier, was diese Daten in der realen Welt bedeuten. Die Aufgabe der Geräte besteht darin, irgendwie adressierte Bytes zu speichern, ohne auf deren Bedeutung einzugehen, diese Bytes auf Anforderung von Programmen zu versenden, sowie die Programme selbst zu speichern und deren Ausführung zu ermöglichen.

3. Elemente und Beziehungen
Ein Unternehmen wird in Architem in Form von Elementen (dargestellt durch verschiedene Figuren) beschrieben, die in irgendeiner Beziehung zueinander stehen (Beziehungen werden in Form von Verbindungslinien zwischen den Figuren der Elemente dargestellt). Archimate ist wertvoll, weil es alles bietet, um die Arbeit eines Unternehmens zu beschreiben
-- 16 Arten von Elementen für die Personenebene,
-- 7 Arten von Elementen für die Programmebene,
-- 9 Arten von Elementen pro Ausrüstungsstufe,
-- 11 Arten von Beziehungen, in denen Elemente miteinander stehen können, und Darstellung der Verzweigungen dieser Beziehungen.

Wenn Sie die Architektur eines Unternehmens im wirklichen Leben irgendwie ändern möchten (warum sollten Sie sonst überhaupt mit dem Zeichnen von Archimate-Diagrammen beginnen?), können Sie hierfür auch Folgendes verwenden:
-- 7 Arten von Elementen zur Zielsetzung und Begründung von Veränderungen in der Organisation
-- 4 Arten von Elementen zur Gestaltung des Übergangs zu einer neuen Architektur

Außerdem gibt es einen Kommentar und eine Beziehung zwischen dem Kommentar und einigen anderen Elementen sowie einen Rahmen zum Gruppieren von Elementen.

Das ist das ganze Archimate. Aber lassen Sie sich nicht von seiner Einfachheit täuschen. Auch „The Great and the Mighty“ hat nur 33 Buchstaben.

4. Es sind nicht Sie, die gebraucht werden, sondern Ihr Dienst, der gebraucht wird.

Es ist wichtig, dass im Unternehmen keine Arbeit ohne Grund verrichtet wird, sie werden alle aus irgendeinem Grund von jemandem benötigt. Dienste sind Werke, die für einige andere Künstler nützlich sind (genauer gesagt, nützlich für die Arbeit dieser Künstler). Für die Konsumenten von Dienstleistungen ist es völlig unwichtig, wie die Umsetzung dieser Arbeit organisiert ist: Wer arbeitet mit was, um die Dienstleistung für den externen Konsum bereitzustellen. Für sie ist nur wichtig, über welche Kanäle (E-Mail, Fenster mit einem Mädchen, Telefonanruf usw.) und Schnittstellen (sofern es sich um Programme handelt) diese Dienste bereitgestellt werden.

Es gibt Hardwaredienste, die für Programme bereitgestellt werden, und Programmdienste, die für Personen bereitgestellt werden. Durch diese Leistungen werden die drei Ebenen des Unternehmens zusammengehalten – von jeder Ebene sind nur die Leistungen der anderen Ebenen sichtbar.

Das heißt, Sie können die gesamte Ausrüstung austauschen, und Programme werden dies nicht bemerken, wenn die Ausrüstungsdienste gleich bleiben. Mit Programmen ist es genauso: Ersetzen Sie sie alle, aber wenn die Dienste gleich bleiben, werden die Leute es vollständig überleben. Dies gilt grundsätzlich auch für das Unternehmen selbst: wenn die Dienstleistungen von Personen, die das Unternehmen nach außen erbringt (und die Kombination dieser Dienstleistungen und der sie verbindende Vertrag genannt wird). Produkt) von organisierten Leuten, die ganz andere Programme verwenden, die auf ganz anderen Geräten laufen, auf ganz andere Art und Weise durchgeführt wird, dann wird es den Kunden nicht auffallen. Dies machen sich Unternehmensarchitekten zunutze: Sie beschreiben das Unternehmen und ändern dann langsam Software und Hardware, um die Bereitstellung geschäftskritischer Dienste zu unterstützen. Dies wird als serviceorientierter Ansatz bezeichnet: Teilen (verschiedene Arbeitsebenen nach Diensten) und erobern. Man kann es also anders betrachten: Das Unternehmen wird durch Dienstleistungen zusammengehalten, für den Architekten ist es jedoch durch diese Dienstleistungen getrennt.

Der Wunsch nach Teilen und Erobern ist unter Architekten so groß, dass sie Leistungen und Arbeiten auch auf gleicher Ebene teilen. Beispielsweise kann man sich leicht Programme vorstellen, die Dienste nicht für Menschen, sondern für andere Programme bereitstellen. Oder Ausrüstung, deren Bedeutung darin besteht, anderen Geräten zu dienen (Dienstleistung zu erbringen, d. h. für sie zu arbeiten).

Bereitstellen äußerlich Sichtbare Arbeitsleistung muss von außen unsichtbar erfolgen intern Arbeit – Änderungen an Arbeitsobjekten durch Arbeitsausführende. Das Vorhandensein dieser Grenze zwischen interner und externer Betrachtung (eine „Black Box“ mit unsichtbaren internen Darstellern, Jobs und Objekten im Vergleich zu einer „transparenten Box“, wenn sie deutlich sichtbar sind) ist das Vorhandensein einer Grenze Systeme. Archmate-Modelle Systeme, Trennung von Teilen/Ebenen des Unternehmens durch Dienste (obwohl in der Architem-Spezifikation kein Wort über „Systeme“ verloren geht).

5 Personen

Erinnern wir uns an Punkt drei: Um den Grad der Organisation der Arbeit der Menschen zu beschreiben, verfügt Archimate über die gleiche Anzahl von Elementtypen (17) wie für die Ebenen von Programmen und Geräten zusammen (7+9) – und das ist keineswegs zufällig .

Die Menschen selbst werden im Archimeite nicht durch ihre Persönlichkeit repräsentiert. Bei Archimeite ist es nicht die Person, die den Ort malt, sondern der Ort, der die Person malt. In Archimeite ist der Darsteller eine lebende Person, aber nur jemand, der einen organisatorischen Platz einnimmt. Deshalb nennt der Archmate genau diese Orte „Menschen“, egal wer sie gerade besetzt – eine Person, eine ganze Gruppe von Menschen auf Organisationsebene (von einem Sektor und einer Abteilung bis zu einer Niederlassung in einem anderen Staat oder sogar das gesamte Unternehmen). ), Zeitarbeiter, gelegentliche Bürger-Kunden, Partnerfirmen. Der Erzkamerad versteht, dass alle diese organisatorischen Orte von lebenden Menschen besetzt sind, aber er nennt diese Menschen genau mit den Namen der organisatorischen Orte. Ein Generalarbeiter, ein stellvertretender Leiter der Lieferabteilung, eine Lieferabteilung, eine Filiale in Mytischtschi, ein Kunde, ein Wirtschaftsprüfer – das sind die „Menschen“, egal wer die Mitarbeiter sind, die zufällig diese Organisationspositionen besetzen. Der Architekt kümmert sich wie immer um das Ewige: Wenn ein Handwerker oder ein Präsident krank wird und während der Krankheit eine Person die andere ersetzt, bleibt das Diagramm wahr: Die Arbeitsorganisation wird sich nicht ändern.

Die Menschen des Archmates sind vielfältiger als die Menschen, die in der „Organisationsstruktur“ (Organigramm) zu finden sind: Nicht alle Beziehungen zwischen den Leuten des Archmates reduzieren sich auf Überlegenheit und Unterordnung. Daher werden Partner und Kunden in der Organisationsstruktur normalerweise nicht erwähnt, in Architem ist ihre Anzeige jedoch üblich.

6. Rollen

Architekten sind so heimtückisch, dass sie mit Teilen von Menschen arbeiten und sie „Rollen“ nennen. Rolle Als Teil der zeitlich begrenzten Personen wird der Teil der Personen bezeichnet, der eine bestimmte Anzahl von Tätigkeiten ausübt, für die besondere Qualifikationen erforderlich sind. Wenn also ein Handwerker in einem Theater gezwungen wird, entweder zu singen oder zu tanzen, hat er zwei Rollen: Wenn er singt, ist die Rolle eines Sängers, und wenn er tanzt, ist die Rolle eines Tänzers.

Menschen ernannt werden für Rollen und Rollen ernannt werden arbeiten. Besonders hervorzuheben ist die Tatsache, dass Organisationsarchitekten sich mit der Organisation der Arbeit und nicht mit der Führung befassen. Die Verteilung von Personen in Rollen und Rollen in Jobs ist das Anliegen des Organisationsarchitekten. Und das Anliegen des Führers ist a) die Ernennung lebender „Menschen“ an die Stellen der „Menschen“ mit Nachnamen, Vornamen und Vatersnamen, schlechten und guten Angewohnheiten, bestimmten Fähigkeiten und b) das Einreden der Menschen an die Stellen der „Menschen“ mit Zuckerbrot und Peitsche ” um die ihnen übertragenen Arbeiten auszuführen. Daher werden in den Archimate-Diagrammen keine Namen angezeigt: nur Positionen, Rollen, Abteilungen, Unternehmen, „Diensthabende“, „Vertreter“, Kollegialorgane, temporäre Gruppen und Verbände usw.

Im Leben Termin Rollen und Arbeiten spiegeln sich in der Regel in Anordnungen, Weisungen, Vorschriften und anderen „Verwaltungsdokumenten“ wider. Ein solches System der Fragmentierung von Menschen ist nicht nur notwendig, um die Vielseitigkeit der Berufe der Menschen zu zeigen (ich möchte Sie daran erinnern: sowohl einzelne Menschen als auch ganze Abteilungen – wenn ein großes Unternehmen mit 1000 Mitarbeitern sowohl als Lieferant gegenüber einigen Unternehmen fungiert als auch als Kunde gegenüber anderen Unternehmen), sondern auch, dass Architekten ihre Pläne seltener ändern und Anordnungen zur Arbeitsorganisation seltener erteilt werden.

Ein typisches Beispiel: Eine Organisation beginnt mit dem Pflanzen von Petersilie, aber es ist noch nicht klar, wer diese Petersilie pflanzen wird – die Geschäftsführung sagt: „Sie zeigen, was dort zu tun ist, und dann bestelle ich einen geeigneten Kandidaten.“ Sie schreiben „Vorschriften zur Petersilie“, in denen sie die Rolle der „Chefpetersilie“ und der „Oberstenpetersilie“ einführen und ihre gesamte Arbeit vorschreiben. Bitte beachten Sie, dass es sich bei der Verordnung noch nicht um eine Verordnung oder Richtlinie handelt. Dies ist eine Aussage darüber, dass einige organisatorische Positionen (Chef und leitender Petersilie) besetzt werden müssen, damit die Arbeit (Petersilienanbau) fortgesetzt werden kann. Der Chef studiert diesen Verordnungsentwurf und kommt zu dem Schluss, dass sein Petersilienanbau von Ingenieuren und Anwälten durchgeführt werden sollte. Als nächstes schreibt er eine Anordnung, in der er a) die Position genehmigt und b) vorschreibt, dass die Rolle des Chefs der Petersilie von einem Ingenieur und die des Chefs der Petersilie von einem Anwalt besetzt wird. So sieht es aus:

Verbindungslinien mit Punkten sind die „Zielbeziehungen“ zwischen Elementen. Natürlich gibt es direkte Beziehungen zwischen Menschen und Jobs (wenn wir die Erwähnung von Rollen weglassen). Diese Beziehung wird Ableitung genannt, aber sie besteht immer noch – wir können sagen, dass in diesem Fall der Ingenieur mit der Sicherung der Setzlinge beauftragt wird und der Anwalt mit der Überwachung der Pflanzung.

Bitte beachten Sie, dass dieser Entwurf auch dann funktioniert, wenn Ingenieur Ivanov in den Ruhestand geht und Sidorov an seiner Stelle eingestellt wird. In diesem Design ist es einfach, einen Ingenieur gegen einen Agronomen oder gegen die Direktion für Petersilie (wenn die Aktivität zunimmt) auszutauschen – dieser Mechanismus Termine Rollen für Jobs (z. B. Vorschriften) und Personen für Rollen (z. B. Befehle) funktionieren auch, wenn „Personen“ eine ganze Menschenmenge usw. sind. Wir sprechen über die organisatorische Ebene. Alle diese Vorschriften und Anordnungen sind in der Regel nicht auf dem Diagramm vermerkt: Auf den Diagrammen wird vereinbart, wie die Arbeiten organisiert werden und nicht mit welchen Dokumenten diese Verträge erstellt werden.

Hinweis: Ich kenne mehrere Organisationen, in denen vom Direktor Alben mit Architekturbeschreibungen des Unternehmens anstelle eines dicken Stapels von Vorschriften genehmigt wurden. Denn Architekturdiagramme erwiesen sich als genauer und aussagekräftiger als die zahlreichen Textbeschreibungen, die sie später daraus zusammenzustellen versuchten.

Es ist klar, dass am Ende die Lebenden, die am Petersilienanbau arbeiten, Ivanov und Sidorov (oder Mitarbeiter, die in der Petersiliendirektion aufgeführt sind) sind. Aber sie werden nur einen Teil ihrer Zeit und ihres Talents in das Unternehmen investieren (und nur dieser Teil der Zeit spiegelt sich im Element „Menschen“ in der Architektur des Unternehmens wider) und den Rest der Zeit werden sie schlafen, essen und spazieren gehen , lernen und Spaß haben. Sie werden nur einen Teil der Zeit, die sie im Unternehmen verbringen, mit ihrer Rolle beim Petersilienanbau verbringen – denn sie haben wahrscheinlich viele verschiedene Rollen und führen viele verschiedene Aufgaben aus. Und durchaus kann es sein, dass einer bestimmten Anzahl von Personen – einzelnen Personen oder sogar mehreren Abteilungen – dieselbe Rolle zugewiesen wird.

Sowohl Personen als auch Rollen können in beliebig viele Teile unterteilt werden, wenn Sie einige Details über die Beschäftigung der Personen, die sie ausüben, zeigen müssen.

Um eine Arbeit auszuführen, können sich verschiedene Personen für eine Weile zusammenschließen (dies spiegelt sich normalerweise nicht in der Organisationsstruktur wider), und ein solcher vorübergehender Zusammenschluss wird genannt kollegiale Rolle.

7. Volkswerke

Die Jobs der Leute sind so:

• Schon passiert - Veranstaltungen. Ereignisse werden normalerweise mit einem Verb in der Perfektform der Vergangenheitsform benannt: „Petersilie wird gepflanzt.“ Diese Arbeiten können unbeabsichtigt („ein Fehler ist aufgetreten“) von Personen durchgeführt werden, die nicht zum Unternehmen gehören (Kunden, Wettbewerber, Partner), und im Allgemeinen könnten diese Arbeiten nicht von Personen (sondern beispielsweise von Programmen, Geräten usw.) ausgeführt werden. oder sogar die Kräfte der Natur - - "Sonnenuntergang").
• auf das Erreichen eines Ergebnisses ausgerichtet und in einer zeitlichen Abfolge (oft nacheinander) ausgeführt - Prozesse. Sie werden als Verb in der unbestimmten Form bezeichnet – „graben“, „pflanzen“, „entwickeln“. Prozesse sind in der Regel werden ins Leben gerufen Veranstaltung und Start Ereignisse lösen sich gegenseitig aus und bilden eine Kette vom Anfangsereignis bis zum Ergebnisereignis.
• erhalten als Ergebnis der Arbeit eines temporären Teams, das durch eine kollegiale Rolle vereint ist - kollegiale Prozesse. Sie werden auch Verben in der unbestimmten Form genannt.
• für etwas anderes als die Zeitentwicklung ausgewählt, um ein Ergebnis zu erzielen (z. B. die Zuweisung von Rollen mit bestimmten Qualifikationen oder der Verbrauch einer bestimmten Art von Ressource) – Praktiken Methoden Ausübungen. Die Praktiken werden nicht so sehr selbst ausgeführt, sondern vielmehr werden zu verschiedenen Zeitpunkten bestimmte durch sie kombinierte Prozesse ausgeführt (oder Fragmente von Prozessen, die im Diagramm nie erreicht wurden, sodass sie ohne zeitliche Entwicklung dargestellt wurden, mit a chomp, „in der Tasche“ – das wird als „das, was geübt wird“ bezeichnet und nicht als Hinweis auf die Leistung zu einem bestimmten Zeitpunkt. Daher werden Praktiken nicht durch Verben, sondern durch Verbalsubstantive bezeichnet: „Petersilie pflanzen“ ist genau eine Praxis.


• Arbeit, die jemand Außenstehendem leistet, wie bedeutsam sie ist und wie sie von außen gesehen wird - Dienstleistungen. Dienstleistungen umgesetzt interne Arbeit, die von internen Rollen ausgeführt wird, und gebraucht bei externen Arbeiten durch externe Rollen. Grundsätzlich wird jede Arbeit von Menschen nur zu diesem Zweck verrichtet implementieren eine Art Dienstleistung – das heißt, damit jemand anderes (z. B. ein Kunde oder Subunternehmer) diese Arbeit nutzen kann.

Victor Galaktionov, 20.05.2002
Zeitschrift „IS Director“, Nr. 05, 2002 // Open Systems Publishing House (http://www.osp.ru/)

Unter modernen Bedingungen ist es besonders wichtig, die IT-Aspekte der Struktur eines modernen automatisierten Unternehmens ständig und korrekt mit aktuellen Geschäftsaspekten abzustimmen. Dies muss beginnend mit der Definition der Geschäftsarchitektur des Unternehmens und der Entwicklung einer damit konsistenten Systemarchitektur (IT-Architektur) erfolgen. In diesem Artikel teilt der Autor praktische Erfahrungen bei der Entwicklung von Systemarchitekturen für Großbanken und gibt konkrete Hinweise, wie dies auch für Unternehmen anderer Branchen umgesetzt werden kann.

Ich bin Geograph, kein Reisender. Ich vermisse Reisende schrecklich. Schließlich sind es nicht die Geographen, die Städte, Flüsse, Berge, Meere, Ozeane und Wüsten zählen. Der Geograph ist ein zu wichtiger Mensch, er hat keine Zeit, herumzulaufen. Er verlässt sein Büro nicht. Aber er beherbergt Reisende und zeichnet ihre Geschichten auf.

Antoine de Saint-Exupéry. "Der kleine Prinz". Kapitel 15. Geograph

Grundlegendes Konzept

• statisch – je nach Zustand der Bank zu einem bestimmten Zeitpunkt;
• dynamisch – als Übergangsprozess (Migration) einer Bank von ihrem aktuellen Zustand in einen gewünschten zukünftigen Zustand.

• Mission und Strategie, strategische Ziele und Vorgaben;
• Geschäftsarchitektur;
• Systemarchitektur.

Reis. 2.

• formulierte Mission und Strategie der Bank, strategische Ziele und Zielsetzungen;
• Geschäftsarchitektur im aktuellen (Ist-) und geplanten (Soll-)Zustand,
• Systemarchitektur im aktuellen (wie sie ist) und geplanten (sollten) Zustand;
• Pläne für Aktivitäten und Projekte für den Übergang vom Ist-Zustand zum Geplanten.

• von der Bank angebotene und zum Verkauf geplante Produkte und Dienstleistungen (einschließlich einzelner Pläne zu ihrer Herstellung), formalisiert in Form eines einheitlichen Produkt- und Dienstleistungsregisters, das auch Kundensegmentierung, Tarife und Produktbesitzer enthält;
• Kanäle für den Verkauf von Produkten und Dienstleistungen, die sowohl auf der Grundlage der strukturellen und territorialen Abteilungen der Bank als auch auf der Grundlage moderner Informationstechnologien aufgebaut sind;
• Funktionen und Prozesse zur Umsetzung externer und interner Produkte und Dienstleistungen, die Funktions- und Prozessbäume bilden (im Folgenden Geschäftsfunktionen und Geschäftsprozesse genannt);
• Finanz- und Verwaltungsdokumente (sowohl in Papierform als auch in elektronischer Form), formalisiert in Form eines einzigen Registers (Formularalbum) von Bankdokumenten;
• Dokumentenflüsse, die durch Vorschriften zum internen und externen Dokumentenfluss bestimmt werden;
• Organisationsstruktur, einschließlich der Besetzungstabelle der Bank und ihrer Gebietseinheiten, die eigenständige Wirtschaftseinheiten (juristische Personen) sind, Ausschüsse, Arbeitsgruppen und Rollenfunktionen einzelner Mitarbeiter, Stellenbeschreibungen, Regelungen zu Abteilungen und Arbeitsgremien und andere Dokumente, die die regeln Beziehung und Aufgabenverteilung zwischen den Mitarbeitern der Bank sowie zwischen den Strukturbereichen der Bank.

• Definieren eines Projekts als eine Reihe von Aufgaben und Arbeiten;
• Phasen und Fristen für die Umsetzung des gesamten Projekts sowie der Aufgaben und Arbeiten, die das Projekt umfasst;
• Analyse des Wettbewerbsumfelds und der mit der Umsetzung des Projekts verbundenen Risiken;
• Zusammensetzung der Ausgabenposten des Projektbudgets;
• Kriterien für den Erfolg des Projekts und den erwarteten wirtschaftlichen Effekt.

Systemarchitektur

Reis. 3.

Komponenten der Systemarchitektur

• Anwendungssysteme (Applikationen), die die Ausführung von Geschäftsfunktionen und Geschäftsprozessen sicherstellen;
• Schnittstellen zur Interaktion von Anwendungssystemen untereinander und mit externen Systemen und Datenquellen bzw. Verbrauchern;
• Werkzeuge und Methoden zur Entwicklung und Wartung von Anwendungen.

• Automatisierte Datenbanken, die die Sammlung, Speicherung und Verarbeitung von Daten ermöglichen, die durch die Geschäftsarchitektur bestimmt werden;
• Zu diesem Zweck verwendete Datenbank- oder Data-Warehouse-Verwaltungssysteme;
• Regeln und Mittel zur Autorisierung des Zugriffs auf Daten.

• lokale und territoriale Computernetzwerke, einschließlich physischer eigener und gemieteter Kommunikationskanäle und kanalbildender Geräte;
• Kommunikationsprotokolle, Dienste und Adressierungssysteme zur Verwendung in Netzwerken;
• Notfallpläne, um den unterbrechungsfreien Betrieb von Netzen in Notsituationen sicherzustellen.

• Computerhardware – Server, Workstations, Laufwerke und andere Computerausrüstung;
• Betriebs- und Steuerungssysteme, Dienstprogramme und Bürosoftwaresysteme;
• Notfallpläne, um den unterbrechungsfreien Betrieb von Geräten (hauptsächlich Servern) und Datenbanken in Notfallsituationen sicherzustellen.

• Koordinierung der Arbeit der IT-Abteilungen zur Dokumentation der aktuellen Systemarchitektur in der Anfangsphase und anschließende Aktualisierung der Wissensbasis über die Systemarchitektur;
• Festlegung erfolgversprechender Richtungen für die Entwicklung der Systemarchitektur entsprechend den strategischen Zielen und Zielsetzungen der Bank, konkretisiert in Form einer erfolgversprechenden Geschäftsarchitektur;
• Entwurf (zusammen mit anderen spezialisierten Informationstechnologieabteilungen) einer zukünftigen Systemarchitektur und Migrationsplänen vom aktuellen Stand in die Zukunft;
• Formulierung von Anforderungen und Einschränkungen für erstellte oder implementierte Automatisierungstools, die die Qualität und Integrität der Systemarchitektur sicherstellen;
• Kontrolle der Konsistenz von Systemarchitekturen, die im Rahmen verschiedener Projekte entwickelt wurden;
• Überwachung der Einhaltung der Anforderungen zur Gewährleistung der Qualität und Integrität der Systemarchitektur durch Bankabteilungen, die an der Entwicklung, Wartung und dem Betrieb von Informationssystemen beteiligt sind.

Beziehung zwischen Systemarchitektur und Geschäftsarchitektur

1. Mission und Strategie der Bank, strategische Ziele und Zielsetzungen.
2. Produkte und Geschäftsprozesse.
3. Dokumentation.
4. Organisatorische Struktur.
5. Anwendungen.
6. Daten.
7. Ausrüstung.
8. Pläne von Aktivitäten und Projekten für den Übergang vom Ist-Zustand zum Geplanten.

Reis. 4. Wechselbeziehung der Entitäten der obersten Ebene der Unternehmensarchitektur

Reis. 5. Unternehmensarchitektur und der Platz der Systemarchitektur darin

Reis. 6.

Wesen und Beziehungen zweier Architekturen

Lebenszyklus der Systemarchitektur

Reis. 7.

• Erstdokumentation;
• Verwendung;
• Design;
• Migration.

Reis. 8.

• Machbarkeitsanalyse;
• Entwicklung technischer Spezifikationen;
• Entwicklung eines technischen Projekts;
• Entwicklung und Dokumentation von Software;
• PS-Tests;
• Implementierung von PS;
• Betrieb des Umspannwerks;
• Stilllegung des Umspannwerks.

Erstdokumentation

Tabelle 1.

Verwendung

• Entwicklung technischer Spezifikationen für das PS.
• Entwicklung des technischen Designs der Umspannstation.
• PS-Test.

Tabelle 2.

Design

• Erstellung technischer Spezifikationen für das PS.
• Vorbereitung des technischen Entwurfs der Umspannstation.

1. Änderungen in der Mission oder Strategie;
2. Veränderungen der Marktsituation;
3. Regulierungsbehörden.

Tisch 3.

Migration

• Softwaretest.
• Implementierung von Software.

Tabelle 4.

• Auf Phase „Entwicklung technischer Spezifikationen für das Umspannwerk“ Es erfolgt eine Analyse der bestehenden Systemarchitektur im Hinblick auf die Möglichkeit und Machbarkeit, vorhandene Ressourcen zur Lösung neu gestellter Geschäftsprobleme zu nutzen. Darüber hinaus werden bei der Erstellung der technischen Spezifikationen nach Möglichkeit die Anforderungen und Einschränkungen der bestehenden Systemarchitektur berücksichtigt.
• Auf Phase „Entwicklung des technischen Designs der Umspannstation“ Es erfolgt die eigentliche Gestaltung oder Änderung der Systemarchitektur, die zur Umsetzung neu gestellter Geschäftsaufgaben erforderlich ist. Dabei werden Anforderungen und Einschränkungen der bestehenden Systemarchitektur berücksichtigt, um Kontinuität zu gewährleisten und Modernisierungskosten zu minimieren.
• Auf Phasen „Testen“ und „Umsetzung“ Die entwickelten Softwareanforderungen der Systemarchitektur werden genutzt, um die notwendige technologische Umgebung für den Test und Betrieb dieser Umspannwerke zu bilden.

Zusammensetzung der Wissensbasis zur Systemarchitektur

1. Aktuelle Systemarchitektur.
2. Perspektivische (geplante) Systemarchitektur.
3. Migrationspläne.

1. Prinzipien der Systemarchitekturkonstruktion.
2. Grundlegende technische und technologische Lösungen.
3. Anforderungen und Standards.
4. Angewandte Architektur.
5. Technische Architektur.
6. Datenarchitektur.

Konstruktionsprinzipien

Grundlegende Lösungen

Anforderungen und Standards

Anwendungsarchitektur

Technische Architektur

Netzwerkarchitektur

Plattformarchitektur

Datenarchitektur

Enthält eine Beschreibung von Datenbanken und anderweitig organisierten Informationsfeldern.

Datenbankmanagementsystem

Enthält eine Beschreibung der verwendeten Datenbankverwaltungssysteme.

Migrationsplan

Abschluss

• Wer in der Bank führt diese oder jene Geschäftsfunktion aus, wie regelmäßig führt er sie aus, welches Ereignis löst die Ausführung dieser Geschäftsfunktion aus, ist die Ausführung dieser Geschäftsfunktion automatisiert oder nicht?
• Welche Informationen sind in einer bestimmten Geschäftsfunktion enthalten, wer ist der Lieferant dieser Informationen und in welcher Form gelangen sie?
• Mit welchen Softwaretools wird diese oder jene Geschäftsfunktion ausgeführt, welche anderen IT-Funktionen werden von diesen Programmen ausgeführt, welche Datenbanken und Verzeichnisse werden verwendet, welche Bildschirme und welche Berichte werden vom Programm generiert?
• Welche Informationen gehen für ein bestimmtes Programm ein und aus, in welcher Form werden eingehende Informationen empfangen und ausgehende Informationen generiert?
• Wie ist die Informationsinteraktion zwischen zwei Programmen organisiert: durch die Bildung/das Lesen einer Datei, direkt über die API, per E-Mail, durch Middleware-Systeme, wie ist die Struktur des Informationsaustauschs, wie hoch ist die Häufigkeit?
• Welche Abteilungen nutzen dieses oder jenes Programm und wer muss benachrichtigt werden, wenn sich das Programm oder andere Vorschriften ändern?
• Ist diese oder jene IT-Funktion des Programms aktuell genutzt, von wem wird es wie oft genutzt?

Ich wage zu behaupten, dass sich die Probleme der Unternehmer mit dem Aufkommen von Computern nicht grundlegend geändert haben. Computertechnologien sind einfach zu neuen Werkzeugen zur Lösung von Problemen geworden. Im Laufe ihrer langen Geschichte hat die Wirtschaft viele neue Werkzeuge und Technologien kennengelernt und sie erfolgreich zu ihrem Vorteil eingesetzt: Schreiben, Mathematik, doppelte Buchführung, Arbeitsteilung und vieles mehr.

Angesichts technologischer Innovationen löst ein Unternehmen, vertreten durch seinen Eigentümer, zwei Probleme:

• Was kann eine technologische Innovation dem Unternehmen bringen?
• Wie und wann (unter welchen Bedingungen) sollte es verwendet werden?

In der Praxis beziehen sich diese Aufgaben auf die innovative Ausrichtung des Unternehmens und ihre Lösung wird auf Unternehmer, Manager verschiedener Bereiche und Spezialisten für relevante technologische Innovationen verteilt. In unserem Fall sprechen wir von der IT-Abteilung des Unternehmens.

Jede Kategorie von Topmanagern verfügt über unterschiedliche Kompetenzen, Ziele, Befugnisse und die Menge an Informationen, die sie beherrschen können. Unternehmer sind das interessanteste Publikum. Einerseits die Großmächte, andererseits ist IT nur eines von vielen Themen, denen die Eigentümer Aufmerksamkeit schenken. Darüber hinaus werden viele Entscheidungen über die Auswahl, Implementierung und Betreuung von IT-Lösungen von Unternehmern delegiert. Daher ist das, was sie nicht delegieren können, entweder aufgrund der hohen Kosten des Projekts oder weil es mehrere Bereiche der Unternehmensaktivitäten betrifft, von besonderer Bedeutung. Dieses Thema scheint mir eine Beschreibung zu sein Unternehmensstruktur(AP).

Das Konzept der Systemarchitektur ist einfach. Architektur ist die Verbindung von Strukturen, die ein Objekt beschreiben. Struktur wiederum ist die Verbindung homogener Elemente, aus denen ein Objekt besteht. Jedes Unternehmen hat also eine Architektur. Mit anderen Worten handelt es sich bei AP um die geschriebenen und ungeschriebenen Regeln für das Auftreten, die Veränderung, die Entfernung und die Interaktion der Bestandteile eines Unternehmens. Es stellt sich heraus, dass fast jedes Unternehmen eine Beschreibung des AP hat. Außer natürlich die „ungeschriebenen Regeln“. Warum besteht dann gerade jetzt ein besonderes Interesse daran, IT zur Beschreibung von AP zu nutzen? Ich nenne drei Merkmale:

1) Computertechnologien selbst sind zu Elementen der AP geworden. Es gibt viele davon und es gibt ziemlich viele Verbindungen zwischen ihnen;

2) Computertechnologien sind mit vielen anderen Elementen der AP verbunden;

3) Computertechnologien ändern sich sehr schnell, daher ändert sich AP schnell.

Die AP-Beschreibung enthält lediglich Informationen darüber, wie das Unternehmen organisiert ist und funktioniert. Solange niemand die Informationen nutzt, bringen sie niemandem etwas. Diese Tatsache sollte niemanden entmutigen. Auch wenn Softwaresysteme laute, attraktive Namen wie „Projektmanagement“ oder „Personalmanagement“ tragen, verwalten sie keine Projekte und außerdem wird ihnen niemand erlauben, Personal zu verwalten. Solche Systeme bieten Spezialisten lediglich Informationen über den Gegenstand ihrer Beschäftigung und die Automatisierung einzelner Vorgänge zur Aufbereitung und Verarbeitung dieser Informationen.

Mit der Beschreibung des AP ist die Situation genau die gleiche. Informationen bieten nur Chancen. Damit sie jedoch sinnvoll umgesetzt werden können, bedarf es Spezialisten, deren Qualifikationen es ihnen ermöglichen, diese Chancen zu erkennen und deren Autorität es ihnen ermöglicht, die entdeckten Chancen umzusetzen. Die Beschreibung des AP ist ein vollständiges, aber statisches Bild des Unternehmens. Es wird nicht von Mitarbeitern benötigt, die in betriebliche Tätigkeiten und den regulären Tagesbetrieb eingebunden sind. Eine solche Beschreibung ist für diejenigen Mitarbeiter erforderlich, deren Kompetenz Aufgaben der Geschäftsentwicklung oder -reorganisation umfasst. Sie benötigen eine Beschreibung des AP, damit Entscheidungen, die in einem der Tätigkeitsbereiche des Unternehmens getroffen werden, keine großen Probleme in anderen Bereichen verursachen und seine weitere Entwicklung nicht behindern.

Da das Geschäft immer komplexer wird, fallen immer mehr Manager unter die Definition von AP-Benutzern, und ihre Entscheidungen und Fehler werden immer teurer.

So erstellen Sie eine Beschreibung der Unternehmensarchitektur

Die kurze Antwort: schrittweise und kontinuierlich. Beschreibung AP ist ein Prozess. Es ist völlig unmöglich, dies zu automatisieren, da sich AP nicht nur quantitativ (das Personal wächst, neue Geräte erscheinen), sondern auch qualitativ (neue Ziele, Technologien, Produkte, Geschäftsbereiche entstehen) ständig verändert.

Vereinfacht lässt sich der Prozess der Beschreibung einer Unternehmensarchitektur in fünf Phasen unterteilen:

• Beginnen Sie mit der Arbeit gemäß der Beschreibung des AP: Ernennen Sie einen verantwortlichen Testamentsvollstrecker oder bilden Sie eine Abteilung. Öffnen Sie ein Projekt, legen Sie Fristen fest, weisen Sie Ressourcen zu, wählen Sie Tools (Software) aus.
• Bestimmen Sie die Elemente, ihre Eigenschaften und Beziehungen, die in die Beschreibung des AP einbezogen werden sollen.
• Bestimmen Sie Datenquellen zur Beschreibung architektonischer Elemente und Vorschriften für deren Bereitstellung.
• Laden Sie ausgewählte Daten hoch, bereinigen und aggregieren Sie sie in den Speicher.
• Visualisieren Sie die Architekturbeschreibung.

Die Stufen Nr. 2-5 werden regelmäßig wiederholt.

Zyklen zur Erstellung einer Beschreibung der Unternehmensarchitektur

Der Schlüssel in diesem Prozess ist Stufe Nr. 1, in der ein allgemeines Modell zur Beschreibung des AP erstellt und überarbeitet wird. Das heißt, Elemente, ihre Eigenschaften und Zusammenhänge werden identifiziert, Daten darüber gesammelt und Regeln gebildet, anhand derer sie, wie es heißt, im „wirklichen Leben“ identifiziert werden können.

Es ist unmöglich und auch nicht notwendig, alle Elemente von AP zu beschreiben. In jedem Zyklus sollten Sie zunächst diejenigen AP-Elemente auswählen, über die Sie der Meinung sind, dass die Informationen unzureichend sind. Die Vertrautheit mit zahlreichen Modellen und Methoden zum Aufbau einer Unternehmensarchitektur kann bei der Auswahl von Elementen eine große Hilfe sein: TOGAF, Zachman-Modell, DoDAF und andere.

1) Versuchen Sie nicht, komplexe Architekturelemente sofort vollständig zu beschreiben. Das gewählte AP-Darstellungsmodell sollte es ermöglichen, die Unvollständigkeit der Beschreibung zu erfassen. Beispielsweise ist es besser, die Werte der beschriebenen Elemente nicht leer zu lassen. Wenn eines der Merkmale fehlt, geben Sie einfach „N/A“ (nicht zutreffend) an. Wenn der Wert eines Merkmals ermittelt werden muss, schreiben Sie „TBD“ (zu definieren). Sie können diese Klassifizierung um Ihre eigenen Kategorien erweitern: „wird in Stufe vor allem warum – Dies sind auch Informationen zur Entscheidungsfindung.

2) Trennen Sie die Beschreibung des AM von seinem Design (Entwicklung). Die Beschreibung des AP ist die Dokumentation aller im Unternehmen vorgenommenen Änderungen gemäß den dem Modell zugrunde liegenden Entscheidungen. AP-Design – Vorbereitung etwaiger Änderungen für Unternehmen. Diese beiden Aktivitäten verwenden unterschiedliche Methoden. Gemeinsam ist ihnen lediglich die Dokumentation. Technisch gesehen ist es möglich, in der allgemeinen Beschreibung von AP sowohl die Beschreibung „wie es ist“ als auch die Beschreibung „wie es sein wird“ (sein) zu kombinieren. Es ist jedoch zu berücksichtigen, dass es sich um unterschiedliche Aufgaben, unterschiedliche Kompetenzen und unterschiedliche Projekte handelt.

3) Ernennen Sie nicht den „Chefarchitekten“, der für die Beschreibung des AP verantwortlich ist. Und im Allgemeinen sollten Sie nicht nach einem Chefarchitekten suchen. Es gibt viele Architekten: Geschäftsprozessarchitekten, Datenarchitekten, Inund einige andere. Jeder, der befugt ist, Entscheidungen über die Gestaltung oder Veränderung von Strukturen oder Prozessen in einem Unternehmen zu treffen, ist ein Architekt. Und sie alle sind für die relevanten Elemente des AP verantwortlich. An der Spitze der Architektenhierarchie steht selbstverständlich der Unternehmer. Der Zweck der Beschreibung besteht darin, die Datenkonsolidierung vorzubereiten. Der Verantwortliche für die Beschreibung des AP sollte keine Veränderungen im Unternehmen oder in der IT planen. Die einzige Voraussetzung für seine beruflichen Fähigkeiten ist die Entwicklung eines AP-Modells und die Arbeitsorganisation zu dessen Ausfüllung.

4) Nehmen Sie sich Zeit, neue Technologien zu automatisieren. Eine IT-Lösung automatisiert nicht alle Technologien. Das heißt, Sie ersetzen den technologischen Prozess nicht durch eine vollautomatische IT-Lösung. Unter Automatisierung versteht man keinen automatischen Prozess, sondern lediglich die Automatisierung einzelner Datenvorgänge in diesem Prozess. Ob die Mitarbeiter diese Daten rechtzeitig aufbereiten und zum Nutzen des Unternehmens nutzen können, liegt in der Verantwortung des Unternehmens. Daher wird empfohlen, den erforderlichen Prozess zunächst mit vorhandenen Tools im Unternehmen bereitzustellen. Wenn Sie dann davon überzeugt sind, dass die Technologie praktikabel und sinnvoll ist, können Sie die Frage nach einem breiteren Einsatz der IT stellen. In diesem Fall können Sie sich darauf verlassen, dass IT-Spezialisten genau bestimmen, wo und wie Sie die IT optimal einsetzen.

5) Informationen zu den Elementen des AP sollten von den Mitarbeitern bereitgestellt werden, die für diese Elemente verantwortlich sind. Das Management kann von den Verantwortlichen für die Elemente des AP erwarten, dass sie in ihren Fachgebieten kompetent sind und jederzeit bereit sind, die erforderlichen Kenntnisse nachzuweisen. Das heißt, sie erstatten „schriftlich“ einen Bericht über den Status ihres Verantwortungsbereichs. Und das ist keine zusätzliche Belastung, sondern eine unmittelbare Verantwortung der Verantwortlichen. Insbesondere wenn Sie keine besonderen Anforderungen an die Form der Bereitstellung dieser Informationen stellen. Die Informationen müssen in der Form bereitgestellt werden, in der verantwortliche Personen betriebliche Aufzeichnungen darüber führen. Allerdings sollte diese Bereitstellungsform in internen Regelungen festgehalten werden. Alle notwendigen Transformationen der empfangenen Daten in ein einheitliches Format zur Beschreibung des AP können nach der Datenerfassung abgeschlossen werden.

Aus dem oben vorgeschlagenen Grundsatz ergibt sich eine wichtige Konsequenz: Wenn niemand für irgendein Element des AP verantwortlich ist, sollte es nicht in die Beschreibung des AP aufgenommen werden, bevor der spezifische Mitarbeiter für die Erstellung, Änderung und Zerstörung (Ausschluss) des AP verantwortlich ist Das Element wurde identifiziert.

6) Versuchen Sie nicht, die gesamte Beschreibung des AP in einem Informationssystem zusammenzufassen. Nutzen Sie Daten zu Kreditorenbuchhaltungselementen, die bereits in den bestehenden Systemen des Unternehmens verwaltet werden, optimal aus.

7) Denken Sie darüber nach, den AP zu beschreiben, wenn Sie sich über die richtige Priorisierung Ihrer Aufgaben nicht sicher sind.

Im Wesentlichen handelt es sich bei der AP-Beschreibung um eine Karte des Unternehmens. Da ein bestehendes Unternehmen lebendig ist, verändert es sich und wächst, und dementsprechend ändert sich auch seine Architektur. Auch hier gehört die Beschreibung des AP nicht zu den Aufgaben, die erledigt und abgeschlossen werden können. Dies ist ein regelmäßiger, darüber hinaus systematischer Prozess. Je aufmerksamer Sie darauf achten, die Beschreibung des AP regelmäßig zu aktualisieren, desto genauer wird die Karte und desto nützlicher wird sie sein. Auch in Bezug auf die Definition der IT-Richtlinie. Aber das ist nur ein Sonderfall. Architektur beschreibt die gesamte Tätigkeit eines Unternehmens und ihr Umfang wird nur durch die vom Eigentümer gesetzten Ziele begrenzt.

Unternehmensarchitektur ist die Art und Weise, wie sie organisiert ist. Wie ist sie organisiert (Architektur) – wer arbeitet woran (wer macht was). verantwortlich), und wer braucht diese Arbeit. Ein Unternehmen ist immer irgendwie organisiert, ob gut oder schlecht. Die Organisation (Architektur) eines Unternehmens ist unsichtbar (es ist ein „logisches Objekt“), es kann jedoch eine vollständig sichtbare Architekturbeschreibung erstellt werden. Liegt eine Architekturbeschreibung vor, dann kann diese genutzt werden, um die Organisation des Unternehmens von allen an dieser Organisation interessierten Parteien (einschließlich der in Organisationsfragen kompetenten Personen) zu diskutieren – und dann besteht die Chance, dass die Organisation verbessert werden kann. Wenn es keine architektonische Beschreibung gibt, die auf irgendeinem vom Kopf entfremdeten Informationsträger dokumentiert ist, dann hat jeder eine (frag nicht welche) Beschreibung in irgendeiner (frag nicht welche) Form im eigenen Kopf und sogar während eines Gesprächs diese Beschreibung kann für eine Person drei- oder viermal geändert werden. Wenn es um die Organisation der Arbeit in einem Unternehmen geht, hat garantiert jeder unterschiedliche Vorstellungen von den Vereinbarungen, und das Ergebnis der Arbeit im Rahmen solcher Vereinbarungen wird in Krylovs Fabel über den Schwan, den Krebs und den Hecht beschrieben. Selbst wenn wir uns auf eine „Organisationsstruktur“ einigen würden (das Einzige, was in solchen Gesprächen normalerweise dokumentiert wird), ist dies nur ein kleiner Teil dessen, worüber man sich richtig einigen könnte.

Eine Architekturbeschreibung besteht aus einer Reihe von Diagrammen, durch die Menschen ihre Finger bewegen, um die Struktur der Organisation zu verstehen und sich dann darauf zu einigen, was in der Organisation geändert werden muss. Eine Architekturbeschreibung ist in erster Linie ein Instrument zum Abschluss von Vereinbarungen zwischen wichtigen Personen (Stakeholdern – Stakeholder) zu wichtigen Aspekten der Arbeitsorganisation Interessen diese Stakeholder. Es besteht kein Grund, Organisationsvorschriften (die sowohl wichtige als auch nicht sehr wichtige und im Allgemeinen viele Wörter enthalten) mit einer Architekturbeschreibung zu verwechseln, die nur das Wichtigste (Dinge, die Sie benötigen, wenn Sie sie ändern) enthält auch viele andere Dinge ändern) ), aber so formell wie möglich ausgedrückt, um Fehler zu vermeiden.

Zur Beschreibung der Unternehmensarchitektur wird eine spezielle Sprache, ArchiMate, verwendet. Diese Sprache ermöglicht es Ihnen, die wichtigsten Dinge in der Organisation eines Unternehmens aufzuschreiben – und die kleinen Details zu ignorieren.

Machen wir gleich einen Vorbehalt, dass wir in Archimete nur die Arbeitsorganisation für Büroplankton beschreiben können. In Architem können keine Objekte realer materieller Produktion beschrieben werden, es werden nur Informationen zu diesen Objekten beschrieben. Kein Kartoffelkochen, kein Schweinetransport von Maschine zu Maschine – darüber nur und ausschließlich Informationen. Archimate ist ideal für Banken und Versicherungen, Zentralen (von denen aus keine echten Werkstätten sichtbar sind), Konstruktionsbüros (wo schwere Balken nur in Computermodellen und Papierausdrucken zu finden sind) und sogar für Bauzentralen (wo sie mit der Erteilung von Anweisungen und der Buchhaltung befasst sind). was getan wurde, aber sie selbst tun nichts mit ihren Händen). Aber diejenigen Teile des Unternehmens, die das Anziehen von Muttern nicht berücksichtigen, sondern die rostigen Muttern nach Erhalt aus dem Lager tatsächlich anziehen, können von Archimate nicht beschrieben werden. Aber bitte stellen Sie die Lagerbuchhaltung bzw. die Gestaltung und Abrechnung der Arbeiten dar.

Ein Architekt ist derjenige, der eine Architektur entwirft, die ihre Ziele erreicht und die alle interessierten Parteien und alle Beteiligten zufriedenstellt. Er entwickelt diese Architektur, beschreibt sie in Form von Archimate-Diagrammen und stimmt sie mit verschiedenen wichtigen Personen ab. Der Moment der Beschreibung der Architektur auf Archimete ist unwichtig. Diejenigen, die einfach nach dem Diktat in Archimeite (Spanisch, Suaheli) schreiben, können nicht als Architekten bezeichnet werden, sie sind nur Schreiber (Schriftgelehrte). Okay, Erzschreiber (Erzschreiber). Architekten sind diejenigen, die herausfinden, was sie über die Organisation aufschreiben sollen, und nicht, wie sie es im Architem mit raffinierten Symbolen ausdrücken.

Für viele Leute, die als Architekten ernannt wurden (insbesondere für diejenigen, die „von Programmierern“ oder „von Systemadministratoren“ kamen), erweist es sich als völlige Überraschung, dass der unvermeidliche Übergang von der Darstellung der Ergebnisse verschiedener Interviews zu Archimet als „Architekturbeschreibung“ erfolgt „as is“ bis hin zum Verfassen einer „Architekturbeschreibung zur Architektur“ und unmittelbar anschließender enger Kommunikation mit dem Management hinsichtlich der Transformation der neu erstellten Archimate-Diagramme in die organisatorische Realität des Unternehmens. Ein Archmate hilft Ihnen in Ihrem Geschäft nicht mehr als eine Rechtschreibprüfung, und die Fähigkeit, mit Word-Stilen umzugehen, wird Ihnen helfen, den Nobelpreis für Literatur zu gewinnen.

Du wurdest gewarnt.

2. Aktivitäten, Software, Hardware

Für Archimate ist die Anwesenheit von drei Personen das Wichtigste in einem Unternehmen Arbeitsebenen, bei denen das menschliche Element jeweils abnimmt: Aktivitäten, "Software" Und "Drüse". Aktivitäten ohne „Software“ sind archaisch und hilflos, „Software“ ohne „Hardware“ ist tot. Hardware ohne laufende Programme ist nutzlose Hardware, und Programme ohne deren Verwendung in menschlichen Aktivitäten sind für niemanden von Nutzen. Daher muss die Unternehmensarchitektur alle drei Arbeitsebenen in ihrer Wechselbeziehung abbilden.

Jede Ebene hat ihre eigene Darsteller der Arbeit, und deins Objekte funktioniert Tatsächlich besteht die Arbeit darin, dass die Darsteller die Arbeitsgegenstände irgendwie verändern. Künstler und Arbeitsgegenstände werden normalerweise durch Substantive dargestellt, Arbeit durch Verben und Verbalsubstantive. Wichtig ist, dass die Arbeitsgegenstände selbst nichts zu tun wissen, sie sind passiv. Aber die Performer sind aktiv, sie sind diejenigen, die an den Objekten arbeiten. „Jemand“ (der Ausführende der Arbeit) macht etwas (die Arbeit) mit etwas (dem Gegenstand der Arbeit).

Der Grad der Aktivität ist aussagekräftig. Die Menschen hinter den Informationen sehen die Objekte der umgebenden Welt, die diese Informationen darstellen. Sie schauen sich die Wettervorhersage an und sehen das Wetter von morgen (nicht die Beschreibung des Wetters, das sie gerade betrachten), schauen sich einen Baubericht an und sehen die Anzahl der tatsächlichen Stockwerke (nicht den tatsächlichen Bericht, den sie betrachten), schauen sich den Gewinn an und Verlustbericht und sie sehen genau diesen Gewinn (ohne darauf zu achten, ob dieser Bericht auf dem Bildschirm oder auf Papier erscheint). Menschen haben Interessen und Ziele, sie können Verantwortung übernehmen (sie müssen versprechen, bestimmte Anweisungen für andere auszuführen), sie haben Autorität (sie können anderen Personen Anweisungen zur Ausführung von Arbeiten erteilen). Nur auf dieser Ebene gibt es zielgerichtetes Handeln, das den Interessen und Zielen einiger menschlicher Stakeholder gerecht wird.

Die „Software“-Ebene ist die Verarbeitung der in den Daten enthaltenen Informationen. Aus einigen Daten erstellen Programme andere Daten, die sich sowohl im Format als auch im Inhalt unterscheiden. Niemand verspricht irgendjemandem etwas (Programme können nichts versprechen, nur Menschen können dies in ihren Aktivitäten tun) und gibt keine Anweisungen (nur Menschen können Anweisungen geben). Auf dieser Ebene weiß man, was die Daten in der realen Welt bedeuten: Schließlich ist es gefährlich, Kilometer zu Kilogramm zu addieren. Die Hauptaufgabe der Programmebene besteht darin, sicherzustellen, dass die auf die richtige Art und Weise zur richtigen Zeit verarbeiteten Daten die richtigen Verantwortlichen erreichen, die eine bestimmte Rolle im Unternehmen ausüben.

Die Hardware-Ebene ist eine seelenlose Welt, in der es keine Datenverarbeitung mehr gibt, sondern nur noch Datenspeicherung und -weiterleitung. Natürlich gibt es auf der Hardware-Ebene auch Programme (Systemsoftware), aber die sind von anderer Art – niemand weiß hier, was diese Daten in der realen Welt bedeuten. Die Aufgabe der Hardware besteht wie bei jedem Gerät darin, irgendwie adressierte Bytes zu speichern, ohne auf deren Bedeutung einzugehen, diese Bytes auf Anfrage von Anwendungsprogrammen zu versenden und außerdem die Programme selbst zu speichern und deren Ausführung zu ermöglichen.

3. Elemente und Beziehungen
Ein Unternehmen wird in Architem in Form von Elementen (dargestellt durch unterschiedliche Icons) beschrieben, die in irgendeiner Beziehung zueinander stehen (unterschiedliche Beziehungen werden in Form unterschiedlich gezeichneter Verbindungslinien zwischen Element-Icons dargestellt). Archimate ist wertvoll, weil es alles bietet, um die Arbeit eines Unternehmens zu beschreiben
-- 16 Arten von Elementen für das Aktivitätsniveau,
-- 7 Arten von Elementen für die Programmebene,
-- 9 Arten von Elementen pro Ausrüstungsstufe,
-- 11 Arten von Beziehungen, in denen Elemente miteinander stehen können, und Darstellung der Verzweigungen (vom Typ „und“ und „oder“) für diese Beziehungen.

Wenn Sie ein Unternehmen im wirklichen Leben irgendwie verändern möchten (warum sollten Sie sonst überhaupt anfangen, Archimate-Diagramme zu zeichnen, die seine Architektur widerspiegeln?), können Sie hierfür auch Folgendes verwenden:
-- 7 Arten von Elementen zur Zielsetzung und Begründung von Veränderungen in der Organisation
-- 4 Arten von Elementen zur Gestaltung des Übergangs zu einer neuen Architektur

Außerdem gibt es einen Kommentar und eine Beziehung zwischen dem Kommentar und einigen anderen Elementen sowie einen Rahmen zum Gruppieren von Elementen.

Das ist das gesamte Archimate, 54 Konzepte. Aber lassen Sie sich nicht von seiner Einfachheit täuschen. Auch „The Great and the Mighty“ hat nur 33 Buchstaben.

4. Es sind nicht Sie, die gebraucht werden, sondern Ihr Dienst, der gebraucht wird.

Es ist wichtig, dass im Unternehmen keine Arbeit ohne Grund verrichtet wird, sie werden alle aus irgendeinem Grund von jemandem benötigt. Dienstleistungen sind Werke, die für einige andere Künstler nützlich sind (genauer gesagt, nützlich für die Arbeit dieser Künstler), die „von außen“ eines Teils des Unternehmens sichtbar sind. Für die Konsumenten von Dienstleistungen ist es völlig unwichtig, wie die Umsetzung dieser Arbeit organisiert ist: Wer arbeitet mit was, um die Dienstleistung für den externen Konsum bereitzustellen. Für sie kommt es nur darauf an, über welche Kanäle (E-Mail, Fenster mit einem Mädchen, Telefonanruf usw.) diese Aktivität durchgeführt wurde und über welche Schnittstellen (sofern es sich um „Software“ handelt) diese Dienste bereitgestellt werden.

Es gibt Hardware-Dienste für Software und Software-Dienste für Aktivitäten. Durch diese Leistungen werden die drei Ebenen des Unternehmens zusammengehalten – von jeder Ebene sind nur die Leistungen der anderen Ebenen sichtbar. Sie können einfach nichts anderes als den Service anzeigen: Es sind die Services, die es Ihnen ermöglichen, von den Details der Unternehmensstruktur zu abstrahieren, es sind die Services, die einen systematischen Ansatz umsetzen und das gesamte System in Teile unterteilen. Moderne Architekturen sind serviceorientiert.

Diese Teile des Systems sind sowohl funktional (der Zweck des Dienstes besteht darin, eine Funktion in Bezug auf das System auszuführen, das ihn nutzt; Dienste sind das, wie die Arbeit „von außerhalb“ des Subsystems aussieht) als auch modular (d. h. austauschbar, wenn die Funktion bleibt erhalten). Sie können also die gesamte Hardware austauschen und die Software merkt es nicht, wenn die Hardware-Dienste gleich bleiben. Mit „Software“ ist es dasselbe: Ersetzen Sie alles, aber wenn die Softwaredienste gleich bleiben, wird die Aktivität es nicht bemerken – alle gleichen Softwarefunktionen werden in der Aktivität verfügbar sein. Dies gilt grundsätzlich auch für das Unternehmen selbst: wenn es sich um die organisatorischen Leistungen handelt, die das Unternehmen nach außen erbringt (und um die Kombination dieser organisatorischen Leistungen und des sie bindenden Service Level Agreements). organisatorisches Dienstleistungsprodukt) von einer völlig anders organisierten Tätigkeit durchgeführt wird, die eine völlig andere „Software“ verwendet, die wiederum auf einer völlig anderen Hardware läuft, dann werden die Kunden dies nicht bemerken. Dies machen sich Unternehmensarchitekten zunutze: Sie beschreiben das Unternehmen und ändern dann langsam Aktivitäten, Software und Hardware, um die Bereitstellung kritischer Dienste zu unterstützen. Dies wird als serviceorientierter Ansatz bezeichnet: Teilen (verschiedene Arbeitsebenen nach Diensten) und erobern. Unternehmen geklebt Dienstleistungen, und für den Architekten sind es diese Dienstleistungen geteilt.

Der Wunsch nach Teilen und Erobern ist unter Architekten so groß, dass sie Leistungen und Arbeiten auch auf gleicher Ebene teilen. Beispielsweise kann man sich leicht Programme vorstellen, die Dienste nicht für Menschen, sondern für andere Programme bereitstellen. Oder „Hardware“, deren Bedeutung darin besteht, anderen Geräten zu dienen (Dienstleistung zu erbringen, d. h. „für sie zu arbeiten“).

Bereitstellen äußerlich Sichtbare Arbeitsleistung muss von außen unsichtbar erfolgen intern Arbeit – Änderungen an Arbeitsobjekten durch Arbeitsausführende. Das Vorhandensein dieser Grenze zwischen interner und externer Betrachtung (eine „Black Box“ mit unsichtbaren internen Darstellern, Jobs und Objekten im Vergleich zu einer „transparenten Box“, wenn sie deutlich sichtbar sind) ist das Vorhandensein einer Grenze Systeme. Archmate-Modelle Systeme, Trennung von Teilen/Ebenen des Unternehmens durch Dienste (obwohl in der ArchiMate-Spezifikation kein Wort explizit über „Systeme“ gesagt wird, sondern nur Hinweise).