Enterprise-Architektur, die Zuständigkeiten klärt, bevor gebaut wird.
Unsere Beratung zur Enterprise-Architektur sorgt für eine Systemlandschaft mit klaren Entscheidungen.
Ob ServiceNow, SAP, Salesforce oder eine Landschaft, die über viele Projekte gewachsen ist: Ist diese Arbeit getan, wird jede spätere Entscheidung günstiger.
Was ist Enterprise-Architektur?
Enterprise-Architektur, auf Deutsch auch Unternehmensarchitektur, richtet Systeme, Daten und Fähigkeiten einer Organisation an der Geschäftsstrategie aus. Systeme, Daten und Fähigkeiten werden dabei als zusammenhängendes Ganzes betrachtet statt Projekt für Projekt. Maßgeblich ist, was das Unternehmen erreichen muss, nicht allein die IT-Architektur. Auf Basis standardisierter Frameworks wie TOGAF und IT4IT beantwortet die Disziplin vier Fragen.
Die Disziplin unterscheidet fünf Ebenen. Diese Einteilung hilft weiter, denn Probleme werden fast immer auf einer bestimmten Ebene sichtbar.
Geschäftsarchitektur
Hier geht es um die Fähigkeiten und Wertströme, die die Organisation braucht, unabhängig von jeder Software. Die Auftragsabwicklung ist eine Fähigkeit, das System, in dem sie läuft, dagegen nicht.
Enterprise-Architektur ist keine Lösungsarchitektur.
Die Lösungsarchitektur entwirft ein einzelnes System für klar umrissene Anforderungen. Die Enterprise-Architektur legt fest, wie die gesamte Systemlandschaft aussehen soll. Diese Entscheidungen müssen auch dann noch tragen, wenn in achtzehn Monaten ein neues Projekt beginnt. Deshalb ist die dokumentierte Begründung wichtiger als das Diagramm.
Und sie ist kein Prozessdesign.
Im Prozessdesign wird festgelegt, wie ein einzelner Arbeitsablauf funktionieren soll. Die Enterprise-Architektur bestimmt die Systemlandschaft, auf der diese Prozesse laufen.
Was bringt Ihnen die Arbeit an der Unternehmensarchitektur?
Die Arbeit an der Unternehmensarchitektur ersetzt wiederkehrende Diskussionen durch dokumentierte Entscheidungen: ein führendes System je Geschäftsobjekt, vereinbarte Grenzen zwischen den Anwendungen und eine verbindliche Zielarchitektur. Plattformentscheidungen werden belastbar, Schnittstellen lassen sich leichter spezifizieren, und neue Projekte beginnen mit einem Ergebnis statt mit einer Debatte.
Projekte starten mit einer Entscheidung, nicht mit einer Diskussion
Weil Grenzen, Zuständigkeiten und die Zuordnung der Fähigkeiten dokumentiert sind, beginnt die Projektplanung dort, wo sie früher aufgehört hat.
Schnittstellen lassen sich günstiger spezifizieren und sicherer ändern
Welches Integrationsmuster passt, ergibt sich daraus, wie jedes System klassifiziert ist. Jede Schnittstelle wird einmal entworfen, statt in jedem Projekt neu verhandelt zu werden.
Plattform- und Lizenzentscheidungen werden belastbar
Bevor ein Vertrag unterschrieben wird, ist geklärt, welche Fähigkeit in welchem System liegt. So kaufen Sie, was Ihre Landschaft braucht, und können es gegenüber der Geschäftsführung begründen.
Doppelungen werden sichtbar, Ablösungen möglich
Wird das Anwendungsportfolio den Fähigkeiten zugeordnet, zeigt sich, wo zwei Systeme dieselbe Aufgabe erfüllen. Damit ist der erste Schritt getan, um nur noch eines davon zu betreiben.
Ihre Daten sind bereit für KI und für Prüfungen
Ist für jedes Objekt klar geregelt, wer zuständig ist, arbeiten KI-Agenten und Prüfer mit dem richtigen Datensatz.
Veränderungen werden nicht ständig neu verhandelt
Zu jeder Entscheidung ist die Begründung dokumentiert. Ein neues Team baut darauf auf, statt die Diskussion neu aufzurollen.
Die Arbeit rechnet sich, wenn …
Konkrete Artefakte statt Folien voller Absichtserklärungen
Ihre Verantwortlichen aus Fachbereich und Technologie treffen die Entscheidungen gemeinsam, und jede wird mit ihrer Begründung dokumentiert: welche Fähigkeit in welchem System liegt, welches System für welches Geschäftsobjekt führend ist, wo die Grenzen verlaufen, was abgelöst wird und was gebaut werden muss. Wenn die Berater gehen, bleiben die Entscheidungen und ihre Begründung. Bei vertraglich vereinbarter Designarbeit sind genau diese Entscheidungen die Liefergegenstände, jeweils mit Abnahmekriterien.
Eine Fähigkeitslandkarte
Die Karte zeigt, welche Fähigkeiten Ihre Organisation braucht, wie sie zusammenhängen und welche davon die heutige Landschaft abdeckt. Auf ihr baut jeder spätere Business Case auf.
Ein Anwendungsportfolio
Jede Anwendung im vereinbarten Umfang wird den Fähigkeiten zugeordnet, die sie unterstützt. So werden Überschneidungen, Lücken und Kandidaten für eine Ablösung sichtbar, statt nur vermutet zu werden.
Ein Überblick über die Daten- und Informationsebene
Der Überblick zeigt, wie Informationen tatsächlich zwischen den Systemen fließen und welches System für welches Objekt führend ist. Hier beginnt die Portfoliooptimierung, denn vereinfachen lässt sich nur, was sich nachverfolgen lässt.
Eine Identitäts- und Schlüsselstrategie
Festgelegt werden die Kennungen, auf denen die Landschaft aufbaut, etwa für Kunde, Kontakt, Produkt und Abonnement, und die Regeln, nach denen sie systemübergreifend abgeglichen werden.
Ein Diagramm, das sich auf keine Entscheidung zurückführen lässt, ist Dekoration.
Über welche Grenze streiten Ihre Projekte immer wieder? Bringen Sie sie mit, und wir zeigen Ihnen, wie sie aussieht, wenn sie entschieden, dokumentiert und eingehalten wird.
Die meisten Systemlandschaften wurden nie entworfen. Sie sind gewachsen.
Ein System kam mit einem Projekt, ein zweites mit einer Akquisition und ein drittes, weil ein Team schnell eine Lösung brauchte. Für sich genommen war jede dieser Entscheidungen vernünftig. In der Summe entsteht aber eine Landschaft, in der zwei Systeme denselben Kunden führen, niemand weiß, welcher Datensatz stimmt, und jede neue Anforderung mit einem Streit beginnt. Dabei zeigen sich fast immer vier Muster.
Die Fähigkeiten sind nicht am Bedarf des Unternehmens ausgerichtet
Niemand weiß, welche Fähigkeiten die Landschaft heute abdeckt und wo zwei Systeme dieselbe Fähigkeit bedienen. Deshalb beginnt jeder Business Case mit einer Bestandsaufnahme der Landschaft, für deren Aufbau Sie längst bezahlt haben.
Anwendungen sind verbunden, nicht integriert
Jedes Projekt bringt eigene Schnittstellen mit, ein gemeinsames Integrationsmuster fehlt. Synchronisiert werden Daten, für die kein System eindeutig zuständig ist. Deshalb muss ständig abgeglichen werden, und jede neue Schnittstelle kostet mehr als die vorherige.
Niemand verantwortet eine Anwendung durchgängig
Es gibt Diagramme und viele Zuständige, aber keinen Anwendungsverantwortlichen, der die Artefakte aktuell hält und darauf achtet, dass die Anwendung wie vorgesehen genutzt wird. Weil niemand über die Entscheidungen wacht, werden sie immer wieder neu getroffen.
Die Plattformentscheidung fällt in der falschen Reihenfolge
Zuerst fällt die Wahl auf ein Produkt, danach wird die Landschaft daran angepasst. Welche Fähigkeit in welches System gehört, wird erst nach der Lizenzunterschrift geklärt. Das ist die teuerste aller möglichen Reihenfolgen.
Streiten Sie in jedem Projekt über dieselbe Grenze?
Wir entscheiden sie einmal gemeinsam mit Ihnen und halten sie schriftlich fest.
Was ist Enterprise-Architektur-Management, und wann brauchen Sie es?
Was ist es?
Als laufende Steuerungsaufgabe sorgt Enterprise-Architektur-Management (EAM) dafür, dass die IT-Landschaft die Geschäftsstrategie messbar und effizient unterstützt. Die Enterprise-Architektur ist der Bauplan mit Konzept und Zielbild. EAM setzt ihn im Tagesgeschäft durch, steuert ihn finanziell und hält ihn lebendig.
Was leistet es?
EAM verankert den Übergang von der Strategie zur Umsetzung im operativen Alltag und gibt den Rahmen vor, in dem die Lösungsarchitektur dezentral und schnell eigene Lösungen entwickeln kann. Die Organisation als Ganzes gerät dabei nicht ins Chaos.
Die Unterscheidung, die wirtschaftlich zählt:
Viele Organisationen investieren in EAM-Software, Gremien und gepflegte Repositories, bevor die eigentliche Designarbeit getan ist. Dann verwalten sie den Bestand, statt auf den Sollzustand hinzusteuern: Die Prozesse sind gesteuert, die steuernden Entscheidungen fehlen. Es kommt auf die Reihenfolge an. Zuerst gestalten Fachbereich und Technologie gemeinsam das Zielbild, danach wird der Weg dorthin gesteuert.
Ein offenes Wort zur Software.
Spezialisierte Plattformen wie ServiceNow Enterprise Architecture bieten viel: strukturierte Repositories, die Abbildung von Fähigkeiten, die Visualisierung von Abhängigkeiten und ein Lebenszyklusmanagement. Viele Organisationen steuern auf dieser Plattform bereits ihren IT-Betrieb. Eine Software löst jedoch Probleme der Dokumentation und Steuerung, keine Entscheidungsprobleme. Unser Rat: Etablieren Sie zuerst die Disziplin. Läuft ServiceNow bereits in Ihrer Landschaft, ist das ein guter Ausgangspunkt, denn die Plattform reicht für die ersten Reifestufen von EAM aus. Investieren Sie aber in die Designarbeit, bevor Sie in die Plattform investieren, die deren Ergebnisse aufnehmen soll.
EAM ohne Enterprise-Architektur ist Verwaltung.
Enterprise-Architektur ohne EAM ist ein Whiteboard, das verblasst.
Hinter komplexen Integrationen steckt meist eine offene Zuständigkeitsfrage, in Code gegossen.
Jede Anwendung in einer Systemlandschaft hat eine von drei Rollen. Aus dieser Rolle ergibt sich das Integrationsmuster, nicht umgekehrt. Ist die Klassifizierung richtig, werden Schnittstellen spezifiziert statt verhandelt.
Führendes System
Widersprechen sich Systeme, gilt die Version eines Geschäftsobjekts aus diesem System als richtig.
Finanzsystem für Rechnungen · Produktstamm für Preise · Identity Provider für Identitäten
Interaktionssystem
Portale, mobile Apps und Service Desks: Hier arbeiten Mitarbeiter und Kunden. Solche Systeme ändern sich schnell, erhalten häufig neue Releases und dürfen nicht eng an die führenden Systeme gekoppelt sein.
Die Interaktionsebene entwickelt sich weiter, das führende System bleibt stabil: Dafür sorgen Abstraktionsschichten wie API-Gateways oder Integrationsplattformen.
Analysesystem
Das Analysesystem bezieht Daten aus beiden anderen Systemarten, meist asynchron und in großem Volumen, und erzeugt daraus Analysen, Prognosen oder operative Erkenntnisse.
Es liest und wertet aus, ist aber nicht führend.
Strikte, synchrone Operationen und gesteuerte Schreibrechte.
Tempo und lose Kopplung.
Durchsatz und Toleranz für Latenz.
Der Begriff „Single Source of Truth“ unterstellt, dass ein System alle Daten führt. Als Design ist das fast nie sinnvoll.
Präziser ist der Begriff „führendes System“. Die Matrix der führenden Systeme gehört zu unseren standardisierten Liefergegenständen, denn auf ihr baut jede weitere Integrationsentscheidung auf.
Aus der Klassifizierung folgt das Integrationsmuster. Werden Systeme falsch herum verbunden, wirkt die entstehende Komplexität technisch, ist in Wahrheit aber eine offene Zuständigkeitsfrage, in Code gegossen.
Verwandt: ServiceNow Integrations.
Negative Abgrenzungen verhindern mehr Arbeit, als positive Abgrenzungen schaffen.
Die meisten Architekturdokumente beschreiben, was ein System tut. Nur wenige legen fest, wofür es ausdrücklich nicht zuständig ist. Genau dort entstehen aber die teuren Unklarheiten. Wir halten negative Abgrenzungen deshalb als standardisierte Artefakte fest. Diese haben dasselbe Gewicht wie die Zuordnung von Fähigkeiten oder die Festlegung führender Systeme: Wir dokumentieren und begründen sie und steuern sie über dasselbe Entscheidungsprotokoll.
Die Marketingplattform ist nicht für Pipeline-Steuerung, Angebotserstellung oder Auftragsabwicklung zuständig.
Wird ein solcher Satz als formale Architekturentscheidung samt Begründung festgehalten, beendet er mehr Integrationsdebatten als alle Beschreibungen dessen, was ein System leisten soll.
Für Event-Brokering in großem Volumen, den digitalen Zwilling oder ein natives EDI-Gateway ist ServiceNow nicht der richtige Ort. Wir dokumentieren das und halten ebenso fest, wann der bestehende Enterprise Service Bus, die Datenplattform und das EDI-Gateway genau dort bleiben sollten, wo sie sind.
Eine Workflow-Plattform ist ein System für die Ausführung von Abläufen und kein Ersatz für alle Systeme, mit denen sie verbunden ist. Diese Position ist bei uns ein eigener Liefergegenstand und keine Meinungsäußerung.
Der wertvollste Satz in einem Architekturdokument ist oft ein klares Nein.
Wer was sehen darf, ist Architektur, keine Konfiguration.
Zugriffsrechte gelten oft als Detail, das sich in der Bauphase klären lässt. Später verschieben sie dann den Go-live. Wir entwerfen das Zugriffsmodell stattdessen zusammen mit der Architektur: Least Privilege, Rollen statt namentlich benannter Personen, ein additives Rollenmodell und attributbasierte Zugriffe, wenn Gesellschaft, Region oder Zuweisungsgruppe einschränken, was jemand sieht. Auch das sind Architekturentscheidungen, und sie werden über dasselbe Entscheidungsprotokoll gesteuert wie alle anderen.
Geschäftsrollen
Die Rollen der Mitarbeiter, entworfen zusammen mit der Geschäftsarchitektur.
Durchsetzungsebene
Setzt die Rollen auf Tabellen-, Feld- und Datensatzebene durch.
Servicekonten
Über diese Konten greifen Integrationen zu. Servicekonten sind keine Personen und sollten nie die Rechte einer Person erben.
Alle Ergebnisse sind standardisierte Artefakte mit Begründung.
Wir sehen uns an, was Sie schon haben, bevor wir Ihnen mehr anbieten.
Ein großer Teil des Architekturbudgets fließt in einen zweiten Anlauf für Arbeit, die längst vorliegt, nur in einem Zustand, dem niemand vertraut hat. Bei Review-Aufträgen gehen wir deshalb bewusst in dieser Reihenfolge vor.
Vorhandene Prozessdokumentation, Backlog, Architekturentscheidungen und den aktuellen Stand der Plattform lesen
Unterscheiden, was unverändert wiederverwendbar ist, was nachgeschärft werden muss und wo eine echte Lücke besteht
Die noch offenen Entscheidungen auflisten
Den tatsächlich nötigen Aufwand schätzen
Gemeinsam mit Fachbereich und Technologie empfehlen, ob es überhaupt weitergehen soll
Soll es weitergehen, ordnen wir jede Anforderung einer von vier Kategorien zu. Die Kategorien unterscheiden sich in den Kosten stark, doch in den meisten Schätzungen verschwimmen die Grenzen. Jede Zuordnung halten wir als standardisiertes Artefakt mit Begründung fest, nicht als Zeile in einer Tabelle.
Bei Designarbeit dokumentieren wir das empfohlene führende System und die Integrationsgrenze samt Begründung. Dazu verpflichtet uns der Vertrag, auch wenn ein bestehendes System oder das Produkt eines anderen Anbieters für Sie die bessere Lösung ist.
Erfahrene Architekten, die direkt mit Ihnen arbeiten.
Wissen über Frameworks ist veröffentlicht und frei verfügbar. Darin liegt nicht der Wert. Er liegt darin, das Gespräch zwischen Fachbereich und Technologie zu moderieren, das den meisten Organisationen schwerfällt. Wir bringen die richtigen Menschen zusammen, strukturieren das Design über alle Ebenen hinweg und sorgen dafür, dass Entscheidungen getroffen statt vertagt werden.
Wer das Projekt plant, setzt es auch um
Es gibt keine Betreuungsebene dazwischen und keine Übergabe an ein Team, das Sie nie kennengelernt haben. Wer in Ihrem Workshop sitzt, arbeitet auch in Ihrem Projekt.
Erfahrene Spezialisten vom ersten Workshop bis zum Go-live
Unsere Gründer bringen jahrzehntelange Erfahrung in Plattform- und Geschäftsbetrieb mit. Genau sie erarbeiten das Design gemeinsam mit Ihnen, statt Folien zu präsentieren.
Wir implementieren, was wir entwerfen
Auf ServiceNow setzen wir die kaufmännischen Abläufe, den Kundenservice, Field Service und das Portfoliomanagement um. Wer nie selbst implementiert hat, entwirft Architekturen, die an bestimmten, vorhersehbaren Stellen zu optimistisch sind. In unsere Artefakte fließt ein, was sich in der Umsetzung bewährt hat.
Unsere Unabhängigkeit ist vertraglich festgehalten
Wo ein anderes Produkt die bessere Lösung ist, müssen wir das dokumentieren. Diese Pflicht steht im Vertrag, nicht in einem Leitbild.
Ob sich diese Faktoren vervielfachen oder nicht, entscheidet sich in der Architektur. Ist die Landschaft gemeinsam und passend zur Strategie gestaltet, macht sie jede spätere Entscheidung günstiger.
Sehen Sie, worauf Ihr nächstes Projekt aufbauen könnte.
Im ersten Gespräch geht es nicht um ein Angebot. Wir sehen uns Ihre aktuelle Dokumentation, Ihre offenen Entscheidungen und den Zustand Ihrer Systemlandschaft an. Danach sagen wir Ihnen, ob sich Designarbeit an der Unternehmensarchitektur lohnt oder ob eine günstigere Lösung Ihr eigentliches Problem behebt.
Die Fragen, die uns Entscheider stellen.
Was ist der Unterschied zwischen Enterprise-Architektur und Lösungsarchitektur?
›
Die Unterschiede liegen im Umfang, in der Lebensdauer und bei der Frage, wer am Tisch sitzt. Lösungsarchitektur ist klassisches IT-Lösungsdesign: ein System, klar umrissene Anforderungen, eine technische Lösung. Enterprise-Architektur dagegen ist gemeinsame Gestaltungsarbeit. Strategieverantwortliche, Fachexperten aus den Bereichen und Architekten entwerfen auf Basis standardisierter Frameworks zusammen die Fähigkeiten, Daten und Technologielandschaft der Organisation. Beides ist nötig. Gefährlich wird es, wenn sich viele gute Lösungsentscheidungen zu einer Landschaft summieren, die niemand bewusst gewählt hat.
Brauchen wir eine eigene Software für Enterprise-Architektur?
›
Vermutlich später, als die Anbieter es nahelegen. Plattformen wie ServiceNow Enterprise Architecture eignen sich gut, um ein Modell zu pflegen und Veränderungen zu steuern. Offene Entscheidungen nehmen sie Ihnen aber nicht ab. Weiß niemand, welches System für den Kundendatensatz führend ist, hält die Software diese Unklarheit nur fest, statt sie aufzulösen. Etablieren Sie zuerst die Designdisziplin, und lizenzieren Sie eine Plattform erst, wenn feststeht, was sie aufnehmen soll.
Ist jetzt der richtige Zeitpunkt für Enterprise-Architektur?
›
Nicht immer, und ob es so weit ist, sagen wir Ihnen im ersten Gespräch. Betreiben Sie nur wenige Anwendungen mit klaren Zuständigkeiten, lautet die ehrliche Antwort: noch nicht. Liegt das eigentliche Problem in einem einzelnen Prozess, den nie jemand gestaltet hat, ist Business Process Consulting and Design der günstigere Weg. Gibt es eine Zielarchitektur, aber niemand trifft Entscheidungen, fehlen klare Entscheidungsrechte. Dann ist Operating Model Design der richtige Ansatz. Ein Landschaftsmodell, an das sich kein Projekt halten muss, bewirkt nichts. Deshalb richten sich Ihre Projekte nach dem Modell, das wir mit Ihnen entwerfen.
Brauchen wir dafür TOGAF oder ArchiMate?
›
Ein formales Framework lohnt sich, wenn mehrere Personen dasselbe Modell über Jahre hinweg lesen müssen. Besteht das eigentliche Ergebnis aus vier Entscheidungen, ist es Ballast. Das Ebenenmodell von TOGAF setzen wir dort ein, wo es einen echten Nutzen bringt. Wo Fachbereich und Technologie gemeinsam diskutieren, arbeiten wir mit kollaborativen Designsprachen. Welchen Modellierungsstandard wir verwenden, legen wir zu Beginn gemeinsam mit Ihnen fest. Ein kleines Modell, das für Ihre Projekte verbindlich ist, ist uns lieber als ein vollständiges, das niemand nutzt.
Ist das Produkt Enterprise Architecture von ServiceNow dasselbe?
›
Nein. Enterprise Architecture ist bei ServiceNow ein Produkt, das das Architekturmanagement innerhalb der Plattform unterstützt. Unser Angebot ist dagegen Beratung: die Entscheidung, wie die Landschaft über alle Ihre Systeme hinweg aussehen soll, auch über die, die nicht auf ServiceNow laufen. Beides lässt sich verbinden, denn eine Entscheidung über die Landschaft muss anschließend irgendwo gepflegt werden. Läuft ServiceNow bereits bei Ihnen, ist die Plattform dafür ein starker Kandidat. Mit dem Kauf des Produkts allein sind aber noch keine Entscheidungen getroffen.
Wie verändert KI die Architekturentscheidung?
›
KI macht unklare Zuständigkeiten für Daten teurer. Handelt eine KI systemübergreifend, muss sie wissen, welcher Datensatz führend ist und was sie tun darf. Eine Unklarheit, um die ein Kollege einfach herumarbeitet, wird damit zum Governance-Problem. Wir gestalten die Architektur für ServiceNow und Claude gemeinsam: ServiceNow orchestriert den Workflow und verantwortet die Governance. Claude liefert die Intelligenz, die Informationen aus der gesamten Landschaft liest, abwägt und daraus Entwürfe erstellt. Die Architektur legt fest, wo welche Plattform handelt, auf welche Datensätze sie zugreifen darf und welchem führenden System sie verpflichtet ist. An den Fragen selbst ändert sich nichts. Allerdings werden sie früher gestellt, präziser beantwortet und über dieselben standardisierten Artefakte gesteuert wie jede andere Architekturentscheidung.